Aplicar princípios de Confiança Zero para segmentar a comunicação de rede baseada no Azure

Artigo
06/04/2024

Esse artigo fornece orientações para a aplicação dos princípios de Confiança Zero para segmentar redes em ambientes Azure. Aqui estão os princípios de Confiança Zero.

Princípio de Confiança Zero	Definição
Verificação explícita	Sempre autenticar e autorizar com base em todos os pontos de dados disponíveis.
Usar o acesso de privilégio mínimo	Limite o acesso do usuário com JIT/JEA (Just-In-Time e Just-Enough-Access), políticas adaptáveis baseadas em risco e proteção de dados.
Pressupor a violação	Minimize o raio de alcance e segmente o acesso. Verifique a criptografia de ponta a ponta e use a análise para obter visibilidade, promover a detecção de ameaças e melhorar as defesas. Você pode minimizar o raio de ataque cibernético e segmentar o acesso executando a segmentação de rede em vários níveis em sua infraestrutura do Azure.

Este artigo faz parte de uma série de artigos que demonstram como aplicar os princípios da Confiança Zero à rede do Azure.

À medida que as organizações crescem de pequenas empresas para grandes empresas, elas geralmente precisam passar de apenas uma assinatura do Azure para várias assinaturas, a fim de separar recursos para cada departamento. É importante planejar cuidadosamente a segmentação de sua rede para criar limites lógicos e isolamento entre ambientes.

Cada ambiente, normalmente refletindo um departamento separado de sua organização, deve ter as próprias permissões de acesso e políticas para cargas de trabalho específicas. Por exemplo, os usuários de sua assinatura interna de desenvolvedor de software não devem ter acesso ao gerenciamento e implantação de recursos de rede na assinatura de conectividade. No entanto, esses ambientes ainda precisam de conectividade de rede para obterem a funcionalidade necessária para serviços básicos, como DNS, conectividade híbrida e serem capazes de alcançar outros recursos em VNets (redes virtuais) diferentes do Azure.

A segmentação da infraestrutura do Azure fornece não apenas isolamento, mas também pode criar limites de segurança que impedem que um invasor se mova entre ambientes e cause danos adicionais (o princípio de Confiança Zero de Pressupor a violação).

Arquitetura de referência

Você pode usar diferentes níveis de segmentação no Azure para ajudar a proteger seus recursos contra acesso não autorizado ou ataque mal-intencionado. Esses níveis de segmentação começam no nível da assinatura e vão até os aplicativos em execução em máquinas virtuais. A segmentação cria um limite que separa um ambiente de outro, cada um com regras e políticas próprias. Com a suposição de que as violações podem acontecer, você precisa segmentar suas redes para evitar a propagação delas.

A rede do Azure usa os seguintes níveis de segmentação:

Assinaturas

Uma assinatura do Azure é um contêiner lógico usado para provisionar recursos no Azure. Ele está vinculado a uma conta do Azure em um locatário do Microsoft Entra ID e serve como uma unidade de cobrança para recursos do Azure atribuídos à assinatura. Uma assinatura do Azure também é um limite lógico para o acesso aos recursos contidos na assinatura. O acesso entre recursos em assinaturas diferentes requer permissões explícitas.
VNets

Uma VNet do Azure é uma rede privada isolada que, por padrão, permite que todas as máquinas virtuais dentro dela se comuniquem entre si. Por padrão, as VNets não podem se comunicar com outras VNets, a menos que você crie conexões entre elas por meio de emparelhamento, conexões VPN ou ExpressRoute. VNets individuais podem ser usadas como um limite de confiança que divide diferentes aplicativos, cargas de trabalho, departamentos ou organizações.

O AVNM (Gerenciador de Rede Virtual do Azure) é um serviço de gerenciamento de rede que permite que apenas uma equipe de administração gerencie VNets e imponha regras de segurança em várias assinaturas globalmente. Você pode usar o AVNM para definir grupos de rede para determinar quais VNets podem se comunicar entre elas. Você também pode usar o AVNM para monitorar as alterações de configuração de rede.
Cargas de trabalho em uma VNet

