Migre e modernize a arquitetura de rede

Este guia fornece um caminho de leitura sequenciado por meio do Guia de Design de Rede Azure para clientes que adotam serviços, contêineres e bancos de dados gerenciados da Plataforma como Serviço (PaaS). Siga as etapas numeradas para criar uma rede em camadas de segurança de várias regiões que dá suporte a arquiteturas de aplicativos modernas.

Overview

Migrar e modernizar projetos vão além das máquinas virtuais para serviços nativos de Azure: AKS (Serviço de Kubernetes do Azure) para contêineres, Serviço de Aplicativo do Azure para aplicativos Web, Banco de Dados SQL do Azure e Azure Cosmos DB para dados gerenciados e Azure Front Door para distribuição de tráfego global. Sua rede deve suportar conectividade privada com esses serviços PaaS, implantações multirregionais no modelo ativo-ativo e segmentação de segurança rigorosa entre as camadas da aplicação.

Sua arquitetura de destino usa uma topologia de hub duplo que abrange duas regiões Azure. As VNets do hub gerenciado por TI hospedam serviços compartilhados como Firewall do Azure e Gateway de VPN. As equipes de aplicativos são proprietárias de suas VNets spoke e controlam suas próprias sub-redes de Link Privado para conectividade PaaS. O tráfego entra por meio do Azure Front Door ou do Gerenciador de Tráfego do Azure, passa pela inspeção do firewall do hub e chega aos serviços de aplicação executados em spokes isolados.

Este caminho de leitura leva você a 14 artigos essenciais em cinco fases. O caminho é mais longo do que a migração direta (lift and shift) porque as arquiteturas modernas exigem decisões sobre padrões de entrada, conectividade PaaS privada, firewalls de aplicativos da Web e proteção contra DDoS que os designs somente IaaS podem adiar. Dois pontos de verificação importantes ajudam a identificar quando você pode avançar se sua carga de trabalho não precisar de todos os componentes.

Pré-requisitos

  • Leia o plano de rede Azure e a visão geral do design para orientação sobre os serviços disponíveis.
  • Saiba quais serviços de PaaS seus aplicativos visam (AKS, App Service, SQL do Azure, Azure Cosmos DB ou outros).
  • Determine se sua implantação abrange várias regiões de Azure (ativo-ativo ou ativo-passivo).
  • Identifique seu padrão de entrada: seu aplicativo atende ao tráfego da Web público, ao tráfego de API móvel ou ao tráfego somente interno?

Seu caminho de leitura

Fase 1: Fundações

1. Redes virtuais e sub-redes

Dimensione suas sub-redes para pools de nós do AKS, sub-redes delegadas do Ambiente de Serviço de Aplicativo (ASE) e sub-redes de Link Privado. Ao usar a sobreposição da Interface de Rede de Contêiner (CNI) do AKS, os endereços IP dos pods vêm de um CIDR de sobreposição separado e não consomem espaço de sub-rede da VNet. Somente os IPs de nó exigem endereços de sub-rede. Planeje seu intervalo de CIDR de sobreposição para acomodar a escalabilidade dos pods e aloque sub-redes dedicadas para cada tipo de serviço.

2. Planejamento de endereço IP

Planeje a alocação de IP em duas regiões para uma implantação ativa-ativa. Suas regiões primárias e de backup precisam de espaços de endereço não sobrepostos que dão suporte ao emparelhamento VNet e à replicação entre regiões. Aloque intervalos suficientemente grandes para acomodar futuras adições de spokes.

3. Grupos de segurança de rede e grupos de segurança de aplicativos

Crie uma segmentação estrita para que apenas o tráfego do balanceador de carga atinja as sub-redes do aplicativo. Bloqueie o acesso direto da internet às camadas da aplicação. Use OSGs (Grupos de Segurança de Aplicativo) para aplicar regras com base na função de carga de trabalho em vez de endereços IP individuais.

Fase 2: Topologia

4. Topologia hub-and-spoke

Implantar uma topologia de hub duplo para várias regiões. A assinatura de TI é proprietária das duas VNets do hub e gerencia serviços compartilhados, como o Firewall do Azure, o Gateway de VPN e os encaminhadores de DNS. As equipes de aplicativos são proprietárias de suas VNets spoke e gerenciam sub-redes de Link Privado, clusters do AKS e recursos de aplicativos dentro de seu espaço de endereço alocado.

5. Rede de várias regiões

