Topologia de rede e conectividade para o acelerador de zonas de destino do Azure Spring Apps

Este artigo descreve considerações de design e recomendações para a rede onde a carga de trabalho do Spring Boot é colocada. A estrutura de destino depende dos requisitos da carga de trabalho e dos requisitos de segurança e conformidade da sua organização.

A equipa centralizada da plataforma e a equipa de aplicações partilham a responsabilidade da área de design de rede. A equipa de plataforma seleciona a topologia de rede, que pode ser um modelo hub-spoke tradicional ou WAN Virtual topologia de rede (gerida pela Microsoft). A equipa de aplicações é responsável pelas escolhas de design da rede spoke. Espera-se que a carga de trabalho tenha dependências em serviços partilhados geridos pela plataforma. A equipa de aplicações tem de compreender as implicações dessas dependências e comunicar os seus requisitos para que os objetivos gerais da carga de trabalho sejam cumpridos.

Para obter mais informações sobre a estrutura da plataforma, veja Topologia de rede e conectividade.

Siga estas considerações e recomendações de design como melhores práticas para sub-redes, entradas e controlos de saída.

Considerações de design

• Isolamento. A equipa central pode fornecer uma rede virtual para a equipa da aplicação executar as respetivas cargas de trabalho. Se a carga de trabalho do Spring Boot tiver uma separação de preocupações de outras cargas de trabalho, considere aprovisionar a sua própria rede virtual para o runtime do serviço Spring App e a aplicação.

• Sub-rede. Considere a escalabilidade da aplicação quando escolher o tamanho da sub-rede e o número de aplicações.

  Se utilizar sub-redes existentes ou trazer as suas próprias tabelas de rotas, tenha políticas implementadas para garantir que as regras adicionadas pelo Azure Spring Apps não são atualizadas ou eliminadas.

  Outro aspeto é a segurança. Considere as regras que permitem ou negam o tráfego para a sub-rede.

• Tráfego de saída (saída). O tráfego proveniente da rede virtual tem de ser encaminhado através de Azure Firewall ou da aplicação virtual de rede (NVA).

  Considere as limitações do balanceador de carga incorporado fornecido pelo Azure Spring Apps. Com base nos seus requisitos, poderá ter de personalizar os caminhos de saída através do encaminhamento definido pelo utilizador (UDR), por exemplo, para encaminhar todo o tráfego através de uma NVA.

• Tráfego de entrada (entrada). Considere utilizar um proxy inverso para o tráfego que vai para o Azure Spring Apps. Com base nos seus requisitos, escolha opções nativas, como Gateway de Aplicação do Azure, Front Door ou serviços regionais, como Gestão de API (APIM). Se essas opções não corresponderem às necessidades da carga de trabalho, os serviços que não são do Azure podem ser considerados.

Recomendações de conceção

Estas recomendações fornecem orientações prescritivas para o conjunto de considerações anterior.

Rede virtual e sub-redes

• O Azure Spring Apps requer permissão de proprietário para a sua rede virtual. Esta função é necessária para conceder um principal de serviço dedicado e dinâmico para implementação e manutenção. Para obter mais informações, veja Implementar o Azure Spring Apps numa rede virtual.

• O Azure Spring Apps implementado numa rede privada fornece um nome de domínio completamente qualificado (FQDN) acessível apenas na rede privada. Crie uma zona DNS privada do Azure para o endereço IP da sua aplicação Spring. Ligue o DNS privado à sua rede virtual ao atribuir um FQDN privado no Azure Spring Apps. Para obter instruções passo a passo, consulte Aceder à sua aplicação numa rede privada.

• O Azure Spring Apps necessita de duas sub-redes dedicadas. Uma sub-rede tem o runtime do serviço e a outra sub-rede destina-se às aplicações spring boot.

  O tamanho mínimo do bloco CIDR de cada uma destas sub-redes é /28. A sub-rede runtime e a sub-rede da aplicação precisam de um espaço mínimo de endereços de /28. Mas o número de aplicações Spring que pode implementar influenciam o tamanho da sub-rede. Para obter informações sobre as instâncias máximas da aplicação por intervalo de sub-rede, veja Utilizar intervalos de sub-rede mais pequenos.

• Se utilizar Gateway de Aplicação do Azure como proxy inverso em frente ao Azure Spring Apps, precisa de outra sub-rede para essa instância. Para obter mais informações, veja Utilizar Gateway de Aplicação como proxy inverso.

• Utilize Grupos de Segurança de Rede (NSGs) em sub-redes para filtrar o tráfego este-oeste para restringir o tráfego à sub-rede do runtime do serviço.

• Os grupos de recursos e as sub-redes que a implementação do Azure Spring Apps gere não devem ser modificados.

Tráfego de saída

• Por predefinição, o Azure Spring Apps tem acesso à Internet de saída sem restrições. Utilize uma NVA, como Azure Firewall para filtrar o tráfego norte-sul. Tire partido das Azure Firewall na rede centralizada do hub para reduzir a sobrecarga de gestão.

  Nota

  O tráfego de saída para os componentes do Azure Spring é necessário para suportar as instâncias de serviço. Para obter informações sobre pontos finais e portas específicos, veja Requisitos de rede do Azure Spring Apps.

• O Azure Spring Apps fornece um tipo de saída de rota definida pelo utilizador (UDR) para controlar totalmente o caminho de tráfego de saída. OutboundType deve ser definido quando é criada uma nova instância de serviço do Azure Spring Apps. Não pode ser atualizado posteriormente. OutboundType só pode ser configurado com uma rede virtual. Para obter mais informações, veja Personalizar a saída do Azure Spring Apps com uma rota definida pelo utilizador.

• A aplicação tem de comunicar com outros serviços do Azure na solução. Utilize Azure Private Link para serviços suportados se as aplicações necessitarem de conectividade privada.

Tráfego de entrada

• Utilize um proxy inverso para garantir que os utilizadores maliciosos são impedidos de ignorar a firewall de aplicações Web (WAF) ou contornar os limites de limitação. Gateway de Aplicação do Azure com WAF integrado é recomendado.

  Se estiver a utilizar o escalão Enterprise, utilize o ponto final atribuído da aplicação Spring Cloud Gateway como o conjunto de back-end do Gateway de Aplicação. Este ponto final é resolvido para um endereço IP privado na sub-rede runtime do serviço Azure Spring Apps.

  Adicione um NSG na sub-rede do runtime do serviço que permite tráfego apenas a partir da sub-rede Gateway de Aplicação, sub-rede do Azure Spring Apps e Balanceador de Carga do Azure.

  Nota

  Pode escolher uma alternativa para o proxy inverso, como o Azure Front Door ou serviços que não são do Azure. Para obter informações sobre as opções de configuração, veja Expor o Azure Spring Apps através de um proxy inverso.

• O Azure Spring Apps pode ser implementado numa rede virtual através da injeção de VNet ou fora da rede. Para obter mais informações, veja Resumo da configuração.

Passos seguintes

Considerações de segurança para o acelerador de zonas de destino do Azure Spring Apps