Para cargas de trabalho em uma VNet, como máquinas virtuais ou serviços de PaaS que dão suporte à integração de VNet, como o Azure Databricks e o Serviço de Aplicativo, a comunicação é permitida por padrão, pois elas estão contidas na mesma VNet e precisam ser protegidas ainda mais usando grupos de segurança de rede. As ferramentas e os serviços para segmentação em uma VNet incluem o seguinte:
- Firewall do Azure
  
  O Firewall do Azure é um serviço implantado em uma VNet para filtrar o tráfego entre os recursos de nuvem, o local e a Internet. Com o Firewall do Azure, você pode definir regras e políticas para permitir ou negar o tráfego nas camadas de rede e de aplicativo. Você também pode se beneficiar dos recursos avançados de proteção contra ameaças fornecidos pelo Firewall do Azure, como IDPS (Sistema de Detecção e Prevenção de Intrusões), inspeção do protocolo TLS e filtragem baseada em inteligência contra ameaças.
- Grupo de segurança de rede
  
  Um grupo de segurança de rede é um mecanismo de controle de acesso que filtra o tráfego de rede entre recursos do Azure, como máquinas virtuais em uma VNet. Um grupo de segurança de rede contém regras de segurança que permitem ou negam o tráfego nos níveis de sub-rede ou máquina virtual em uma VNet. Um uso comum de grupos de segurança de rede é segmentar os conjuntos de máquinas virtuais em sub-redes diferentes.
- Grupo de segurança do aplicativo
  
  Um grupo de segurança de aplicativo é uma extensão de um grupo de segurança de rede que permite agrupar as interfaces de rede de máquinas virtuais com base em suas funções e funções. Em seguida, você pode usar os grupos de segurança do aplicativo em um grupo de segurança de rede em escala sem precisar definir os endereços IP das máquinas virtuais.
- Porta da frente do Azure
  
  O Azure Front Door é a CDN (Rede de Distribuição de Conteúdo) em nuvem moderna da Microsoft, que fornece acesso rápido, confiável e seguro entre os usuários e o conteúdo da Web estático e dinâmico dos aplicativos em todo o mundo.

O diagrama a seguir mostra a arquitetura de referência para os níveis de segmentação.

No diagrama, as linhas vermelhas sólidas indicam níveis de segmentação entre:

Assinaturas do Azure
VNets em uma assinatura
Sub-redes em uma VNet
A Internet e uma VNet

O diagrama também mostra um conjunto de VNets gerenciadas pelo AVNM que podem abranger assinaturas do Azure.

O que você encontrará neste artigo?

Os princípios de Confiança Zero são aplicados na arquitetura de referência na nuvem do Azure. A tabela a seguir descreve as recomendações para segmentar redes nessa arquitetura para aderir ao princípio de Confiança Zero de Pressupor a violação.

Etapa	Tarefa
1	Segmente dentro de suas VNets individuais.
2	Conecte várias VNets com emparelhamento.
3	Conecte várias VNets em uma configuração de hub e spoke.

Etapa 1: segmentar dentro de suas VNets individuais

Em apenas uma VNet em uma assinatura do Azure, você usa sub-redes para obter a separação e a segmentação de recursos. Por exemplo, em uma VNet, pode haver uma sub-rede para servidores de banco de dados, outra para aplicativos Web e uma sub-rede dedicada para um Firewall do Azure ou Gateway de Aplicativo do Azure com um Firewall de Aplicativo Web. Por padrão, toda a comunicação entre sub-redes está habilitada em uma VNet.

Para criar isolamento entre sub-redes, você pode aplicar grupos de segurança de rede ou grupos de segurança do aplicativo para permitir ou negar tráfego de rede específico com base em endereços IP, portas ou protocolos. No entanto, projetar e manter grupos de segurança de rede e grupos de segurança do aplicativo também pode criar sobrecarga de gerenciamento.

Esta ilustração mostra uma configuração comum e recomendada de um aplicativo de três camadas com sub-redes separadas para cada camada e o uso de grupos de segurança de rede e grupos de segurança do aplicativo para criar limites segmentados entre cada sub-rede.

