Aplicar os princípios de Zero Trust à segmentação da comunicação de rede baseada no Azure

Artigo
05/31/2024

Este artigo fornece orientação para aplicar os princípios do Zero Trust para segmentar redes em ambientes do Azure. Aqui estão os princípios do Zero Trust.

Princípio Zero Trust	Definição
Verificar explicitamente	Sempre autentique e autorize com base em todos os pontos de dados disponíveis.
Use o acesso menos privilegiado	Limite o acesso do usuário com Just-In-Time e Just-Enough-Access (JIT/JEA), políticas adaptativas baseadas em risco e proteção de dados.
Assuma a violação	Minimize o raio de jateamento e o acesso ao segmento. Verifique a criptografia de ponta a ponta e use análises para obter visibilidade, impulsionar a deteção de ameaças e melhorar as defesas. Você pode minimizar o raio de explosão de ataque cibernético e o acesso ao segmento 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 do Zero Trust à rede do Azure.

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

Cada ambiente, normalmente refletindo um departamento separado da sua organização, deve ter suas 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 obter a funcionalidade necessária para serviços básicos, como DNS, conectividade híbrida e ser capaz de alcançar outros recursos em diferentes redes virtuais do Azure (VNets).

A segmentação da sua 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 infliga danos adicionais (o princípio Assumir violação Zero Trust).

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 de assinatura e vão até os aplicativos executados em máquinas virtuais. A segmentação cria um limite que separa um ambiente de outro, cada um com suas próprias regras e políticas. Com a suposição de que violações podem acontecer, você precisa segmentar suas redes para evitar sua disseminação.

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

Subscrições

Uma subscrição do Azure é um contentor lógico utilizado para aprovisionar recursos no Azure. Ele está vinculado a uma conta do Azure em um locatário do Microsoft Entra ID e serve como uma única unidade de cobrança para os 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 redes virtuais não podem se comunicar com outras redes virtuais a menos que você crie conexões entre elas por meio de emparelhamento, conexões VPN ou Rota Expressa. As redes virtuais individuais podem ser usadas como um limite de confiança que divide diferentes aplicativos, cargas de trabalho, departamentos ou organizações.

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

Para cargas de trabalho dentro de uma VNet, como máquinas virtuais ou quaisquer serviços PaaS que suportem a integração de VNet, como o Azure Databricks e o Serviço de Aplicativo, a comunicação é permitida por padrão, pois eles estão contidos na mesma VNet e devem ser protegidos usando grupos de segurança de rede. As ferramentas e serviços para segmentação dentro de uma VNet incluem o seguinte:
- Azure Firewall
  
  O Firewall do Azure é um serviço implantado em uma rede virtual para filtrar o tráfego entre recursos de nuvem, no local e a Internet. Com o Firewall do Azure, você pode definir regras e políticas para permitir ou negar tráfego nas camadas de rede e 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 Deteção e Prevenção de Intrusões), inspeção TLS (Transport Layer Security) e filtragem baseada em inteligência de 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 rede virtual. Um grupo de segurança de rede contém regras de segurança que permitem ou negam tráfego nos níveis de sub-rede ou máquina virtual em uma rede virtual. Um uso comum de grupos de segurança de rede é segmentar os conjuntos de máquinas virtuais em diferentes sub-redes.
- Grupo de segurança de aplicações
  
  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.
- Azure Front Door
  
  O Azure Front Door é a moderna Rede de Distribuição de Conteúdo (CDN) na nuvem da Microsoft que fornece acesso rápido, confiável e seguro entre seus usuários e o conteúdo da Web estático e dinâmico de seus 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:

Subscrições do Azure
VNets em uma assinatura
Sub-redes em uma rede virtual
A Internet e uma rede virtual

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

O que contém este artigo?

Os princípios Zero Trust são aplicados em toda a 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 Assumir violação Zero Trust.

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

Etapa 1: segmentar dentro de suas redes virtuais individuais

Em uma única VNet em uma assinatura do Azure, você usa sub-redes para obter separação e segmentação de recursos. Por exemplo, dentro de 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 é habilitada em uma rede virtual.

Para criar isolamento entre sub-redes, você pode aplicar grupos de segurança de rede ou grupos de segurança de aplicativos 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 de aplicativos 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 de aplicativos para criar limites segmentados entre cada sub-rede.

Você também pode obter 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 um NVA (Network Virtual Appliance) de terceiros. O Firewall do Azure e os NVAs também têm a capacidade de permitir ou negar tráfego usando controles de camada 3 a camada 7. A maioria desses serviços fornece recursos avançados de filtragem.

