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

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

Esta área de design explora vários tópicos de topologia de rede ao nível da aplicação, tendo em conta a conectividade necessária e a gestão de tráfego redundante. Mais especificamente, destaca considerações e recomendações críticas destinadas a informar a conceção de uma topologia de rede global segura e dimensionável para uma aplicação crítica para a missão.

Importante

Este artigo faz parte da série de cargas de trabalho críticas para a missão do Azure Well-Architected . Se não estiver familiarizado com esta série, recomendamos que comece com o que é uma carga de trabalho crítica para a missão?

Encaminhamento de tráfego global

A utilização de vários selos de implementação regional ativa requer um serviço de encaminhamento global para distribuir o tráfego por cada selo ativo.

O Azure Front Door, o Gestor de Tráfego do Azure e o Azure Balanceador de Carga Standard fornecem as capacidades de encaminhamento necessárias para gerir o tráfego global numa aplicação de várias regiões.

Em alternativa, as tecnologias de encaminhamento global de terceiros podem ser consideradas. Estas opções podem ser trocadas de forma quase totalmente integrada para substituir ou expandir a utilização de serviços de encaminhamento global nativos do Azure. As opções populares incluem tecnologias de encaminhamento por fornecedores de CDN.

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

Considerações de design

• Um serviço de encaminhamento vinculado a uma única região representa um ponto único de falha e um risco significativo no que diz respeito a falhas regionais.

• Se a carga de trabalho da aplicação abranger o controlo de cliente, como aplicações cliente móveis ou de ambiente de trabalho, é possível fornecer redundância de serviço na lógica de encaminhamento do cliente.

  • Várias tecnologias de encaminhamento global, como o Azure Front Door e o Gestor de Tráfego do Azure, podem ser consideradas em paralelo para redundância, com os clientes configurados para efetuar a ativação pós-falha para uma tecnologia alternativa quando determinadas condições de falha são cumpridas. A introdução de vários serviços de encaminhamento global introduz complexidades significativas em torno das capacidades de colocação em cache e Firewall de Aplicações Web de limites, bem como a gestão de certificados para a descarga de SSL e a validação de aplicações para caminhos de entrada.
  • As tecnologias de terceiros também podem ser consideradas, proporcionando resiliência de encaminhamento global a todos os níveis de falhas da plataforma do Azure.

• A disparidade de capacidade entre o Azure Front Door e o Gestor de Tráfego significa que, se as duas tecnologias estiverem posicionadas juntamente entre si para redundância, será necessário um caminho de entrada ou alterações de estrutura diferentes para garantir a manutenção de um nível de serviço consistente e aceitável.

• O Azure Front Door e o Gestor de Tráfego do Azure são serviços distribuídos globalmente com redundância e disponibilidade incorporadas em várias regiões.

  • Os cenários de falha hipotética de uma escala suficientemente grande para ameaçar a disponibilidade global destes serviços de encaminhamento resilientes apresentam um risco mais amplo para a aplicação em termos de falhas em cascata e correlacionadas.
    • Os cenários de falha desta escala só são causados por serviços fundamentais partilhados, como o DNS do Azure ou o ID de Microsoft Entra, que servem como dependências de plataforma global para quase todos os serviços do Azure. Se for aplicada uma tecnologia redundante do Azure, é provável que o serviço secundário também esteja a ter indisponibilidade ou um serviço degradado.
    • Os cenários de falha do serviço de encaminhamento global são altamente propensos a afetar significativamente muitos outros serviços utilizados para componentes principais da aplicação através de dependências intersserviços. Mesmo que seja utilizada uma tecnologia de terceiros, é provável que a aplicação esteja num estado de mau estado de funcionamento devido ao impacto mais amplo do problema subjacente, o que significa que o encaminhamento para pontos finais de aplicações no Azure fornecerá pouco valor.

• A redundância do serviço de encaminhamento global proporciona mitigação para um número extremamente pequeno de cenários de falha hipotética, em que o impacto de uma indisponibilidade global está limitado ao próprio serviço de encaminhamento.

  Para proporcionar uma redundância mais ampla para cenários de indisponibilidade global, pode considerar-se uma abordagem de implementação ativa-ativa de várias cloud. Uma abordagem de implementação ativa-ativa de várias clouds introduz complexidades operacionais significativas, que representam riscos significativos de resiliência, provavelmente superando em muito os riscos hipotéticos de uma falha global.

• Para cenários em que o controlo do cliente não é possível, tem de ser tomada uma dependência num único serviço de encaminhamento global para fornecer um ponto de entrada unificado para todas as regiões de implementação ativas.

  • Quando utilizados isoladamente, representam um ponto único de falha ao nível do serviço devido a dependências globais, embora sejam fornecidas redundância e disponibilidade incorporadas em várias regiões.
  • O SLA fornecido pelo serviço de encaminhamento global selecionado representa o SLA composto máximo alcançável, independentemente do número de regiões de implementação consideradas.

• Quando o controlo 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 encaminhamento global secundário se uma falha global desativar o serviço primário. Migrar de um serviço de encaminhamento global para outro é normalmente um processo demorado que dura várias horas, especialmente quando a propagação de DNS é considerada.

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

  • Embora estes serviços forneçam reparações financeiras para a indisponibilidade, tem pouco significado quando o impacto da indisponibilidade é significativo, como em cenários críticos de segurança em que a vida humana está em jogo. Por conseguinte, a redundância tecnológica ou mitigações operacionais suficientes devem continuar a 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 com o protocolo Anycast com TCP dividido para tirar partido da rede principal global da Microsoft.

  • São mantidas várias ligações para cada um dos pontos finais de back-end.
  • Os pedidos de cliente recebidos são terminados pela primeira vez no nó edge mais próximo do cliente de origem.
  • Após qualquer inspeção de tráfego necessária, os pedidos são reencaminhados sobre o backbone da Microsoft para o back-end adequado com ligações existentes ou servidos a partir da cache interna de um nó de extremidade.
  • Esta abordagem é muito eficiente na distribuição de volumes de tráfego elevados através das ligações de back-end.

• Fornece uma cache incorporada que serve conteúdo estático a partir de nós de extremidade. Em muitos casos de utilização, isto também pode eliminar a necessidade de uma Rede de Entrega de Conteúdos (CDN) dedicada.

• O Azure Firewall de Aplicações Web (WAF) pode ser utilizado no Azure Front Door e, uma vez que está implementado em localizações de limite de rede do Azure em todo o mundo, todos os pedidos recebidos entregues pelo Front Door na periferia da rede são inspecionados.

