Rede e conectividade para cargas de trabalho de missão crítica no Azure

A rede é uma área fundamental para uma aplicação de missão crítica, dada a abordagem de design ativo-ativo distribuída globalmente recomendada.

Esta área de design explora vários tópicos de topologia de rede em nível de aplicativo, considerando a conectividade necessária e o gerenciamento de tráfego redundante. Mais especificamente, destaca considerações críticas e recomendações destinadas a informar o projeto de uma topologia de rede global segura e escalável para um aplicativo de missão crítica.

Importante

Este artigo faz parte da série de carga de trabalho de missão crítica do Azure Well-Architected. Se você não está familiarizado com esta série, recomendamos que comece com o que é uma carga de trabalho de missão crítica?

Roteamento de tráfego global

O uso de vários carimbos de implantação regionais ativos requer um serviço de roteamento global para distribuir o tráfego para cada carimbo ativo.

O Azure Front Door, o Azure Traffic Manager e o Azure Standard Load Balancer fornecem os recursos de roteamento necessários para gerenciar o tráfego global em um aplicativo de várias regiões.

Como alternativa, tecnologias de roteamento global de terceiros podem ser consideradas. Essas opções podem ser trocadas quase perfeitamente para substituir ou estender o uso de serviços de roteamento global nativos do Azure. As opções populares incluem tecnologias de roteamento por provedores de CDN.

Esta seção explora as principais diferenças dos serviços de roteamento do Azure para definir como cada um pode ser usado para otimizar diferentes cenários.

Considerações de design

• Um serviço de roteamento vinculado a uma única região representa um único ponto de falha e um risco significativo em relação a interrupções regionais.

• Se a carga de trabalho do aplicativo englobar o controle do cliente, como com aplicativos cliente móveis ou de desktop, é possível fornecer redundância de serviço dentro da lógica de roteamento do cliente.

  • Várias tecnologias de roteamento global, como o Azure Front Door e o Azure Traffic Manager, podem ser consideradas em paralelo para redundância, com clientes configurados para failover para uma tecnologia alternativa quando determinadas condições de falha são atendidas. A introdução de vários serviços de roteamento global introduz complexidades significativas em torno dos recursos de cache de borda e firewall de aplicativos Web, além do gerenciamento de certificados para descarregamento SSL e validação de aplicativos para caminhos de entrada.
  • Tecnologias de terceiros também podem ser consideradas, fornecendo resiliência de roteamento global para todos os níveis de falhas da plataforma Azure.

• A disparidade de capacidade entre o Azure Front Door e o Traffic Manager significa que, se as duas tecnologias estiverem posicionadas uma ao lado da outra para redundância, um caminho de entrada diferente ou alterações de design serão necessárias para garantir que um nível de serviço consistente e aceitável seja mantido.

• O Azure Front Door e o Azure Traffic Manager são serviços distribuídos globalmente com redundância e disponibilidade de várias regiões integradas.

  • Cenários hipotéticos de falha de uma escala grande o suficiente para ameaçar a disponibilidade global desses serviços de roteamento resilientes apresentam um risco mais amplo para o aplicativo em termos de falhas em cascata e correlacionadas.
    • Cenários de falha dessa escala só são causados de forma viável por serviços básicos compartilhados, como o DNS do Azure ou o Microsoft Entra ID, que servem como dependências de plataforma global para quase todos os serviços do Azure. Se uma tecnologia redundante do Azure for aplicada, é provável que o serviço secundário também esteja enfrentando indisponibilidade ou um serviço degradado.
    • É altamente provável que os cenários de falha do serviço de roteamento global afetem significativamente muitos outros serviços usados para componentes-chave de aplicativos por meio de dependências entre serviços. Mesmo que uma tecnologia de terceiros seja usada, o aplicativo provavelmente estará em um estado não íntegro devido ao impacto mais amplo do problema subjacente, o que significa que o roteamento para pontos de extremidade de aplicativo no Azure fornece pouco valor de qualquer maneira.

• A redundância do serviço de roteamento global fornece mitigação para um número extremamente pequeno de cenários hipotéticos de falha, onde o impacto de uma interrupção global é restrito ao próprio serviço de roteamento.

  Para fornecer redundância mais ampla para cenários de interrupção global, uma abordagem de implantação ativa-ativa multicloud pode ser considerada. Uma abordagem de implantação ativa-ativa multicloud introduz complexidades operacionais significativas, que representam riscos de resiliência significativos, provavelmente superando em muito os riscos hipotéticos de uma interrupção global.

• Para cenários em que o controle do cliente não é possível, uma dependência deve ser assumida em um único serviço de roteamento global para fornecer um ponto de entrada unificado para todas as regiões de implantação ativas.

  • Quando usados isoladamente, eles representam um único ponto de falha em um nível de serviço devido a dependências globais, mesmo que redundância e disponibilidade de várias regiões internas sejam fornecidas.
  • O SLA fornecido pelo serviço de roteamento global selecionado representa o SLO composto máximo alcançável, independentemente de quantas regiões de implantação são consideradas.

• Quando o controle do cliente não é possível, as mitigações operacionais podem ser consideradas para definir um processo de migração para um serviço de roteamento global secundário se uma interrupção global desativar o serviço principal. A migração de um serviço de roteamento global para outro normalmente é um processo demorado que dura várias horas, particularmente quando a propagação de DNS é considerada.

• Alguns serviços de roteamento global de terceiros fornecem um SLA de 100%. No entanto, o SLA histórico e alcançável fornecido por esses serviços é normalmente inferior a 100%.

  • Embora esses serviços forneçam reparações financeiras pela indisponibilidade, elas têm pouca importância quando o impacto da indisponibilidade é significativo, como em cenários críticos para a segurança em que a vida humana está, em última análise, em jogo. Portanto, a redundância tecnológica ou mitigações operacionais suficientes ainda devem ser consideradas, mesmo quando o SLA legal anunciado é de 100%.

Azure Front Door

• O Azure Front Door fornece balanceamento de carga HTTP/S global e conectividade otimizada usando o protocolo Anycast com TCP dividido para aproveitar a rede de backbone global da Microsoft.

  • Várias conexões são mantidas para cada um dos pontos de extremidade de back-end.
  • As solicitações de entrada do cliente são primeiro encerradas no nó de borda mais próximo do cliente de origem.
  • Após qualquer inspeção de tráfego necessária, as solicitações são encaminhadas pelo backbone da Microsoft para o back-end apropriado usando conexões existentes ou servidas a partir do cache interno de um nó de borda.
  • Essa abordagem é eficiente na distribuição de altos volumes de tráfego pelas conexões de back-end.

• Fornece um cache interno que serve conteúdo estático de nós de borda. Em muitos casos de uso, isso também pode eliminar a necessidade de uma Rede de Distribuição de Conteúdo (CDN) dedicada.

• O Azure Web Application Firewall (WAF) pode ser usado no Azure Front Door e, como é implantado em pontos de presença de rede do Azure em todo o mundo, todas as solicitações de entrada entregues pela Front Door são inspecionadas na borda da rede.