Projete uma implantação ativa-ativa entre regiões primárias e de backup. Configure o emparelhamento de VNet entre regiões entre os hubs, configure o roteamento de failover e planeje para falhas em uma única região. Ambas as regiões processam o tráfego simultaneamente, com o Azure Front Door distribuindo as solicitações com base na latência e nas sondas de integridade.

Note

Marco: topologia concluída. Sua topologia de dois hubs e multirregião está implementada. Se o aplicativo for somente interno sem pontos de extremidade voltados para a Internet, você poderá pular para a etapa 9 (acesso à Internet de saída) e continuar a partir daí.

O que você ignora: As etapas 6 a 8 abrangem entrada na Internet, entrega e desempenho de aplicativos e acesso privado de PaaS. Ignorar esta etapa é seguro se sua carga de trabalho não tiver pontos de extremidade voltados para o público e não exigir Link Privado.

Importante: Mesmo aplicativos somente internos geralmente precisam de Link Privado (etapa 8) se se conectarem a SQL do Azure, Armazenamento do Azure, Azure Key Vault ou outros serviços de PaaS em pontos de extremidade privados. Se o aplicativo usar qualquer um desses serviços, conclua a etapa 8 antes de pular para a etapa 9.

Artigos restantes: Seis artigos após pular (etapas 9–14), em comparação com nove artigos sem pular (etapas 6–14).

Fase 3: Conectividade

6. Entrada da Internet

Os padrões de tráfego voltados para o cliente determinam a forma externa de sua arquitetura. Use Azure Front Door para aplicativos Web que precisam de balanceamento de carga global, cache e WAF (Firewall de Aplicativo Web). Use o Gerenciador de Tráfego do Azure para aplicativos móveis ou APIs nos quais o roteamento baseado em DNS com sondas de integridade é suficiente.

7. Entrega e desempenho do aplicativo

Escolha entre Azure Front Door e Gerenciador de Tráfego do Azure com base no tipo de aplicativo. Os aplicativos Web se beneficiam dos recursos de Camada 7 do Front Door: descarregamento de TLS, cache, roteamento baseado em URL e WAF integrado. Back-ends de aplicativos móveis e APIs usam o Gerenciador de Tráfego para failover no nível de DNS com menor sobrecarga.

8. Acesso privado de PaaS

Crie sub-redes de Link Privado em cada VNet spoke para conectividade com o serviço PaaS. As equipes de aplicativos gerenciam seus próprios pontos de extremidade privados: o AKS puxa imagens de contêiner por Link Privado, os aplicativos Web se conectam a SQL do Azure em pontos de extremidade privados e nenhum tráfego de PaaS atravessa a Internet pública. Dedique uma sub-rede por spoke para recursos de Link Privado.

Note

Marco: conectividade concluída. Sua entrada e conectividade paaS privada estão configuradas.

Etapas restantes: Egresso de saída (etapa 9), Firewall do Azure (etapa 10), Firewall de Aplicativo Web (etapa 11), proteção contra DDoS (etapa 12), segurança de DNS (etapa 13) e monitoramento de rede (etapa 14), totalizando seis artigos.

Essencial para todas as implantações: as etapas de 9 a 10 (saída de tráfego e Firewall do Azure) se aplicam a todas as implantações de modernização. O firewall do hub controla todo o tráfego de saída e fornece inspeção centralizada, independentemente de sua carga de trabalho ser voltada para o público ou somente interna.

Somente pontos de extremidade públicos: As etapas 11 a 12 (proteção de WAF e DDoS) se aplicam somente se o aplicativo expõe pontos de extremidade voltados para o público por meio de Azure Front Door, Gateway de Aplicativo ou um Load Balancer público. As cargas de trabalho somente internas podem ignorar esses dois artigos e prosseguir para a etapa 13 (segurança DNS).

9. Acesso de saída à internet

Encaminhe todo o tráfego de saída do spoke para o firewall do hub usando UDRs (rotas definidas pelo usuário). O firewall do hub atua como o ponto de SNAT (Conversão de Endereços de Rede de Origem) para todo o tráfego de saída. A TI gerencia as regras de firewall centralmente, para que as equipes de aplicativos não possam ignorar os controles de saída.

Fase 4: Segurança

10. Firewall do Azure

Configure o Firewall do Azure em ambas as VNets do hub como ponto de SNAT e DNAT (Tradução de Endereço de Rede de Destino). Todo o tráfego de entrada passa pelo firewall antes de chegar à camada de aplicativo. Use políticas de firewall para controlar o tráfego leste-oeste entre os spokes e o tráfego norte-sul para a Internet.

