Rede e conectividade para cargas de trabalho críticas no Azure

A rede é uma área fundamental para um aplicativo 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 um nível de aplicativo, considerando a conectividade necessária e o gerenciamento de tráfego redundante. Mais especificamente, ele destaca considerações e recomendações críticas destinadas a informar o design 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 crítica do Azure Well-Architected. Se você não estiver familiarizado com esta série, recomendamos que comece com o que é uma carga de trabalho crítica?

Roteamento de tráfego global

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

O Azure Front Door, o Gerenciador de Tráfego do Azure 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 de 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 sobre o design

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

• Se a carga de trabalho do aplicativo abranger o controle do cliente, como ocorre com os aplicativos cliente móveis ou da área de trabalho, é possível fornecer redundância de serviço na lógica de roteamento de cliente.

  • Várias tecnologias de roteamento global, como o Azure Front Door e o Gerenciador de Tráfego do Azure, podem ser consideradas em paralelo para redundância, com os clientes configurados para fazer failover para uma tecnologia alternativa quando determinadas condições de falha forem atendidas. A introdução de vários serviços de roteamento global introduz complexidades significativas em torno do cache de borda e dos recursos do Web Application Firewall e do gerenciamento de certificados para descarregamento de 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 funcionalidade entre o Azure Front Door e o Gerenciador de Tráfego significa que, se as duas tecnologias estiverem posicionadas lado a lado 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 Gerenciador de Tráfego do Azure são serviços distribuídos globalmente com redundância e disponibilidade internas de várias regiões.

  • Cenários de falha hipotéticos de uma escala grande o suficiente para ameaçar a disponibilidade global desses serviços de roteamento resilientes apresentam um risco mais amplo para a aplicação 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 fundamentais compartilhados, como DNS do Azure ou ID do Microsoft Entra, 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 os principais componentes do aplicativo 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 do 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 de falha hipotéticos, em que 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 significativos de resiliência, provavelmente superando em muito os riscos hipotéticos de uma interrupção global.

• Para os cenários em que o controle do cliente não é possível, uma dependência precisa ser usada em um só 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, embora redundância e disponibilidade internas de várias regiões sejam fornecidas.
  • O SLA fornecido pelo serviço de roteamento global selecionado representa o SLO composto máximo atingí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 desabilitar o serviço primário. A migração de um serviço de roteamento global para outro é normalmente um processo demorado que dura várias horas, principalmente 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 atingível fornecido por esses serviços é normalmente inferior a 100%.

  • Embora esses serviços forneçam reparações financeiras pela indisponibilidade, isso tem pouca importância quando o impacto da indisponibilidade é significativo, como em cenários críticos de segurança em que a vida humana está em jogo. A redundância de tecnologia ou mitigações operacionais suficientes devem, portanto, ainda ser consideradas, mesmo quando o SLA legal anunciado for 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 cliente recebidas são encerradas primeiro 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 atendidas 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 fornece 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 WAF (Firewall de Aplicativo Web) do Azure pode ser usado no Azure Front Door e, como ele é implantado em locais de borda de rede do Azure em todo o mundo, todas as solicitações de entrada entregues pelo 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 DDoS Standard do Azure fornece recursos adicionais e mais avançados de proteção e detecçã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. Habilita a segurança de conexão TLS para endpoints sem precisar 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 investigações de integridade e URLs (pontos de extremidade de integridade de back-end) que são chamados em intervalos para retornar um código de status HTTP refletindo se o back-end está operando normalmente, com uma resposta HTTP 200 (OK) refletindo um status íntegro. Assim que um back-end refletir um status não íntegro, da perspectiva de um determinado nó de borda, esse nó de borda deixará de enviar solicitações para lá. Os back-ends não íntegros são, portanto, removidos de forma transparente da circulação de tráfego sem demora.

• Suporta apenas protocolos HTTP/S.

• O WAF do Azure Front Door 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 detecção ou no modo de prevenção.

