Rede e conectividade para cargas de trabalho de missão crítica 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 críticas e recomendações 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 de missão crítica do Azure Well-Architected. Se você não está familiarizado com esta série, recomendamos que você 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 Gerenciador de Tráfego do Azure e o Balanceador de Carga Padrão do Azure 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 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 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 recursos 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 ou alterações de design diferentes serão necessários 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 internas de várias regiões.

  • 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 por serviços básicos compartilhados, como o DNS do Azure ou a 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 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, 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 paralisação global, uma abordagem de implantação ativa-ativa multinuvem 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, mesmo que a redundância e a disponibilidade internas de várias regiões sejam fornecidas.
  • O SLA fornecido pelo serviço de roteamento global selecionado representa o SLA 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 principal. A migração de um serviço de roteamento global para outro normalmente é um processo demorado que dura várias horas, especialmente 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 é tipicamente inferior a 100%.

  • Embora esses serviços forneçam reparações financeiras por indisponibilidade, isso é pouco significativo quando o impacto da indisponibilidade é significativo, como em cenários críticos de 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 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 CDN (Rede de Distribuição de Conteúdo) dedicada.

• O WAF (Firewall de Aplicativo Web do Azure) pode ser usado no Azure Front Door e, como ele é implantado em pontos de presença de rede do Azure em todo o mundo, cada solicitação de entrada entregue pelo Front Door é inspecionada na borda da rede.

• O Azure Front Door protege pontos de extremidade de aplicativos contra ataques DDoS usando a proteção Básica contra DDoS do Azure. O Azure DDoS Standard 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 pontos de extremidade sem precisar gerenciar o ciclo de vida do certificado.

• O Azure Front Door Premium oferece 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 rede virtual para tornar os back-ends acessíveis por meio do Azure Front Door Premium.

• O Azure Front Door depende de testes de integridade e pontos de extremidade (URLs) 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á 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á. Backends insalubres são, portanto, removidos de forma transparente da circulação de tráfego sem qualquer atraso.

• 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 Tags de Serviço do Azure. É possível assinar Intervalos de IP e Marcas de Serviço do Azure para receber notificações sobre quaisquer 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, onde o tráfego sempre deve ser enviado para um back-end principal, a menos que não esteja disponível.
  • Ponderado: aplicável para 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 obtêm 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 manipulada 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.

  • A carga real da solicitação não é processada, 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 é subsequentemente chamado diretamente pelo cliente.

• A resposta DNS é armazenada em cache e reutilizada pelo cliente por um período de tempo de vida (TTL) especificado, e as solicitações feitas durante esse período irão diretamente para o ponto de extremidade de back-end sem interação com o Gerenciador de Tráfego. Elimina a etapa extra de conectividade que proporciona 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 testes 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á 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 expirar, 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 Cross-Region Standard Load Balancer está disponível em versão prévia com limitações técnicas. Essa opção não é recomendada para cargas de trabalho de missão crítica.

Recomendações sobre 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 Web Application Firewall (WAF).

• 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 considerada a possibilidade de encaminhar directamente para um único carimbo 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 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 redundantes de terceiros usadas para roteamento global.

O Azure pode ser efetivamente integrado a 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 da 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) usando o Gerenciador de Tráfego do Azure para redundância de roteamento global para o Azure Front Door, considere descarregar o WAF (Web Application Firewall) para o Gateway de Aplicativo para tráfego aceitável fluindo 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, 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 abordagem de design atenuante. Para garantir um nível consistente de serviço, considere transferir 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 do 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 IP usando Marcas de Serviço Front Door para validar o tráfego originado 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 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 retornada para que todo o carimbo regional possa ser retirado de circulação.

• Certifique-se de que as respostas de investigação 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, espalhe 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 que seja 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 ela pode ter um impacto negativo no saldo 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.

Gerenciador de Tráfego do Azure

• Use o Gerenciador de Tráfego para cenários que não sejam 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 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 não estar í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 carimbo 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 considerar adicionalmente o failover regional de nível de serviço. como "legging de cachorro", 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 provedores de CDN de terceiros para obter 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 do Application Gateway.

Serviços de entrega de aplicativo

O caminho de entrada de rede para um aplicativo de missão crítica também deve considerar serviços de entrega de aplicativos para garantir 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 Balanceador de Carga Padrão do Azure, 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 descarregamento de TLS aplicado apenas no ponto de entrada de um carimbo 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 scripts entre sites, e é essencial para alcançar as aspirações de confiabilidade máxima 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 visualização 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 bots, que ainda não são oferecidos no WAF do Gateway de Aplicativo. No entanto, todos eles oferecem suporte a regras internas e personalizadas e podem ser configurados para operar no modo de detecção ou no 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 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 processará apenas 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 perfeitas 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 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 protege contra inundações comuns de consulta 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 diante de um ataque DDoS. 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 de WAF em um nível de tráfego global, enquanto o WAF do Gateway de Aplicativo deve ser fornecido em cada carimbo 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

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

Recomendações sobre design

• Execute o descarregamento de 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 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), verifique se os recursos do WAF são aplicados no 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 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 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 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 armazenamento em 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 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 (Web Application Firewall) recomendados para outras áreas de um design de aplicativo. No entanto, oferece mais flexibilidade para se integrar a serviços semelhantes de soluções de terceiros, como Akamai e Verizon.
  • Ao comparar os serviços Azure Front Door e 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 varia de acordo com o destino).

