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

A rede é uma área fundamental para um aplicativo crítico, dada a abordagem recomendada de design ativo-ativo distribuído globalmente.

Essa á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 escalonável para um aplicativo crítico.

Importante

Este artigo faz parte da série de cargas de trabalho críticas 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 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 cenários diferentes.

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 relação aos recursos de cache de borda e Firewall de Aplicativo Web e ao 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 de plataforma do Azure.

• A disparidade de capacidade entre o Azure Front Door e o Gerenciador de Tráfego significa que, se as duas tecnologias estiverem posicionadas umas com as outras para redundância, um caminho de entrada diferente ou alterações de design 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 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 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 correlacionadas e em cascata.
    • Cenários de falha dessa escala só são viáveis causados por serviços fundamentais compartilhados, como DNS do Azure ou ID de 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.
    • Cenários de falha de serviço de roteamento global são altamente propensos a afetar significativamente muitos outros serviços usados para os principais componentes do aplicativo por meio de dependências de intersserviço. 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 fornecerá pouco valor de qualquer maneira.

• A redundância de serviço de roteamento global fornece mitigação para um número extremamente pequeno de cenários de falha hipotética, 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 de várias nuvens pode ser considerada. Uma abordagem de implantação ativa-ativa de várias nuvens 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 ponto único de falha em um nível de serviço devido a dependências globais, embora 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 alcançável, independentemente de quantas regiões de implantação são consideradas.

• Quando o controle do cliente não é possível, 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 longo que dura várias horas, especialmente onde a propagação de DNS é considerada.

• Alguns serviços de roteamento global de terceiros fornecem um SLA 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 para indisponibilidade, ele vem de pouco significado quando o impacto da indisponibilidade é significativo, como com cenários críticos de segurança em que a vida humana está em jogo. Portanto, a redundância de tecnologia ou mitigações operacionais suficientes ainda devem ser consideradas mesmo quando o SLA legal anunciado for 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 de entrada 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 é muito eficiente na disseminação de grandes volumes de tráfego nas 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 (Azure Firewall de Aplicativo Web) 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 em inspecionadas na borda da rede.

• O Azure Front Door protege os pontos de extremidade do aplicativo contra ataques de DDoS usando a proteção contra DDoS do Azure Básico. 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 dá suporte a pontos de extremidade privados, permitindo que o tráfego flua da Internet diretamente para 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 uma base de intervalo para retornar um código http status 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 do tráfego sem nenhum atraso.

• Dá suporte apenas a protocolos HTTP/S.

• O WAF do Azure Front Door e o WAF Gateway de Aplicativo fornecem um conjunto de recursos ligeiramente diferente, embora o suporte a regras internas e personalizadas possa ser definido para operar no modo de detecção ou prevenção.

• O espaço de IP de back-end do Front Door pode mudar, mas a Microsoft garantirá a integração com intervalos de IP do Azure e marcas de serviço. É possível assinar intervalos de IP do Azure e marcas de serviço 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 sempre deve ser enviado para um back-end primário, a menos que não esteja disponível.
  • Ponderado: aplicável a implantações canários nas quais um determinado percentual de tráfego é enviado 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 real da solicitação não é processado, mas, em vez disso, o Gerenciador de Tráfego retorna o nome DNS de um dos back-ends que ele tem no pool, com base nas regras configuradas para o método de roteamento de tráfego selecionado.
  • Em seguida, o nome DNS de back-end é resolvido para seu endereço IP final que é chamado diretamente pelo cliente.

• A resposta DNS é armazenada em cache e reutilizado pelo cliente para um período 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 de conectividade extra que fornece 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 compatível com o 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á problemas contínuos e interromperá o roteamento de solicitações para esse back-end específico.

  • No entanto, ao contrário do Azure Front Door, essa remoção de back-ends não íntegros não é instantânea, pois os clientes continuarão a criar conexões com o back-end não íntegro até que o TTL DNS expire e um novo ponto de extremidade de back-end seja solicitado do serviço gerenciador de tráfego.
  • Além disso, mesmo quando a TTL expira, não há garantia de que os servidores DNS públicos respeitarão esse valor, portanto, a propagação de 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.

