Migrar e modernizar a abordagem de conceção de redes

Este guia fornece um percurso de leitura sequencial através do Azure Networking Design Guide para clientes que adotam serviços, contentores e bases de dados geridas como Plataforma como Serviço (PaaS). Siga os passos numerados para construir uma rede multirregional e com camadas de segurança que suporte arquiteturas de aplicações modernas.

Descrição geral

Os projetos de migração e modernização vão além das máquinas virtuais e passam para serviços nativos do Azure: Azure Kubernetes Service (AKS) para contentores, Serviço de Aplicações do Azure para aplicações Web, Base de Dados SQL do Azure e Azure Cosmos DB para dados geridos e Azure Front Door para distribuição global de tráfego. A sua rede deve suportar conectividade privada a estes serviços de PaaS, implementações multirregionais em modo ativo-ativo e uma segmentação de segurança rigorosa entre as camadas da aplicação.

A tua arquitetura alvo usa uma topologia de duplo hub que abrange duas regiões do Azure. O hub gerido por TI VNets aloja serviços partilhados como Azure Firewall e Gateway de VPN. As equipas de aplicação possuem os seus VNets spoke e controlam as suas próprias subredes Private Link para conectividade PaaS. O tráfego entra pelo Azure Front Door ou pelo Gestor de Tráfego do Azure, passa pela inspeção da firewall do hub e chega aos serviços aplicacionais em execução em spokes isolados.

Este percurso de leitura leva-o por 14 artigos essenciais em cinco fases. O processo é mais longo do que o “lift and shift”, porque as arquiteturas modernas exigem decisões sobre padrões de tráfego de entrada, conectividade privada ao PaaS, firewalls de aplicações Web e proteção contra DDoS, que as conceções exclusivamente de IaaS podem adiar. Dois pontos de controlo intermédios ajudam a identificar quando pode avançar diretamente se a sua carga de trabalho não precisar de todos os componentes.

Pré-requisitos

  • Leia o plano de redes do Azure e a visão geral do design para orientação sobre os serviços disponíveis.
  • Saiba quais os serviços PaaS a que as suas aplicações se destinam (AKS, App Service, SQL do Azure, Azure Cosmos DB ou outros).
  • Determine se a sua implementação abrange várias regiões do Azure (ativo-ativo ou ativo-passivo).
  • Identifique o seu padrão de entrada: a sua aplicação serve tráfego web público, tráfego de API móvel ou tráfego apenas interno?

O teu percurso de leitura

Fase 1: Fundações

1. Redes e sub-redes virtuais

Dimensione adequadamente as suas subredes para pools de nós AKS, subredes delegadas do Ambiente do Serviço de Aplicações (ASE) e subredes do Private Link. Quando utiliza o AKS Container Networking Interface (CNI) Overlay, os endereços IP dos pods provêm de um CIDR de sobreposição separado e não ocupam espaço na sub-rede da VNet. Apenas os IPs dos nós requerem endereços de sub-rede. Planeie o seu intervalo CIDR sobreposto para acomodar a escala dos pods e aloque sub-redes dedicadas para cada tipo de serviço.

2. Planeamento de endereços IP

Planeie a atribuição de endereços IP em duas regiões para uma implementação em modo ativo-ativo. As suas regiões primárias e de backup precisam de espaços de endereçamento não sobrepostos que suportem peering VNet e replicação entre regiões. Atribua intervalos suficientemente grandes para permitir futuras adições de spokes.

3. Grupos de segurança de rede e grupos de segurança de aplicações

Projete uma segmentação rigorosa para que apenas o tráfego do balanceador de carga chegue às subredes da aplicação. Bloqueie o acesso direto à internet aos níveis de aplicação. Use Grupos de Segurança de Aplicações (ASGs) para aplicar regras baseadas no papel da carga de trabalho em vez de endereços IP individuais.

Fase 2: Topologia

4. Topologia hub-and-spoke

Implemente uma topologia de duplo hub para multirregião. A subscrição de TI é proprietária de ambas as VNets de hub e gere serviços partilhados, como o Azure Firewall, o Gateway de VPN e os reencaminhadores de DNS. As equipas de aplicações possuem os seus VNets spoke e gerem sub-redes Private Link, clusters AKS e recursos de aplicação dentro do espaço de endereçamento atribuído.

5. Redes multi-regionais