Você também pode obter a segmentação de recursos roteando o tráfego entre sub-redes usando UDRs (rotas definidas pelo usuário) apontando para um Firewall do Azure ou uma NVA (Solução de Virtualização de Rede) de terceiros. O Firewall do Azure e os NVAs também têm a capacidade de permitir ou negar o tráfego usando controles de camada 3 a 7. A maioria desses serviços fornece recursos avançados de filtragem.

Para obter mais informações, consulte as diretrizes no Padrão 1: rede virtual única.

Etapa 2: Conectar várias VNets com emparelhamento

Por padrão, não há nenhuma comunicação permitida entre VNets com apenas uma assinatura do Azure ou em várias assinaturas. Várias VNets, cada uma pertencente a entidades diferentes, têm controles de acesso próprios. Eles podem se conectar uns aos outros ou a uma VNet de hub centralizada usando o emparelhamento de VNet, em que um Firewall do Azure ou uma NVA de terceiros inspeciona todo o tráfego.

Esta ilustração mostra uma conexão de emparelhamento de VNet entre duas VNets e o uso do Firewall do Azure em cada extremidade da conexão.

Uma VNet de hub normalmente contém componentes compartilhados, como firewalls, provedores de identidade e componentes de conectividade híbrida, entre outros. O gerenciamento de UDR torna-se mais simples porque a adição de UDRs de prefixo específico para microssegmentação só seria necessária se o tráfego dentro da VNet fosse um requisito. No entanto, como a VNet tem limites próprios, os controles de segurança já estão em vigor.

Para obter mais informações, confira as seguintes diretrizes:

Etapa 3: Conectar várias VNets em uma configuração de hub e spoke

Para várias VNets em uma configuração de hub e spoke, você precisa considerar como segmentar o tráfego de rede para esses limites:

Limite da Internet
Limite de rede local
Limites para serviços globais do Azure

Limite da Internet

Proteger o tráfego da Internet é uma prioridade fundamental na segurança de rede, que envolve o gerenciamento do tráfego de entrada da Internet (não confiável) e o tráfego de saída direcionado para a Internet (confiável) de suas cargas de trabalho do Azure.

A Microsoft recomenda que o tráfego de entrada da Internet tenha apenas um ponto de entrada. A Microsoft recomenda muito que o tráfego de entrada percorra um recurso de PaaS do Azure, como o Firewall do Azure, o Azure Front Door ou o Gateway de Aplicativo do Azure. Esses recursos de PaaS oferecem mais funcionalidades do que uma máquina virtual com um endereço IP público.

Firewall do Azure

Esta ilustração mostra como o Firewall do Azure, em uma sub-rede própria, atua como um ponto de entrada central e um limite de segmentação para o tráfego entre a Internet e uma carga de trabalho de três camadas em uma VNet do Azure.

Para obter mais informações, confira Firewall do Azure em Microsoft Azure Well-Architected Framework.

Porta da frente do Azure

O Azure Front Door pode atuar como um limite entre a Internet e os serviços hospedados no Azure. O Azure Front Door dá suporte à conectividade de Link Privado para recursos como ILB (Balanceamento de Carga Interno) para acesso à VNet, contas de armazenamento para sites estáticos e armazenamento de blobs e Serviços de Aplicativo do Azure. O Azure Front Door geralmente é feito para implantações em escala.

O Azure Front Door é mais do que um serviço de balanceamento de carga. A infraestrutura do Azure Front Door tem a proteção contra DDoS interna. Quando o cache está habilitado, o conteúdo pode ser recuperado de locais de POP (ponto de presença) em vez de acessar constantemente servidores de back-end. Quando o cache expira, o Azure Front Door recupera o recurso solicitado e atualiza o cache. Em vez de os usuários finais acessarem os servidores deles, o Azure Front Door usa o TCP Dividido para duas conexões separadas. Isso não apenas aprimora a experiência do usuário final, mas também impede que atores mal-intencionados acessem recursos diretamente.

Esta ilustração mostra como o Azure Front Door fornece segmentação entre usuários da Internet e recursos do Azure, que podem estar em contas de armazenamento.

