Arquitetura de linha de base crítica com controles de rede
Essa arquitetura fornece orientação para projetar uma carga de trabalho de missão crítica que tenha controles de rede rigorosos em vigor 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 confiabilidade geral do sistema não seja afetada. Por exemplo, um ataque de negação de serviço distribuído (DDoS), se não for verificado, pode fazer com que um recurso fique indisponível, sobrecarregando-o com tráfego ilegítimo.
Ele se baseia na arquitetura de linha de base de missão crítica, focada em maximizar a confiabilidade e a eficácia operacional sem controles de rede. Essa arquitetura adiciona recursos para restringir caminhos de entrada e saída usando os recursos nativos da nuvem apropriados, como Rede Virtual do Azure (VNet) e pontos de extremidade privados, Link Privado do Azure, Zona DNS Privada do Azure e outros.
É recomendável que você se familiarize com a linha de base antes de prosseguir com este artigo.
Principais estratégias de design
As estratégias de design para linha de base de missão crítica ainda se aplicam neste caso de uso. Aqui estão as considerações de rede adicionais para essa arquitetura:
Controlar o tráfego de entrada
A entrada ou comunicação de entrada na rede virtual deve ser restrita para evitar ataques mal-intencionados.
Aplique os recursos do Web Application Firewall (WAF) em nível global para impedir ataques na borda da rede mais próxima da origem do ataque.
Elimine a conectividade pública com os serviços do Azure. Uma abordagem é usar pontos de extremidade privados.
Inspecione o tráfego antes que ele entre na rede. Os NSGs (grupos de segurança de rede) em sub-redes ajudam a filtrar o tráfego, permitindo ou negando o fluxo para os endereços IP e portas configurados. Esse nível de controle também ajuda no registro granular.
Controlar o tráfego de saída
O tráfego de saída de uma rede virtual para entidades fora dessa rede deve ser restrito. A falta de controles pode levar a ataques de exfiltração de dados por serviços de terceiros mal-intencionados.
Restrinja o tráfego de saída para a Internet usando o Firewall do Azure. O firewall pode filtrar o tráfego granularmente usando FQDN (nome de domínio totalmente qualificado).
Equilibre compensações com segurança
Há compensações significativas quando os recursos de segurança são adicionados a uma arquitetura de carga de trabalho. Você pode notar algum impacto no desempenho, na agilidade operacional e até mesmo na confiabilidade. No entanto, ataques, como Denial-Of-Service (DDoS), intrusão de dados e outros, podem atingir a confiabilidade geral do sistema e, eventualmente, causar indisponibilidade.
As estratégias são baseadas na orientação geral fornecida para cargas de trabalho de missão crítica em cargas de trabalho de missão crítica bem arquitetadas. Sugerimos que você explore a área de design de rede e conectividade para obter recomendações e práticas recomendadas ao definir sua própria arquitetura de missão crítica.
Arquitetura
Baixe um arquivo Visio desta arquitetura.
Os componentes dessa arquitetura podem ser amplamente categorizados dessa maneira. Para obter a documentação do produto sobre os serviços do Azure, consulte Recursos relacionados.
Recursos globais
Os recursos globais são de longa duração e partilham a vida útil do sistema. Eles têm a capacidade de estar disponíveis globalmente no contexto de um modelo de implantação multirregional. Para obter mais informações, consulte Recursos globais.
O Azure Front Door Premium SKU é usado como o balanceador de carga global para rotear de forma confiável o tráfego para as implantações regionais, que são expostas por meio de pontos de extremidade privados.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: roteamento de tráfego global.
O Azure Cosmos DB para NoSQL ainda é usado para armazenar o estado fora do cluster de computação e tem definições de configuração de linha de base para confiabilidade. O acesso é limitado a conexões de ponto final privadas autorizadas.
O Registro de Contêiner do Azure é usado para armazenar todas as imagens de contêiner com recursos de replicação geográfica. O acesso é limitado a conexões de ponto final privadas autorizadas.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: Registro de contêiner.
Recursos regionais
Os recursos regionais são provisionados como parte de um carimbo de implantação para uma única região do Azure. Eles são de curta duração para fornecer mais resiliência, escala e proximidade com os usuários. Estes recursos não partilham nada com os recursos de outra região. Eles podem ser removidos de forma independente ou replicados para outras regiões. No entanto, partilham recursos globais entre si. Para obter mais informações, consulte Recursos de carimbo regionais.
O site estático em uma Conta de Armazenamento do Azure hospeda um aplicativo de página única (SPA) que envia solicitações para serviços de back-end. Este componente tem a mesma configuração que o frontend de linha de base. O acesso é limitado a conexões de ponto final privadas autorizadas.
As Redes Virtuais do Azure fornecem ambientes seguros para executar a carga de trabalho e as operações de gerenciamento.
O balanceador de carga interno é a origem do aplicativo. O Front Door usa essa origem para estabelecer conectividade privada e direta com o back-end usando o Private Link.
O Serviço Kubernetes do Azure (AKS) é o orquestrador para computação de back-end que executa um aplicativo e é sem monitoração de estado. O cluster AKS é implantado como um cluster privado. Assim, o servidor de API do Kubernetes não está exposto à Internet pública. O acesso ao servidor de API é limitado a uma rede privada. Para obter mais informações, consulte o artigo Cluster de computação desta arquitetura.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: Orquestração de contêineres e Kubernetes.
O Firewall do Azure inspeciona e protege todo o tráfego de saída dos recursos da Rede Virtual do Azure.
Os Hubs de Eventos do Azure são usados como o agente de mensagens. O acesso é limitado a conexões de ponto final privadas autorizadas.
O Azure Key Vault é usado como o armazenamento secreto regional. O acesso é limitado a conexões de ponto final privadas autorizadas.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: Proteção da integridade de dados.
Recursos de pipeline de implantação
Os pipelines de construção e liberação para um aplicativo de missão crítica devem ser totalmente automatizados para garantir uma maneira consistente de implantar um selo validado.
O GitHub ainda é usado para controle do código-fonte como uma plataforma baseada em git altamente disponível.
O Azure Pipelines foi escolhido para automatizar pipelines necessários para criar, testar e implantar uma carga de trabalho em ambientes de pré-produção e produção.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: processos de DevOps.
Os pools de agentes de compilação do Azure DevOps auto-hospedados são usados para ter mais controle sobre as compilações e implantações. Esse nível de autonomia é necessário porque o cluster de computação e todos os recursos PaaS são privados, o que requer uma integração de nível de rede que não é possível em agentes de compilação hospedados pela Microsoft.
Recursos de observabilidade
Os dados de monitoramento para recursos globais e recursos regionais são armazenados de forma independente. Um único armazenamento de observabilidade centralizado não é recomendado para evitar um único ponto de falha. Para obter mais informações, consulte Recursos de observabilidade.
O Azure Log Analytics é usado como um coletor unificado para armazenar logs e métricas para todos os componentes de aplicativo e infraestrutura.
O Azure Application Insights é usado como uma ferramenta de Gerenciamento de Desempenho de Aplicativo (APM) para coletar todos os dados de monitoramento de aplicativos e armazená-los diretamente no Log Analytics.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: ação preditiva e operações de IA.
Recursos de gestão
Uma alteração significativa do projeto em relação à arquitetura de linha de base é o cluster de computação. Neste projeto, o cluster AKS é privado. Essa alteração exige que recursos extras sejam provisionados para obter acesso.
Conjuntos de Escala de Máquina Virtual do Azure para os agentes de compilação privados e instâncias de caixa de salto para executar ferramentas no cluster, como kubectl.
O Azure Bastion fornece acesso seguro às VMs da caixa de salto e elimina a necessidade de as VMs terem IPs públicos.
Pontos finais privados para serviços PaaS
Para processar operações de negócios ou implantação, o aplicativo e os agentes de compilação precisam acessar vários serviços de PaaS do Azure que são provisionados globalmente, dentro da região e até mesmo dentro do carimbo. Na arquitetura de linha de base, essa comunicação é sobre os pontos de extremidade públicos dos serviços.
Neste projeto, esses serviços foram protegidos com terminais privados para removê-los do acesso público à Internet. Essa abordagem reduz a área geral da superfície de ataque para mitigar a violação direta do serviço de fontes inesperadas. No entanto, introduz outro potencial ponto de falha e aumenta a complexidade. Considere cuidadosamente as compensações com a segurança antes de adotar essa 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 de extremidade privados são atribuídos a partir dessa sub-rede. Essencialmente, qualquer recurso na rede virtual pode se comunicar com o serviço alcançando o endereço IP privado. Verifique se o espaço de endereço é grande o suficiente para acomodar todos os pontos de extremidade privados necessários para esse carimbo.
Para se conectar através de um ponto de extremidade privado, você precisa de um registro DNS. É recomendável que os registros DNS associados aos serviços sejam mantidos em zonas de DNS Privado do Azure atendidas pelo DNS do Azure. Certifique-se de que o nome de domínio totalmente qualificado (FQDN) é resolvido para o endereço IP privado.
Nessa arquitetura, os pontos de extremidade privados foram configurados para o Registro de Contêiner do Azure, o Azure Cosmos DB, o Cofre da Chave, os recursos de armazenamento e os Hubs de Eventos. Além disso, o cluster AKS é implantado como um cluster privado, que cria um ponto de extremidade privado para o serviço de API do Kubernetes na rede do cluster.
Há duas redes virtuais provisionadas neste design e ambas têm sub-redes dedicadas para manter pontos de extremidade privados para todos esses serviços. O layout de rede é descrito em Layout de rede virtual.
À medida que você adiciona mais componentes à arquitetura, considere adicionar mais pontos de extremidade privados. Por exemplo, você pode adicionar restrições aos recursos de observabilidade. O Azure Log Analytics e o Azure Application Insights dão suporte ao uso de pontos de extremidade privados. Para obter detalhes, consulte Usar o Azure Private Link para conectar redes ao Azure Monitor.
Eles podem ser criados na mesma sub-rede ou em sub-redes diferentes dentro da mesma rede virtual. Há limites para o número de pontos de extremidade privados que se pode criar numa assinatura. Para obter mais informações, consulte Limites do Azure.
Controle ainda mais o acesso aos serviços usando grupos de segurança de rede na sub-rede.
Entrada privada
O Azure Front Door Premium SKU é usado como o ponto de entrada global para todo o tráfego de entrada de clientes. Ele usa recursos do Web Application Firewall (WAF) para permitir ou negar o tráfego na borda da rede. As regras WAF configuradas impedem ataques antes mesmo de entrarem nas redes virtuais de carimbo.
Essa arquitetura também aproveita a capacidade do Front Door de usar o Azure Private Link para acessar a origem do aplicativo sem o uso de IPs/pontos de extremidade públicos nos back-ends. Isso requer um balanceador de carga interno na rede virtual de carimbo. Este recurso está na frente do Kubernetes Ingress Controller em execução no cluster. Além deste Load Balancer privado, um serviço Private Link é criado pelo AKS, que é usado para a conexão privada da Front Door.
Depois que a conexão é estabelecida, os pontos de extremidade privados na rede Front Door têm conectividade direta com o balanceador de carga e o site estático na rede de carimbo através do Private Link.
Para obter mais informações, consulte Como funciona o Private Link.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: Serviços de entrega de aplicativos.
Saída restrita
Os aplicativos podem exigir alguma conectividade de saída com a Internet. Controlar esse tráfego fornece uma maneira de limitar, monitorar e restringir o tráfego de saída. Caso contrário, o acesso inesperado de dentro para fora pode levar a um comprometimento e, potencialmente, a um estado do sistema não confiável. A saída restrita também pode resolver outras questões de segurança, como a exfiltração de dados.
O uso de firewall e NSGs (Network Security Groups) pode garantir que o tráfego de saída do aplicativo seja inspecionado e registrado.
Nessa arquitetura, o Firewall do Azure é o único ponto de saída e é usado para inspecionar todo o tráfego de saída originado da rede virtual. Rotas definidas pelo usuário (UDRs) são usadas em sub-redes capazes de gerar tráfego de saída, como a sub-rede do aplicativo.
Para obter informações sobre como restringir o tráfego de saída, consulte Controlar o tráfego de saída para nós de cluster no Serviço Kubernetes do Azure (AKS).
Layout de rede virtual
Isolar recursos regionais e recursos de gerenciamento em redes virtuais separadas. Eles têm características, finalidades e considerações de segurança distintas.
Tipo de tráfego: Os recursos regionais, que participam no processamento das operações comerciais, necessitam de controlos de segurança mais elevados. Por exemplo, o cluster de computação deve ser protegido contra tráfego direto da Internet. Os recursos de gerenciamento são provisionados apenas para acessar os recursos regionais para operações.
Tempo de vida: O tempo de vida esperado desses recursos também é diferente. Espera-se que os recursos regionais sejam de curta duração (efêmeros). Eles são criados como parte do selo de implantação e destruídos quando o carimbo é derrubado. Os recursos de gestão partilham o tempo de vida da região e vivem os recursos do selo.
Nesta arquitetura, existem duas redes virtuais: rede de carimbo e rede de operações. Crie mais isolamento dentro de cada rede virtual usando sub-redes e NSGs (grupos de segurança de rede) para proteger a comunicação entre as sub-redes.
Consulte Cargas de trabalho de missão crítica bem arquitetadas: redes virtuais isoladas.
Rede virtual de selos regionais
O carimbo de implantação provisiona uma rede virtual em cada região.
A rede virtual é dividida nestas sub-redes principais. Todas as sub-redes têm NSGs (Network Security Groups) atribuídos para bloquear qualquer acesso não autorizado da rede virtual. Os NSGs restringirão o tráfego entre a sub-rede do aplicativo e outros componentes da rede.
Sub-rede do aplicativo
Os pools de nós do cluster AKS são isolados em uma sub-rede. Se precisar isolar ainda mais o pool de nós do sistema do pool de nós de trabalho, você poderá colocá-los em sub-redes separadas.
Sub-rede de entrada de carimbo
O ponto de entrada para cada carimbo é um Balanceador de Carga Padrão do Azure interno que é colocado em uma sub-rede dedicada. O serviço Private Link usado para a conexão privada da Front Door também é colocado aqui.
Ambos os recursos são provisionados como parte da implantação do carimbo.
Sub-rede de saída de carimbo
O Firewall do Azure é colocado em uma sub-rede separada e inspeciona o tráfego de saída da sub-rede do aplicativo usando uma rota definida pelo usuário (UDR).
Sub-rede de pontos de extremidade privados
A sub-rede do aplicativo precisará acessar os serviços PaaS no selo regional, Key Vault e outros. Além disso, o acesso a recursos globais, como o registro de contêiner, é necessário. Nessa arquitetura, todos os serviços PaaS são bloqueados e só podem ser acessados por meio de pontos de extremidade privados. Assim, outra sub-rede é criada para esses pontos de extremidade. O acesso de entrada a essa sub-rede é protegido pelo NSG que só permite o tráfego do aplicativo.
Você pode adicionar mais restrições usando o suporte UDR para pontos de extremidade privados, para que esse tráfego também possa sair pela sub-rede de saída de carimbo.
Rede virtual de operações
O tráfego operacional é isolado em uma rede virtual separada. Como o serviço de API do cluster AKS é privado nessa arquitetura, toda a implantação e o tráfego operacional também devem vir de recursos privados, como agentes de compilação auto-hospedados e caixas de salto. Esses recursos são implantados em uma rede virtual separada com conectividade direta aos recursos do aplicativo por meio de seu próprio conjunto de pontos de extremidade privados. Os agentes de compilação e as caixas de salto estão em sub-redes separadas.
Em vez de usar pontos de extremidade privados, uma abordagem alternativa é usar emparelhamento de rede virtual. No entanto, o emparelhamento adiciona complexidade que pode ser difícil de gerenciar, especialmente quando as redes virtuais são projetadas para serem efêmeras.
Ambos os agentes de compilação (e, opcionalmente, as caixas de salto) precisam acessar serviços de PaaS localizados globalmente e dentro do selo regional. Semelhante à rede virtual de selos regionais, uma sub-rede dedicada é criada para os pontos de extremidade privados para os serviços PaaS necessários. O NSG nessa sub-rede garante que o tráfego de entrada seja permitido somente das sub-redes de gerenciamento e implantação.
Operações de gestão
Um caso de uso típico é quando um operador precisa acessar o cluster de computação para executar ferramentas e comandos de gerenciamento. O serviço de API em um cluster privado não pode ser acessado diretamente. É por isso que as caixas de salto são provisionadas onde o operador pode executar as ferramentas. Há uma sub-rede separada para as caixas de salto.
Mas, essas caixas de salto também precisam ser protegidas contra acesso não autorizado. O acesso direto a caixas de salto abrindo portas RDP/SSH deve ser evitado. O Azure Bastion é recomendado para esta finalidade e requer uma sub-rede dedicada nesta rede virtual.
Atenção
A conectividade por meio do Azure Bastion e jump boxes pode ter um impacto na produtividade do desenvolvedor, como a execução de ferramentas de depuração que requer processo adicional. Esteja ciente desses impactos antes de decidir reforçar a segurança para sua carga de trabalho de missão crítica.
Você pode restringir ainda mais o acesso à sub-rede da caixa de salto usando um NSG que só permite o tráfego de entrada da sub-rede Bastion sobre SSH.
Operações de implementação
Para criar pipelines de implantação, você precisa provisionar computação adicional para executar agentes de compilação. Esses recursos não afetarão diretamente a disponibilidade de tempo de execução da carga de trabalho, mas uma falha de confiabilidade pode comprometer a capacidade de implantar ou atender seu ambiente de missão crítica. Assim, os recursos de confiabilidade devem ser estendidos a esses recursos.
Essa arquitetura usa Conjuntos de Escala de Máquina Virtual para agentes de compilação e caixas de salto (em oposição a VMs únicas). Além disso, a segmentação de rede é fornecida através do uso de sub-redes. A entrada é restrita ao Azure DevOps.
Considerações de custo
Há um impacto significativo no custo de cargas de trabalho de missão crítica. Nessa arquitetura, as opções de tecnologia, como usar o Azure Front Door Premium SKU e provisionar o Firewall do Azure em cada carimbo, levarão a um aumento de custos. Há também custos adicionais relacionados com manutenção e recursos operacionais. Tais compensações devem ser cuidadosamente consideradas antes de adotar uma versão controlada pela rede da arquitetura de linha de base.
Implantar esta arquitetura
Os aspetos de rede dessa arquitetura são implementados na implementação Mission-critical Connected.
Observação
A implementação Connected destina-se a ilustrar uma carga de trabalho de missão crítica que depende de recursos organizacionais, integra-se com outras cargas de trabalho e usa serviços compartilhados. Ele se baseia nessa arquitetura e usa os controles de rede descritos neste artigo. No entanto, o cenário Conectado pressupõe que a rede privada virtual ou a Zona DNS Privada do Azure já existam dentro da assinatura de conectividade das zonas de aterrissagem do Azure.
Próximos passos
Para obter detalhes sobre as decisões de design tomadas nessa arquitetura, revise a área de design de rede e conectividade para cargas de trabalho de missão crítica no Azure Well-architected Framework.
Recursos relacionados
Para obter a documentação do produto sobre os serviços do Azure usados nessa arquitetura, consulte estes artigos.