• O Azure Front Door protege os pontos de extremidade do aplicativo contra ataques DDoS usando a proteção contra DDoS do Azure Basic. O Azure DDoS Standard fornece recursos adicionais e mais avançados de proteção e deteção e pode ser adicionado como uma camada adicional ao Azure Front Door.

• O Azure Front Door oferece um serviço de certificado totalmente gerenciado. Permite a segurança da conexão TLS para pontos de extremidade sem a necessidade de gerenciar o ciclo de vida do certificado.

• O Azure Front Door Premium dá suporte a pontos de extremidade privados, permitindo que o tráfego flua da Internet diretamente para as redes virtuais do Azure. Isso eliminaria a necessidade de usar IPs públicos na VNet para tornar os back-ends acessíveis por meio do Azure Front Door Premium.

• O Azure Front Door depende de testes de integridade e URLs (pontos de extremidade) de integridade de back-end que são chamados em uma base de intervalo para retornar um código de status HTTP refletindo se o back-end está funcionando normalmente, com uma resposta HTTP 200 (OK) refletindo um status íntegro. Assim que um back-end refletir um status não íntegro, da perspetiva de um determinado nó de borda, esse nó de borda deixará de enviar solicitações para lá. Os backends insalubres são, portanto, transparentemente removidos da circulação de tráfego sem qualquer atraso.

• Suporta apenas protocolos HTTP/S.

• O WAF de porta frontal do Azure e o WAF do Gateway de Aplicativo fornecem um conjunto de recursos ligeiramente diferente, embora ambos ofereçam suporte a regras internas e personalizadas e possam ser definidos para operar no modo de deteção ou no modo de prevenção.

• O espaço IP de back-end da porta frontal pode mudar, mas a Microsoft garantirá a integração com intervalos de IP e tags de serviço do Azure. É possível subscrever Intervalos de IP e Etiquetas de Serviço do Azure para receber notificações sobre quaisquer alterações ou atualizações.

• O Azure Front Door suporta várias configurações de distribuição de carga:

  • Baseado em latência: a configuração padrão que roteia o tráfego para o back-end "mais próximo" do cliente; com base na latência da solicitação.
  • Baseado em prioridades: útil para configurações ativo-passivo, onde o tráfego deve sempre ser enviado para um back-end primário, a menos que não esteja disponível.
  • Ponderado: aplicável a implantações canárias em que uma determinada percentagem do tráfego é enviada para um back-end específico. Se vários back-ends tiverem os mesmos pesos atribuídos, o roteamento baseado em latência será usado.

• Por padrão, o Azure Front Door usa roteamento baseado em latência que pode levar a situações em que alguns back-ends recebem muito mais tráfego de entrada do que outros, dependendo de onde os clientes se originam.

• Se uma série de solicitações de cliente deve ser tratada pelo mesmo back-end, a Afinidade de Sessão pode ser configurada no front-end. Ele usa um cookie do lado do cliente para enviar solicitações subsequentes para o mesmo back-end da primeira solicitação, desde que o back-end ainda esteja disponível.

Gestor de Tráfego do Azure

• O Azure Traffic Manager é um serviço de redirecionamento de DNS.

  • A carga útil da solicitação real não é processada, mas o Gerenciador de Tráfego retorna o nome DNS de um dos back-ends do pool, com base em regras configuradas para o método de roteamento de tráfego selecionado.
  • O nome DNS de back-end é então resolvido para seu endereço IP final que é subsequentemente chamado diretamente pelo cliente.

• A resposta DNS é armazenada em cache e reutilizada pelo cliente por um período TTL (Time-To-Live) especificado, e as solicitações feitas durante esse período irão diretamente para o ponto de extremidade de back-end sem interação do Gerenciador de Tráfego. Elimina a etapa de conectividade extra que fornece benefícios de custo em comparação com a porta frontal.

• Como a solicitação é feita diretamente do cliente para o serviço de back-end, qualquer protocolo suportado pelo back-end pode ser aproveitado.

• Semelhante ao Azure Front Door, o Azure Traffic Manager também depende de testes de integridade para entender se um back-end está íntegro e funcionando normalmente. Se outro valor for retornado ou nada for retornado, o serviço de roteamento reconhecerá problemas contínuos e interromperá o roteamento de solicitações para esse back-end específico.

  • No entanto, ao contrário do Azure Front Door, essa remoção de back-ends não íntegros não é instantânea, pois os clientes continuarão a criar conexões com o back-end não íntegro até que o TTL DNS expire e um novo ponto de extremidade de back-end seja solicitado ao serviço Gerenciador de Tráfego.
  • Além disso, mesmo quando o TTL expira, não há garantia de que os servidores DNS públicos honrarão esse valor, então a propagação do DNS pode realmente levar muito mais tempo para ocorrer. Isso significa que o tráfego pode continuar a ser enviado para o ponto de extremidade não íntegro por um período de tempo sustentado.

Azure Standard Load Balancer

Importante

O balanceador de carga padrão entre regiões está disponível em versão prévia com limitações técnicas. Esta opção não é recomendada para cargas de trabalho de missão crítica.

Recomendações de design

• Use o Azure Front Door como o principal serviço de roteamento de tráfego global para cenários HTTP/S. O Azure Front Door é fortemente defendido para cargas de trabalho HTTP/S, pois fornece roteamento de tráfego otimizado, failover transparente, pontos de extremidade de back-end privados (com o SKU Premium), cache de borda e integração com o Web Application Firewall (WAF).

• Para cenários de aplicativo onde o controle do cliente é possível, aplique a lógica de roteamento do lado do cliente para considerar cenários de failover em que a tecnologia de roteamento global principal falha. Duas ou mais tecnologias de roteamento global devem ser posicionadas em paralelo para redundância adicional, se um SLA de serviço único não for suficiente. A lógica do cliente é necessária para rotear para a tecnologia redundante em caso de falha de serviço global.

  • Duas URLs distintas devem ser usadas, com uma aplicada a cada um dos diferentes serviços de roteamento global para simplificar a experiência geral de gerenciamento de certificados e a lógica de roteamento para um failover.
  • Priorize o uso de tecnologias de roteamento de terceiros como o serviço de failover secundário, pois isso mitigará o maior número de cenários de falha global e os recursos oferecidos pelos principais provedores de CDN do setor permitirão uma abordagem de projeto consistente.
  • Deve também ser considerada a possibilidade de encaminhar diretamente para um único carimbo regional em vez de para um serviço de encaminhamento separado. Embora isso resulte em um nível degradado de serviço, representa uma abordagem de design muito mais simples.

Esta imagem mostra uma configuração de balanceador de carga global redundante com failover de cliente usando o Azure Front Door como principal balanceador de carga global.

Importante

Para realmente mitigar o risco de falhas globais na plataforma Azure, uma abordagem de implantação ativa-ativa multicloud deve ser considerada, com carimbos de implantação ativos hospedados em dois ou mais provedores de nuvem e tecnologias de roteamento de terceiros redundantes usadas para roteamento global.

O Azure pode ser efetivamente integrado com outras plataformas de nuvem. No entanto, é altamente recomendável não aplicar uma abordagem multicloud porque ela introduz uma complexidade operacional significativa, com diferentes definições de carimbo de implantação e representações de integridade operacional nas diferentes plataformas de nuvem. Essa complexidade, por sua vez, introduz inúmeros riscos de resiliência dentro da operação normal do aplicativo, que superam em muito os riscos hipotéticos de uma interrupção global da plataforma.