Para obter mais informações, confira Azure Front Door no Azure Well-Architected Framework.

Gateway de Aplicativo do Azure

O ponto de entrada da Internet também pode ser uma combinação de pontos de entrada. Por exemplo, o tráfego HTTP/HTTPS pode entrar por meio de um Gateway de Aplicativo protegido por um Firewall de Aplicativo Web ou pelo Azure Front Door. O tráfego não HTTP/HTTPS, como RDP/SSH, pode ser ingressado por meio do Firewall do Azure ou de uma NVA. Você pode usar esses dois elementos em conjunto para uma inspeção mais profunda e para controlar o fluxo de tráfego usando UDRs.

Esta ilustração mostra o tráfego de entrada da Internet e o uso de um Gateway de Aplicativo com um Firewall de Aplicativo Web para tráfego HTTP/HTTPS e um Firewall do Azure para todos os outros tráfegos.

Dois cenários normalmente recomendados são:

Colocar um Firewall do Azure ou uma NVA em paralelo com um Gateway de Aplicativo.
Colocar um Firewall do Azure ou uma NVA após um Gateway de Aplicativo para inspeção de tráfego adicional antes de chegar ao destino.

Para obter mais informações, confira Gateway de Aplicativo do Azure no Microsoft Azure Well-Architected Framework.

Aqui estão padrões comuns adicionais para fluxos de tráfego da Internet.

Tráfego de entrada usando várias interfaces

Uma abordagem envolve o uso de várias interfaces de rede em máquinas virtuais ao usar NVAs: uma interface para tráfego não confiável (voltado para o lado externo) e outra para tráfego confiável (voltado para o lado interno). Em termos de fluxo de tráfego, você precisa rotear o tráfego de entrada do local para a NVA usando UDRs. O tráfego de entrada da Internet recebido pela NVA precisa ser roteado para a carga de trabalho de destino na VNet ou sub-rede apropriada por uma combinação de rotas estáticas no dispositivo de SO convidado e UDRs.

Tráfego de saída e UDRs

Para o tráfego que parte da VNet para a Internet, você pode aplicar uma UDR usando uma tabela de rotas com a NVA escolhida como o próximo salto. Para reduzir a complexidade, você pode implantar um Firewall do Azure ou NVA dentro do hub de WAN Virtual do Azure e ativar a Segurança da Internet com Intenção de Roteamento. Isso garante que o tráfego norte-sul (entrando e saindo de um escopo de rede) e o tráfego leste-oeste (entre dispositivos dentro de um escopo de rede) destinado a VIPs (endereços IP virtuais) não do Azure seja inspecionado.

Tráfego de saída e uma rota padrão

Alguns métodos envolvem o gerenciamento de uma rota padrão (0.0.0.0/0) com métodos diferentes. Como regra geral, é recomendável que o tráfego de saída originário do Azure utilize pontos de saída e inspeção com o Firewall do Azure ou NVAs devido à quantidade de taxa de transferência que a infraestrutura do Azure pode manipular, o que, na maioria dos casos, pode ser muito maior e mais resiliente. Nesse caso, configurar uma rota padrão nas UDRs de sub-redes de carga de trabalho pode forçar o tráfego para esses pontos de saída. Você também pode preferir rotear o tráfego de saída do local para o Azure como um ponto de saída. Nesse caso, utilize o Servidor de Rota do Azure em combinação com uma NVA para anunciar uma rota padrão para o BGP (Border Gateway Protocol) local.

Há casos especiais em que você precisa que todo o tráfego de saída seja roteado de volta para o local anunciando uma rota padrão pelo BGP. Isso força o tráfego deixando a VNet a ser tunelado por meio de sua rede local para um firewall para inspeção. Essa última abordagem é a menos desejada devido ao aumento da latência e à falta de controles de segurança fornecidos pelo Azure. Essa prática é amplamente adotada pelo governo e setores bancários que têm requisitos específicos para inspeção de tráfego no ambiente local deles.

Em termos de escala:

Para uma VNet individual, você pode usar grupos de segurança de rede, que aderem estritamente à semântica da camada 4, ou você pode usar um Firewall do Azure que adere à semântica de Camada 4 e Camada 7.
Para várias VNets, um Firewall do Azure individual ainda poderá ser usado se estiver acessível, ou você poderá implantar um Firewall do Azure em cada rede virtual e direcionar o tráfego com UDRs.

Para redes distribuídas de grandes empresas, você ainda pode usar o modelo hub e spoke e o tráfego direto com UDRs. No entanto, isso pode levar a sobrecarga de gerenciamento e limites de emparelhamento de VNet. Para facilitar o uso, a WAN Virtual do Azure poderá alcançar esse resultado se você implantar um Firewall do Azure no hub virtual e ativar a Intenção de Roteamento para segurança da Internet. Isso injetará rotas padrão em todos os spokes e redes de branch e enviará o tráfego associado à Internet para o Firewall do Azure para inspeção. O tráfego privado destinado aos blocos de endereço RFC 1918 é enviado para o Firewall do Azure ou NVA como o próximo salto designado dentro do hub de WAN Virtual do Azure.

Limite de rede local

No Azure, os principais métodos para estabelecer conectividade com redes locais incluem túneis IPsec (Protocolo IPsec), túneis do ExpressRoute ou túneis WAN (SD-WAN) definidos por software. Normalmente, você usa uma conexão VPN S2S (Site a Site) do Azure para cargas de trabalho menores que exigem menos largura de banda. Para cargas de trabalho que exigem um caminho de serviço dedicado e necessidades de taxa de transferência mais altas, a Microsoft recomenda o ExpressRoute.

Esta ilustração mostra os diferentes tipos de métodos de conexão entre um ambiente do Azure e uma rede local.

Embora as conexões VPN do Azure possam dar suporte a vários túneis, o ExpressRoute geralmente é configurado para redes empresariais maiores que exigem maior largura de banda e conexões privadas por meio de um parceiro de conectividade. Para o ExpressRoute, é possível conectar a mesma VNet a vários circuitos, mas para fins de segmentação, isso geralmente não é ideal, pois permite que VNets não conectadas entre si se comuniquem.

Um método de segmentação envolve optar por não usar um gateway remoto em VNets spoke ou desabilitar a propagação de rotas BGP se você está usando tabelas de rotas. Você ainda pode segmentar hubs conectados ao ExpressRoute com NVAs e Firewalls. Para spokes que são emparelhados com hubs, você pode optar por não usar o gateway remoto nas propriedades de emparelhamento de VNet. Dessa forma, os spokes só aprendem sobre os hubs conectados diretamente deles e não qualquer rota local.

Outra abordagem emergente para segmentar o tráfego indo e vindo do local é o uso de tecnologias SD-WAN. Você pode estender suas localizações de branch para o SD-WAN do Azure usando NVAs de terceiros no Azure para criar segmentação com base em túneis SD-WAN provenientes de diferentes branches dentro dos dispositivos NVA. Você pode usar o Servidor de Rota do Azure para injetar os prefixos de endereço para os túneis SD-WAN na plataforma do Azure para uma topologia de hub e spoke.

Para uma topologia wan virtual, você pode ter integração direta do NVA SD-WAN de terceiros dentro do hub virtual. Você também pode usar pontos de extremidade BGP para permitir o uso de soluções SD-WAN, criando túneis por meio da NVA integrada ao hub virtual.

Para ambos os modelos, você pode usar o ExpressRoute para segmentar a conectividade privada ou pública subjacente com emparelhamento privado ou emparelhamento da Microsoft. Para segurança, uma prática comum é anunciar uma rota padrão pelo ExpressRoute. Isso força todo o tráfego deixando a VNet para ser tunelado para sua rede local para inspeção. Da mesma forma, o tráfego proveniente da VPN e do ExpressRoute pode ser enviado para uma NVA para inspeção adicional. Isso também se aplica ao tráfego saindo do Azure. Esses métodos são simples quando o ambiente é menor, como uma ou duas regiões.

Para redes grandes e distribuídas, você também pode usar a WAN Virtual do Azure ativando a inspeção de tráfego privado usando a Intenção de Roteamento. Isso direciona todo o tráfego destinado a um endereço IP privado da NVA para inspeção. Assim como acontece com os métodos acima, isso é muito mais fácil de gerenciar quando seu ambiente abrange várias regiões.