• O espaço IP de back-end do Front Door pode mudar, mas a Microsoft garantirá a integração com os intervalos de IP e as marcas de serviço do Azure. É possível assinar Intervalos de IP e Marcas de Serviço do Azure para receber notificações sobre alterações ou atualizações.

• O Azure Front Door dá suporte a 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 prioridade: útil para configurações ativo-passivo, em que 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 nas quais uma determinada porcentagem 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 precisar ser tratada pelo mesmo back-end, a afinidade de sessão poderá 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.

Gerenciador de Tráfego do Azure

• O Gerenciador de Tráfego do Azure é um serviço de redirecionamento de DNS.

  • O conteúdo da solicitação real não é processado, mas o Gerenciador de Tráfego retorna o nome DNS de um dos back-ends do pool, com base nas 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 é posteriormente chamado diretamente pelo cliente.

• A resposta DNS é armazenada em cache e reutilizada pelo cliente por um período de TTL (vida útil) 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 extra de conectividade que oferece benefícios de custo em comparação com o Front Door.

• 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 Gerenciador de Tráfego do Azure também depende de investigações de integridade para entender se um back-end está íntegro e operando normalmente. Se outro valor for retornado ou nada for retornado, o serviço de roteamento reconhecerá os problemas em andamento e interromperá as solicitações de roteamento 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 do serviço do 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, portanto, a propagação do DNS pode levar muito mais tempo para ocorrer. Isso significa que o tráfego pode continuar a ser enviado para o endpoint não íntegro por um período prolongado de tempo.

Balanceador de Carga Standard do Azure

Importante

O Balanceador de Carga Padrão entre Regiões está disponível em versão prévia com limitações técnicas. Essa opção não é recomendada para cargas de trabalho críticas.

Recomendações de design

• Use o Azure Front Door como o serviço de roteamento de tráfego global primário 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 WAF (Firewall de Aplicativo Web).

• Para os cenários de aplicativo em que 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 primária falha. Duas ou mais tecnologias de roteamento global devem ser posicionadas em paralelo para maior redundância, caso o SLA de serviço único não seja suficiente. A lógica do cliente é necessária para roteamento para a tecnologia redundante em caso de falha do 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 atenuará o maior número de cenários de falha global e os recursos oferecidos pelos provedores de CDN líderes do setor permitirão uma abordagem de design consistente.
  • Deve também ser ponderada a possibilidade de encaminhar directamente para um único selo regional em vez de um serviço de encaminhamento separado. Embora isso resulte em um nível de serviço degradado, 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 balanceador de carga global primário.

Importante

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

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

• Embora não seja recomendado, para cargas de trabalho HTTP(s) usando o Gerenciador de Tráfego do Azure para redundância de roteamento global para o Azure Front Door, considere descarregar o WAF (Firewall de Aplicativo Web) para o Gateway de Aplicativo para obter um tráfego aceitável que flui pelo Azure Front Door.
  • Isso introduzirá um ponto de falha adicional para o caminho de entrada padrão, um componente adicional de caminho crítico 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 Gerenciador de Tráfego do Azure, tanto em termos de execução do WAF, quanto em 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 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.

Recomendamos considerar o uso de 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, pois a maioria dos provedores de CDN líderes do setor oferece funcionalidades de borda amplamente consistentes com as oferecidas 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 (Firewall de Aplicativo Web) do Azure Front Door para fornecer proteção na borda contra explorações e vulnerabilidades 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 aplicativo 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 do Front Door. Considere também configurar a ACLing de IP usando Marcas de Serviço do Front Door para validar se o tráfego se origina do espaço de endereço IP de 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 downstream críticas em um selo 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 não íntegras, a investigação de integridade deverá refletir isso na resposta retornada para que todo o selo regional possa ser retirado de circulação.

• Verifique se as respostas da investigação de integridade são registradas e ingira todos os dados operacionais expostos pelo Azure Front Door no workspace 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 entre todos os selos regionais considerados para usar com mais eficiência os recursos implantados.

  • Para conseguir isso, defina o parâmetro "Sensibilidade de latência (latência adicional)" 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 a Afinidade de Sessão, a menos que seja exigida pelo aplicativo, pois isso pode ter um impacto negativo no equilíbrio da distribuição de tráfego. Com um aplicativo totalmente sem estado, se a abordagem de design de aplicativo crítico recomendada for seguida, qualquer solicitação poderá ser tratada por qualquer uma das implantações regionais.