• Embora não seja recomendado, para cargas de trabalho HTTP(s) que usam o Azure Traffic Manager para redundância de roteamento global para o Azure Front Door, considere descarregar o Web Application Firewall (WAF) para o Application Gateway para tráfego aceitável fluindo pela Porta da Frente do Azure.
  • Isso introduzirá um ponto de falha adicional para o caminho de entrada padrão, um componente de caminho crítico adicional para gerenciar e dimensionar, e também incorrerá em custos adicionais para garantir a alta disponibilidade global. No entanto, ele simplificará muito o cenário de falha, fornecendo consistência entre os caminhos de entrada aceitáveis e não aceitáveis por meio do Azure Front Door e do Azure Traffic Manager, tanto em termos de execução do WAF, mas também de pontos de extremidade de aplicativos privados.
  • A perda de cache de borda em um cenário de falha afetará o desempenho geral, e isso deve estar alinhado com um nível aceitável de serviço ou uma abordagem de design de mitigação. Para garantir um nível consistente de serviço, considere descarregar o cache de borda para um provedor de CDN de terceiros para ambos os caminhos.

É recomendável considerar um serviço de roteamento global de terceiros no lugar de dois serviços de roteamento global do Azure. Isso fornece o nível máximo de mitigação de falhas e uma abordagem de design mais simples, já que a maioria dos provedores de CDN líderes do setor oferece recursos de borda amplamente consistentes com os oferecidos pelo Azure Front Door.

Azure Front Door

• Use o serviço de certificado gerenciado do Azure Front Door para habilitar conexões TLS e remover a necessidade de gerenciar ciclos de vida de certificados.

• Use o WAF (Azure Front Door Web Application Firewall) para fornecer proteção na borda contra vulnerabilidades e explorações comuns da Web, como injeção de SQL.

• Use o cache interno do Azure Front Door para fornecer conteúdo estático de nós de borda.

  • Na maioria dos casos, isso também eliminará a necessidade de uma Rede de Distribuição de Conteúdo (CDN) dedicada.

• Configure os pontos de entrada da plataforma de aplicativos para validar solicitações de entrada por meio da filtragem baseada em cabeçalho usando o X-Azure-FDID para garantir que todo o tráfego esteja fluindo pela instância configurada da Front Door. Considere também configurar a ACL IP usando as Tags de Serviço da Front Door para validar o tráfego originado do espaço de endereço IP do back-end do Azure Front Door e dos serviços de infraestrutura do Azure. Isso garantirá que o tráfego flua pelo Azure Front Door em um nível de serviço, mas a filtragem baseada em cabeçalho ainda será necessária para garantir o uso de uma instância configurada do Front Door.

• Defina um ponto de extremidade de integridade TCP personalizado para validar dependências críticas downstream em um carimbo de implantação regional, incluindo réplicas de plataforma de dados, como o Azure Cosmos DB no exemplo fornecido pela implementação de referência fundamental. Se uma ou mais dependências se tornarem insalubres, a sonda de saúde deve refletir isso na resposta devolvida para que todo o carimbo regional possa ser retirado de circulação.

• Certifique-se de que as respostas da sonda de integridade sejam registradas e ingira todos os dados operacionais expostos pelo Azure Front Door no espaço de trabalho global do Log Analytics para facilitar um coletor de dados unificado e uma exibição operacional única em todo o aplicativo.

• A menos que a carga de trabalho seja extremamente sensível à latência, distribua o tráfego uniformemente por todos os carimbos regionais considerados para usar os recursos implantados com mais eficiência.

  • Para conseguir isso, defina o parâmetro "Latency Sensitivity (Additional Latency)" para um valor alto o suficiente para atender às diferenças de latência entre as diferentes regiões dos back-ends. Garanta uma tolerância aceitável para a carga de trabalho do aplicativo em relação à latência geral da solicitação do cliente.

• Não habilite o Session Affinity a menos que seja exigido pelo aplicativo, pois pode ter um impacto negativo no equilíbrio da distribuição de tráfego. Com um aplicativo totalmente sem monitoração de estado, se a abordagem de design de aplicativo de missão crítica recomendada for seguida, qualquer solicitação poderá ser tratada por qualquer uma das implantações regionais.

Gestor de Tráfego do Azure

• Use o Gerenciador de Tráfego para cenários não HTTP/S como um substituto para o Azure Front Door. As diferenças de capacidade conduzirão a diferentes decisões de design para recursos de cache e WAF e gerenciamento de certificados TLS.

• Os recursos do WAF devem ser considerados dentro de cada região para o caminho de entrada do Gerenciador de Tráfego, usando o Gateway de Aplicativo do Azure.

• Configure um valor de TTL adequadamente baixo para otimizar o tempo necessário para remover um ponto de extremidade de back-end não íntegro da circulação no caso de o back-end se tornar não íntegro.

• Semelhante ao Azure Front Door, um ponto de extremidade de integridade TCP personalizado deve ser definido para validar dependências críticas downstream dentro de um carimbo de implantação regional, que deve ser refletido na resposta fornecida pelos pontos de extremidade de integridade.

  No entanto, para o Traffic Manager, deve ser dada uma consideração adicional ao failover regional de nível de serviço. como 'legging de cão', para mitigar o atraso potencial associado à remoção de um back-end não íntegro devido a falhas de dependência, particularmente se não for possível definir um TTL baixo para registros DNS.

• Deve-se considerar os provedores de CDN de terceiros para obter o cache de borda ao usar o Gerenciador de Tráfego do Azure como um serviço de roteamento global primário. Quando os recursos WAF de borda também são oferecidos pelo serviço de terceiros, deve-se considerar simplificar o caminho de entrada e, potencialmente, remover a necessidade do Application Gateway.

Serviços de entrega de aplicativos

O caminho de entrada de rede para um aplicativo de missão crítica também deve considerar os serviços de entrega de aplicativos para garantir tráfego de entrada seguro, confiável e escalável.

Esta seção se baseia em recomendações de roteamento global explorando os principais recursos de entrega de aplicativos, considerando serviços relevantes, como o Balanceador de Carga Padrão do Azure, o Gateway de Aplicativo do Azure e o Gerenciamento de API do Azure.

Considerações de design

• A criptografia TLS é fundamental para garantir a integridade do tráfego de entrada de usuários para um aplicativo de missão crítica, com o descarregamento de TLS aplicado apenas no ponto de entrada de um selo para descriptografar o tráfego de entrada. Descarregamento de TLS Requer a chave privada do certificado TLS para desencriptar o tráfego.

• Um Web Application Firewall fornece proteção contra vulnerabilidades e exploits comuns da Web, como injeção de SQL ou scripts entre sites, e é essencial para alcançar as aspirações máximas de confiabilidade de um aplicativo de missão crítica.