Projetar uma implementação ativa-ativa entre regiões primárias e de backup. Configure o emparelhamento de VNets entre regiões entre hubs, configure o encaminhamento por failover e preveja a falha de uma única região. Ambas as regiões processam o tráfego em simultâneo, com o Azure Front Door a distribuir os pedidos com base na latência e nas sondas de estado de funcionamento.

Note

Etapa: topologia concluída. A sua topologia com dois hubs e multirregião está implementada. Se a sua aplicação for apenas interna, sem endpoints com acesso à internet, pode avançar para o passo 9 (acesso à internet de saída) e continuar a partir daí.

O que saltar: Os passos 6–8 abrangem entrada na internet, entrega e desempenho de aplicações, e acesso privado PaaS. Saltar é seguro se a sua carga de trabalho não tiver endpoints públicos e não tiver requisitos de Private Link.

Importante: Mesmo aplicações apenas internas muitas vezes precisam do Private Link (passo 8) se se ligarem ao SQL do Azure, Armazenamento do Azure, Azure Key Vault ou outros serviços PaaS através de endpoints privados. Se a sua candidatura utilizar algum destes serviços, complete o passo 8 antes de saltar para o passo 9.

Artigos restantes: Seis artigos após saltar (passos 9–14), comparado com nove artigos sem saltar (passos 6–14).

Fase 3: Conectividade

6. Entrada na Internet

Os padrões de tráfego voltados para o cliente determinam a forma externa da sua arquitetura. Use o Azure Front Door para aplicações web que necessitem de balanceamento global de carga, cache e Firewall de Aplicações Web (WAF). Use o Gestor de Tráfego do Azure para aplicações móveis ou API onde o encaminhamento baseado em DNS com sondas de saúde seja suficiente.

7. Entrega e desempenho da candidatura

Escolha entre o Azure Front Door e o Gestor de Tráfego do Azure consoante o tipo de aplicação. As aplicações web beneficiam das capacidades da Camada 7 do Front Door: descarregamento de TLS, armazenamento em cache, encaminhamento baseado no URL e WAF integrado. Os backends móveis e de API utilizam o Traffic Manager para failover ao nível de DNS, com menor sobrecarga.

8. Acesso privado PaaS

Crie sub-redes do Private Link em cada VNet spoke para conectividade a serviços PaaS. As equipas de aplicações gerem os seus próprios endpoints privados: o AKS extrai imagens de contentores através do Private Link, as aplicações web ligam-se ao SQL do Azure sobre endpoints privados, e nenhum tráfego PaaS atravessa a internet pública. Dedique uma sub-rede por spoke para recursos de Private Link.

Note

Marco: conectividade concluída. A sua conetividade de entrada e a conetividade PaaS privada estão configuradas.

Passos restantes: Tráfego de saída (passo 9), Azure Firewall (passo 10), Firewall de Aplicações Web (passo 11), proteção DDoS (passo 12), segurança DNS (passo 13) e monitorização de rede (passo 14), perfazendo um total de 6 artigos.

Essencial para todas as implementações: Os passos 9–10 (tráfego de saída e Azure Firewall) aplicam-se a todas as implementações de modernização. O firewall do seu hub controla todo o tráfego de saída e fornece inspeção centralizada, independentemente de a sua carga de trabalho ser pública ou apenas interna.

Apenas endpoints públicos: Os passos 11–12 (proteção contra WAF e DDoS) aplicam-se apenas se a sua aplicação expor endpoints públicos através do Azure Front Door, Application Gateway ou um Balanceador de Carga público. Cargas de trabalho apenas internas podem saltar estes dois artigos e avançar para o passo 13 (segurança DNS).

9. Acesso de saída à Internet

Encaminhe todo o tráfego de saída das redes spoke para o firewall do hub, utilizando rotas definidas pelo utilizador (UDRs). O firewall do hub atua como ponto de Tradução de Endereços de Rede de Origem (SNAT) para todas as saídas. O TI gere as regras do firewall de forma centralizada, para que as equipas de aplicações não consigam contornar os controlos de saída.

Fase 4: Segurança

10. Azure Firewall

Configure o Azure Firewall em ambas as VNets de hub como ponto de SNAT e de Tradução de Endereços de Rede de Destino (DNAT). Todo o tráfego de entrada passa pelo firewall antes de chegar ao nível de aplicação. Utilize políticas de firewall para controlar o tráfego este-oeste entre spokes e o tráfego norte-sul com a Internet.