Standard Load Balancer do Azure

Importante

O Standard Load Balancer 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 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 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 globais de falha e os recursos oferecidos pelos principais provedores de CDN do setor permitirão uma abordagem de design consistente.
  • Consideração também deve ser dada ao roteamento direto para um único selo regional em vez de um serviço de roteamento separado. Embora isso resulte em um nível degradado de serviço, ele 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 atenuar o risco de falhas globais na plataforma do Azure, uma abordagem de implantação ativa-ativa de várias nuvens deve ser considerada, com selos de implantação ativos hospedados em dois ou mais provedores de nuvem e tecnologias redundantes de roteamento 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 de várias nuvens porque introduz 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 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 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 Firewall de Aplicativo Web (WAF) para Gateway de Aplicativo para 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 de caminho crítico adicional para gerenciar e dimensionar e também incorrerá em custos adicionais para garantir a alta disponibilidade global. No entanto, isso simplificará consideravelmente 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 de WAF quanto de pontos de extremidade de aplicativo privados.
  • A perda de cache de borda em um cenário de falha afetará o desempenho geral, e isso deve estar alinhado com um nível aceitável de serviço ou uma abordagem de design atenuante. 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 remova a necessidade de gerenciar ciclos de vida de certificado.

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

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

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

• Configure os pontos de entrada da plataforma de aplicativo para validar as 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 o IP ACLing usando marcas de serviço do Front Door para validar o tráfego proveniente 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 por meio do Azure Front Door em um nível de serviço, mas a filtragem baseada em cabeçalho ainda será necessária para garantir o uso de uma instância 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 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 de investigação de integridade são registradas e ingerir todos os dados operacionais expostos pelo Azure Front Door no workspace global do Log Analytics para facilitar um coletor de dados unificado e uma única exibição operacional em todo o aplicativo.

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

  • Para fazer isso, defina o parâmetro "Sensibilidade de Latência (Latência Adicional)" como um valor alto o suficiente para atender a 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 estado, se a abordagem de design de aplicativo 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 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.

• As funcionalidades do WAF devem ser consideradas em cada região para o caminho de entrada do Gerenciador de Tráfego, usando 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 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 críticas de downstream dentro de um carimbo de implantação regional, o que deve ser refletido na resposta fornecida pelos pontos de extremidade de integridade.

  No entanto, para o Gerenciador de Tráfego, deve-se considerar o failover regional no nível do serviço. como 'dog legging', para atenuar o atraso potencial 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 os provedores de CDN de terceiros para obter o cache de borda ao usar o Gerenciador de Tráfego do Azure como um serviço de roteamento global primário. Quando os recursos do WAF de borda também são oferecidos pelo serviço de terceiros, deve-se considerar para simplificar o 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 crítico também deve considerar os serviços de entrega de aplicativos para garantir o tráfego de entrada seguro, confiável e escalonável.

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

Considerações sobre o design

• A criptografia TLS é essencial para garantir a integridade do tráfego de usuário de entrada para um aplicativo crítico, com o descarregamento de TLS aplicado somente 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 Firewall de Aplicativo Web fornece proteção contra vulnerabilidades e explorações comuns da Web, como injeção de SQL ou script entre sites, e é essencial para alcançar as aspirações máximas de confiabilidade de um aplicativo crítico.

• 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 de bot, que ainda não são oferecidas no WAF Gateway de Aplicativo. No entanto, todos dão suporte a regras internas e personalizadas e podem ser definidos para operar no modo de detecção ou no modo de prevenção.
    • O roteiro do WAF do Azure garantirá que um conjunto de recursos de 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 para fornecer 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 aceita apenas o tráfego HTTP e HTTPS e só processará solicitações com um cabeçalho conhecido Host . Esse bloqueio de protocolo ajuda a atenuar ataques volumétricas espalhados por protocolos e portas e ataques de amplificação de DNS e envenenamento por TCP.

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

  • A configuração de recursos pode ser distribuída em grande escala para lidar com centenas de milhares de solicitações por segundo.
  • Atualizações à 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 bring-your-own-certificate 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 certificados "gerenciados" pelo menos 60 dias antes da expiração do certificado para proteger contra riscos de certificado expirados. Se certificados autogerenciados forem usados, 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 Básica, que é integrada ao Front Door por padrão. Isso fornece monitoramento de tráfego sempre ativado, mitigação em tempo real e também defende 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 de DDoS. Ataques de DDoS (negação de serviço distribuído) podem renderizar um recurso de destino indisponível sobrecarregando-o com tráfego ilegítimo.