Gerenciador de Tráfego do Azure

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

• Os recursos do WAF devem ser considerados em 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 de circulação caso o back-end se torne não íntegro.

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

  No entanto, para o Gerenciador de Tráfego, deve-se dar consideração adicional ao failover regional de nível de serviço. como 'legging de cachorro', para mitigar o possível atraso associado à remoção de um back-end não íntegro devido a falhas de dependência, especialmente se não for possível definir um TTL baixo para registros DNS.

• Deve-se considerar 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 de WAF de borda também são oferecidos pelo serviço de terceiros, deve-se considerar a simplificação do caminho de entrada e potencialmente remover a necessidade de Gateway de Aplicativo.

Serviços de entrega de aplicativo

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 um tráfego de entrada seguro, confiável e escalável.

Esta seção se baseia nas recomendações de roteamento global explorando os principais recursos de entrega de aplicativos, considerando serviços relevantes, como o Azure Standard Load Balancer, o Gateway de Aplicativo do Azure e o Gerenciamento de API do Azure.

Considerações sobre o design

• A criptografia TLS é fundamental para garantir a integridade do tráfego de entrada do usuário para um aplicativo de missão crítica, com o TLS Offloading 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 descriptografar o tráfego.

• Um Web Application Firewall fornece proteção contra explorações e vulnerabilidades comuns da Web, como injeção de SQL ou cross site scripting, e é essencial para atingir as aspirações máximas de confiabilidade de um aplicativo de missão crítica.

• O WAF do Azure fornece proteção pronta para uso contra as dez principais vulnerabilidades do OWASP por meio de conjuntos de regras gerenciados.

  • 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 Gateway de Aplicativo do Azure ou na CDN do Azure (atualmente em versão prévia pública).
    • Os recursos oferecidos 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 contra 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 detecção ou no modo de prevenção.
    • O roteiro do WAF do Azure garantirá que um conjunto consistente de recursos do WAF 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 para fornecer a proteção de vulnerabilidade necessária.

• 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, e ataques de amplificação de DNS e 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 na 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 design 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 certificado expirado. Se forem usados certificados autogerenciados, os certificados atualizados deverão 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 expirados.

• 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 pela Proteção contra DDoS do Azure Basic, que é integrada 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 de Camada 7 ou ataques volumétricos de Camada 3/4.

  • Essas proteções ajudam a manter a disponibilidade do Azure Front Door mesmo quando confrontadas com um ataque de 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 do WAF em um nível de tráfego global, enquanto o WAF do Gateway de Aplicativo deve ser fornecido em cada selo de implantação regional. Entre as funcionalidades estão 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.

  Azure Load Balancer

• O SKU do Azure Basic Load Balancer não é apoiado por um SLA e tem várias restrições de funcionalidade em comparação com o SKU Standard.

Recomendações de design

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

• Use conexões criptografadas (por exemplo, HTTPS) do ponto em que 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 do WAF sejam aplicados no caminho de entrada para todos os endpoints expostos publicamente.

• Habilite os recursos do WAF em um único local de serviço, globalmente com o Azure Front Door ou regionalmente com o Gateway de Aplicativo do Azure, 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 apenas o WAF no modo de Detecção (ou seja, apenas registrando em log, mas não bloqueando as solicitações suspeitas) quando a penalidade de desempenho do modo de Prevenção for muito alta. O risco adicional implícito precisa ser totalmente compreendido e alinhado aos requisitos específicos do cenário da carga de trabalho.

• Priorize o uso do WAF do Azure Front Door, pois ele fornece o conjunto de recursos nativo do Azure mais avançado 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 a clientes externos ou equipes de aplicativos diferentes.

