Arquitetura de linha de base crítica com controles de rede
Essa arquitetura fornece diretrizes para criar uma carga de trabalho crítica de missão que tenha controles de rede estritos em vigor para impedir o acesso público não autorizado da Internet a qualquer um dos recursos de carga de trabalho. A intenção é interromper os vetores de ataque na camada de rede para que a confiabilidade geral do sistema não seja afetada. Por exemplo, um ataque DDoS (Negação de Serviço Distribuído), se deixado desmarcado, 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 crítica, que se concentra 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 de nuvem apropriados, como VNet (Rede Virtual) do Azure 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.
Estratégias-chave de design
As estratégias de design para a linha de base crítica ainda se aplicam nesse caso de uso. Aqui estão as considerações de rede adicionais para esta arquitetura:
Controlar o tráfego de entrada
A entrada ou a comunicação de entrada na rede virtual devem ser restritas para evitar ataques mal-intencionados.
Aplique recursos do WAF (Firewall de Aplicativo Web) no nível global para interromper ataques na borda da rede mais perto da fonte de ataque.
Elimine a conectividade pública com os serviços do Azure. Uma abordagem é usar pontos de extremidade privados.
Inspecione o tráfego antes de entrar 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 em log 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 mal-intencionados de terceiros.
Restrinja o tráfego de saída à Internet usando o Firewall do Azure. O firewall pode filtrar o tráfego granularmente usando o FQDN (nome de domínio totalmente qualificado).
Balancear 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 DDoS (NegaçãoOf-Service), intrusão de dados e outros, podem atingir a confiabilidade geral do sistema e, eventualmente, causar indisponibilidade.
As estratégias se baseiam nas diretrizes gerais fornecidas para cargas de trabalho críticas em cargas de trabalho críticas de missão bem arquiteta. Sugerimos que você explore a área de design de rede e conectividade para recomendações e práticas recomendadas ao definir sua própria arquitetura crítica de missão.
Arquitetura
Baixe um arquivo do Visio dessa 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 vida longa e compartilham o tempo de vida do sistema. Eles têm a capacidade de estar globalmente disponíveis no contexto de um modelo de implantação de várias regiões. Para obter mais informações, consulte Recursos globais.
O SKU Premium do Azure Front Door é 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 críticas de missão bem arquiteta: 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 configurações de configuração de linha de base para confiabilidade. O acesso é limitado a conexões de ponto de extremidade privado 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 de extremidade privado autorizadas.
Consulte cargas de trabalho críticas de missão bem arquiteta: 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 aos usuários. Esses recursos não compartilham nada com recursos em outra região. Eles podem ser removidos ou replicados de forma independente para outras regiões. Eles, no entanto, compartilham recursos globais entre si. Para obter mais informações, consulte os recursos de carimbo regionais.
O site estático em uma Conta de Armazenamento do Azure hospeda um SPA (aplicativo de página única) que envia solicitações para serviços de back-end. Esse componente tem a mesma configuração que o front-end de linha de base. O acesso é limitado a conexões de ponto de extremidade privado 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 Link Privado.
O AKS (Serviço de Kubernetes do Azure) é o orquestrador de computação de back-end que executa um aplicativo e não tem estado. O cluster do AKS é implantado como um cluster privado. Portanto, o servidor de API do Kubernetes não é exposto à Internet pública. O acesso ao servidor de API é limitado a uma rede privada. Para obter mais informações, consulte o artigo do cluster de computação dessa arquitetura.
Consulte cargas de trabalho críticas de missão bem arquiteta: Orquestração de Contêiner 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 de extremidade privado autorizadas.
O Azure Key Vault é usado como o repositório de segredos regional. O acesso é limitado a conexões de ponto de extremidade privado autorizadas.
Consulte cargas de trabalho críticas de missão bem arquiteta: proteção de integridade de dados.
Recursos de pipeline de implantação
Os pipelines de build e lançamento de um aplicativo de missão crítica devem ser totalmente automatizados para garantir uma maneira consistente de implantar um carimbo validado.
O GitHub ainda é usado para o controle do código-fonte como uma plataforma baseada em git altamente disponível.
O Azure Pipelines é escolhido para automatizar pipelines necessários para compilar, testar e implantar uma carga de trabalho em ambientes de pré-produção e produção.
Consulte cargas de trabalho críticas de missão bem arquiteta: processos de DevOps.
Pools de agentes de build 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 de PaaS são privados, o que requer uma integração de nível de rede que não é possível em agentes de build hospedados pela Microsoft.
Recursos de observabilidade
Os dados de monitoramento de recursos globais e recursos regionais são armazenados de forma independente. Um único repositório de observabilidade centralizado não é recomendado para evitar um único ponto de falha. Para mais informações, veja 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 Aplicativos (APM) para coletar todos os dados de monitoramento de aplicativos e armazená-los diretamente no Log Analytics.
Consulte cargas de trabalho críticas de missão bem arquiteta: ação preditiva e operações de IA.
Recursos de gerenciamento
Uma alteração significativa do design da arquitetura de linha de base é o cluster de computação. Nesse design, o cluster do AKS é privado. Essa alteração requer que recursos extras sejam provisionados para obter acesso.
Conjuntos de Dimensionamento de Máquinas Virtuais do Azure para os agentes de build privados e instâncias de jump box para executar ferramentas no cluster, como kubectl.
O Azure Bastion fornece acesso seguro às VMs jump box e remove a necessidade de as VMs terem IPs públicos.
Pontos de extremidade privados para serviços de PaaS
Para processar operações comerciais ou de implantação, o aplicativo e os agentes de build precisam alcançar vários serviços de PaaS do Azure provisionados globalmente, dentro da região e até mesmo dentro do selo. Na arquitetura de linha de base, essa comunicação é sobre os pontos de extremidade públicos dos serviços.
Nesse design, esses serviços foram protegidos com pontos de extremidade privados para removê-los do acesso público à Internet. Essa abordagem reduz a área geral da superfície de ataque para atenuar a violação direta de serviço de fontes inesperadas. No entanto, ele introduz outro ponto potencial de falha e aumenta a complexidade. Considere cuidadosamente as compensações com a segurança antes de adotar essa abordagem.
Os pontos de extremidade privados devem ser colocados em uma 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 acessando 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 em 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 DNS privadas do Azure atendidas pelo DNS do Azure. Verifique se o FQDN (nome de domínio totalmente qualificado) é 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 Key Vault, os recursos de armazenamento e os Hubs de Eventos. Além disso, o cluster do AKS é implantado como um cluster privado, o que cria um ponto de extremidade privado para o serviço de API do Kubernetes na rede do cluster.
Há duas redes virtuais provisionadas nesse design e ambas têm sub-redes dedicadas para manter pontos de extremidade privados para todos esses serviços. O layout de rede é descrito no 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 Link Privado do Azure para conectar redes ao Azure Monitor.
Elas podem ser criadas nas mesmas sub-redes ou em sub-redes diferentes na mesma rede virtual. Há limites para o número de pontos de extremidade privados que você pode criar em uma assinatura. Para obter mais informações, confira Limites do Azure.
Controlar ainda mais o acesso aos serviços usando grupos de segurança de rede na sub-rede.
Entrada privada
O SKU Premium do Azure Front Door é usado como o ponto de entrada global para todo o tráfego de cliente de entrada. Ele usa recursos do WAF (Firewall de Aplicativo Web) para permitir ou negar o tráfego na borda da rede. As regras de 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 Link Privado do Azure 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. Esse recurso está na frente do Controlador de Entrada do Kubernetes em execução no cluster. Além desse Load Balancer privado, um serviço de Link Privado é criado pelo AKS, que é usado para a conexão privada do Front Door.
Depois que a conexão for estabelecida, os pontos de extremidade privados na rede do Front Door terão conectividade direta com o balanceador de carga e o site estático na rede de selos por meio do Link Privado.
Para obter mais informações, consulte Como funciona o Link Privado.
Consulte cargas de trabalho críticas de missão bem arquiteta: 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 preocupações de segurança, como a exfiltração de dados.
O uso de firewall e NSGs (Grupos de Segurança de Rede) 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 originário da rede virtual. As UDRs (rotas definidas pelo usuário) 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 AKS (Serviço de Kubernetes do Azure).
Layout de rede virtual
Isolar recursos regionais e recursos de gerenciamento em redes virtuais separadas. Elas têm características, finalidades e considerações de segurança distintas.
Tipo de tráfego: os recursos regionais, que participam do processamento de operações de negócios, precisam de controles de segurança mais altos. Por exemplo, o cluster de computação deve ser protegido contra o tráfego direto da Internet. Os recursos de gerenciamento são provisionados apenas para acessar os recursos regionais para operações.
Tempo de vida: os tempos de vida esperados desses recursos também são diferentes. Espera-se que os recursos regionais sejam de curta duração (efêmeros). Eles são criados como parte do carimbo de implantação e destruídos quando o selo é derrubado. Os recursos de gerenciamento compartilham o tempo de vida da região e ativam os recursos de selo.
Nessa arquitetura, há duas redes virtuais: rede de carimbo e rede de operações. Crie um isolamento adicional em 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 críticas de missão bem arquiteta: redes virtuais isoladas.
Rede virtual de carimbo regional
O carimbo de implantação provisiona uma rede virtual em cada região.
A rede virtual é dividida nessas sub-redes principais. Todas as sub-redes têm NSGs (Grupos de Segurança de Rede) 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 na rede.
Sub-rede do aplicativo
Os pools de nós de cluster do AKS são isolados em uma sub-rede. Se você precisar isolar ainda mais o pool de nós do sistema do pool de nós de trabalho, poderá colocá-lo em sub-redes separadas.
Sub-rede de entrada de selo
O ponto de entrada para cada carimbo é um Azure Standard Load Balancer interno que é colocado em uma sub-rede dedicada. O serviço de Link Privado usado para a conexão privada do Front Door também é colocado aqui.
Ambos os recursos são provisionados como parte da implantação do selo.
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 UDR (rota definida pelo usuário).
Sub-rede de pontos de extremidade privados
A sub-rede do aplicativo precisará acessar os serviços de PaaS no selo regional, no Key Vault e em outros. Além disso, o acesso a recursos globais, como o registro de contêiner, é necessário. Nessa arquitetura, todos os serviços de PaaS são bloqueados e só podem ser acessados por meio de pontos de extremidade privados. Portanto, 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 de UDR para pontos de extremidade privados, para que esse tráfego também possa ser egresso por meio da sub-rede de saída do selo.
Rede virtual de operações
O tráfego operacional é isolado em uma rede virtual separada. Como o serviço de API do cluster do AKS é privado nessa arquitetura, toda a implantação e o tráfego operacional também devem vir de recursos privados, como agentes de build auto-hospedados e jump boxes. Esses recursos são implantados em uma rede virtual separada com conectividade direta com os recursos do aplicativo por meio de seu próprio conjunto de pontos de extremidade privados. Os agentes de build e as caixas de salto estão em sub-redes separadas.
Em vez de usar pontos de extremidade privados, uma abordagem alternativa é usar o emparelhamento de rede virtual. No entanto, o emparelhamento adiciona complexidade que pode ser difícil de gerenciar especialmente quando redes virtuais são projetadas para serem efêmeras.
Os agentes de build (e, opcionalmente, jump boxes) precisam acessar os serviços de PaaS localizados globalmente e dentro do carimbo regional. Semelhante à rede virtual de selo regional, uma sub-rede dedicada é criada para os pontos de extremidade privados para os serviços de 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 gerenciamento
Um caso de uso típico é quando um operador precisa acessar o cluster de computação para executar comandos e ferramentas de gerenciamento. O serviço de API em um cluster privado não pode ser acessado diretamente. É por isso que as jump boxes são provisionadas em que o operador pode executar as ferramentas. Há uma sub-rede separada para as caixas de salto.
Mas essas caixas de salto precisam ser protegidas também contra acesso não autorizado. O acesso direto a jump boxes abrindo portas RDP/SSH deve ser evitado. O Azure Bastion é recomendado para essa finalidade e requer uma sub-rede dedicada nessa rede virtual.
Cuidado
A conectividade por meio do Azure Bastion e das jump boxes pode ter um impacto na produtividade do desenvolvedor, como a execução de ferramentas de depuração, requer um processo adicional. Esteja ciente desses impactos antes de decidir proteger a segurança para sua carga de trabalho crítica.
Você pode restringir ainda mais o acesso à sub-rede jump box usando um NSG que só permite o tráfego de entrada da sub-rede do Bastion por SSH.
Operações de implantação
Para criar pipelines de implantação, você precisa provisionar computação adicional para executar agentes de build. Esses recursos não afetarão diretamente a disponibilidade de runtime da carga de trabalho, mas uma falha de confiabilidade pode comprometer a capacidade de implantar ou atender seu ambiente crítico de missão. Portanto, os recursos de confiabilidade devem ser estendidos a esses recursos.
Essa arquitetura usa conjuntos de dimensionamento de máquinas virtuais para agentes de build e jump boxes (em vez de VMs individuais). Além disso, a segmentação de rede é fornecida por meio do uso de sub-redes. A entrada é restrita ao Azure DevOps.
Considerações de custo
Há um impacto significativo no custo para cargas de trabalho críticas. Nessa arquitetura, as opções de tecnologia, como o uso do SKU Premium do Azure Front Door e o provisionamento do Firewall do Azure em cada selo, levarão a custos maiores. Também há custos adicionais relacionados à manutenção e aos recursos operacionais. Essas compensações devem ser cuidadosamente consideradas antes de adotar uma versão controlada pela rede da arquitetura de linha de base.
Implantar essa arquitetura
Os aspectos de rede dessa arquitetura são implementados na implementação conectada crítica da missão.
Observação
A implementação conectada destina-se a ilustrar uma carga de trabalho crítica que depende de recursos organizacionais, integra-se a 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 virtual privada ou a Zona DNS Privada do Azure já existam dentro da assinatura de conectividade das zonas de destino do Azure.
Próximas etapas
Para obter detalhes sobre as decisões de design tomadas nesta arquitetura, examine a área de design de rede e conectividade para cargas de trabalho críticas 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.