• O Azure Front Door protege os pontos finais da aplicação contra ataques DDoS com a proteção do Azure DDoS Basic. O Azure DDoS Standard fornece capacidades de proteção e deteção adicionais e mais avançadas e pode ser adicionado como uma camada adicional ao Azure Front Door.

• O Azure Front Door oferece um serviço de certificados totalmente gerido. Ativa a segurança da ligação TLS para pontos finais sem ter de gerir o ciclo de vida do certificado.

• O Azure Front Door Premium suporta pontos finais privados, permitindo que o tráfego flua diretamente da Internet para redes virtuais do Azure. Isto eliminaria a necessidade de utilizar IPs públicos na VNet para tornar os back-end acessíveis através do Azure Front Door Premium.

• O Azure Front Door baseia-se em pesquisas de estado de funcionamento e pontos finais de estado de funcionamento de back-end (URLs) que são chamados numa base de intervalo para devolver um código de estado HTTP que reflete se o back-end está a funcionar normalmente, com uma resposta HTTP 200 (OK) a refletir um estado de funcionamento. Assim que um back-end refletir um estado de mau estado de funcionamento, na perspetiva de um determinado nó de extremidade, esse nó de extremidade deixará de enviar pedidos para lá. Os back-ends em mau estado de funcionamento são, portanto, removidos de forma transparente da circulação de tráfego sem qualquer atraso.

• Suporta apenas protocolos HTTP/S.

• A WAF do Azure Front Door e Gateway de Aplicação WAF fornecem um conjunto de funcionalidades ligeiramente diferente, embora suportem regras incorporadas e personalizadas e podem ser definidas para funcionar no modo de deteção ou no modo de prevenção.

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

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

  • Baseado na latência: a predefinição que encaminha o tráfego para o back-end "mais próximo" do cliente; com base na latência do pedido.
  • Baseado na prioridade: útil para configurações ativas passivas, em que o tráfego tem de ser sempre enviado para um back-end primário, a menos que não esteja disponível.
  • Ponderada: aplicável a implementações canárias em que uma determinada percentagem de tráfego é enviada para um back-end específico. Se vários back-ends tiverem os mesmos pesos atribuídos, é utilizado o encaminhamento baseado em latência.

• Por predefinição, o Azure Front Door utiliza o encaminhamento 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, consoante a origem dos clientes.

• Se uma série de pedidos de cliente tiver de ser processado pelo mesmo back-end, a Afinidade de Sessão pode ser configurada no front-end. Utiliza um cookie do lado do cliente para enviar pedidos subsequentes para o mesmo back-end que o primeiro pedido, desde que o back-end ainda esteja disponível.

Gestor de Tráfego do Azure

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

  • O payload do pedido real não é processado, mas, em vez disso, o Gestor de Tráfego devolve o nome DNS de um dos back-ends do conjunto, com base em regras configuradas para o método de encaminhamento de tráfego selecionado.
  • Em seguida, o nome DNS de back-end é resolvido para o endereço IP final que é posteriormente chamado diretamente pelo cliente.

• A resposta DNS é colocada em cache e reutilizada pelo cliente para um período de TTL (Time To Live) especificado e os pedidos efetuados durante este período irão diretamente para o ponto final de back-end sem interação do Gestor de Tráfego. Elimina o passo de conectividade adicional que proporciona benefícios de custos em comparação com o Front Door.

• Uma vez que o pedido é feito diretamente do cliente para o serviço de back-end, qualquer protocolo suportado pelo back-end pode ser aproveitado.

• À semelhança do Azure Front Door, o Gestor de Tráfego do Azure também depende de sondas de estado de funcionamento para compreender se um back-end está em bom estado de funcionamento e a funcionar normalmente. Se for devolvido outro valor ou não for devolvido nada, o serviço de encaminhamento reconhece problemas contínuos e deixará de encaminhar pedidos para esse back-end específico.

  • No entanto, ao contrário do Azure Front Door, esta remoção de back-end em mau estado de funcionamento não é instantânea, uma vez que os clientes continuarão a criar ligações para o back-end em mau estado de funcionamento até que o TTL do DNS expire e seja pedido um novo ponto final de back-end ao serviço Gestor de Tráfego.
  • Além disso, mesmo quando o TTL expira, não há garantias de que os servidores DNS públicos vão respeitar este valor, pelo que a propagação do DNS pode demorar muito mais tempo a ocorrer. Isto significa que o tráfego pode continuar a ser enviado para o ponto final em mau estado de funcionamento durante um período de tempo sustentado.

Balanceador de Carga Standard do Azure

Importante

A Balanceador de Carga Standard entre regiões está disponível em pré-visualização com limitações técnicas. Esta opção não é recomendada para cargas de trabalho críticas para a missão.

Recomendações de conceção

• Utilize o Azure Front Door como o principal serviço de encaminhamento de tráfego global para cenários HTTP/S. O Azure Front Door é fortemente defendido para cargas de trabalho HTTP/S, uma vez que fornece encaminhamento de tráfego otimizado, ativação pós-falha transparente, pontos finais de back-end privados (com o SKU Premium), colocação em cache de limites e integração com Firewall de Aplicações Web (WAF).

• Para cenários de aplicação em que o controlo de cliente é possível, aplique a lógica de encaminhamento do lado do cliente para considerar cenários de ativação pós-falha em que a tecnologia de encaminhamento global principal falha. Duas ou mais tecnologias globais de encaminhamento devem ser posicionadas em paralelo para redundância adicional, se o SLA de serviço único não for suficiente. A lógica de cliente é necessária para encaminhar para a tecnologia redundante em caso de falha de serviço global.

  • Devem ser utilizados dois URLs distintos, com um aplicado a cada um dos diferentes serviços de encaminhamento global para simplificar a experiência geral de gestão de certificados e a lógica de encaminhamento para uma ativação pós-falha.
  • Priorize a utilização de tecnologias de encaminhamento de terceiros como o serviço de ativação pós-falha secundário, uma vez que isto irá mitigar o maior número de cenários de falha global e as capacidades oferecidas pelos principais fornecedores de CDN do setor permitirão uma abordagem de conceção consistente.
  • Deve igualmente ter em consideração o encaminhamento direto para um único selo regional em vez de um serviço de encaminhamento separado. Embora isto resulte num 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 a ativação pós-falha do cliente com o Azure Front Door como balanceador de carga global primário.

Configuração da para a para a Missão

Importante

Para mitigar verdadeiramente o risco de falhas globais na plataforma do Azure, deve considerar-se uma abordagem de implementação ativa-ativa multi cloud, com selos de implementação ativos alojados em dois ou mais fornecedores de cloud e tecnologias de encaminhamento redundantes de terceiros utilizadas para o encaminhamento global.