11. Firewall de Aplicações Web

Implemente o WAF no Azure Front Door ou Gateway de Aplicação do Azure para as suas aplicações web. O WAF protege contra as 10 principais ameaças do Open Web Application Security Project (OWASP), injeção SQL, cross-site scripting (XSS) e outros ataques ao nível da camada HTTP. Use conjuntos de regras geridos e adicione regras personalizadas para os padrões específicos da sua aplicação.

12. Proteção DDoS

Ative a Proteção DDoS do Azure para todos os recursos públicos de IP. A Proteção DDoS oferece monitorização de tráfego sempre ativa, mitigação automática de ataques e garantias de proteção de custos. Combine a proteção contra DDoS com o WAF para uma defesa em camadas contra ataques volumétricos e ataques à camada de aplicação.

13. Segurança DNS e resolução privada de nomes

Configure zonas DNS públicas para os seus domínios voltados para o cliente com registos CNAME apontados para os endpoints do Azure Front Door ou Traffic Manager. Aplicar Role-Based Controlo de Acesso (RBAC) às zonas DNS para que apenas equipas autorizadas possam modificar registos. Ative as Extensões de Segurança DNS (DNSSEC) para zonas que requerem validação criptográfica.

Fase 5: Operações

14. Monitorização e observabilidade da rede

A prontidão para a produção requer monitorização desde o primeiro dia. Ative o Observador de Rede do Azure para diagnósticos de conectividade, o Network Performance Monitor para rastreio de latência e os registos de fluxo para análise de tráfego. As equipas de aplicações monitorizam as suas próprias cargas de trabalho AKS e ASE. A equipa da plataforma monitoriza a infraestrutura central e a conectividade entre regiões.

Artigos condicionais

Inclua estes artigos com base nas suas necessidades específicas:

Condição Artigo Quando incluir
Coexistência híbrida Conectividade híbrida As suas aplicações modernizadas devem coexistir com sistemas on-premises durante o período de transição
É necessário acesso de administrador de VM Acesso para programadores e administradores A sua infraestrutura inclui VMs que necessitam de acesso RDP/SSH seguro, a par de cargas de trabalho PaaS
Grande propriedade governada Gestão centralizada da rede Geres uma infraestrutura de VNets com várias subscrições e várias equipas que necessita de imposição centralizada de políticas
Cross-cloud Conectividade entre regiões e multicloud A sua arquitetura requer conectividade privada explícita entre regiões para além do que a rede multirregional oferece
Carga de trabalho muito pequena Topologia da rede plana Tens uma única carga de trabalho que não justifica a complexidade da topologia de hub-and-spoke

Resumo

Ao seguir este percurso de leitura, desenhou uma arquitetura de rede multirregião com múltiplas camadas de segurança para cargas de trabalho PaaS. O seu design inclui topologia de hub duplo com serviços partilhados geridos pela TI, arquitetura multirregional ativo-ativo com Azure Front Door ou Gestor de Tráfego do Azure, conectividade Private Link para serviços PaaS, inspeção centralizada da firewall para todos os fluxos de tráfego, proteção WAF e DDoS para pontos finais públicos e DNS com RBAC e DNSSEC. Esta arquitetura suporta padrões de aplicação modernos, mantendo uma governação centralizada de segurança.

Lista de verificação de validação

Use esta lista de verificação para confirmar que o seu design de rede de modernização está concluído:

  • Topologia de duplo hub implementada em regiões primárias e de backup.
  • Espaços de endereços sem sobreposição alocados para ambas as regiões e para spokes futuros.
  • Azure Front Door ou Gestor de Tráfego do Azure configurados para entrada global, se a sua carga de trabalho for pública.
  • Subredes Private Link provisionadas em cada VNet spoke que alojam dependências PaaS.
  • As rotas definidas pelo utilizador encaminham o tráfego de saída do spoke através da firewall do hub.
  • O Azure Firewall foi implementado em ambas as redes virtuais hub para inspeção do tráfego de entrada, leste-oeste e de saída.
  • Políticas WAF aplicadas a endpoints web públicos, se aplicável.
  • Proteção DDoS ativada em recursos IP públicos, se aplicável.
  • Zonas DNS e resolução DNS privada configuradas para endpoints privados.
  • Observador de Rede, registos de fluxo e monitorização de conectividade entre regiões ativados.

Passos seguintes

  • Last updated on