• O Azure Front Door também fornece funcionalidades de WAF em um nível de tráfego global, enquanto Gateway de Aplicativo WAF deve ser fornecido dentro de 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 Load Balancer Básico do Azure não é apoiado por um SLA e tem várias restrições de funcionalidade em comparação com o SKU Standard.

Recomendações sobre design

• Execute o Descarregamento de TLS no menor número possível de locais para manter a segurança, simplificando o ciclo de vida de gerenciamento de certificados.

• Use conexões criptografadas (por exemplo, HTTPS) do ponto em que o descarregamento de TLS ocorre 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 o tráfego HTTP(S), verifique se as funcionalidades do WAF são aplicadas dentro do caminho de entrada para todos os pontos de extremidade expostos publicamente.

• Habilite as funcionalidades do WAF em um único local de serviço, seja globalmente com o Azure Front Door ou regionalmente com Gateway de Aplicativo do Azure, pois isso simplifica o ajuste fino de 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 Azure Gerenciamento de API 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 os pontos de extremidade públicos hospedados em cada rede virtual do aplicativo.

Armazenamento em cache e distribuição 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 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 capacidade 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 atendem a ativos estáticos (imagens, JavaScript, CSS, arquivos de localização etc.) e conteúdo dinâmico.
• Cargas de trabalho com conteúdo estático acessado com frequência se beneficiam muito do cache, pois reduz a carga em 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 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 distribuição 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 Firewall de Aplicativo Web (WAF) que são recomendados para outras áreas de um design de aplicativo. No entanto, ele oferece mais flexibilidade para se integrar a 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 do 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 por destino).

Recomendações sobre design

• Conteúdo estático gerado, como cópias dimensionadas de arquivos de imagem que nunca ou apenas raramente são alterados, também podem 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 globais de roteamento e Firewall de Aplicativo Web (WAF), é recomendável priorizar o uso de recursos de cache do Azure Front Door, a menos que existam lacunas.

Integração de rede virtual

Um aplicativo crítico normalmente abrange os 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 no nível da rede. Em última análise, o método pelo qual a integração de aplicativos é obtida terá um impacto significativo na segurança, no desempenho e na confiabilidade da solução e afetando fortemente as decisões de design em outras áreas de design.

Um aplicativo crítico 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úblicosem conectividade de rede corporativa.
2. Aplicativo públicocom conectividade de rede corporativa.
3. Aplicativo privadocom conectividade de rede corporativa.

Cuidado

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

Esta seção explora esses cenários de integração de rede, camadas no uso apropriado das Redes Virtuais do Azure e nos serviços de rede do Azure para garantir que os requisitos de integração sejam atendidos de forma 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 só percorrerá 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 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, pois muitos serviços, como o AKS, têm um requisito rígido para uma rede virtual subjacente.

Redes virtuais isoladas

• Para atenuar 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 de plataforma do Azure pode ser estabelecida com pontos de extremidade privados, se houver suporte. Se houver 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, implantar a solução em um ambiente de rede isolado fornece flexibilidade máxima de design. Sem restrições de endereçamento e roteamento associadas à integração de rede mais ampla.

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

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

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

Redes virtuais conectadas