O Azure pode ser integrado eficazmente noutras plataformas na cloud. No entanto, recomenda-se vivamente que não aplique uma abordagem multi-cloud porque introduz uma complexidade operacional significativa, com diferentes definições de carimbos de implementação e representações de estado de funcionamento operacional nas diferentes plataformas da cloud. Esta complexidade, por sua vez, apresenta inúmeros riscos de resiliência no âmbito do funcionamento normal da aplicação, que superam largamente os riscos hipotéticos de uma indisponibilidade da plataforma global.

• Embora não seja recomendado, para cargas de trabalho HTTP(s) que utilizam o Gestor de Tráfego do Azure para redundância de encaminhamento global para o Azure Front Door, considere descarregar Firewall de Aplicações Web (WAF) para Gateway de Aplicação para tráfego aceitável que flua através do Azure Front Door.
  • Isto irá introduzir um ponto de falha adicional para o caminho de entrada padrão, um componente de caminho crítico adicional para gerir e dimensionar, e também irá incorrer em custos adicionais para garantir a elevada disponibilidade global. No entanto, simplificará consideravelmente o cenário de falha ao fornecer consistência entre os caminhos de entrada aceitáveis e não aceitáveis através do Azure Front Door e do Gestor de Tráfego do Azure, tanto em termos de execução de WAF como de pontos finais de aplicações privados.
  • A perda de colocação em cache de arestas num cenário de falha afetará o desempenho global, o que tem de estar alinhado com um nível de serviço aceitável ou uma abordagem de conceção mitigadora. Para garantir um nível de serviço consistente, considere descarregar a colocação em cache de limites para um fornecedor de CDN de terceiros para ambos os caminhos.

Recomenda-se considerar um serviço de encaminhamento global de terceiros em vez de dois serviços de encaminhamento global do Azure. Isto fornece o nível máximo de mitigação de falhas e uma abordagem de design mais simples, uma vez que a maioria dos fornecedores de CDN líderes do setor oferecem capacidades edge em grande parte consistentes com as oferecidas pelo Azure Front Door.

Azure Front Door

• Utilize o serviço de certificados geridos do Azure Front Door para ativar as ligações TLS e remova a necessidade de gerir os ciclos de vida dos certificados.

• Utilize o Firewall de Aplicações Web do Azure Front Door (WAF) para fornecer proteção no limite contra exploits e vulnerabilidades comuns da Web, como a injeção de SQL.

• Utilize a cache incorporada do Azure Front Door para servir conteúdo estático a partir de nós de extremidade.

  • Na maioria dos casos, isto também eliminará a necessidade de uma Rede de Entrega de Conteúdos (CDN) dedicada.

• Configure os pontos de entrada da plataforma de aplicação para validar os pedidos recebidos através da filtragem baseada em cabeçalhos com o X-Azure-FDID para garantir que todo o tráfego está a fluir através da instância configurada do Front Door. Considere também configurar a ACLing ip com Etiquetas de Serviço do Front Door para validar o tráfego proveniente do espaço de endereços IP de back-end do Azure Front Door e dos serviços de infraestrutura do Azure. Isto irá garantir que o tráfego flui através do Azure Front Door ao nível do serviço, mas a filtragem baseada em cabeçalhos continuará a ser necessária para garantir a utilização de uma instância configurada do Front Door.

• Defina um ponto final de estado de funcionamento TCP personalizado para validar dependências críticas a jusante num carimbo de implementação regional, incluindo réplicas da plataforma de dados, como o Azure Cosmos DB, no exemplo fornecido pela implementação de referência fundamental. Se uma ou mais dependências ficarem em mau estado de funcionamento, a sonda de estado de funcionamento deverá refletir isso na resposta devolvida para que todo o carimbo regional possa ser retirado da circulação.

• Certifique-se de que as respostas da pesquisa de estado de funcionamento são registadas e ingerir todos os dados operacionais expostos pelo Azure Front Door na área de trabalho global do Log Analytics para facilitar um sink de dados unificado e uma única vista operacional em toda a aplicação.

• A menos que a carga de trabalho seja extremamente sensível à latência, espalhe o tráfego uniformemente em todos os selos regionais considerados para utilizar os recursos implementados de forma mais eficaz.

  • Para tal, defina o parâmetro "Sensibilidade à Latência (Latência Adicional)" para um valor suficientemente alto para satisfazer as diferenças de latência entre as diferentes regiões dos back-ends. Confirme uma tolerância aceitável para a carga de trabalho da aplicação relativamente à latência geral do pedido de cliente.

• Não ative a Afinidade de Sessão, a menos que seja necessária pela aplicação, uma vez que pode ter um impacto negativo no equilíbrio da distribuição de tráfego. Com uma aplicação totalmente sem estado, se for seguida a abordagem de conceção de aplicações críticas para a missão recomendada, qualquer pedido poderá ser processado por qualquer uma das implementações regionais.

Gestor de Tráfego do Azure

• Utilize o Gestor de Tráfego para cenários não HTTP/S como substituição do Azure Front Door. As diferenças de capacidade irão impulsionar diferentes decisões de design para capacidades de cache e WAF e gestão de certificados TLS.

• As capacidades waf devem ser consideradas em cada região para o caminho de entrada do Gestor de Tráfego, com Gateway de Aplicação do Azure.

• Configure um valor TTL convenientemente baixo para otimizar o tempo necessário para remover um ponto final de back-end em mau estado de funcionamento da circulação no caso de o back-end ficar em mau estado de funcionamento.

• Tal como acontece com o Azure Front Door, deve ser definido um ponto final de estado de funcionamento TCP personalizado para validar dependências críticas a jusante dentro de um carimbo de implementação regional, que deve ser refletido na resposta fornecida pelos pontos finais de estado de funcionamento.

  No entanto, para o Gestor de Tráfego, deve ser dada uma consideração adicional à ativação pós-falha regional ao nível do serviço. como "pernas para cães", para mitigar o potencial atraso associado à remoção de um back-end em mau estado de funcionamento devido a falhas de dependência, especialmente se não for possível definir um TTL baixo para registos DNS.

• Deve ter em consideração os fornecedores de CDN de terceiros para alcançar a colocação em cache de limites ao utilizar o Gestor de Tráfego do Azure como um serviço de encaminhamento global primário. Quando as capacidades de WAF edge também são oferecidas pelo serviço de terceiros, deve ter em consideração para simplificar o caminho de entrada e potencialmente remover a necessidade de Gateway de Aplicação.

Serviços de entrega de aplicações