• Use o SKU do Azure Standard Load Balancer para qualquer cenário de distribuição de tráfego interno nas cargas de trabalho de microsserviço.

  • Fornece um SLA de 99,99% quando implantado em zonas de disponibilidade.
  • Fornece funcionalidades críticas, como diagnóstico ou regras de saída.

• Use a Proteção de Rede contra DDoS do Azure para ajudar a proteger pontos de extremidade públicos hospedados em cada rede virtual do 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 sobre o design

• Nem todo o conteúdo que uma solução disponibiliza pela 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 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 Distribuição de Conteúdo) do Azure.
  • O Azure Front Door fornece recursos de cache de borda nativos do Azure e recursos de roteamento para dividir o 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 o 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 de conteúdo estático significativos.
    • O serviço CDN do Azure provavelmente será mais econômico, mas não fornece os mesmos recursos avançados de roteamento e WAF (Firewall de Aplicativo Web) recomendados para outras áreas de um design de aplicativo. No entanto, oferece mais flexibilidade para integração com serviços semelhantes de soluções de terceiros, como Akamai e Verizon.
  • Ao comparar os serviços do Azure Front Door e da CDN do Azure, 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 difere 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 de cache variável.
• 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 para otimizar o desempenho dos usuários finais.
• Dada a forte recomendação (área de design de rede e conectividade ) para usar o Azure Front Door para fins de roteamento global e WAF (Firewall de Aplicativo Web), é recomendável priorizar o uso dos recursos de cache do Azure Front Door, a menos que haja lacunas.

Integração de rede virtual

Um aplicativo crítico normalmente abrangerá requisitos de 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 endpoints 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, no desempenho e na confiabilidade da solução, além de impactar fortemente as decisões de design em outras áreas de design.

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. Aplicativo público sem conectividade de rede corporativa.
2. Aplicativo público com conectividade de rede corporativa.
3. Aplicativo privado com conectividade de rede corporativa.

Cuidado

Ao implantar em uma zona de destino do Azure, a configuração 1. devem ser implantados em uma Zona de Destino Online, enquanto 2) e 3) devem ser implantados em uma Zona de Destino 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 circundantes para garantir que os requisitos de integração sejam atendidos de maneira ideal.

Considerações de criação

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 considerados do Azure 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 percorrerá apenas o backbone da Microsoft e não passará pela Internet pública.
  • A conectividade com qualquer sistema externo fora do Azure será fornecida pela Internet pública.

• Essa abordagem de design adota a "identidade como um perímetro de segurança" para fornecer controle de acesso entre os vários componentes de serviço e a solução dependente. Essa 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 endpoint público, o que os deixa vulneráveis a vetores de ataque adicionais orientados para obter acesso não autorizado.

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

Redes virtuais isoladas

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

• As solicitações de cliente de entrada ainda exigirão que um ponto de extremidade público seja exposto à Internet, no entanto, toda a comunicação subsequente pode estar 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 aplicativo privados.

• Embora a conectividade privada entre os componentes do aplicativo 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 houver suporte. 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 qualquer sistema externo 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 fornece flexibilidade máxima de design. Sem restrições de endereçamento e roteamento associadas a uma integração de rede mais ampla.

• O Azure Bastion é um serviço de PaaS totalmente gerenciado pela 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 significativas de implantação em pipelines de CI/CD, pois o acesso ao plano de dados e ao plano de controle aos recursos hospedados em redes privadas é necessário para facilitar as implantações de aplicativos.

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

Redes virtuais conectadas

• Para cenários com requisitos de integração de rede externa, as redes virtuais de aplicativo 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 aplicativo 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 em relação a tópicos como endereçamento e roteamento.

• A sobreposição de espaços de endereço IP entre 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ço adicional, no entanto, quando um espaço de endereço de rede virtual de uma rede emparelhada é alterado, é necessária uma sincronização no link de emparelhamento, o que desabilitará temporariamente o emparelhamento.
  • O Azure reserva cinco endereços IP em cada sub-rede, que devem ser considerados ao determinar os tamanhos apropriados para redes virtuais de aplicativos e sub-redes abrangidas.
  • 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, pois 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 do ExpressRoute pode ser dimensionado para fornecer larguras de banda de até 100 Gbps.
  • Uma VPN (Rede Virtual Privada) 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.