A outra abordagem com a WAN Virtual do Azure é usar tabelas de rotas personalizadas para limites de isolamento. Você pode criar rotas personalizadas e associar e propagar apenas as VNets que deseja para essas tabelas de rotas. No entanto, essa funcionalidade não pode ser combinada com a intenção de roteamento atualmente. Para isolar branches, você pode atribuir rótulos para associar branches a esse rótulo. Você também pode desabilitar, independentemente para cada hub, a propagação para o rótulo padrão. Atualmente, você não pode isolar branches individuais no Azure separadamente em apenas um hub. Por exemplo, você não pode isolar o SD-WAN do ExpressRoute. Mas em um hub inteiro, você pode desabilitar a propagação para o rótulo padrão.

Limites para serviços globais do Azure

No Azure, a maioria dos serviços é acessível por padrão por meio da WAN global do Azure. Isso também se aplica ao acesso público aos serviços de PaaS do Azure. Por exemplo, o Armazenamento do Microsoft Azure tem um firewall interno que pode restringir o acesso a VNets e bloquear o acesso público. No entanto, muitas vezes há a necessidade de um controle mais granular. A preferência típica é conectar-se aos VIPs do Azure em particular, em vez de usar os endereços IP públicos padrão fornecidos.

O método mais comum para restringir o acesso aos recursos de PaaS é por meio do Link Privado do Azure. Quando você cria um ponto de extremidade privado, ele é injetado em sua VNet. O Azure usa esse endereço IP privado para fazer o túnel para o recurso de PaaS em questão. O Azure mapeia um registro DNS A para o ponto de extremidade privado usando zonas DNS privadas do Azure e mapeia um registro CNAME para o recurso PaaS de link privado.

Os pontos de extremidade de serviço oferecem um método alternativo para se conectar aos VIPs de PaaS. Você pode selecionar marcas de serviço para permitir conexões com todos os recursos de PaaS dentro dessa marca e fornecer conectividade privada ao recurso de PaaS.

Outro método predominante envolve o uso do Emparelhamento da Microsoft para ExpressRoute. Se você quiser se conectar a VIPs de PaaS localmente, poderá configurar o Emparelhamento da Microsoft. Você pode escolher a comunidade BGP para os VIPs a serem consumidos e isso é anunciado no caminho do Emparelhamento da Microsoft.

Para obter mais informações, confira as seguintes diretrizes:

Resumo da segmentação

Esta tabela resume os diferentes níveis de métodos de segmentação e segurança.

BETWEEN	Comportamento padrão	Comunicação habilitada por...	Métodos de segurança de segmentação
Assinaturas	Sem comunicação	– Emparelhamento de VNet – Gateways de VPN	Firewall do Azure
VNets	Sem comunicação	– Emparelhamento de VNet – Gateways de VPN	Firewall do Azure
Cargas de trabalho em sub-redes em uma VNet	Comunicação aberta	N/D	– Grupos de segurança de rede – Grupos de segurança do aplicativo
A Internet e uma VNet	Sem comunicação	– Load Balancer – IP público – Gateway de Aplicativo – Azure Front Door	– Gateway de Aplicativo do Azure com um Firewall de Aplicativo Web - Firewall do Azure – Azure Front Door com um Firewall de Aplicativo Web
A Internet e suas redes locais	Sem comunicação	– Azure S2S VPN – Túnel IPsec – Túnel do ExpressRoute – Túnel SD-WAN	Firewall do Azure
A Internet e as máquinas virtuais em uma VNet	Sem comunicação se as máquinas virtuais tiverem apenas endereços IP privados	Atribuindo à máquina virtual um endereço IP público	Firewall da máquina virtual local

Treinamento recomendado

Próximas etapas

Para obter informações adicionais sobre como aplicar a Confiança Zero à rede do Azure, consulte:

Referências

Consulte estes links para saber mais sobre os vários serviços e tecnologias mencionados neste artigo.

Compartilhar via