O caminho de entrada de rede para uma aplicação crítica para a missão também tem de considerar os serviços de entrega de aplicações para garantir tráfego de entrada seguro, fiável e dimensionável.

Esta secção baseia-se em recomendações de encaminhamento global ao explorar as principais capacidades de entrega de aplicações, tendo em conta serviços relevantes como o Azure Balanceador de Carga Standard, Gateway de Aplicação do Azure e Gestão de API do Azure.

Considerações de design

• A encriptação TLS é fundamental para garantir a integridade do tráfego de utilizador de entrada para uma aplicação crítica para a missão, com a Descarga de TLS aplicada apenas no ponto de entrada de um carimbo para desencriptar o tráfego de entrada. A Descarga de TLS Requer a chave privada do certificado TLS para desencriptar o tráfego.

• Um Firewall de Aplicações Web fornece proteção contra exploits e vulnerabilidades comuns da Web, como a injeção de SQL ou scripting entre sites, e é essencial para alcançar as aspirações de fiabilidade máximas de uma aplicação crítica para a missão.

• O Azure WAF fornece proteção fora da caixa contra as 10 principais vulnerabilidades OWASP através de conjuntos de regras geridas.

  • As regras personalizadas também podem ser adicionadas para expandir o conjunto de regras geridas.
  • O Azure WAF pode ser ativado no Azure Front Door, Gateway de Aplicação do Azure ou na CDN do Azure (atualmente em pré-visualização pública).
    • As funcionalidades oferecidas em cada um dos serviços diferem ligeiramente. Por exemplo, a WAF do Azure Front Door fornece limitação de taxas, filtragem geográfica e proteção de bots, que ainda não estão disponíveis no Gateway de Aplicação WAF. No entanto, todas suportam regras incorporadas e personalizadas e podem ser definidas para funcionar no modo de deteção ou no modo de prevenção.
    • O mapa de objetivos do Azure WAF garantirá que é fornecido um conjunto de funcionalidades WAF consistente em todas as integrações de serviços.

• As tecnologias WAF de terceiros, como NVAs e controladores de entrada avançados no Kubernetes, também podem ser consideradas para fornecer proteção de vulnerabilidades necessária.

• Normalmente, a configuração de WAF ideal requer otimização, independentemente da tecnologia utilizada.

  Azure Front Door

• O Azure Front Door só aceita tráfego HTTP e HTTPS e só processará pedidos com um cabeçalho conhecido Host . Este bloqueio de protocolo ajuda a mitigar ataques volumetricos distribuídos por protocolos e portas, bem como ataques de amplificação DNS e envenenamento de TCP.

• O Azure Front Door é um recurso global do Azure, pelo que a configuração é implementada globalmente em todas as localizações edge.

  • A configuração de recursos pode ser distribuída em grande escala para processar centenas de milhares de pedidos por segundo.
  • Atualizações à configuração, incluindo rotas e conjuntos de back-end, são totalmente integradas e não causarão qualquer período de inatividade durante a implementação.

• O Azure Front Door fornece um serviço de certificados totalmente gerido e um método bring-your-own-certificate para os certificados SSL destinados ao cliente. O serviço de certificados totalmente gerido fornece uma abordagem operacional simplificada e ajuda a reduzir a complexidade na conceção geral ao efetuar a gestão de certificados numa única área da solução.

• O Azure Front Door roda automaticamente certificados "Geridos" pelo menos 60 dias antes da expiração do certificado para proteger contra riscos de certificado expirado. Se forem utilizados certificados autogeridos, os certificados atualizados devem ser implementados o mais tardar 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 certificados só resultarão em tempo de inatividade se o Azure Front Door estiver alternado entre "Gerido" e "Utilizar o Seu Próprio Certificado".

• O Azure Front Door está protegido pelo Azure DDoS Protection Basic, que está integrado no Front Door por predefinição. Isto fornece monitorização de tráfego sempre ativada, mitigação em tempo real e também defende contra inundações comuns de consultas DNS de Camada 7 ou ataques volumetricos de Camada 3/4.

  • Estas proteções ajudam a manter a disponibilidade do Azure Front Door mesmo quando confrontados com um ataque DDoS. Os ataques Denial of Service distribuídos (DDoS) podem tornar um recurso de destino indisponível ao sobrecarregá-lo com tráfego ilegítimo.

• O Azure Front Door também fornece capacidades WAF ao nível do tráfego global, enquanto Gateway de Aplicação WAF tem de ser fornecido em cada selo de implementação regional. As capacidades incluem conjuntos de regras de firewall para proteger contra ataques comuns, filtragem geográfica, bloqueio de endereços, limitação de taxas e correspondência de assinaturas.

  Balanceador de Carga do Azure

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

Recomendações de conceção

• Efetue a Descarga de TLS no menor número possível de locais para manter a segurança, ao mesmo tempo que simplifica o ciclo de vida da gestão de certificados.

• Utilize ligações encriptadas (por exemplo, HTTPS) a partir do ponto em que a descarga de TLS ocorre nos back-ends reais da aplicação. Os pontos finais da aplicação não serão visíveis para os utilizadores finais, pelo que os domínios geridos pelo Azure, como azurewebsites.net ou cloudapp.net, podem ser utilizados com certificados geridos.

• Para tráfego HTTP(S), certifique-se de que as capacidades WAF são aplicadas dentro do caminho de entrada para todos os pontos finais expostos publicamente.

• Ative as capacidades WAF numa única localização de serviço, seja globalmente com o Azure Front Door ou regionalmente com Gateway de Aplicação do Azure, uma vez que isto simplifica a otimização da configuração e otimiza o desempenho e o custo.

  Configure a WAF no modo de Prevenção para bloquear diretamente ataques. Utilize apenas WAF no modo de Deteção (ou seja, apenas registo, mas não bloquear pedidos suspeitos) quando a penalização de desempenho do modo de Prevenção for demasiado elevada. O risco adicional implícito tem de ser totalmente compreendido e alinhado com os requisitos específicos do cenário de carga de trabalho.

• Priorize a utilização da WAF do Azure Front Door, uma vez que fornece o conjunto de funcionalidades nativo do Azure mais rico e aplica proteções no limite global, o que simplifica a conceção geral e impulsiona mais eficiências.

• Utilize o Azure Gestão de API apenas ao expor um grande número de APIs a clientes externos ou a equipas de aplicações diferentes.

• Utilize o SKU do Azure Balanceador de Carga Standard para qualquer cenário de distribuição de tráfego interno nas cargas de trabalho de microsserviços.

  • Fornece um SLA de 99,99% quando implementado em Zonas de Disponibilidade.
  • Fornece capacidades críticas, como diagnósticos ou regras de saída.