Observação

Ao implantar em uma zona de destino do Azure, lembre-se de que qualquer conectividade necessária com redes locais deve ser fornecida pela implementação da zona de destino. O design pode usar o ExpressRoute 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 considerações operacionais e de confiabilidade adicionais para o aplicativo para garantir que a integridade seja mantida.

Recomendações de design

• Recomendamos que as soluções críticas sejam implantadas em redes virtuais do Azure sempre que possível para remover pontos de extremidade públicos desnecessários, limitando a superfície de ataque do aplicativo a fim de 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 dão suporte ao Link Privado, desde que os riscos de exfiltração de dados sejam aceitáveis ou mitigados por meio de controles alternativos.

• Para os cenários de aplicativo 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 é realizada.

• Ao se conectar a outras redes locais ou do Azure, as redes virtuais de aplicativos não devem ser tratadas como efêmeras, pois elas 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 aplicativo relevantes na rede virtual devem continuar a ser efêmeros, com sub-redes paralelas usadas para facilitar implantações azul-verde de selos de implantação regionais atualizados.

• Nos cenários em que a conectividade de rede corporativa é necessária para facilitar a integração de aplicativos em redes privadas, verifique se o espaço de endereço IPv4 usado para as redes virtuais de aplicativos regionais não se sobrepõe a outras redes conectadas e seja dimensionado corretamente para facilitar a escala necessária sem a necessidade de atualizar o recurso de rede virtual e gerar 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 de 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 aos planos da organização para endereçamento IP no Azure para garantir que o espaço de endereço IP da rede do aplicativo não se sobreponha a outras redes em 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 da CNI do Azure para integração de rede do AKS, pois ela dá suporte a um conjunto de recursos mais avançado.

  • Considere o Kubenet para cenários com uma raiva limitada de endereços IP disponíveis para ajustar o aplicativo em um espaço de endereço restrito.

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

• Para cenários que exigem integração de rede local, priorize o uso do Express Route para garantir conectividade segura e escalonável.

  • Certifique-se de que o nível de confiabilidade aplicado à Rota Expressa ou VPN atenda totalmente aos requisitos do aplicativo.
  • Vários caminhos de rede devem ser considerados para fornecer redundância adicional quando necessário, como circuitos do ExpressRoute conectados entre si ou o uso de VPN como um mecanismo de conectividade de failover.

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

  Observação

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

• Use o Azure Bastion ou conexões privadas com 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 um aplicativo de missão crítica para facilitar a comunicação externa no contexto de:

1. Interação direta do 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 criação

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