• O WAF do Azure fornece proteção imediata contra as 10 principais vulnerabilidades do OWASP usando conjuntos de regras gerenciadas.

  • Regras personalizadas também podem ser adicionadas para estender o conjunto de regras gerenciadas.
  • O WAF do Azure pode ser habilitado no Azure Front Door, no Azure Application Gateway ou na CDN do Azure (atualmente em visualização pública).
    • As características oferecidas em cada um dos serviços diferem ligeiramente. Por exemplo, o WAF do Azure Front Door fornece limitação de taxa, filtragem geográfica e proteção de bot, que ainda não são oferecidos no WAF do Gateway de Aplicativo. No entanto, todos eles suportam regras internas e personalizadas e podem ser configurados para operar no modo de deteção ou modo de prevenção.
    • O roteiro para o WAF do Azure garantirá que um conjunto de recursos WAF consistente seja fornecido em todas as integrações de serviço.

• Tecnologias WAF de terceiros, como NVAs e controladores de entrada avançados no Kubernetes, também podem ser consideradas como fornecendo a proteção necessária contra vulnerabilidades.

• A configuração ideal do WAF normalmente requer ajuste fino, independentemente da tecnologia usada.

  Azure Front Door

• O Azure Front Door só aceita tráfego HTTP e HTTPS e só processará solicitações com um cabeçalho conhecido Host . Esse bloqueio de protocolo ajuda a mitigar ataques volumétricos espalhados por protocolos e portas, além de amplificação de DNS e ataques de envenenamento de TCP.

• O Azure Front Door é um recurso global do Azure, portanto, a configuração é implantada globalmente em todos os pontos de presença.

  • A configuração de recursos pode ser distribuída em grande escala para lidar com centenas de milhares de solicitações por segundo.
  • As atualizações de configuração, incluindo rotas e pools de back-end, são contínuas e não causarão nenhum tempo de inatividade durante a implantação.

• O Azure Front Door fornece um serviço de certificado totalmente gerenciado e um método traga seu próprio certificado para os certificados SSL voltados para o cliente. O serviço de certificado totalmente gerenciado fornece uma abordagem operacional simplificada e ajuda a reduzir a complexidade no projeto geral, executando o gerenciamento de certificados em uma única área da solução.

• O Azure Front Door gira automaticamente os certificados "Gerenciados" pelo menos 60 dias antes da expiração do certificado para proteger contra riscos de certificados expirados. Se forem usados certificados autogerenciados, os certificados atualizados devem ser implantados no máximo 24 horas antes da expiração do certificado existente, caso contrário, os clientes poderão receber erros de certificado expirado.

• As atualizações de certificado só resultarão em tempo de inatividade se o Azure Front Door for alternado entre "Gerenciado" e "Usar seu próprio certificado".

• O Azure Front Door é protegido pelo Azure DDoS Protection Basic, que é integrado ao Front Door por padrão. Isso fornece monitoramento de tráfego sempre ativo, mitigação em tempo real e também defende contra inundações comuns de consultas DNS da Camada 7 ou ataques volumétricos da Camada 3/4.

  • Essas proteções ajudam a manter a disponibilidade do Azure Front Door, mesmo quando confrontado com um ataque DDoS. Os ataques distribuídos de negação de serviço (DDoS) podem tornar um recurso direcionado indisponível, sobrecarregando-o com tráfego ilegítimo.

• O Azure Front Door também fornece recursos WAF em um nível de tráfego global, enquanto o WAF do Gateway de Aplicativo deve ser fornecido dentro de cada carimbo de implantação regional. Os recursos incluem conjuntos de regras de firewall para proteção contra ataques comuns, filtragem geográfica, bloqueio de endereços, limitação de taxa e correspondência de assinaturas.

  Balanceador de Carga do Azure

• O SKU do Balanceador de Carga Básico do Azure não é apoiado por um SLA e tem várias restrições de capacidade em comparação com o SKU Padrão.

Recomendações de design

• Execute o descarregamento TLS no menor número possível de lugares para manter a segurança e, ao mesmo tempo, simplificar o ciclo de vida do gerenciamento de certificados.

• Use conexões criptografadas (por exemplo, HTTPS) do ponto onde ocorre o descarregamento de TLS para os back-ends reais do aplicativo. Os pontos de extremidade do aplicativo não ficarão visíveis para os usuários finais, portanto, os domínios gerenciados pelo Azure, como azurewebsites.net ou cloudapp.net, podem ser usados com certificados gerenciados.

• Para tráfego HTTP(S), certifique-se de que os recursos WAF sejam aplicados dentro do caminho de entrada para todos os pontos de extremidade expostos publicamente.

• Habilite os recursos do WAF em um único local de serviço, globalmente com o Azure Front Door ou regionalmente com o Azure Application Gateway, pois isso simplifica o ajuste fino da configuração e otimiza o desempenho e o custo.

  Configure o WAF no modo de Prevenção para bloquear ataques diretamente. Use o WAF apenas no modo de Deteção (ou seja, apenas registrando, mas não bloqueando solicitações suspeitas) quando a penalidade de desempenho do modo de Prevenção for muito alta. O risco adicional implícito deve ser plenamente compreendido e alinhado com os requisitos específicos do cenário de carga de trabalho.

• Priorize o uso do Azure Front Door WAF, pois ele fornece o conjunto de recursos nativo do Azure mais rico e aplica proteções na borda global, o que simplifica o design geral e gera mais eficiência.

• Use o Gerenciamento de API do Azure somente ao expor um grande número de APIs para clientes externos ou equipes de aplicativos diferentes.

• Use o SKU do Balanceador de Carga Padrão do Azure para qualquer cenário de distribuição de tráfego interno em cargas de trabalho de micros-service.

  • Fornece um SLA de 99,99% quando implantado em zonas de disponibilidade.
  • Fornece recursos críticos, como diagnósticos ou regras de saída.

• Use a Proteção de Rede DDoS do Azure para ajudar a proteger pontos de extremidade públicos hospedados em cada rede virtual de aplicativo.

Armazenamento em cache e entrega de conteúdo estático

O tratamento especial de conteúdo estático como imagens, JavaScript, CSS e outros arquivos pode ter um impacto significativo na experiência geral do usuário, bem como no custo geral da solução. O armazenamento em cache de conteúdo estático na borda pode acelerar os tempos de carregamento do cliente, o que resulta em uma melhor experiência do usuário e também pode reduzir o custo de tráfego, operações de leitura e poder de computação nos serviços de back-end envolvidos.

Considerações de design

