Esta arquitetura fornece orientações para conceber uma carga de trabalho crítica para a missão que tem controlos de rede rigorosos implementados para impedir o acesso público não autorizado da Internet a qualquer um dos recursos da carga de trabalho. A intenção é parar os vetores de ataque na camada de rede para que a fiabilidade geral do sistema não seja afetada. Por exemplo, um ataque Denial of Service Distribuído (DDoS), se não estiver selecionado, pode fazer com que um recurso fique indisponível ao sobrecarregá-lo com tráfego ilegítimo.
Baseia-se na arquitetura de linha de base crítica para a missão, que se concentra em maximizar a fiabilidade e a eficácia operacional sem controlos de rede. Esta arquitetura adiciona funcionalidades para restringir os caminhos de entrada e saída com as capacidades nativas da cloud adequadas, como o Azure Rede Virtual(VNet) e pontos finais privados, Azure Private Link, Zona de DNS Privado do Azure, entre outros.
Recomenda-se que se familiarize com a linha de base antes de prosseguir com este artigo.
Principais estratégias de conceção
As estratégias de conceção para a linha de base crítica para a missão ainda se aplicam neste caso de utilização. Eis as considerações de rede adicionais para esta arquitetura:
Controlar o tráfego de entrada
A comunicação de entrada ou entrada na rede virtual tem de ser restrita para evitar ataques maliciosos.
Aplique capacidades de Firewall de Aplicações Web (WAF) ao nível global para parar os ataques na periferia da rede mais perto da origem de ataque.
Elimine a conectividade pública aos serviços do Azure. Uma abordagem é utilizar pontos finais privados.
Inspecione o tráfego antes de entrar na rede. Os grupos de segurança de rede (NSGs) em sub-redes ajudam a filtrar o tráfego ao permitir ou negar o fluxo para as portas e endereços IP configurados. Este nível de controlo também ajuda no registo granular.
Controlar o tráfego de saída
O tráfego de saída de uma rede virtual para entidades fora dessa rede tem de ser restringido. A falta de controlos pode levar a ataques de exfiltração de dados por serviços maliciosos de terceiros.
Restringir o tráfego de saída para a Internet através de Azure Firewall. A firewall pode filtrar o tráfego de forma granular com um nome de domínio completamente qualificado (FQDN).
Equilibrar compromissos com segurança
Existem compromissos significativos quando as funcionalidades de segurança são adicionadas a uma arquitetura de carga de trabalho. Poderá notar algum impacto no desempenho, agilidade operacional e até fiabilidade. No entanto , os ataques, como Denial-Of-Service (DDoS), intrusão de dados e outros, podem visar a fiabilidade geral do sistema e, eventualmente, causar indisponibilidade.
As estratégias baseiam-se na documentação de orientação geral fornecida para cargas de trabalho fundamentais para a missão em cargas de trabalho críticas para a missão bem arquitetado. Sugerimos que explore a área de design de rede e conectividade para obter recomendações e melhores práticas ao definir a sua própria arquitetura crítica para a sua missão.
Arquitetura
Transfira um ficheiro do Visio desta arquitetura.
Os componentes desta arquitetura podem ser amplamente categorizados desta forma. Para obter a documentação do produto sobre os serviços do Azure, veja Recursos relacionados.
Recursos globais
Os recursos globais têm uma vida longa e partilham a duração do sistema. Têm a capacidade de estar globalmente disponíveis no contexto de um modelo de implementação de várias regiões. Para obter mais informações, veja Recursos globais.
O SKU do Azure Front Door Premium é utilizado como o balanceador de carga global para encaminhar de forma fiável o tráfego para as implementações regionais, que são expostas através de pontos finais privados.
Veja Cargas de trabalho críticas da missão bem arquitetedada: Encaminhamento de tráfego global.
O Azure Cosmos DB para NoSQL ainda é utilizado para armazenar o estado fora do cluster de cálculo e tem definições de configuração de linha de base para fiabilidade. O acesso está limitado a ligações de ponto final privado autorizadas.
Azure Container Registry é utilizado para armazenar todas as imagens de contentor com capacidades de georreplicação. O acesso está limitado a ligações de ponto final privado autorizadas.
Veja Cargas de trabalho críticas da missão bem arquitetedada: Registo de contentores.
Recursos regionais
Os recursos regionais são aprovisionados como parte de um selo de implementação para uma única região do Azure. São de curta duração para proporcionar mais resiliência, dimensionamento e proximidade aos utilizadores. Estes recursos não partilham nada com recursos noutra região. Podem ser removidos ou replicados de forma independente para outras regiões. No entanto, partilham recursos globais entre si. Para obter mais informações, veja Recursos de selos regionais.
O site estático numa Conta de Armazenamento do Azure aloja uma aplicação de página única (SPA) que envia pedidos para serviços de back-end. Este componente tem a mesma configuração que o front-end da linha de base. O acesso está limitado a ligações de ponto final privado autorizadas.
As Redes Virtuais do Azure fornecem ambientes seguros para executar a carga de trabalho e as operações de gestão.
O balanceador de carga interno é a origem da aplicação. O Front Door utiliza esta origem para estabelecer conectividade privada e direta ao back-end com Private Link.
Azure Kubernetes Service (AKS) é o orquestrador da computação de back-end que executa uma aplicação e não tem estado. O cluster do AKS é implementado como um cluster privado. Assim, o servidor da API do Kubernetes não está exposto à Internet pública. O acesso ao servidor de API está limitado a uma rede privada. Para obter mais informações, veja o artigo Cluster de cálculo desta arquitetura.
Veja Cargas de trabalho críticas da missão bem arquitetado: Container Orchestration e Kubernetes.
Azure Firewall inspeciona e protege todo o tráfego de saída dos recursos do Azure Rede Virtual.
Hubs de Eventos do Azure é utilizado como mediador de mensagens. O acesso está limitado a ligações de ponto final privado autorizadas.
O Azure Key Vault é utilizado como arquivo de segredos regionais. O acesso está limitado a ligações de ponto final privado autorizadas.
Veja Cargas de trabalho críticas da missão bem arquitetado: Proteção da integridade dos dados.
Recursos do pipeline de implementação
Os pipelines de compilação e versão de uma aplicação crítica para a missão têm de ser totalmente automatizados para garantir uma forma consistente de implementar um selo validado.
O GitHub continua a ser utilizado para o controlo de código fonte como uma plataforma baseada em git de elevada disponibilidade.
O Azure Pipelines é escolhido para automatizar os pipelines necessários para criar, testar e implementar uma carga de trabalho em ambientes de pré-produção e produção.
Veja Cargas de trabalho críticas da missão bem arquitetado: processos de DevOps.
Os conjuntos de agentes de compilação do Azure DevOps autoalojados são utilizados para ter mais controlo sobre as compilações e implementações. Este nível de autonomia é necessário porque o cluster de cálculo e todos os recursos PaaS são privados, o que requer uma integração ao nível da rede que não é possível nos agentes de compilação alojados na Microsoft.
Recursos de observabilidade
Os dados de monitorização dos recursos globais e dos recursos regionais são armazenados de forma independente. Não é recomendado um único arquivo de observabilidade centralizado para evitar um único ponto de falha. Para obter mais informações, veja Recursos de observabilidade.
O Azure Log Analytics é utilizado como um sink unificado para armazenar registos e métricas para todos os componentes de aplicação e infraestrutura.
Aplicação Azure Insights é utilizado como uma ferramenta de Gestão de Desempenho de Aplicações (APM) para recolher todos os dados de monitorização de aplicações e armazená-lo diretamente no Log Analytics.
Veja Cargas de trabalho críticas da missão bem arquitetado: Ação preditiva e operações de IA.
Recursos de gestão
Uma alteração de estrutura significativa da arquitetura de linha de base é o cluster de computação. Neste design, o cluster do AKS é privado. Esta alteração requer que sejam aprovisionados recursos adicionais para obter acesso.
O Azure Conjuntos de Dimensionamento de Máquinas Virtuais para que os agentes de compilação privados e as instâncias de jump box executem ferramentas no cluster, como o kubectl.
O Azure Bastion fornece acesso seguro às VMs jump box e remove a necessidade de as VMs terem IPs públicos.
Pontos finais privados para serviços PaaS
Para processar operações empresariais ou de implementação, a aplicação e os agentes de compilação têm de aceder a vários serviços PaaS do Azure que são aprovisionados globalmente, dentro da região e mesmo dentro do selo. Na arquitetura de linha de base, essa comunicação é sobre os pontos finais públicos dos serviços.
Neste design, esses serviços foram protegidos com pontos finais privados para removê-los do acesso público à Internet. Esta abordagem reduz a área de superfície de ataque geral para mitigar a adulteração direta do serviço de origens inesperadas. No entanto, introduz outro ponto potencial de falha e aumenta a complexidade. Considere cuidadosamente as desvantagens com a segurança antes de adotar esta abordagem.
Os pontos finais privados devem ser colocados numa sub-rede dedicada da rede virtual do selo. Os endereços IP privados para os pontos finais privados são atribuídos a partir dessa sub-rede. Essencialmente, qualquer recurso na rede virtual pode comunicar com o serviço ao aceder ao endereço IP privado. Certifique-se de que o espaço de endereços é suficientemente grande para acomodar todos os pontos finais privados necessários para esse selo.
Para ligar através de um ponto final privado, precisa de um registo DNS. Recomenda-se que os registos DNS associados aos serviços sejam mantidos nas zonas de DNS Privado do Azure com serviços do DNS do Azure. Certifique-se de que o nome de domínio completamente qualificado (FQDN) é resolvido para o endereço IP privado.
Nesta arquitetura, foram configurados pontos finais privados para Azure Container Registry, Azure Cosmos DB, Key Vault, Recursos de armazenamento e Hubs de Eventos. Além disso, o cluster do AKS é implementado como um cluster privado, o que cria um ponto final privado para o serviço de API do Kubernetes na rede do cluster.
Existem duas redes virtuais aprovisionadas neste design e ambas têm sub-redes dedicadas para conter pontos finais privados para todos esses serviços. O esquema de rede é descrito no Esquema de rede virtual.
À medida que adiciona mais componentes à arquitetura, considere adicionar mais pontos finais privados. Por exemplo, pode adicionar restrições aos recursos de observabilidade. O Azure Log Analytics e o Aplicação Azure Insights suportam a utilização de pontos finais privados. Para obter detalhes, veja Utilizar Azure Private Link para ligar redes ao Azure Monitor.
Podem ser criadas nas mesmas sub-redes ou diferentes na mesma rede virtual. Existem limites para o número de pontos finais privados que pode criar numa subscrição. Para obter mais informações, veja Limites do Azure.
Controle ainda mais o acesso aos serviços através de grupos de segurança de rede na sub-rede.
Entrada privada
O SKU Premium do Azure Front Door é utilizado como o ponto de entrada global para todo o tráfego de cliente recebido. Utiliza capacidades de Firewall de Aplicações Web (WAF) para permitir ou negar o tráfego no limite da rede. As regras de WAF configuradas impedem ataques mesmo antes de entrarem nas redes virtuais de selo.
Esta arquitetura também tira partido da capacidade do Front Door de utilizar Azure Private Link para aceder à origem da aplicação sem a utilização de IPs/pontos finais públicos nos back-ends. Isto requer um balanceador de carga interno na rede virtual de selos. Este recurso está à frente do Controlador de Entrada do Kubernetes em execução no cluster. Além deste Balanceador de Carga privado, um serviço Private Link é criado pelo AKS, que é utilizado para a ligação privada do Front Door.
Após a ligação ser estabelecida, os pontos finais privados na rede do Front Door têm conectividade direta com o balanceador de carga e o web site estático na rede de selos através de Private Link.
Para obter mais informações, veja Como funciona o Private Link.
Veja Cargas de trabalho críticas da missão bem arquitetedida: Serviços de entrega de aplicações.
Saída restrita
As aplicações podem exigir alguma conectividade à Internet de saída. Controlar esse tráfego fornece uma forma de limitar, monitorizar e restringir o tráfego de saída. Caso contrário, o acesso interno inesperado pode levar a um compromisso e potencialmente a um estado de sistema pouco fiável. A saída restrita também pode resolver outras questões de segurança, como a exfiltração de dados.
A utilização da firewall e dos Grupos de Segurança de Rede (NSGs) pode garantir que o tráfego de saída da aplicação é inspecionado e registado.
Nesta arquitetura, Azure Firewall é o ponto de saída único e é utilizado para inspecionar todo o tráfego de saída proveniente da rede virtual. As rotas definidas pelo utilizador (UDRs) são utilizadas em sub-redes capazes de gerar tráfego de saída, como a sub-rede da aplicação.
Para obter informações sobre como restringir o tráfego de saída, veja Controlar o tráfego de saída dos nós de cluster no Azure Kubernetes Service (AKS).
Esquema de rede virtual
Isolar recursos regionais e recursos de gestão em redes virtuais separadas. Têm características, propósitos e considerações de segurança distintas.
Tipo de tráfego: os recursos regionais, que participam no processamento de operações empresariais, precisam de controlos de segurança mais elevados. Por exemplo, o cluster de computação tem de ser protegido contra o tráfego direto da Internet. Os recursos de gestão são aprovisionados apenas para aceder aos recursos regionais para operações.
Duração: as durações esperadas desses recursos também são diferentes. Espera-se que os recursos regionais sejam de curta duração (efémeros). São criados como parte do carimbo de implementação e destruídos quando o selo é demolido. Os recursos de gestão partilham a duração da região e vivem os recursos de selo.
Nesta arquitetura, existem duas redes virtuais: rede de selos e rede de operações. Crie um isolamento adicional em cada rede virtual com sub-redes e grupos de segurança de rede (NSGs) para proteger a comunicação entre as sub-redes.
Veja Cargas de trabalho críticas de missão bem arquitetedadas: Redes virtuais isoladas.
Rede virtual de selo regional
O carimbo de implementação aprovisiona uma rede virtual em cada região.
A rede virtual está dividida nestas sub-redes principais. Todas as sub-redes têm Grupos de Segurança de Rede (NSGs) atribuídos para bloquear qualquer acesso não autorizado a partir da rede virtual. Os NSGs irão restringir o tráfego entre a sub-rede da aplicação e outros componentes na rede.
Sub-rede da aplicação
Os conjuntos de nós de cluster do AKS estão isolados numa sub-rede. Se precisar de isolar ainda mais o conjunto de nós do sistema do conjunto de nós de trabalho, pode colocá-los em sub-redes separadas.
Sub-rede de entrada de carimbos
O ponto de entrada para cada selo é uma Balanceador de Carga Standard interna do Azure que é colocada numa sub-rede dedicada. O serviço Private Link utilizado para a ligação privada do Front Door também é colocado aqui.
Ambos os recursos são aprovisionados como parte da implementação do selo.
Sub-rede de saída de selos
Azure Firewall é colocada numa sub-rede separada e inspeciona o tráfego de saída da sub-rede da aplicação através de uma rota definida pelo utilizador (UDR).
Sub-rede de pontos finais privados
A sub-rede da aplicação terá de aceder aos serviços PaaS no selo regional, Key Vault e outros. Além disso, o acesso a recursos globais, como o registo de contentores, é necessário. Nesta arquitetura, todos os serviços PaaS estão bloqueados e só podem ser alcançados através de pontos finais privados. Assim, é criada outra sub-rede para esses pontos finais. O acesso de entrada a esta sub-rede é protegido pelo NSG que só permite o tráfego da aplicação.
Pode adicionar mais restrições ao utilizar o suporte UDR para pontos finais privados, para que este tráfego também possa ser efetuado através da sub-rede de saída de selos.
Rede virtual de operações
O tráfego operacional está isolado numa rede virtual separada. Uma vez que o serviço de API do cluster do AKS é privado nesta arquitetura, toda a implementação e tráfego operacional também têm de ser provenientes de recursos privados, como agentes de compilação autoalojados e caixas de salto. Esses recursos são implementados numa rede virtual separada com conectividade direta aos recursos da aplicação através do seu próprio conjunto de pontos finais privados. Os agentes de compilação e as caixas de salto estão em sub-redes separadas.
Em vez de utilizar pontos finais privados, uma abordagem alternativa consiste em utilizar o peering de rede virtual. No entanto, o peering adiciona complexidade que pode ser difícil de gerir, especialmente quando as redes virtuais são concebidas para serem efémeras.
Tanto os agentes de compilação (como, opcionalmente, as caixas de salto) precisam de aceder aos serviços PaaS que estão localizados globalmente e dentro do carimbo regional. Semelhante à rede virtual de selo regional, é criada uma sub-rede dedicada para os pontos finais privados para os serviços PaaS necessários. O NSG nesta sub-rede garante que o tráfego de entrada só é permitido a partir das sub-redes de gestão e implementação.
Operações de gestão
Um caso de utilização típico é quando um operador precisa de aceder ao cluster de computação para executar ferramentas e comandos de gestão. O serviço de API num cluster privado não pode ser acedido diretamente. É por isso que as caixas de salto são aprovisionadas onde o operador pode executar as ferramentas. Há uma sub-rede separada para as caixas de salto.
Mas essas caixas de salto também têm de ser protegidas de acesso não autorizado. O acesso direto às caixas de salto ao abrir portas RDP/SSH deve ser evitado. O Azure Bastion é recomendado para este fim e requer uma sub-rede dedicada nesta rede virtual.
Atenção
A conectividade através do Azure Bastion e das caixas de salto pode ter impacto na produtividade dos programadores, como a execução de ferramentas de depuração requer um processo adicional. Tenha em atenção estes impactos antes de decidir proteger a segurança da carga de trabalho crítica para a sua missão.
Pode restringir ainda mais o acesso à sub-rede jump box através de um NSG que só permite o tráfego de entrada da sub-rede bastion através de SSH.
Operações de implementação
Para criar pipelines de implementação, tem de aprovisionar computação adicional para executar agentes de compilação. Estes recursos não afetarão diretamente a disponibilidade do runtime da carga de trabalho, mas uma falha de fiabilidade pode comprometer a capacidade de implementar ou servir o ambiente crítico da sua missão. Assim, as funcionalidades de fiabilidade devem ser expandidas para estes recursos.
Esta arquitetura utiliza Conjuntos de Dimensionamento de Máquinas Virtuais para agentes de compilação e caixas de salto (por oposição a VMs individuais). Além disso, a segmentação de rede é fornecida através da utilização de sub-redes. A entrada está restrita ao Azure DevOps.
Considerações de custos
Há um impacto significativo no custo das cargas de trabalho fundamentais para a missão. Nesta arquitetura, as opções de tecnologia, como a utilização do SKU Premium do Azure Front Door e o aprovisionamento de Azure Firewall em cada selo, irão originar um aumento dos custos. Também existem custos adicionais relacionados com a manutenção e os recursos operacionais. Estas desvantagens têm de ser cuidadosamente consideradas antes de adotar uma versão controlada pela rede da arquitetura de linha de base.
Implementar esta arquitetura
Os aspetos de rede desta arquitetura são implementados na implementação Ligada crítica para a Missão.
Nota
A implementação Ligada destina-se a ilustrar uma carga de trabalho crítica para a missão que se baseia em recursos organizacionais, integra-se com outras cargas de trabalho e utiliza serviços partilhados. Baseia-se nesta arquitetura e utiliza os controlos de rede descritos neste artigo. No entanto, o cenário Ligado pressupõe que a rede privada virtual ou a Zona de DNS Privado do Azure já existem na subscrição de conectividade das zonas de destino do Azure.
Passos seguintes
Para obter detalhes sobre as decisões de conceção tomadas nesta arquitetura, reveja a área de design de rede e conectividade para cargas de trabalho críticas para a missão no Azure Well-architected Framework.
Recursos relacionados
Para obter documentação do produto sobre os serviços do Azure utilizados nesta arquitetura, veja estes artigos.