• O Azure fornece diferentes métodos de conectividade de saída direta da Internet, como o gateway NAT do Azure ou o Azure Load Balancer, 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 (Conversão de Endereços de Rede) deve ocorrer. Essa é uma operação de computação que ocorre na 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, poderão ocorrer problemas de rede. Esses problemas geralmente vêm na forma de 'Esgotamento 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 escalonável, como o Gateway NAT do Azure.

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

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

  • O Firewall do Azure (ou uma 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.

Gateway da NAT do Azure

• O Gateway NAT do Azure dá suporte a 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 ociosidade 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 inventário da porta SNAT.

• O gateway NAT não pode fornecer isolamento zonal pronto para uso. Para obter redundância zonal, uma sub-rede que contém recursos zonais deve ser alinhada com os 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 um grande número de conexões vinculadas à Internet for necessário, considere usar o Gateway NAT do Azure para abstrair 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.

Observação

Ao implantar em uma zona de destino do Azure, considere usar o recurso de Firewall do Azure da plataforma básica (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 deverão estar intimamente alinhados com os requisitos do aplicativo. Os dados operacionais do recurso também devem ser disponibilizados para o aplicativo para 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 crítico, para mitigar os riscos associados ao uso de um recurso compartilhado centralmente, como cenários de vizinhos barulhentos.

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

Conectividade entre zonas e regiões

Embora o design do aplicativo defenda fortemente o uso de selos de implantação regionais independentes, muitos cenários de aplicativo ainda podem exigir a integração de rede entre componentes do 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 regiões é alcançada tem uma influência significativa no desempenho geral e na confiabilidade, que será explorado por meio das considerações e recomendações desta seção.

Considerações de criação

• 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 componente em uma única região.

• Uma AZ (Zona de Disponibilidade) é um local de data center fisicamente separado em 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 devido a distâncias variadas e caminhos de fibra entre as 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 ~ 1 ms-2 ms, dado o roteamento entre zonas e as restrições de 'velocidade da luz', mas isso só deve ter influência para cargas de trabalho hipersensíveis.

• As zonas de disponibilidade são tratadas como entidades lógicas no 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 Assinatura A pode corresponder ao mesmo data center físico que a zona 2 na assinatura B.

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

• A comunicação entre diferentes regiões do Azure incorre em um encargo maior de transferência de dados 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 alta.

• Os métodos de conectividade VPN e Express Route 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 comunicação de serviços para serviço, o Link Privado 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 para facilitar o roteamento entre redes virtuais em uma região do Azure e em diferentes regiões do Azure dentro da mesma geografia.

  • O tráfego de fixação de cabelo por meio do Express Route ignorará os custos de transferência de dados associados ao emparelhamento de rede virtual, portanto, pode ser usado como uma maneira de otimizar os 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 do Express Route e dos componentes de gateway associados do Azure/local para abranger também a conectividade do Azure/Azure.

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

Recomendações de design

• Use o emparelhamento de rede virtual para conectar as redes de uma região e entre regiões diferentes. É altamente recomendável evitar a anexação de fios no Express Route.

• Use o Link Privado 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 serviço na Região B.

• Para as cargas de trabalho de aplicativo extremamente verborrágicas entre componentes, considere a possibilidade de restringir um selo de implantação a uma só zona e implantar vários selos nas diferentes zonas. Isso garante que a redundância de zona seja mantida no nível de um selo de implantação encapsulado em vez de um só componente do aplicativo.

• Sempre que possível, trate cada selo 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 um nível de aplicativo com caminhos de rede diretos.
  • Evite o tráfego de 'legging de cachorro' entre diferentes regiões, a menos que seja necessário, mesmo em um cenário de falha. Use serviços de roteamento global e investigações de integridade de ponta a ponta para tirar um selo 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 de rede para caminhos de entrada.

Microssegmentação e políticas de rede do 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 de Confiança Zero. Normalmente, ele é 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 no nível do aplicativo orientados por políticas.

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

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

Considerações de criação

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

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

  Observação

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

• 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 do 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 políticas de rede. A Política de Rede é uma especificação do Kubernetes que define políticas de acesso para comunicação entre pods. Usando as Políticas 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 dá suporte a dois plug-ins que implementam a Política de Rede, Azure e Calico. Ambos os plug-ins usam IPTables do Linux 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, a política de saída no pod de origem e a política de entrada no pod de destino precisam permitir o tráfego.
  • O recurso de política de rede só pode ser habilitado no momento da instanciação do cluster. Não é possível habilitar 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 ser usado.
  • O Calico fornece um conjunto de recursos mais avançado, incluindo suporte para nós do Windows e dá suporte ao CNI do Azure, bem como ao Kubenet.

• O AKS dá suporte à 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 na 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 do aplicativo com base em um modelo de Confiança Zero.

  • Use marcas de serviço do Front Door em NSGs em todas as sub-redes que contêm back-ends de aplicativo 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 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 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 desabilitado nas portas RDP e SSH em todos os NSGs aplicáveis.

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

    • O AKS dá suporte ao uso da CNI do Azure 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 escalonável e é recomendado para a maioria dos cenários.
    • O Kubenet é um plug-in de rede mais leve e é recomendado para cenários com um intervalo limitado de endereços IP disponíveis.
    • Consulte CNI do Azure para obter mais detalhes.

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

  • Habilite a Política de Rede para o Serviço de 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óxima etapa

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

Modelagem de integridade e observabilidade