11. Firewall de Aplicativo Web

Implante o WAF em Azure Front Door ou Gateway de Aplicativo do Azure para seus aplicativos Web. O WAF protege contra ameaças do OWASP Top 10, injeção de SQL, cross-site scripting e outros ataques na camada HTTP. Use conjuntos de regras gerenciadas e adicione regras personalizadas para os padrões específicos do aplicativo.

12. Proteção contra DDoS

Habilite Azure Proteção contra DDoS para todos os recursos de IP públicos. A Proteção contra DDoS fornece monitoramento contínuo de tráfego, mitigação automática de ataques e garantias de proteção contra custos. Combine a proteção contra DDoS ao WAF para uma defesa em camadas contra ataques volumétricos e ataques na camada de aplicação.

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

Configure zonas DNS públicas para seus domínios voltados para o cliente com registros CNAME apontando para pontos de extremidade do Azure Front Door ou do Gerenciador de Tráfego. Aplique Role-Based Controle de Acesso (RBAC) a zonas DNS para que somente equipes autorizadas possam modificar registros. Habilite as DNSSEC (Extensões de Segurança DNS) para zonas que exigem validação criptográfica.

Fase 5: Operações

14. Monitoramento e observabilidade de rede

A preparação para a produção requer monitoramento desde o primeiro dia. Habilite Observador de Rede do Azure para diagnóstico de conectividade, Monitor de Desempenho de rede para acompanhamento de latência e logs de fluxo para análise de tráfego. As equipes de aplicativos monitoram suas próprias cargas de trabalho do AKS e do ASE. A equipe de plataforma monitora a infraestrutura do hub e a conectividade entre regiões.

Artigos condicionais

Inclua estes artigos com base em seus requisitos específicos:

Condition Artigo Quando incluir
Coexistência híbrida Conectividade híbrida Seus aplicativos modernizados devem coexistir com sistemas locais durante o período de transição
Acesso de administrador de VM necessário Acesso de desenvolvedor e administrador Seu ambiente inclui VMs que precisam de acesso seguro por RDP/SSH, além de cargas de trabalho de PaaS.
Grande propriedade governada Gerenciamento de rede centralizado Você gerencia um ambiente de VNets com múltiplas assinaturas e equipes que precisa de aplicação centralizada de políticas
Multinuvem Conectividade entre regiões e multinuvem Sua arquitetura requer conectividade privada entre regiões explícita além do que a rede de várias regiões fornece
Carga de trabalho muito pequena Topologia de rede simples Você tem uma única carga de trabalho que não justifica a complexidade da topologia hub-and-spoke

Resumo

Seguindo este caminho de leitura, você projetou uma arquitetura de rede multiregião em camadas de segurança para cargas de trabalho de PaaS. Seu projeto inclui topologia de hub duplo com serviços compartilhados gerenciados pela TI, multirregião ativa-ativa com Azure Front Door ou Gerenciador de Tráfego do Azure, conectividade de Link Privado para serviços PaaS, inspeção centralizada de firewall para todos os fluxos de tráfego, WAF e proteção contra DDoS para pontos de extremidade públicos e DNS com RBAC e DNSSEC. Essa arquitetura dá suporte a padrões de aplicativo modernos, mantendo a governança de segurança centralizada.

Lista de verificação de validação

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

  • Topologia de hub duplo implantada em regiões primárias e de backup.
  • Espaços de endereço não sobrepostos alocados para ambas as regiões e futuros spokes.
  • Azure Front Door ou Gerenciador de Tráfego do Azure configurados para entrada global, caso sua carga de trabalho seja voltada para o público.
  • Sub-redes de Link Privado provisionadas em cada VNet spoke que hospeda dependências de PaaS.
  • As rotas definidas pelo usuário enviam o tráfego de saída da spoke pelo firewall do hub.
  • Firewall do Azure implantado em ambas as VNets hub para inspeção de entrada, leste-oeste e saída.
  • Políticas de WAF aplicadas a endpoints web públicos, se aplicável.
  • Proteção contra DDoS habilitada em recursos ip públicos, se aplicável.
  • Zonas DNS e resolução de DNS privada configuradas para pontos de extremidade privados.
  • Observador de Rede, logs de fluxo e monitoramento de conectividade entre regiões habilitados.

Próximas Etapas 

  • Last updated on