• Para cenários com requisitos externos de integração de rede, as redes virtuais de aplicativos podem ser conectadas a outras redes virtuais no Azure, outro provedor de nuvem ou redes locais usando uma variedade de opções de conectividade. Por exemplo, alguns cenários de 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 se alinhar com a arquitetura de rede mais ampla, especialmente em relação a tópicos como endereçamento e roteamento.

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

  • Um recurso de rede virtual pode ser atualizado para considerar o espaço de endereço adicional, no entanto, quando um espaço de endereço de rede virtual de uma rede emparelhada altera uma sincronização no link de emparelhamento é necessária, o que desabilitará temporariamente o emparelhamento.
  • O Azure reserva cinco endereços IP em cada sub-rede, que devem ser considerados ao determinar os tamanhos apropriados para redes virtuais de aplicativo e sub-redes englobadas.
  • Alguns serviços do Azure exigem sub-redes dedicadas, como o Azure Bastion, o Firewall do Azure ou o Gateway de Rede Virtual do Azure. O tamanho dessas sub-redes de serviço é muito importante, pois elas devem ser grandes o suficiente para dar suporte a todas as instâncias atuais do serviço considerando requisitos futuros de escala, mas não tão grandes quanto a endereços de desperdício 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 no Azure WAN Virtual.

Observação

Ao implantar dentro de 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 WAN Virtual ou um design de rede hub-and-spoke.

• A inclusão de caminhos e recursos de rede adicionais introduz considerações adicionais de confiabilidade e operacionais 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 de plataforma do Azure. Os pontos de extremidade de serviço podem ser considerados para serviços que dão suporte a 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 no que diz respeito ao emparelhamento de rede virtual e aos recursos de gateway de rede virtual. Todos os recursos de aplicativo relevantes dentro da rede virtual devem continuar a ser efêmeros, com sub-redes paralelas usadas para facilitar implantações azul-verde de selos de implantação 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 a Internet privada (RFC 1918).
    • Para ambientes com disponibilidade limitada de endereços IP privados (RFC 1918), considere o uso do IPv6.
    • Se o uso de endereço IP público for necessário, verifique se apenas os blocos de endereços de propriedade serão 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 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 do CNI do Azure para integração de rede do AKS, pois ele dá suporte a um conjunto de recursos mais avançado.

  • Considere o Kubenet para cenários com um limite 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. Confira Políticas de rede de micro segmentaçã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 a conectividade segura e escalonável.

  • Verifique se o nível de confiabilidade aplicado à Rota Expressa ou à VPN atende 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 cruzados ou o uso de VPN como um mecanismo de conectividade de failover.

• Verifique se todos os componentes em caminhos de rede críticos estão alinhados com os requisitos de confiabilidade e disponibilidade dos fluxos de usuário associados, independentemente de o gerenciamento desses caminhos e componente associado ser entregue pela equipe de aplicativos das equipes centrais de TI.

  Observação

  Ao implantar dentro de 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 fundamental esteja alinhada com as práticas recomendadas da Microsoft.

• Use o Azure Bastion ou conexões privadas com proxie 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 crítico 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 obtida, garantindo 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 crítico.

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 plano de controle operem conforme o esperado.

• O Azure fornece diferentes métodos diretos de conectividade de saída da Internet, como gateway nat do Azure ou 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 dentro da pilha de rede e, portanto, pode afetar o desempenho do sistema.

• Quando a NAT ocorre em pequena escala, o impacto no desempenho deve ser insignificante, no entanto, se houver um grande número de problemas de rede de solicitações de saída poderá ocorrer. Normalmente, esses problemas vêm na forma de esgotamento da porta 'NAT de origem (ou SNAT)'.

• Em um ambiente multilocatário, como 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 se esgotarem, nenhuma nova conexão de saída poderá ser iniciada. Esse problema pode ser mitigado reduzindo o número de passagens de borda pública/privada ou usando uma solução NAT mais escalonável, como o Gateway da NAT do Azure.

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

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

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

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

Gateway da NAT do Azure

• O Gateway da 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 da 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 inventário de portas SNAT.

• O gateway da 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 de NAT zonais correspondentes.

Recomendações sobre design

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

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

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

  • Verifique se 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 a plataforma fundamental Firewall do Azure recurso (ou NVA equivalente). Se uma dependência for realizada 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 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, será necessário considerar um recurso de Firewall do Azure dedicado para um aplicativo crítico, para atenuar 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 aplicativos dedicados para garantir que as posturas de segurança organizacional sejam observadas por meio de políticas de firewall globais.