Recomendações sobre design

• O conteúdo estático gerado, como cópias dimensionadas de arquivos de imagem que nunca ou raramente mudam, também pode se beneficiar do armazenamento em 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 (Web Application Firewall), é recomendável priorizar o uso dos recursos de cache do Azure Front Door, a menos que existam lacunas.

Integração de rede virtual

Um aplicativo de missão crítica normalmente englobará 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 pontos de extremidade voltados para o público e a Internet, ou redes privadas por meio da integração em nível de 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 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. 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 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 em nível de rede.

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

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 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.

• 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 ponto de extremidade público, deixando-os 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, 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 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 privado.

• Embora a conectividade privada entre componentes de 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 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 fornece flexibilidade máxima de projeto. Sem restrições de endereçamento e roteamento associadas a uma integração de rede mais ampla.

• O Bastião do Azure é 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 Bastião do Azure, 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 de rede privada seguro 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, em outro provedor de nuvem ou em redes locais usando uma variedade de opções de conectividade. Por exemplo, alguns cenários de aplicativo podem considerar a integração em nível de 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 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 é alterada, 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 Bastião do Azure, 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 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 de Rota Expressa 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 de hub e spoke e até 20 Gbps na WAN Virtual do Azure.

Observação

Ao implantar em uma zona de aterrissagem do Azure, esteja ciente 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 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 sobre 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 oferecem 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 criam complicações significativas quando se trata de emparelhamento de rede virtual e 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-verdes de carimbos 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 uma 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 de propriedade sejam usados.
  • Alinhe-se com os planos da organização para 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 uma raiva limitada de endereços IP disponíveis para ajustar o aplicativo dentro de um espaço de endereço 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 Microssegmentação e políticas de rede 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 escalável.

  • Certifique-se de que o nível de confiabilidade aplicado à Rota Expressa ou VPN satisfaça totalmente 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.

• 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 do componente associado ser fornecido pela equipe de aplicativos das equipes centrais de TI.

  Observação

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

• Use o Bastião do Azure 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 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 do plano de gerenciamento e 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 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 conversão de endereços de rede (NAT) deve ocorrer. Essa é 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, 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 à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 de 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 ocioso 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 portuário 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 sobre 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 vinculadas à Internet, 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 aterrissagem do Azure, considere usar o recurso de plataforma básica do Firewall do Azure (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 estreitamente alinhados com os requisitos do aplicativo. Os dados operacionais do recurso também devem ser disponibilizados ao 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 de missão crítica, 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 Firewall Manager para fornecer gerenciamento centralizado de instâncias dedicadas do Firewall do Azure para garantir que as posturas de segurança organizacional sejam observadas por meio de diretivas 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ção para permitir a autonomia da política de aplicativo.

Conectividade entre zonas e entre 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 através do qual a comunicação entre zonas e entre regiões é alcançada tem uma influência significativa no desempenho e na fiabilidade globais, que serão explorados através das considerações e recomendações contidas nesta secçã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 zona de disponibilidade (AZ) é 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 de menos de 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 os 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 ~1ms-2ms, dadas as restrições de roteamento entre zonas e '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 aplicativos extremamente tagarelas entre os componentes do aplicativo, a distribuição de camadas de aplicativos entre zonas pode introduzir latência significativa e custos aumentados. É 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 taxa 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 alta.

• Os métodos de conectividade Express Route 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 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 entre diferentes regiões do Azure na mesma geografia.

  • O tráfego 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 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 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 os serviços, os Grupos de Posicionamento de Proximidade podem ser usados quando suportados pelos serviços usados.

Recomendações sobre 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 se comunicando com o 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 carimbo de implantação como independente e desconectado de outros carimbos.

  • 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 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 falha de uma única camada de componente crítico, 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 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, é 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 em nível de aplicativo orientados por políticas.

Um aplicativo de missão crítica pode impor a segurança de rede em nível de aplicativo usando NSG (Grupos de Segurança de Rede) em um nível de sub-rede ou interface de rede, listas de controle de acesso (ACL) de serviço e políticas de rede ao usar o Serviço de 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 em nível de aplicativo.

Considerações de criação

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

  • Rede Kubenet: os nós AKS são integrados em 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 (Interface de Rede de Contêiner do Azure): o cluster 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 conectados. 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

  O Azure CNI 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 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 Política de Rede é uma especificação do Kubernetes que define políticas de acesso para comunicação entre pods. Usando 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 oferece suporte a dois plug-ins que implementam a Política de Rede, o Azure e o 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 diretiva de rede só pode ser habilitado no momento da instanciação do cluster. Não é possível habilitar a diretiva 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 avançado, incluindo suporte para nós de janelas e oferece suporte ao Azure CNI, bem como ao 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 em nível de 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 sobre design

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

  • Use Marcas de Serviço Front Door em 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 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 oferece suporte ao uso do Azure CNI e do Kubenet. Essa opção de rede é selecionada no momento da implantação.
    • O plug-in de rede do Azure CNI é um plug-in de rede mais robusto e escaloná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 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 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 e observabilidade da saúde