Para obter mais informações, consulte as orientações em Padrão 1: Rede virtual única.

Etapa 2: Conectar várias redes virtuais com emparelhamento

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

Esta ilustração mostra uma conexão de emparelhamento de rede virtual entre duas redes virtuais 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íficos para microssegmentação só seria necessária se o tráfego intra-VNet for um requisito. No entanto, como a rede virtual tem seus próprios limites, os controles de segurança já estão em vigor.

Para obter mais informações, veja a seguinte documentação de orientação:

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

Para várias redes virtuais em uma configuração de hub e spoke, você precisa considerar como segmentar seu tráfego de rede para estes 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 da rede, que envolve o gerenciamento do tráfego de entrada da Internet (não confiável) e do 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 um único ponto de entrada. A Microsoft recomenda vivamente que o tráfego de entrada passe por um recurso PaaS do Azure, como o Firewall do Azure, a Porta da Frente do Azure ou o Gateway de Aplicação do Azure. Esses recursos de PaaS oferecem mais recursos do que uma máquina virtual com um endereço IP público.

Azure Firewall

Esta ilustração mostra como o Firewall do Azure em sua própria sub-rede atua como um ponto de entrada central e 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, consulte Firewall do Azure no Microsoft Azure Well-Architected Framework.

Azure Front Door

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 com recursos como ILB (Balanceamento de Carga Interno) para acesso VNet, contas de armazenamento para sites estáticos e armazenamento de blob 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 proteção contra DDoS integrada. Quando o cache está habilitado, o conteúdo pode ser recuperado de locais de ponto de presença (POP) em vez de acessar constantemente os 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 seus servidores, o Azure Front Door usa o Split TCP para duas conexões separadas. Isso não só melhora a experiência do usuário final, mas impede que agentes 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, consulte Azure Front Door no Azure Well-Architected Framework.

Gateway de Aplicação do Azure

O ponto de entrada na 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 pela Porta da Frente do Azure. O tráfego não-HTTP/HTTPS, como RDP/SSH, pode entrar por meio do Firewall do Azure ou de um 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 na 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 todo o outro tráfego.

Dois cenários comumente recomendados são:

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

Para obter mais informações, consulte Azure Application Gateway 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 exterior) e outra para o tráfego confiável (voltado para o interno). Em termos de fluxo de tráfego, você deve rotear o tráfego de entrada do local para o NVA usando UDRs. O tráfego de entrada da Internet recebido pelo NVA deve 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 sai de sua VNet para a Internet, você pode aplicar um UDR usando uma tabela de rotas com o NVA escolhido como o próximo salto. Para reduzir a complexidade, você pode implantar um Firewall do Azure ou NVA dentro do seu hub WAN Virtual do Azure e ativar a segurança da Internet com a Intenção de Roteamento. Isso garante que o tráfego norte-sul (que entra e sai de um escopo de rede) e o tráfego leste-oeste (entre dispositivos dentro de um escopo de rede) destinados a endereços IP virtuais (VIPs) que não são do Azure sejam inspecionados.

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 originado no 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 lidar, que na maioria dos casos pode ser muito maior e mais resiliente. Nesse caso, configurar uma rota padrão nos 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 Azure Route Server em combinação com um NVA para anunciar uma rota padrão para o local utilizando o Border Gateway Protocol (BGP).

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 sobre BGP. Isso força o tráfego que sai da VNet a ser encapsulado através de sua rede local para um firewall para inspeção. Esta última abordagem é a menos desejada devido ao aumento da latência e à falta de controles de segurança fornecidos pelo Azure. Esta prática é amplamente adotada pelo governo e setores bancários que têm requisitos específicos para a inspeção de tráfego dentro de seu ambiente local.

Em termos de escala:

Para uma única rede virtual, você pode usar grupos de segurança de rede, que aderem estritamente à semântica da camada 4, ou pode usar um Firewall do Azure que adere à semântica da Camada 4 e da Camada 7.
Para várias redes virtuais, um único Firewall do Azure ainda pode ser usado se estiver acessível, ou você pode 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 direcionar o tráfego 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 pode conseguir isso 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 raios e redes de filiais e enviará tráfego vinculado à Internet para o Firewall do Azure para inspeção. O tráfego privado destinado aos blocos de endereços RFC 1918 é enviado para o Firewall do Azure ou NVA como o próximo salto designado dentro do hub WAN Virtual do Azure.

Limite de rede local