• Utilize a Proteção de Rede do DDoS do Azure para ajudar a proteger os pontos finais públicos alojados em cada rede virtual da aplicação.

Colocação em cache e entrega de conteúdo estático

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

Considerações de design

• Nem todos os conteúdos que uma solução disponibiliza através da Internet são gerados dinamicamente. As aplicações servem recursos estáticos (imagens, JavaScript, CSS, ficheiros de localização, etc.) e conteúdo dinâmico.
• As cargas de trabalho com conteúdo estático acedido frequentemente beneficiam bastante da colocação em cache, uma vez que reduz a carga nos serviços de back-end e reduz a latência de acesso a conteúdos para os utilizadores finais.
• A colocação em cache pode ser implementada nativamente no Azure com o Azure Front Door ou a Rede de Entrega de Conteúdos (CDN) do Azure.
  • O Azure Front Door fornece funcionalidades de colocação em cache de extremidade nativa do Azure e funcionalidades de encaminhamento para dividir conteúdo estático e dinâmico.
    • Ao criar as regras de encaminhamento adequadas no Azure Front Door, /static/* o tráfego pode ser redirecionado de forma transparente para conteúdo estático.
  • Cenários de colocação em cache mais complexos podem ser implementados com o serviço CDN do Azure para estabelecer uma rede de entrega de conteúdos completa para volumes de conteúdo estáticos significativos.
    • O serviço da CDN do Azure será provavelmente mais rentável, mas não fornece as mesmas capacidades avançadas de encaminhamento e Firewall de Aplicações Web (WAF) que são recomendadas para outras áreas de design de uma aplicação. No entanto, oferece maior flexibilidade para se integrar com serviços semelhantes de soluções de terceiros, como a Akamai e a Verizon.
  • Ao comparar os serviços do Azure Front Door e da CDN do Azure, devem ser explorados os seguintes fatores de decisão:
    • As regras de colocação em cache necessárias podem ser efetuadas com o motor de regras.
    • Tamanho do conteúdo armazenado e do custo associado.
    • Preço por mês para a execução do motor de regras (cobrado por pedido no Azure Front Door).
    • Requisitos de tráfego de saída (o preço é diferente por destino).

Recomendações de conceção

• Os conteúdos estáticos gerados, como cópias dimensionadas de ficheiros de imagem que nunca ou apenas raramente alteram, também podem beneficiar da colocação em cache. A colocação em cache pode ser configurada com base em parâmetros de URL e com uma duração de colocação em cache variável.
• Separe a entrega de conteúdos estáticos e dinâmicos aos utilizadores e forneça conteúdos relevantes de uma cache para reduzir a carga nos serviços de back-end para otimizar o desempenho dos utilizadores finais.
• Tendo em conta a forte recomendação (área de design de rede e conectividade) para utilizar o Azure Front Door para fins globais de encaminhamento e Firewall de Aplicações Web (WAF), recomenda-se que priorize a utilização das capacidades de colocação em cache do Azure Front Door, a menos que existam lacunas.

Integração da rede virtual

Normalmente, uma aplicação crítica para a missão abrange os requisitos de integração com outras aplicações ou sistemas dependentes, que podem ser alojados no Azure, noutra cloud pública ou datacenters no local. Esta integração de aplicações pode ser realizada através de pontos finais destinados ao público e da Internet ou redes privadas através da integração ao nível da rede. Em última análise, o método através do qual a integração de aplicações é alcançada terá um impacto significativo na segurança, desempenho e fiabilidade da solução e afetará fortemente as decisões de conceção noutras áreas de design.

Uma aplicação crítica para a missão pode ser implementada dentro de uma de três configurações de rede abrangentes, que determina como a integração de aplicações pode ocorrer ao nível da rede.

1. Aplicação públicasem conectividade de rede empresarial.
2. Aplicação públicacom conectividade de rede empresarial.
3. Aplicação privadacom conectividade de rede empresarial.

Atenção

Ao implementar numa zona de destino do Azure, configuração 1. deve ser implementado numa Zona de Destino Online, enquanto 2) e 3) devem ser implementados numa Corp. Zona de Destino Ligada para facilitar a integração ao nível da rede.

Esta secção explora estes cenários de integração de rede, colocando em camadas a utilização adequada das Redes Virtuais do Azure e dos serviços de rede do Azure adjacentes para garantir que os requisitos de integração são otimizados.

Considerações sobre Design

Sem redes virtuais

• A abordagem de conceção mais simples é não implementar a aplicação numa rede virtual.

  • A conectividade entre todos os serviços considerados do Azure será fornecida inteiramente através de pontos finais públicos e do backbone do Microsoft Azure. A conectividade entre pontos finais públicos alojados no Azure só atravessará o backbone da Microsoft e não passará pela Internet pública.
  • A conectividade a quaisquer sistemas externos fora do Azure será fornecida pela Internet pública.

• Esta abordagem de conceção adota a "identidade como perímetro de segurança" para fornecer controlo de acesso entre os vários componentes do serviço e a solução dependente. Esta pode ser uma solução aceitável para cenários menos sensíveis à segurança. Todos os serviços de aplicações e dependências são acessíveis através de um ponto final público, o que os deixa vulneráveis a vetores de ataque adicionais orientados para obter acesso não autorizado.

• Esta abordagem de conceção também não é aplicável a todos os serviços do Azure, uma vez que muitos serviços, como o AKS, têm um requisito difícil para uma rede virtual subjacente.

Redes virtuais isoladas

• Para mitigar os riscos associados a pontos finais públicos desnecessários, a aplicação pode ser implementada numa rede autónoma que não esteja ligada a outras redes.

• Os pedidos de cliente recebidos continuarão a exigir que um ponto final público seja exposto à Internet. No entanto, todas as comunicações subsequentes podem estar na rede virtual através de pontos finais privados. Ao utilizar o Azure Front Door Premium, é possível encaminhar diretamente dos nós edge para pontos finais de aplicações privadas.

• Embora a conectividade privada entre componentes da aplicação ocorra através de redes virtuais, toda a conectividade com dependências externas continuará a depender de pontos finais públicos.

  • A conectividade aos serviços da plataforma do Azure pode ser estabelecida com Pontos Finais Privados, se suportado. Se existirem outras dependências externas no Azure, como outra aplicação a jusante, a conectividade será fornecida através de pontos finais públicos e do backbone do Microsoft Azure.
  • A conectividade a quaisquer sistemas externos fora do Azure seria fornecida pela Internet pública.

• Para cenários em que não existem requisitos de integração de rede para dependências externas, a implementação da solução num ambiente de rede isolado proporciona a máxima flexibilidade de conceção. Sem restrições de endereçamento e encaminhamento associadas a uma integração de rede mais ampla.

• O Azure Bastion é um serviço PaaS totalmente gerido pela plataforma que pode ser implementado numa rede virtual e fornece conectividade RDP/SSH segura às VMs do Azure. Quando se liga através do Azure Bastion, as máquinas virtuais não precisam de um endereço IP público.

• A utilização de redes virtuais de aplicações introduz complexidades de implementação significativas nos pipelines de CI/CD, uma vez que tanto o plano de dados como o plano de controlo têm de aceder aos recursos alojados em redes privadas para facilitar as implementações de aplicações.

  • Tem de ser estabelecido um caminho de rede privada seguro para permitir que as ferramentas CI/CD executem as ações necessárias.
  • Os agentes de compilação privadas podem ser implementados em redes virtuais de aplicações para acesso proxy a recursos protegidos pela rede virtual.

Redes virtuais ligadas

• Para cenários com requisitos de integração de rede externa, as redes virtuais de aplicações podem ser ligadas a outras redes virtuais no Azure, outro fornecedor de cloud ou redes no local com uma variedade de opções de conectividade. Por exemplo, alguns cenários de aplicações podem considerar a integração ao nível da aplicação com outras aplicações de linha de negócio alojadas em privado numa rede empresarial no local.

• A estrutura da rede de aplicações tem de estar alinhada com a arquitetura de rede mais ampla, especialmente no que diz respeito a tópicos como o endereçamento e o encaminhamento.

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

  • Um recurso de rede virtual pode ser atualizado para considerar um espaço de endereços adicional, no entanto, quando um espaço de endereços de rede virtual de uma rede em modo de peering altera uma sincronização na ligação de peering é necessário, o que irá desativar temporariamente o peering.
  • O Azure reserva cinco endereços IP em cada sub-rede, que devem ser considerados ao determinar tamanhos adequados para redes virtuais de aplicações e sub-redes englobadas.
  • Alguns serviços do Azure necessitam de sub-redes dedicadas, como o Azure Bastion, o Azure Firewall ou o Gateway de Rede Virtual do Azure. O tamanho destas sub-redes de serviço é muito importante, uma vez que devem ser suficientemente grandes para suportar todas as instâncias atuais do serviço, considerando requisitos de dimensionamento futuros, mas não tão grandes quanto a endereços desnecessariamente desperdiçados.

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

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

Nota

Ao implementar numa zona de destino do Azure, tenha em atenção que qualquer conectividade necessária às redes no local deve ser fornecida pela implementação da zona de destino. A estrutura pode utilizar o ExpressRoute e outras redes virtuais no Azure com 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 fiabilidade adicionais para a aplicação para garantir a manutenção do estado de funcionamento.

Recomendações de conceção

• Recomenda-se que as soluções fundamentais para a missão sejam implementadas nas redes virtuais do Azure sempre que possível para remover pontos finais públicos desnecessários, limitando a superfície de ataque da aplicação para maximizar a segurança e a fiabilidade.

  • Utilize Pontos Finais Privados para conectividade com os serviços de plataforma do Azure. Os Pontos Finais de Serviço podem ser considerados para serviços que suportam Private Link, desde que os riscos de exfiltração de dados sejam aceitáveis ou mitigados através de controlos alternativos.

• Para cenários de aplicações que não requerem conectividade de rede empresarial, trate todas as redes virtuais como recursos efémeros que são substituídos quando é realizada uma nova implementação regional.

• Ao ligar a outras redes do Azure ou no local, as redes virtuais de aplicações não devem ser tratadas como efémeras, uma vez que cria complicações significativas no que diz respeito ao peering de rede virtual e aos recursos do gateway de rede virtual. Todos os recursos de aplicação relevantes na rede virtual devem continuar a ser efémeros, com sub-redes paralelas utilizadas para facilitar implementações a azul-verde de selos de implementação regional atualizados.

• Em cenários em que a conectividade de rede empresarial é necessária para facilitar a integração de aplicações em redes privadas, certifique-se de que o espaço de endereços IPv4 utilizado para redes virtuais de aplicações regionais não se sobrepõe a outras redes ligadas e está devidamente dimensionado para facilitar o dimensionamento necessário sem ter de atualizar o recurso de rede virtual e incorrer em tempo de inatividade.

  • Recomenda-se vivamente que utilize apenas endereços IP da alocação de endereços para a Internet privada (RFC 1918).
    • Para ambientes com uma disponibilidade limitada de endereços IP privados (RFC 1918), considere utilizar o IPv6.
    • Se a utilização do endereço IP público for necessária, certifique-se de que apenas são utilizados blocos de endereços pertencentes.
  • Alinhe-se com os planos de organização para endereçamento IP no Azure para garantir que o espaço de endereços IP da rede de aplicações não se sobrepõe a outras redes em localizações no local ou regiões do Azure.
  • Não crie redes virtuais de aplicações desnecessariamente grandes para garantir que o espaço de endereços IP não é desperdiçado.

• Priorize a utilização do CNI do Azure para integração de rede do AKS, uma vez que suporta um conjunto de funcionalidades mais avançado.

  • Considere o Kubenet para cenários com um limite limitado de endereços IP disponíveis para se ajustarem à aplicação num espaço de endereços restrito.

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

• Para cenários que exijam a integração de rede no local, priorize a utilização do Express Route para garantir uma conectividade segura e dimensionável.

  • Certifique-se de que o nível de fiabilidade aplicado ao Express Route ou VPN cumpre totalmente os requisitos da aplicação.
  • Devem ser considerados vários caminhos de rede para fornecer redundância adicional quando necessário, como circuitos do ExpressRoute ligados cruzados ou a utilização de VPN como um mecanismo de conectividade de ativação pós-falha.

• Certifique-se de que todos os componentes em caminhos de rede críticos estão em conformidade com os requisitos de fiabilidade e disponibilidade dos fluxos de utilizador associados, independentemente de a gestão destes caminhos e componente associado ser fornecida pela equipa de aplicações das equipas de TI centrais.

  Nota

  Ao implementar numa zona de destino do Azure e integrar com uma topologia de rede organizacional mais ampla, considere a documentação de orientação de rede para garantir que a rede de base está alinhada com as melhores práticas da Microsoft.

• Utilize o Azure Bastion ou ligações privadas com proxies para aceder ao plano de dados dos recursos do Azure ou realizar operações de gestão.

Saída da Internet

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

1. Interação direta do utilizador da aplicação.
2. Integração de aplicações com dependências externas fora do Azure.
3. Acesso a dependências externas exigidas pelos serviços do Azure utilizados pela aplicação.

Esta secção explora a forma como a saída da Internet pode ser alcançada, garantindo simultaneamente a manutenção da segurança, fiabilidade e desempenho sustentável, destacando os principais requisitos de saída dos serviços recomendados num contexto crítico para a missão.

Considerações sobre Design

• Muitos serviços do Azure necessitam de acesso a pontos finais públicos para que várias funções do plano de gestão e controlo funcionem conforme pretendido.

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

• Quando o tráfego de uma rede virtual é encaminhado para a Internet, a Tradução de Endereços de Rede (NAT) tem de ocorrer. Esta é uma operação de computação que ocorre dentro da pilha de rede e que pode, portanto, afetar o desempenho do sistema.

• Quando o NAT ocorre a uma pequena escala, o impacto no desempenho deve ser insignificante, no entanto, se existirem um grande número de problemas de rede de pedidos de saída. Normalmente, estes problemas surgem sob a forma de "Esgotamento da porta NAT de Origem (ou SNAT)".

• Num ambiente multi-inquilino, como Serviço de Aplicações do Azure, existe um número limitado de portas de saída disponíveis para cada instância. Se estas portas se esgotarem, não poderão ser iniciadas novas ligações de saída. Este problema pode ser mitigado ao reduzir o número de percursos edge privados/públicos ou através de uma solução NAT mais dimensionável, como o NAT Gateway do Azure.

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

  • Azure Firewall fornece as capacidades de segurança adequadas para proteger a saída de rede.

  • Azure Firewall (ou uma NVA equivalente) podem ser utilizadas para proteger os requisitos de saída do Kubernetes ao fornecer controlo granular sobre fluxos de tráfego de saída.

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

Azure NAT Gateway

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

  • Podem ser atribuídos até 16 endereços IP a um único nat gateway.
  • Um tempo limite de inatividade de TCP predefinido de 4 minutos. Se o tempo limite de inatividade for alterado para um valor mais elevado, os fluxos serão mantidos durante mais tempo, o que aumentará a pressão sobre o inventário de portas SNAT.

• O NAT Gateway não consegue fornecer isolamento zonal fora da caixa. Para obter redundância zonal, uma sub-rede que contenha recursos zonais tem de estar alinhada com os gateways NAT zonais correspondentes.

Recomendações de conceção

• Minimize o número de ligações à Internet de saída, uma vez que isso afetará o desempenho do NAT.

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

• Utilize Azure Firewall quando existirem requisitos para controlar e inspecionar o tráfego de saída da Internet.

  • Confirme Azure Firewall não é utilizado para inspecionar o tráfego entre os serviços do Azure.

Nota

Ao implementar numa zona de destino do Azure, considere utilizar a plataforma base Azure Firewall recurso (ou NVA equivalente). Se for criada uma dependência num recurso de plataforma central para saída da Internet, o nível de fiabilidade desse recurso e o caminho de rede associado devem estar estreitamente alinhados com os requisitos da aplicação. Os dados operacionais do recurso também devem ser disponibilizados à aplicação para informar potenciais ações operacionais em cenários de falha.

Se existirem requisitos de grande escala associados ao tráfego de saída, deve ter em consideração um recurso de Azure Firewall dedicado para uma aplicação crítica para a missão, para mitigar os riscos associados à utilização de um recurso partilhado centralmente, como cenários de vizinho ruidoso.

• Quando implementado num ambiente WAN Virtual, deve ter em consideração o Firewall Manager para fornecer uma gestão centralizada de instâncias de Azure Firewall de aplicações dedicadas para garantir que as posturas de segurança organizacional são observadas através de políticas de firewall globais.
• Confirme que as políticas de firewall incremental são delegadas às equipas de segurança de aplicações através do controlo de acesso baseado em funções para permitir a autonomia da política de aplicações.

Conectividade entre zonas e entre regiões

Embora a conceção da aplicação defenda fortemente selos de implementação regional independentes, muitos cenários de aplicações ainda podem exigir a integração de rede entre componentes de aplicações implementados 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 um impacto significativo no desempenho e fiabilidade globais, que serão explorados através das considerações e recomendações nesta secção.

Considerações sobre Design

• A abordagem de conceção de aplicações para uma aplicação crítica para a missão endossa a utilização de implementações regionais independentes com redundância zonal aplicada a todos os níveis de componentes numa única região.

• Uma Zona de Disponibilidade (AZ) é uma localização de datacenter fisicamente separada numa região do Azure, proporcionando isolamento de falhas físicas e lógicas até ao nível de um único datacenter.

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

• A conectividade da Zona de Disponibilidade depende das características regionais e, por conseguinte, o tráfego que entra numa região através de uma localização de limite poderá ter de ser encaminhado entre zonas para chegar ao destino. Isto irá adicionar uma latência de ~1ms-2ms, dado o encaminhamento entre zonas e as restrições de "velocidade da luz", mas isto deve ter apenas influência para cargas de trabalho hiper sensíveis.

• Zonas de Disponibilidade são tratadas como entidades lógicas no contexto de uma única subscrição, pelo que diferentes subscrições podem ter um mapeamento zonal diferente para a mesma região. Por exemplo, a zona 1 na Subscrição A pode corresponder ao mesmo datacenter físico que a zona 2 na subscrição B.

• A comunicação entre zonas numa região implica um custo de transferência de dados por GB de largura de banda.

• Com cenários de aplicações extremamente chatosos entre componentes da aplicação, a distribuição de camadas de aplicações entre zonas pode introduzir latência significativa e custos acrescidos. É possível mitigar esta situação dentro da estrutura ao restringir um selo de implementação a uma única zona e implementar vários selos nas diferentes zonas.

• A comunicação entre diferentes regiões do Azure implica um custo de transferência de dados maior por GB de largura de banda.

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

• Os métodos de conectividade do Express Route e da VPN também podem ser utilizados para ligar diretamente diferentes regiões do Azure para determinados cenários ou até mesmo plataformas na cloud diferentes.

• Para serviços para serviços de comunicação Private Link podem ser utilizados para comunicação direta através de pontos finais privados.

• O tráfego pode ser afixado pelo cabelo através de circuitos do ExpressRoute utilizados para conectividade no local, de modo a facilitar o encaminhamento entre redes virtuais numa região do Azure e em diferentes regiões do Azure na mesma geografia.

  • O tráfego de fixação de cabelo através do Express Route irá ignorar os custos de transferência de dados associados ao peering de rede virtual, pelo que pode ser utilizado como forma de otimizar os custos.
  • Esta abordagem requer saltos de rede adicionais para a integração de aplicações no Azure, o que introduz riscos de latência e fiabilidade. Expande a função do Express Route e os componentes de gateway associados do Azure/no local para abranger também a conectividade do Azure/Azure.

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

Recomendações de conceção

• Utilize o peering de rede virtual para ligar redes numa região e em diferentes regiões. Recomenda-se vivamente que evite afixar o cabelo no Express Route.

• Utilize Private Link para estabelecer comunicação diretamente entre serviços na mesma região ou entre regiões (serviço na Região A a comunicar com o serviço na Região B.

• Para cargas de trabalho de aplicações extremamente chatas entre componentes, considere restringir um selo de implementação a uma única zona e implementar vários selos nas diferentes zonas. Isto garante que a redundância zonal é mantida ao nível de um carimbo de implementação encapsulado em vez de um único componente de aplicação.

• Sempre que possível, trate cada selo de implementação como independente e desligado de outros selos.

  • Utilize tecnologias de plataforma de dados para sincronizar o estado entre regiões em vez de obter consistência ao nível da aplicação com caminhos de rede diretos.
  • Evite o tráfego de "pernas de cão" entre diferentes regiões, a menos que seja necessário, mesmo num cenário de falha. Utilize serviços de encaminhamento globais e sondas de estado de funcionamento ponto a ponto para retirar um selo completo da circulação caso uma única camada de componente crítica falhe, em vez de encaminhar o tráfego a esse nível de componente com falhas para outra região.

• Para cenários de aplicações sensíveis a hiper latência, priorize a utilização de zonas com gateways de rede regionais para otimizar a latência de rede para caminhos de entrada.

Micro-segmentação e políticas de rede do Kubernetes

A micro segmentação é um padrão de conceção de segurança de rede utilizado para isolar e proteger cargas de trabalho de aplicações individuais, com políticas aplicadas para limitar o tráfego de rede entre cargas de trabalho com base num modelo de Confiança Zero. Normalmente, é aplicada para reduzir a superfície de ataque de rede, melhorar a contenção de falhas de segurança e reforçar a segurança através de controlos de rede ao nível da aplicação orientados por políticas.

Uma aplicação crítica para a missão pode impor a segurança de rede ao nível da aplicação através de Grupos de Segurança de Rede (NSG) ao nível da sub-rede ou da interface de rede, listas de Controlo de Acesso de serviço (ACL) e políticas de rede ao utilizar Azure Kubernetes Service (AKS).

Esta secção explora a utilização ideal destas capacidades, fornecendo considerações e recomendações fundamentais para alcançar a micro segmentação ao nível da aplicação.

Considerações sobre Design

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

  • Redes kubenet: Os nós do AKS estão integrados numa rede virtual existente, mas existem pods numa rede de sobreposição virtual em cada nó. O tráfego entre pods em nós diferentes é encaminhado através do kube-proxy.
  • Rede do Azure Container Networking Interface (CNI): O cluster do AKS está integrado numa rede virtual existente e os respetivos nós, pods e serviços receberam endereços IP da mesma rede virtual à qual os nós de cluster estão ligados. Isto é relevante para vários cenários de rede que requerem conectividade direta de e para pods. Podem ser implementados conjuntos de nós diferentes em sub-redes diferentes.

  Nota

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

• Por predefiniçã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 comunicar com todos os outros pods num determinado cluster do Kubernetes; O Kubernetes não garante qualquer isolamento ao nível da rede e não isola os espaços de nomes ao nível do cluster.

• A comunicação entre Pods e Espaços de Nomes pode ser isolada através de 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. Com as Políticas de Rede, pode ser definido um conjunto ordenado de regras para controlar a forma como o tráfego é enviado/recebido e aplicado a uma coleção de pods que correspondem a um ou mais seletores de etiquetas.

  • O AKS suporta dois plug-ins que implementam a Política de Rede, o Azure e o Calico. Ambos os plug-ins utilizam IPTables do Linux para impor as políticas especificadas. Veja Diferenças entre as políticas do Azure e do Calico e as respetivas capacidades para obter mais detalhes.
  • As políticas de rede não entram em conflito porque são aditivas.
  • Para permitir um fluxo de rede entre dois pods, tanto a política de saída no pod de origem como a política de entrada no pod de destino têm de permitir o tráfego.
  • A funcionalidade de política de rede só pode ser ativada no momento da instanciação do cluster. Não é possível ativar a política de rede num cluster do AKS existente.
  • A entrega de políticas de rede é consistente independentemente de o Azure ou o Calico ser utilizado.
  • O Calico fornece um conjunto de funcionalidades mais avançado, incluindo suporte para nós windows e suporta o Azure CNI, bem como o Kubenet.

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

  • A utilização de conjuntos de nós não fornece isolamento ao nível da rede.
  • Os conjuntos de nós podem utilizar sub-redes diferentes na mesma rede virtual. Os NSGs podem ser aplicados ao nível da sub-rede para implementar a micro-segmentação entre conjuntos de nós.

Recomendações de conceção

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

  • Utilize Etiquetas de Serviço do Front Door em NSGs em todas as sub-redes que contenham back-ends de aplicações definidos no Azure Front Door, uma vez que isto valida o tráfego proveniente de um espaço de endereços IP de back-end legítimo do Azure Front Door. Isto irá garantir que o tráfego flui através do Azure Front Door ao nível do serviço, mas a filtragem baseada em cabeçalhos continuará a ser necessária para garantir a utilização de uma instância específica do Front Door e para mitigar também os riscos de segurança do "spoofing de IP".

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

  • Priorize a utilização do plug-in de rede CNI do Azure e considere o Kubenet para cenários com um intervalo limitado de endereços IP disponíveis para se ajustar à aplicação num espaço de endereços restrito.

    • O AKS suporta a utilização da CNI do Azure e do Kubenet. Está selecionado no momento da implementação.
    • O plug-in de rede CNI do Azure é um plug-in de rede mais robusto e dimensioná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.
    • Veja CNI do Azure para obter mais detalhes.

• A funcionalidade Política de Rede no Kubernetes deve ser utilizada para definir regras para o tráfego de entrada e saída entre pods num cluster. Defina Políticas de Rede granulares para restringir e limitar a comunicação entre pods.

  • Ative a Política de Rede para Azure Kubernetes Service no momento da implementação.
  • Priorize a utilização do Calico porque fornece um conjunto de funcionalidades mais avançado com mais adoção e suporte da comunidade.

Passo seguinte

Reveja as considerações para quantificar e observar o estado de funcionamento da aplicação.

Modelação e observabilidade do estado de funcionamento