• Nem todo o conteúdo que uma solução disponibiliza através da Internet é gerado dinamicamente. Os aplicativos servem tanto ativos estáticos (imagens, JavaScript, CSS, arquivos de localização, etc.) quanto conteúdo dinâmico.
• As cargas de trabalho com conteúdo estático acessado com frequência se beneficiam muito do cache, pois ele reduz a carga nos serviços de back-end e reduz a latência de acesso ao conteúdo para os usuários finais.
• O cache pode ser implementado nativamente no Azure usando o Azure Front Door ou a CDN (Rede de Entrega de Conteúdo) do Azure.
  • O Azure Front Door fornece recursos de cache de borda nativos do Azure e recursos de roteamento para dividir conteúdo estático e dinâmico.
    • Ao criar as regras de roteamento apropriadas no Azure Front Door, /static/* o tráfego pode ser redirecionado de forma transparente para conteúdo estático.
  • Cenários de cache mais complexos podem ser implementados usando o serviço CDN do Azure para estabelecer uma rede de entrega de conteúdo completa para volumes significativos de conteúdo estático.
    • O serviço CDN do Azure provavelmente será mais econômico, mas não fornece os mesmos recursos avançados de roteamento e WAF (Web Application Firewall) recomendados para outras áreas de um design de aplicativo. No entanto, oferece mais flexibilidade para integrar com serviços semelhantes de soluções de terceiros, como a Akamai e a Verizon.
  • Ao comparar os serviços Azure Front Door e Azure CDN, os seguintes fatores de decisão devem ser explorados:
    • As regras de cache necessárias podem ser realizadas usando o mecanismo de regras.
    • Tamanho do conteúdo armazenado e o custo associado.
    • Preço por mês para a execução do mecanismo de regras (cobrado por solicitação no Azure Front Door).
    • Requisitos de tráfego de saída (o preço varia de acordo com o destino).

Recomendações de design

• Conteúdo estático gerado, como cópias dimensionadas de arquivos de imagem que nunca ou raramente mudam, também pode se beneficiar do cache. O cache pode ser configurado com base em parâmetros de URL e com duração variável do cache.
• Separe a entrega de conteúdo estático e dinâmico aos usuários e forneça conteúdo relevante de um cache para reduzir a carga nos serviços de back-end, otimize o desempenho para os usuários finais.
• Dada a forte recomendação (área de design de rede e conectividade ) de usar o Azure Front Door para fins de roteamento global e WAF (Web Application Firewall), é recomendável priorizar o uso dos recursos de cache do Azure Front Door, a menos que existam lacunas.

Integração da rede virtual

Um aplicativo de missão crítica normalmente engloba requisitos para integração com outros aplicativos ou sistemas dependentes, que podem ser hospedados no Azure, em outra nuvem pública ou em data centers locais. Essa integração de aplicativos pode ser realizada usando pontos de extremidade voltados para o público e a Internet, ou redes privadas por meio da integração no nível da rede. Em última análise, o método pelo qual a integração de aplicativos é alcançada terá um impacto significativo na segurança, desempenho e confiabilidade da solução, além de impactar fortemente as decisões de projeto em outras áreas de projeto.

Um aplicativo de missão crítica pode ser implantado em uma das três configurações de rede abrangentes, o que determina como a integração de aplicativos pode ocorrer em um nível de rede.

1. Aplicação pública sem conectividade de rede corporativa.
2. Aplicação pública com conectividade de rede corporativa.
3. Aplicação privada com conectividade de rede corporativa.

Atenção

Ao implantar em uma zona de aterrissagem do Azure, a configuração 1. devem ser implantados dentro de uma Zona de Pouso Online, enquanto 2) e 3) devem ser implantados dentro de uma Zona de Pouso Conectada da Corp. para facilitar a integração no nível da rede.

Esta seção explora esses cenários de integração de rede, colocando em camadas o uso apropriado das Redes Virtuais do Azure e dos serviços de rede do Azure ao redor para garantir que os requisitos de integração sejam atendidos da melhor forma.

Considerações de design

Sem redes virtuais

• A abordagem de design mais simples é não implantar o aplicativo em uma rede virtual.

  • A conectividade entre todos os serviços do Azure considerados será fornecida inteiramente por meio de pontos de extremidade públicos e do backbone do Microsoft Azure. A conectividade entre pontos de extremidade públicos hospedados no Azure atravessará apenas o backbone da Microsoft e não passará pela Internet pública.
  • A conectividade com quaisquer sistemas externos fora do Azure será fornecida pela Internet pública.

• Esta abordagem de design adota "identidade como um perímetro de segurança" para fornecer controle de acesso entre os vários componentes de serviço e solução dependente. Esta pode ser uma solução aceitável para cenários menos sensíveis à segurança. Todos os serviços e dependências de aplicativos são acessíveis por meio de um ponto de extremidade público que os deixa vulneráveis a vetores de ataque adicionais orientados para a obtenção de acesso não autorizado.

• Essa abordagem de design também não é aplicável a todos os serviços do Azure, já que muitos serviços, como o AKS, têm um requisito rígido para uma rede virtual subjacente.

Redes virtuais isoladas

• Para reduzir os riscos associados a pontos de extremidade públicos desnecessários, o aplicativo pode ser implantado em uma rede autônoma que não esteja conectada a outras redes.

• As solicitações de clientes de entrada ainda exigirão que um ponto de extremidade público seja exposto à Internet, no entanto, toda a comunicação subsequente pode ser dentro da rede virtual usando pontos de extremidade privados. Ao usar o Azure Front Door Premium, é possível rotear diretamente de nós de borda para pontos de extremidade de aplicativos privados.

• Embora a conectividade privada entre componentes de aplicativos ocorra em redes virtuais, toda a conectividade com dependências externas ainda dependerá de pontos de extremidade públicos.

  • A conectividade com os serviços da plataforma Azure pode ser estabelecida com Pontos de Extremidade Privados, se suportado. Se existirem outras dependências externas no Azure, como outro aplicativo downstream, a conectividade será fornecida por meio de pontos de extremidade públicos e do backbone do Microsoft Azure.
  • A conectividade com quaisquer sistemas externos fora do Azure seria fornecida pela Internet pública.

• Para cenários em que não há requisitos de integração de rede para dependências externas, a implantação da solução em um ambiente de rede isolado oferece a máxima flexibilidade de projeto. Sem restrições de endereçamento e roteamento associadas a uma integração de rede mais ampla.

• O Azure Bastion é um serviço PaaS totalmente gerenciado por plataforma que pode ser implantado em uma rede virtual e fornece conectividade RDP/SSH segura para VMs do Azure. Quando você se conecta por meio do Azure Bastion, as máquinas virtuais não precisam de um endereço IP público.

• O uso de redes virtuais de aplicativos introduz complexidades de implantação significativas nos pipelines de CI/CD, uma vez que o acesso do plano de dados e do plano de controle aos recursos hospedados em redes privadas é necessário para facilitar as implantações de aplicativos.

  • O caminho seguro da rede privada deve ser estabelecido para permitir que as ferramentas de CI/CD executem as ações necessárias.
  • Os agentes de compilação privados podem ser implantados em redes virtuais de aplicativos para acesso proxy a recursos protegidos pela rede virtual.

Redes virtuais conectadas

• Para cenários com requisitos de integração de rede externa, as redes virtuais de aplicativos podem ser conectadas a outras redes virtuais no Azure, outro provedor de nuvem ou redes locais usando uma variedade de opções de conectividade. Por exemplo, alguns cenários de aplicativos podem considerar a integração no nível do aplicativo com outros aplicativos de linha de negócios hospedados de forma privada em uma rede corporativa local.

• O design da rede de aplicativos deve estar alinhado com a arquitetura de rede mais ampla, particularmente no que diz respeito a tópicos como endereçamento e roteamento.

• A sobreposição de espaços de endereço IP em regiões do Azure ou redes locais criará uma grande contenção quando a integração de rede for considerada.

  • Um recurso de rede virtual pode ser atualizado para considerar espaço de endereçamento adicional, no entanto, quando um espaço de endereço de rede virtual de uma rede emparelhada altera uma sincronização no link de emparelhamento é necessária, o que desabilitará temporariamente o emparelhamento.
  • O Azure reserva cinco endereços IP em cada sub-rede, que devem ser considerados ao determinar tamanhos apropriados para redes virtuais de aplicativos e sub-redes englobadas.
  • Alguns serviços do Azure exigem sub-redes dedicadas, como o Azure Bastion, o Firewall do Azure ou o Gateway de Rede Virtual do Azure. O tamanho dessas sub-redes de serviço é muito importante, uma vez que elas devem ser grandes o suficiente para suportar todas as instâncias atuais do serviço, considerando os requisitos de escala futuros, mas não tão grandes a ponto de desperdiçar endereços desnecessariamente.

• Quando a integração de rede local ou entre nuvens é necessária, o Azure oferece duas soluções diferentes para estabelecer uma conexão segura.

  • Um circuito ExpressRoute pode ser dimensionado para fornecer larguras de banda de até 100 Gbps.
  • Uma VPN (Rede Privada Virtual) pode ser dimensionada para fornecer largura de banda agregada de até 10 Gbps em redes hub e spoke e até 20 Gbps na WAN Virtual do Azure.

Nota

Ao implantar em uma zona de aterrissagem do Azure, lembre-se de que qualquer conectividade necessária para redes locais deve ser fornecida pela implementação da zona de aterrissagem. O design pode usar a Rota Expressa e outras redes virtuais no Azure usando a WAN Virtual ou um design de rede hub-and-spoke.

• A inclusão de caminhos e recursos de rede adicionais introduz confiabilidade adicional e considerações operacionais para o aplicativo, a fim de garantir que a integridade seja mantida.

Recomendações de design

• Recomenda-se que as soluções de missão crítica sejam implantadas nas redes virtuais do Azure sempre que possível para remover pontos de extremidade públicos desnecessários, limitando a superfície de ataque ao aplicativo para maximizar a segurança e a confiabilidade.

  • Use Pontos de Extremidade Privados para conectividade com os serviços da plataforma Azure. Os Pontos de Extremidade de Serviço podem ser considerados para serviços que não suportam Private Link, desde que os riscos de exfiltração de dados sejam aceitáveis ou mitigados por meio de controles alternativos.

• Para cenários de aplicativos que não exigem conectividade de rede corporativa, trate todas as redes virtuais como recursos efêmeros que são substituídos quando uma nova implantação regional é conduzida.

• Ao se conectar a outras redes do Azure ou locais, as redes virtuais de aplicativos não devem ser tratadas como efêmeras, pois criam complicações significativas no que diz respeito ao emparelhamento de rede virtual e aos recursos de gateway de rede virtual. Todos os recursos de aplicativos relevantes dentro da rede virtual devem continuar a ser efêmeros, com sub-redes paralelas usadas para facilitar implantações azul-verde de selos de implantação regional atualizados.

• Em cenários em que a conectividade de rede corporativa é necessária para facilitar a integração de aplicativos em redes privadas, certifique-se de que o espaço de endereçamento IPv4 usado para redes virtuais de aplicativos regionais não se sobreponha a outras redes conectadas e seja dimensionado adequadamente para facilitar a escala necessária sem a necessidade de atualizar o recurso de rede virtual e incorrer em tempo de inatividade.

  • É altamente recomendável usar apenas endereços IP da alocação de endereços para internet privada (RFC 1918).
    • Para ambientes com disponibilidade limitada de endereços IP privados (RFC 1918), considere o uso do IPv6.
    • Se o uso de endereço IP público for necessário, certifique-se de que apenas blocos de endereços próprios sejam usados.
  • Alinhe-se com os planos da organização para o endereçamento IP no Azure para garantir que o espaço de endereço IP da rede de aplicativos não se sobreponha a outras redes em locais locais ou regiões do Azure.
  • Não crie redes virtuais de aplicativos desnecessariamente grandes para garantir que o espaço de endereço IP não seja desperdiçado.

• Priorize o uso do Azure CNI para integração de rede AKS, pois ele oferece suporte a um conjunto de recursos mais avançado.

  • Considere o Kubenet para cenários com endereços IP disponíveis limitados para ajustar o aplicativo a um espaço de endereçamento restrito.

  • Priorize o uso do plug-in de rede CNI do Azure para integração de rede AKS e considere o Kubenet para cenários com um intervalo limitado de endereços IP disponíveis. Consulte Micro-segmentação e políticas de rede kubernetes para obter mais detalhes.

• Para cenários que exigem integração de rede local, priorize o uso da Rota Expressa para garantir conectividade segura e escalável.

  • Garantir que o nível de confiabilidade aplicado à Rota Expressa ou VPN satisfaça plenamente os requisitos do aplicativo.
  • Vários caminhos de rede devem ser considerados para fornecer redundância adicional quando necessário, como circuitos de Rota Expressa conectados entre si ou o uso de VPN como um mecanismo de conectividade de failover.

• Garantir que todos os componentes em caminhos de rede críticos estejam alinhados com os requisitos de confiabilidade e disponibilidade dos fluxos de usuários associados, independentemente de o gerenciamento desses caminhos e componentes associados ser fornecido pela equipe de aplicativos das equipes centrais de TI.

  Nota

  Ao implantar em uma zona de aterrissagem do Azure e integrar-se a uma topologia de rede organizacional mais ampla, considere as diretrizes de rede para garantir que a rede fundamental esteja alinhada com as práticas recomendadas da Microsoft.

• Use o Azure Bastion ou conexões privadas por proxy para acessar o plano de dados dos recursos do Azure ou executar operações de gerenciamento.

Saída da Internet

A saída da Internet é um requisito de rede fundamental para uma aplicação de missão crítica para facilitar a comunicação externa no contexto de:

1. Interação direta com o usuário do aplicativo.
2. Integração de aplicativos com dependências externas fora do Azure.
3. Acesso a dependências externas exigidas pelos serviços do Azure usados pelo aplicativo.

Esta seção explora como a saída da Internet pode ser alcançada e, ao mesmo tempo, garantir que a segurança, a confiabilidade e o desempenho sustentável sejam mantidos, destacando os principais requisitos de saída para serviços recomendados em um contexto de missão crítica.

Considerações de design

• Muitos serviços do Azure exigem acesso a pontos de extremidade públicos para que várias funções do plano de gerenciamento e controle operem conforme o esperado.

• O Azure fornece diferentes métodos de conectividade direta de saída da Internet, como o gateway NAT do Azure ou o Balanceador de Carga do Azure, para máquinas virtuais ou instâncias de computação em uma rede virtual.

• Quando o tráfego de dentro de uma rede virtual viaja para a Internet, a NAT (Network Address Translation) deve ocorrer. Esta é uma operação de computação que ocorre dentro da pilha de rede e que, portanto, pode afetar o desempenho do sistema.

• Quando o NAT ocorre em pequena escala, o impacto no desempenho deve ser insignificante, no entanto, se houver um grande número de solicitações de saída, podem ocorrer problemas de rede. Esses problemas geralmente vêm na forma de "Exaustão da porta NAT (ou SNAT) de origem".

• Em um ambiente multilocatário, como o Serviço de Aplicativo do Azure, há um número limitado de portas de saída disponíveis para cada instância. Se essas portas acabarem, nenhuma nova conexão de saída poderá ser iniciada. Esse problema pode ser atenuado reduzindo o número de travessias de borda privadas/públicas ou usando uma solução NAT mais escalável, como o Gateway NAT do Azure.

• Além das limitações NAT, o tráfego de saída também pode estar sujeito às inspeções de segurança necessárias.

  • O Firewall do Azure fornece recursos de segurança apropriados para proteger a saída da rede.

  • O Firewall do Azure (ou um NVA equivalente) pode ser usado para proteger os requisitos de saída do Kubernetes fornecendo controle granular sobre os fluxos de tráfego de saída.

• Grandes volumes de saída da Internet incorrerão em taxas de transferência de dados.

Azure NAT Gateway

• O Gateway NAT do Azure suporta 64.000 conexões para TCP e UDP por endereço IP de saída atribuído.

  • Até 16 endereços IP podem ser atribuídos a um único gateway NAT.
  • Um tempo limite de inatividade TCP padrão de 4 minutos. Se o tempo limite ocioso for alterado para um valor mais alto, os fluxos serão mantidos por mais tempo, o que aumentará a pressão sobre o estoque de portas SNAT.

• O gateway NAT não pode fornecer isolamento zonal pronto para uso. Para obter redundância zonal, uma sub-rede contendo recursos zonais deve ser alinhada com gateways NAT zonais correspondentes.

Recomendações de design

• Minimize o número de conexões de saída com a Internet, pois isso afetará o desempenho do NAT.

  • Se for necessário um grande número de conexões ligadas à Internet, considere usar o Gateway NAT do Azure para abstrair os fluxos de tráfego de saída.

• Use o Firewall do Azure onde existem requisitos para controlar e inspecionar o tráfego de saída da Internet.

  • Verifique se o Firewall do Azure não é usado para inspecionar o tráfego entre os serviços do Azure.

Nota

Ao implantar em uma zona de aterrissagem do Azure, considere usar o recurso de Firewall do Azure da plataforma fundamental (ou NVA equivalente). Se uma dependência for assumida em um recurso de plataforma central para saída da Internet, o nível de confiabilidade desse recurso e o caminho de rede associado devem estar estreitamente alinhados com os requisitos do aplicativo. Os dados operacionais do recurso também devem ser disponibilizados ao aplicativo, a fim de informar possíveis ações operacionais em cenários de falha.

Se houver requisitos de alta escala associados ao tráfego de saída, deve-se considerar um recurso dedicado do Firewall do Azure para um aplicativo de missão crítica, para mitigar os riscos associados ao uso de um recurso compartilhado centralmente, como cenários vizinhos barulhentos.

• Quando implantado em um ambiente de WAN Virtual, deve-se considerar o Gerenciador de Firewall para fornecer gerenciamento centralizado de instâncias dedicadas do Firewall do Azure de aplicativos para garantir que as posturas de segurança organizacional sejam observadas por meio de políticas globais de firewall.
• Garanta que as políticas incrementais de firewall sejam delegadas às equipes de segurança de aplicativos por meio do controle de acesso baseado em função para permitir autonomia na política de aplicativos.

Conectividade entre zonas e entre regiões

Embora o design do aplicativo defenda fortemente carimbos de implantação regional independentes, muitos cenários de aplicativo ainda podem exigir integração de rede entre componentes de aplicativo implantados em diferentes zonas ou regiões do Azure, mesmo que apenas em circunstâncias de serviço degradadas. O método pelo qual a comunicação entre zonas e entre regiões é alcançada tem uma influência significativa no desempenho geral e na fiabilidade, que serão explorados através das considerações e recomendações contidas nesta secção.

Considerações de design

• A abordagem de design de aplicativo para um aplicativo de missão crítica endossa o uso de implantações regionais independentes com redundância zonal aplicada em todos os níveis de componentes em uma única região.

• Uma zona de disponibilidade (AZ) é um local de data center fisicamente separado dentro de uma região do Azure, fornecendo isolamento de falhas físicas e lógicas até o nível de um único data center.

  Uma latência de ida e volta inferior a 2 ms é garantida para comunicação entre zonas. As zonas terão uma pequena variação de latência, dadas as distâncias variadas e caminhos de fibra entre zonas.

• A conectividade da Zona de Disponibilidade depende das características regionais e, portanto, o tráfego que entra em uma região por meio de um ponto de presença pode precisar ser roteado entre zonas para chegar ao seu destino. Isso adicionará uma latência de ~1ms-2ms, dadas as restrições de roteamento entre zonas e 'velocidade da luz', mas isso só deve ter um impacto para cargas de trabalho hipersensíveis.

• As zonas de disponibilidade são tratadas como entidades lógicas dentro do contexto de uma única assinatura, portanto, assinaturas diferentes podem ter um mapeamento zonal diferente para a mesma região. Por exemplo, a zona 1 na Subscrição A pode corresponder ao mesmo centro de dados físico que a zona 2 na subscrição B.

• Com cenários de aplicativos que são extremamente tagarelas entre os componentes do aplicativo, a distribuição das camadas de aplicativos entre zonas pode introduzir latência significativa e aumento de custos. É possível atenuar isso no design restringindo um carimbo de implantação a uma única zona e implantando vários carimbos nas diferentes zonas.

• A comunicação entre diferentes regiões do Azure incorre em uma cobrança de transferência de dados maior por GB de largura de banda.

  • A taxa de transferência de dados aplicável depende do continente das regiões do Azure consideradas.
  • Os dados que atravessam continentes são cobrados a uma taxa consideravelmente mais elevada.

• Os métodos de conectividade de Rota Expressa e VPN também podem ser usados para conectar diretamente diferentes regiões do Azure para determinados cenários ou até mesmo diferentes plataformas de nuvem.

• Para serviços de comunicação de serviço, o Private Link pode ser usado para comunicação direta usando pontos de extremidade privados.

• O tráfego pode ser fixado por meio de circuitos de Rota Expressa usados para conectividade local, a fim de facilitar o roteamento entre redes virtuais dentro de uma região do Azure e entre diferentes regiões do Azure dentro da mesma geografia.

  • O tráfego fixo por meio da Rota Expressa ignorará os custos de transferência de dados associados ao emparelhamento de rede virtual, portanto, pode ser usado como uma maneira de otimizar custos.
  • Essa abordagem requer saltos de rede adicionais para integração de aplicativos no Azure, o que introduz riscos de latência e confiabilidade. Expande a função da Rota Expressa e dos componentes de gateway associados do Azure/local para também abranger a conectividade do Azure/Azure.

• Quando a latência de submilissegundos é necessária entre serviços, os Grupos de Colocação de Proximidade podem ser usados quando suportados pelos serviços usados.

Recomendações de design

• Use o emparelhamento de rede virtual para conectar redes dentro de uma região e entre diferentes regiões. É altamente recomendável evitar prender o cabelo dentro da Rota Expressa.

• Use o Private Link para estabelecer comunicação diretamente entre serviços na mesma região ou entre regiões (serviço na Região A comunicando-se com o serviço na Região B.

• Para cargas de trabalho de aplicativos que são extremamente tagarelas entre componentes, considere restringir um carimbo de implantação a uma única zona e implantar vários carimbos nas diferentes zonas. Isso garante que a redundância zonal seja mantida no nível de um carimbo de implantação encapsulado, em vez de um único componente de aplicativo.

• Sempre que possível, trate cada carimbo de implantação como independente e desconectado de outros selos.

  • Use tecnologias de plataforma de dados para sincronizar o estado entre regiões, em vez de obter consistência em nível de aplicativo com caminhos de rede diretos.
  • Evite o tráfego de "dog legging" entre diferentes regiões, a menos que seja necessário, mesmo em um cenário de falha. Use serviços de roteamento global e testes de integridade de ponta a ponta para tirar um carimbo inteiro de circulação no caso de uma única camada de componente crítico falhar, em vez de rotear o tráfego nesse nível de componente defeituoso para outra região.

• Para cenários de aplicativos sensíveis à hiperlatência, priorize o uso de zonas com gateways de rede regionais para otimizar a latência da rede para caminhos de entrada.

Microssegmentação e políticas de rede Kubernetes

A microssegmentação é um padrão de design de segurança de rede usado para isolar e proteger cargas de trabalho de aplicativos individuais, com políticas aplicadas para limitar o tráfego de rede entre cargas de trabalho com base em um modelo Zero Trust. Normalmente é aplicado para reduzir a superfície de ataque à rede, melhorar a contenção de violações e fortalecer a segurança por meio de controles de rede orientados por políticas no nível do aplicativo.

Um aplicativo de missão crítica pode impor a segurança de rede no nível do aplicativo usando NSG (Grupos de Segurança de Rede) em nível de sub-rede ou interface de rede, ACL (Listas de Controle de Acesso) de serviço e políticas de rede ao usar o Serviço Kubernetes do Azure (AKS).

Esta seção explora o uso ideal desses recursos, fornecendo as principais considerações e recomendações para alcançar a microssegmentação no nível do aplicativo.

Considerações de design

• O AKS pode ser implantado em dois modelos de rede diferentes:

  • Rede Kubenet: os nós AKS são integrados dentro de uma rede virtual existente, mas os pods existem dentro de uma rede de sobreposição virtual em cada nó. O tráfego entre pods em nós diferentes é roteado através do kube-proxy.
  • Rede CNI (Container Networking Interface) do Azure: O cluster AKS é integrado em uma rede virtual existente e seus nós, pods e serviços receberam endereços IP da mesma rede virtual à qual os nós do cluster estão conectados. Isso é relevante para vários cenários de rede que exigem conectividade direta de e para pods. Pools de nós diferentes podem ser implantados em sub-redes diferentes.

  Nota

  O Azure CNI requer mais espaço de endereço IP em comparação com o Kubenet. É necessário um planeamento inicial e dimensionamento adequados da rede. Para obter mais informações, consulte a documentação do Azure CNI.

• Por padrão, os pods não são isolados e aceitam tráfego de qualquer origem e podem enviar tráfego para qualquer destino; um pod pode se comunicar com todos os outros pods em um determinado cluster Kubernetes; O Kubernetes não garante nenhum isolamento no nível da rede e não isola namespaces no nível do cluster.

• A comunicação entre Pods e Namespaces pode ser isolada usando Diretivas de Rede. A Diretiva de Rede é uma especificação do Kubernetes que define políticas de acesso para comunicação entre Pods. Usando as Diretivas de Rede, um conjunto ordenado de regras pode ser definido para controlar como o tráfego é enviado/recebido e aplicado a uma coleção de pods que correspondem a um ou mais seletores de rótulo.

  • O AKS suporta dois plugins que implementam a Política de Rede, o Azure e o Calico. Ambos os plugins usam Linux IPTables para impor as políticas especificadas. Consulte Diferenças entre as políticas do Azure e do Calico e seus recursos para obter mais detalhes.
  • As políticas de rede não entram em conflito, pois são aditivas.
  • Para que um fluxo de rede entre dois pods seja permitido, tanto a política de saída no pod de origem quanto a política de entrada no pod de destino precisam permitir o tráfego.
  • O recurso de diretiva de rede só pode ser habilitado no momento da instanciação do cluster. Não é possível ativar a política de rede em um cluster AKS existente.
  • A entrega de políticas de rede é consistente, independentemente de o Azure ou o Calico serem usados.
  • O Calico fornece um conjunto de recursos mais rico, incluindo suporte para nós do Windows e suporta Azure CNI, bem como Kubenet.

• O AKS suporta a criação de diferentes pools de nós para separar diferentes cargas de trabalho usando nós com diferentes características de hardware e software, como nós com e sem recursos de GPU.

  • O uso de pools de nós não fornece nenhum isolamento no nível da rede.
  • Os pools de nós podem usar sub-redes diferentes dentro da mesma rede virtual. Os NSGs podem ser aplicados no nível da sub-rede para implementar a microssegmentação entre pools de nós.

Recomendações de design

• Configure um NSG em todas as sub-redes consideradas para fornecer uma ACL IP para proteger caminhos de entrada e isolar componentes de aplicativos com base em um modelo Zero Trust.

  • Use as Tags de Serviço da Front Door dentro dos NSGs em todas as sub-redes que contêm back-ends de aplicativos definidos no Azure Front Door, pois isso validará o tráfego originado de um espaço de endereço IP de back-end legítimo do Azure Front Door. Isso garantirá que o tráfego flua através do Azure Front Door em um nível de serviço, mas a filtragem baseada em cabeçalho ainda será necessária para garantir o uso de uma instância específica do Front Door e também para mitigar os riscos de segurança de 'falsificação de IP'.

  • O tráfego público da Internet deve ser desativado nas portas RDP e SSH em todos os NSGs aplicáveis.

  • Priorize o uso do plug-in de rede CNI do Azure e considere o Kubenet para cenários com um intervalo limitado de endereços IP disponíveis para ajustar o aplicativo dentro de um espaço de endereçamento restrito.

    • O AKS suporta o uso do Azure CNI e do Kubenet. Essa opção de rede é selecionada no momento da implantação.
    • O plug-in de rede CNI do Azure é um plug-in de rede mais robusto e escalável e é recomendado para a maioria dos cenários.
    • Kubenet é um plugin de rede mais leve, e é recomendado para cenários com uma gama limitada de endereços IP disponíveis.
    • Consulte Azure CNI para obter mais detalhes.

• O recurso de Diretiva de Rede no Kubernetes deve ser usado para definir regras para o tráfego de entrada e saída entre pods em um cluster. Defina políticas de rede granulares para restringir e limitar a comunicação entre pods.

  • Habilite a Política de Rede para o Serviço Kubernetes do Azure no momento da implantação.
  • Priorize o uso do Calico porque ele fornece um conjunto de recursos mais rico com adoção e suporte mais amplos da comunidade.

Próximo passo

Analise as considerações para quantificar e observar a integridade do aplicativo.

Modelação e observabilidade em saúde