No Azure, os principais métodos para estabelecer conectividade com redes locais incluem túneis IPsec, túneis de Rota Expressa ou túneis WAN (SD-WAN) definidos por software. Normalmente, você usa uma conexão VPN Site a Site (S2S) 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 a Rota Expressa.

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, a Rota Expressa geralmente é configurada para redes corporativas 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 muitas vezes 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ê estiver usando tabelas de rotas. Você ainda pode segmentar hubs conectados à Rota Expressa com NVAs e Firewalls. Para raios emparelhados a hubs, você pode optar por não usar o gateway remoto nas propriedades de emparelhamento de VNet. Dessa forma, os porta-vozes só aprendem sobre seus hubs diretamente conectados e não sobre quaisquer rotas locais.

Outra abordagem emergente para segmentar o tráfego de e para o local é o uso de tecnologias SD-WAN. Você pode estender seus locais de filial para o Azure SD-WAN usando NVAs de terceiros no Azure para criar segmentação com base em túneis SD-WAN provenientes de diferentes ramificações dentro dos dispositivos NVA. Você pode usar o Azure Route Server para injetar os prefixos de endereço para os túneis SD-WAN na plataforma Azure para uma topologia de hub e spoke.

Para uma topologia de WAN virtual, você pode ter integração direta do SD-WAN NVA 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 a partir do NVA integrado ao hub virtual.

Para ambos os modelos, você pode usar a Rota Expressa para segmentar a conectividade pública ou privada subjacente com emparelhamento privado ou emparelhamento da Microsoft. Por segurança, uma prática comum é anunciar uma rota padrão pela Rota Expressa. Isso força todo o tráfego que sai da rede virtual a ser encapsulado para sua rede local para inspeção. Da mesma forma, o tráfego proveniente de VPN e ExpressRoute pode ser enviado para um NVA para inspeção adicional. Isso também se aplica ao tráfego que sai 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 privada usando a Intenção de Roteamento. Isso direciona todo o tráfego destinado a um endereço IP privado do NVA para inspeção. Assim como nos 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 apenas associar e propagar as VNets desejadas para essas tabelas de rotas. No entanto, esse recurso não pode ser combinado com a intenção de roteamento atualmente. Para isolar ramificações, você pode atribuir rótulos para associar ramificações a esse rótulo. Você também pode desabilitar a propagação para o rótulo padrão por hub. Atualmente, não é possível isolar filiais individuais no Azure separadamente em um único hub. Por exemplo, não é possível isolar SD-WAN da Rota Expressa. Mas em um hub inteiro, você pode desativar a propagação para o rótulo padrão.

Limites para serviços globais do Azure

No Azure, a maioria dos serviços é, por padrão, acessível 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 Azure tem um firewall interno que pode restringir o acesso a redes virtuais 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 de forma privada, em vez de usar os endereços IP públicos padrão fornecidos.

O método mais comum para restringir o acesso a recursos de PaaS é por meio do Azure Private Link. Quando você cria um ponto de extremidade privado, ele é injetado em sua rede virtual. O Azure usa esse endereço IP privado para fazer um túnel para o recurso PaaS em questão. O Azure mapeia um registro DNS A para o ponto de extremidade privado usando as 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 a VIPs PaaS. Você pode selecionar tags de serviço para permitir conexões com todos os recursos PaaS dentro dessa tag e fornecer conectividade privada ao recurso PaaS.

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

Para obter mais informações, veja a seguinte documentação de orientação:

Resumo da segmentação

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

Entre as	Comportamento predefinido	Comunicação possibilitada por...	Método(s) de segurança de segmentação
Subscrições	Sem comunicação	- Emparelhamento VNet - Gateways VPN	Azure Firewall
VNets	Sem comunicação	- Emparelhamento VNet - Gateways VPN	Azure Firewall
Cargas de trabalho em sub-redes dentro de uma VNet	Comunicação aberta	N/A	- Grupos de segurança de rede - Grupos de segurança de aplicações
A Internet e uma rede virtual	Sem comunicação	- Balanceador de Carga - IP público - Gateway de Aplicação - Azure Front Door	- Gateway de Aplicativo do Azure com um Firewall de Aplicativo Web - Firewall do Azure - Azure Front Door com um Firewall de Aplicação Web
A Internet e suas redes locais	Sem comunicação	- Azure S2S VPN - Túnel IPSec - Túnel ExpressRoute - Túnel SD-WAN	Azure Firewall
A Internet e as máquinas virtuais em uma rede virtual	Nenhuma 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

Formação recomendada

Passos Seguintes

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

Referências

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

Partilhar via