• Verifique se as políticas incrementais de firewall são delegadas às equipes de segurança do aplicativo 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 pelo qual a comunicação entre zonas e entre regiões é obtida tem uma influência significativa no desempenho geral e na confiabilidade, que serão exploradas por meio das considerações e recomendações nesta seção.

Considerações de criação

• A abordagem de design do aplicativo para um aplicativo crítico 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 falha física e lógica 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, considerando distâncias variadas e caminhos de fibra entre zonas.

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

• Zonas de Disponibilidade são tratados como entidades lógicas dentro do contexto de uma única assinatura, portanto, assinaturas diferentes podem ter um mapeamento zonal diferente para a mesma região. Por exemplo, a zona 1 na Assinatura A pode corresponder ao mesmo data center físico que a zona 2 na assinatura B.

• A comunicação entre zonas dentro de uma região incorre em uma taxa de transferência de dados por GB de largura de banda.

• Com cenários de aplicativo extremamente tagarelas entre os componentes do aplicativo, a disseminação de camadas de aplicativo entre zonas pode introduzir latência significativa e custos aumentados. É possível atenuar isso dentro do design restringindo um carimbo 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 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 consideradas do Azure.
  • Os continentes de passagem de dados são cobrados a uma taxa consideravelmente maior.

• 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 Link Privado podem ser usados para comunicação direta usando pontos de extremidade privados.

• O tráfego pode ser fixado por meio de circuitos de Rota Expressa usados para conectividade local, a fim de facilitar o roteamento entre redes virtuais em uma região do Azure e em diferentes regiões do Azure na 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 exige saltos de rede adicionais para a integração de aplicativos no Azure, o que introduz riscos de latência e confiabilidade. Expande a função de Express Route e componentes de gateway associados do Azure/local para também abranger a conectividade do Azure/Azure.

• Quando a latência de submilissegundo é necessária entre os serviços, os Grupos de Posicionamento por Proximidade podem ser usados quando compatíveis com os 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 Link Privado para estabelecer a comunicação diretamente entre serviços na mesma região ou entre regiões (serviço na Região A comunicando-se com o serviço na Região B.

• Para 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 "pernas de cachorro" entre regiões diferentes, 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 carimbo inteiro de circulação caso uma única camada de componente crítica falhe, em vez de rotear o tráfego nesse nível de componente defeituoso para outra região.

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

Políticas de rede de micro segmentação e 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, ela é aplicada para reduzir a superfície de ataque de rede, melhorar a contenção de violações e fortalecer a segurança por meio de controles de rede no nível do aplicativo controlados 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 interface de rede, ACL (listas de Controle de Acesso de serviço) e políticas de rede ao usar 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 micro segmentaçã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 da 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. Pools de nós diferentes podem ser implantados em sub-redes diferentes.

  Observação

  A CNI do Azure requer mais espaço de endereço IP em comparação com o Kubenet. O planejamento e o dimensionamento antecipados adequados da rede são necessários. 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 o 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 de nível de 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 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, o Azure e o Calico. Ambos os plug-ins usam IPTables do Linux para impor as políticas especificadas. Confira 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 windows e dá suporte à CNI do Azure, bem como ao Kubenet.

• O AKS dá suporte à criação de pools de nós diferentes para separar cargas de trabalho diferentes usando nós com diferentes características de hardware e software, como nós com e sem funcionalidades 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 micro segmentaçã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 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 por meio do Azure Front Door em um nível de serviço, mas a filtragem baseada em cabeçalho ainda será necessária para garantir o uso de uma instância específica do Front Door e também atenuar 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. Ele é selecionado 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 Serviço de Kubernetes do Azure no momento da implantação.
  • Priorize o uso do Calico porque ele fornece um conjunto de recursos mais avançado com adoção e suporte mais amplos da comunidade.

Próxima etapa

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

Modelagem e observabilidade de integridade