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

Artigo
04/13/2024

Este artigo fornece diretrizes para aplicar os princípios da Confiança Zero para criptografar a comunicação de rede de, para e entre ambientes do Azure das maneiras a seguir.

Princípio de Confiança Zero	Definição	Atendido por
Verificação explícita	Sempre autenticar e autorizar com base em todos os pontos de dados disponíveis.	Usando políticas de Acesso Condicional para suas conexões do Gateway de VPN do Azure e SSH (Secure Shell) e protocolo RDP para suas conexões de usuário a máquina virtual.
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.	Configurando seus dispositivos MSEE (Microsoft Enterprise Edge) para usar a CAK (chave de associação de conectividade) estática para o Azure ExpressRoute com portas diretas e usando a identidade gerenciada para autenticar recursos de circuito do ExpressRoute.
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.	Protegendo o tráfego de rede com métodos e protocolos de criptografia que fornecem confidencialidade, integridade e autenticidade de seus dados em trânsito. Usando o Azure Monitor para fornecer alertas e métricas de desempenho de rede do ExpressRoute. Usando o Azure Bastion para gerenciar sessões individuais do serviço Bastion e excluir ou forçar uma desconexão.

Os níveis de criptografia para o tráfego de rede são:

Criptografia de camada de rede
- Proteja e verifique a comunicação da Internet ou da sua rede local com as VNets e máquinas virtuais do Azure
- Proteger e verificar a comunicação dentro de VNets do Azure e entre elas
Criptografia de camada de aplicativo
- Proteção para aplicativos Web do Azure
Proteção para cargas de trabalho em execução em máquinas virtuais do Azure

Arquitetura de referência

O diagrama a seguir mostra a arquitetura de referência para esta diretriz de Confiança Zero para comunicação criptografada entre usuários e administradores locais ou na Internet e componentes no ambiente do Azure para as etapas descritas neste artigo.

No diagrama, os números correspondem às etapas nas seções a seguir.

O que você encontrará neste artigo?

Os princípios da Confiança Zero são aplicados em toda a arquitetura de referência, desde usuários e administradores na Internet ou na sua rede local até a nuvem do Azure e dentro dela. A tabela a seguir descreve as recomendações para garantir a criptografia do tráfego de rede em toda essa arquitetura.

Etapa	Tarefa	Princípios de confiança zero aplicados
1	Implementar uma criptografia de camada de rede.	Verificação explícita Usar o acesso com privilégios mínimos Pressupor a violação
2	Proteja e verifique a comunicação de uma rede local para VNets do Azure.	Verificação explícita Pressupor a violação
3	Proteja e verifique a comunicação dentro de VNets do Azure e entre elas.	Pressupor a violação
4	Implementar uma criptografia de camada de aplicativo.	Verificação explícita Pressupor a violação
5	Use o Azure Bastion para proteger máquinas virtuais do Azure.	Pressupor a violação

Etapa 1: Implementar uma criptografia de camada de rede

A criptografia de camada de rede é essencial ao aplicar princípios de Confiança Zero ao seu ambiente local e do Azure. Quando o tráfego de rede passa pela Internet, você sempre deve assumir que há uma possibilidade de interceptação de tráfego por invasores, e seus dados podem ser expostos ou alterados antes de chegarem ao destino. Como os provedores de serviços controlam como os dados são roteados pela Internet, você deseja garantir que a privacidade e a integridade de seus dados sejam mantidas desde o momento em que eles deixam sua rede local até a nuvem da Microsoft.

O diagrama a seguir mostra a arquitetura de referência para implementar a criptografia de camada de rede.

Nas próximas duas seções, discutiremos a Segurança de Protocolo de Internet (IPsec) e a Segurança de Controle de Acesso à Mídia (MACsec), quais serviços de rede do Azure dão suporte a esses protocolos e como você pode garantir que eles estejam sendo usados.

IPSec

O IPsec é um grupo de protocolos que fornece segurança para comunicações de IP (Protocolo de Internet). Ele autentica e criptografa pacotes de rede usando um conjunto de algoritmos de criptografia. O IPSec é o protocolo de encapsulamento de segurança usado para estabelecer VPNs (redes virtuais privadas). Um túnel VPN IPsec consiste em duas fases: a fase 1, conhecida como modo principal, e a fase 2, conhecida como modo rápido.

A fase 1 do IPsec é o estabelecimento de túnel, onde os pares negociam parâmetros para a associação de segurança do protocolo IKE, como criptografia, autenticação, hash e algoritmos Diffie-Hellman. Para verificar suas identidades, os pares trocam uma chave pré-compartilhada. A fase 1 do IPsec pode operar em dois modos: modo principal ou modo agressivo. O Gateway de VPN do Azure dá suporte a duas versões de IKE, IKEv1 e IKEv2, e opera apenas no modo principal. O modo principal garante a criptografia da identidade da conexão entre o Gateway de VPN do Azure e o dispositivo local.

Na fase 2 do IPsec, os pares negociam parâmetros de segurança para transmissão de dados. Nesta fase, ambos os pares concordam com os algoritmos de criptografia e autenticação, o valor de tempo de vida da SA (associação de segurança) e os TS (seletores de tráfego) que definem qual tráfego é criptografado no túnel IPsec. O túnel criado na fase 1 serve como um canal seguro para essa negociação. O IPsec pode proteger pacotes IP usando o protocolo AH (Cabeçalho de Autenticação) ou o protocolo ESP (encapsulamento de conteúdo de segurança). O AH fornece integridade e autenticação, enquanto o ESP também fornece confidencialidade (criptografia). A fase 2 do IPsec pode operar no modo de transporte ou de túnel. No modo de transporte, apenas o conteúdo do pacote IP é criptografado, enquanto no modo de túnel todo o pacote IP é criptografado e um novo cabeçalho IP é adicionado. A fase 2 do IPsec pode ser estabelecida sobre IKEv1 ou IKEv2. A implementação atual do IPsec do Gateway de VPN do Azure dá suporte apenas ao ESP no modo de túnel.

Alguns dos serviços do Azure que dão suporte ao IPsec são:

Gateway de VPN do Azure
- Conexões VPN site a site
- Conexões de rede virtual a rede virtual
- Conexões ponto a ponto
WAN Virtual do Azure
- Sites VPN
- Configurações de VPN de usuário

Não há configurações que você precise modificar para habilitar o IPsec para esses serviços. Eles estão habilitados por padrão.

MACsec e Azure Key Vault

O MACsec (IEEE 802.1AE) é um padrão de segurança de rede que aplica o princípio de Confiança Zero de Pressupor a violação na camada de vínculo de dados, fornecendo autenticação e criptografia por meio de um link Ethernet. O MACsec pressupõe que qualquer tráfego de rede, mesmo na mesma rede local, pode ser comprometido ou interceptado por atores mal-intencionados. O MACsec verifica e protege cada quadro usando uma chave de segurança compartilhada entre duas interfaces de rede. Essa configuração só pode ser realizada entre dois dispositivos compatíveis com MACsec.

O MACsec é configurado com associações de conectividade, que são um conjunto de atributos que os adaptadores de rede usam para criar canais de segurança de entrada e de saída. Depois de criado, o tráfego por esses canais é trocado por dois links protegidos por MACsec. O MACsec tem dois modos de associação de conectividade:

Modo CAK (chave de associação de conectividade estática): os links protegidos por MACsec são estabelecidos usando uma chave pré-compartilhada que inclui um CKN (nome de chave de associação de conectividade) e a CAK atribuída. Essas chaves são configuradas nas duas extremidades do link.
Modo CAK dinâmico: as chaves de segurança são geradas dinamicamente usando o processo de autenticação 802.1x, que pode usar um dispositivo de autenticação centralizado, como um servidor RADIUS (Remote Authentication Dial-In User Service).

Os dispositivos MSEE (Microsoft Enterprise Edge) dão suporte à CAK estática armazenando a CAK e a CKN em um Azure Key Vault quando você configura o Azure ExpressRoute com portas diretas. Para acessar os valores no Azure Key Vault, configure a identidade gerenciada para autenticar o recurso de circuito do ExpressRoute. Essa abordagem segue o princípio de Confiança Zero Usar o acesso de privilégio mínimo porque somente dispositivos autorizados podem acessar as chaves do Azure Key Vault. Para obter mais informações, consulte Configurar o MACsec em portas do ExpressRoute Direct.

Etapa 2: Proteger e verificar a comunicação de uma rede local para VNets do Azure

À medida que a migração para a nuvem se torna mais prevalente entre empresas de diferentes escalas, a conectividade híbrida desempenha um papel fundamental. É crucial não apenas proteger, mas também verificar e monitorar a comunicação de rede entre sua rede local e o Azure.

O diagrama a seguir mostra a arquitetura de referência para proteger e verificar a comunicação de uma rede local para VNets do Azure.

O Azure fornece duas opções para conectar sua rede local a recursos em uma VNet do Azure:

O Gateway de VPN do Azure permite que você crie um túnel VPN site a site usando o IPsec para criptografar e autenticar a comunicação de rede entre sua rede em escritórios centrais ou remotos e uma VNet do Azure. Ele também permite que clientes individuais estabeleçam uma conexão ponto a site para acessar recursos em uma VNet do Azure sem um dispositivo VPN. Para a adesão ao princípio de Confiança Zero, configure a autenticação do Entra ID e as políticas de Acesso Condicional para suas conexões do Gateway de VPN do Azure para verificar a identidade e a conformidade dos dispositivos que se conectam. Para obter mais informações, consulte Usar o gateway de VPN do Microsoft Tunnel com políticas de Acesso Condicional.
O Azure ExpressRoute fornece uma conexão privada de alta largura de banda que permite estender sua rede local para o Azure com a ajuda de um provedor de conectividade. Como o tráfego de rede não viaja pela Internet pública, os dados não são criptografados por padrão. Para criptografar o tráfego pelo ExpressRoute, configure um túnel IPsec. No entanto, tenha em mente que, ao executar túneis IPsec sobre o ExpressRoute, a largura de banda é limitada à largura de banda do túnel e talvez seja necessário executar vários túneis para corresponder à largura de banda do circuito do ExpressRoute. Para obter mais informações, confira Conexões VPN site a site por meio do emparelhamento privado do ExpressRoute – Gateway de VPN do Azure.

Se estiver usando portas do ExpressRoute Direct, você poderá aumentar a segurança da rede habilitando a autenticação ao estabelecer pares BGP ou configurando o MACsec para proteger a comunicação da camada 2. O MACsec fornece criptografia para quadros Ethernet, garantindo confidencialidade, integridade e autenticidade dos dados entre o roteador de borda e o roteador de borda da Microsoft.

O Azure ExpressRoute também dá suporte ao Azure Monitor para alertas e métricas de desempenho de rede.

A criptografia pode proteger seus dados contra interceptação não autorizada, mas também introduz uma camada extra de processamento para criptografar e descriptografar o tráfego de rede que pode afetar o desempenho. O tráfego de rede passando pela Internet também pode ser imprevisível porque ele precisa percorrer vários dispositivos de rede que podem introduzir latência de rede. Para evitar problemas de desempenho, a Microsoft recomenda usar o ExpressRoute porque ele oferece desempenho de rede confiável e alocação de largura de banda que você pode personalizar para sua carga de trabalho.

Ao decidir entre o Gateway de VPN do Azure ou o ExpressRoute, considere as seguintes perguntas:

Que tipos de arquivos e aplicativos você está acessando entre sua rede local e o Azure? Você precisa de largura de banda consistente para transferir grandes volumes de dados?
Você precisa de latência consistente e baixa para que seus aplicativos sejam executados de maneira ideal?
Você precisa monitorar o desempenho da rede e a integridade da conectividade híbrida?

Se você respondeu sim a qualquer uma dessas perguntas, o Azure ExpressRoute deverá ser seu método principal de conectar sua rede local ao Azure.

Há dois cenários comuns em que o ExpressRoute e o Gateway de VPN do Azure podem coexistir:

O Gateway de VPN do Azure pode ser usado para conectar suas filiais ao Azure tendo sua sede conectada usando o ExpressRoute.
Você também pode usar o Gateway de VPN do Azure como uma conexão de backup com o Azure para seu escritório central se o serviço ExpressRoute tiver uma interrupção.

Etapa 3: Proteger e verificar a comunicação dentro de VNets do Azure e entre elas

O tráfego no Azure tem um nível subjacente de criptografia. Quando o tráfego se move entre VNets em regiões diferentes, a Microsoft usa o MACsec para criptografar e autenticar o tráfego de emparelhamento na camada de link de dados.

O diagrama a seguir mostra a arquitetura de referência para proteger e verificar a comunicação dentro de VNets do Azure e entre elas.

No entanto, a criptografia por si só não é suficiente para garantir a Confiança Zero. Você também deve verificar e monitorar a comunicação de rede dentro de VNets do Azure e entre elas. Mais criptografia e verificação entre VNets são possíveis com a ajuda do Gateway de VPN do Azure ou NVAs (dispositivos virtuais de rede), mas essa não é uma prática comum. A Microsoft recomenda criar sua topologia de rede para usar um modelo de inspeção de tráfego centralizado que possa impor políticas granulares e detectar anomalias.

Para reduzir a sobrecarga de configurar um gateway de VPN ou uma solução de virtualização, habilite o recurso de criptografia de VNet para determinados tamanhos de máquina virtual para criptografar e verificar o tráfego entre máquinas virtuais no nível do host, dentro de uma VNet e entre emparelhamentos de VNet.

Etapa 4: Implementar criptografia na camada de aplicativo

A criptografia de camada de aplicativo é um fator-chave para a Confiança Zero que exige que todos os dados e comunicações sejam criptografados quando os usuários estiverem interagindo com aplicativos Web ou dispositivos. A criptografia da camada de aplicativo garante que apenas entidades verificadas e confiáveis possam acessar aplicativos Web ou dispositivos.

O diagrama a seguir mostra a arquitetura de referência para implementar a criptografia na camada do aplicativo.

Um dos exemplos mais comuns de criptografia na camada de aplicativo é o HTTPS (Hypertext Transfer Protocol Secure), que criptografa dados entre um navegador da Web e um servidor Web. O HTTPS usa o protocolo TLS (Transport Layer Security) para criptografar a comunicação cliente-servidor e usa um certificado digital TLS para verificar a identidade e a confiabilidade do site ou domínio.

Outro exemplo de segurança da camada de aplicativo é o Secure Shell (SSH) e o RDP (Protocolo de Área de Trabalho Remota) que criptografa os dados entre o cliente e o servidor. Esses protocolos também dão suporte à autenticação multifator e às políticas de Acesso Condicional para garantir que somente dispositivos ou usuários autorizados e compatíveis possam acessar recursos remotos. Consulte a Etapa 5 para obter informações sobre como proteger conexões SSH e RDP para máquinas virtuais do Azure.

Proteção para aplicativos Web do Azure

Você pode usar o Azure Front Door ou o Gateway de Aplicativo do Azure para proteger seus aplicativos Web do Azure.

Porta da frente do Azure

O Azure Front Door é um serviço de distribuição global que otimiza a entrega de conteúdo para usuários finais por meio dos locais de borda da Microsoft. Com recursos como WAF (Firewall de Aplicativo Web) e serviço de Link Privado, você pode detectar e bloquear ataques mal-intencionados em seus aplicativos Web na borda da rede da Microsoft enquanto acessa suas origens de maneira privada usando a rede interna da Microsoft.

Para proteger seus dados, o tráfego para pontos de extremidade do Azure Front Door é protegido usando HTTPS com TLS de ponta a ponta para todo o tráfego que vai para e sai de seus pontos de extremidade. O tráfego é criptografado do cliente para a origem e da origem para o cliente.

O Azure Front Door manipula solicitações HTTPS e determina qual ponto de extremidade em seu perfil tem o nome de domínio associado. Em seguida, ele verifica o caminho e determina qual regra de roteamento corresponde ao caminho da solicitação. Se o cache estiver habilitado, o Azure Front Door verificará seu cache para ver se há uma resposta válida. Se não houver uma resposta válida, o Azure Front Door selecionará a melhor origem que pode fornecer o conteúdo solicitado. Antes que a solicitação seja enviada para a origem, um conjunto de regras pode ser aplicado à solicitação para alterar o cabeçalho, a cadeia de consulta ou o destino de origem.

O Azure Front Door dá suporte ao TLS de front-end e back-end. O TLS front-end criptografa o tráfego entre o cliente e o Azure Front Door. O TLS de back-end criptografa o tráfego entre o Azure Front Door e a origem. O Azure Front Door dá suporte ao TLS 1.2 e ao TLS 1.3. Você pode configurar o Azure Front Door para usar um certificado TLS personalizado ou usar um certificado gerenciado pelo Azure Front Door.

Observação

Você também pode usar o recurso Link Privado para conectividade com NVAs para inspeção de pacotes adicionais.

Gateway de Aplicativo do Azure

O Gateway de Aplicativo do Azure é um balanceador de carga regional que opera na Camada 7. Ele roteia e distribui o tráfego da Web com base em atributos de URL HTTP. Ele pode rotear e distribuir o tráfego usando três abordagens diferentes:

Somente HTTP: o Gateway de Aplicativo recebe e roteia solicitações HTTP de entrada para o destino apropriado de maneira não criptografada.
Terminação SSL: o Gateway de Aplicativo descriptografa solicitações HTTPS de entrada no nível da instância, inspeciona-as e encaminha-as não criptografadas para o destino.
TLS de ponta a ponta: o Gateway de Aplicativo descriptografa solicitações HTTPS de entrada no nível da instância, inspeciona-as e criptografa-as novamente antes de roteá-las para o destino.

A opção mais segura é o TLS de ponta a ponta, que permite a criptografia e a transmissão de dados confidenciais exigindo o uso de certificados de autenticação ou certificados raiz confiáveis. Ele também requer que você carregue esses certificados para os servidores de back-end e garanta que esses servidores de back-end sejam conhecidos pelo Gateway de Aplicativo. Para obter mais informações, confira Como configurar o TLS de ponta a ponta usando o Gateway de Aplicativo.

Além disso, usuários locais ou usuários em máquinas virtuais em outra VNet podem usar o front-end interno do Gateway de Aplicativo com os mesmos recursos do TLS. Junto com a criptografia, a Microsoft recomenda que você sempre habilite o WAF para mais proteção de front-end para seus pontos de extremidade.

Etapa 5: Usar o Azure Bastion para proteger máquinas virtuais do Azure

O Azure Bastion é um serviço de PaaS gerenciado que permite que você se conecte com segurança às suas máquinas virtuais por meio de uma conexão TLS. Essa conectividade pode ser estabelecida no portal do Azure ou por meio de um cliente nativo para o endereço IP privado na máquina virtual. As vantagens de usar o Bastion incluem:

As máquinas virtuais do Azure não precisam de um endereço IP público. As conexões são pela porta TCP 443 para HTTPS e podem atravessar a maioria dos firewalls.
As máquinas virtuais são protegidas contra verificação de porta.
A plataforma do Azure Bastion é constantemente atualizada e protegida contra explorações de dia zero.

Com o Bastion, você pode controlar a conectividade RDP e SSH com sua máquina virtual de apenas um ponto de entrada. Você pode gerenciar sessões individuais do serviço do Bastion no portal do Azure. Você também pode excluir ou forçar uma desconexão de uma sessão remota em andamento se suspeitar que um usuário não deveria estar se conectando a esse computador.

O diagrama a seguir mostra a arquitetura de referência para usar o Azure Bastion para proteger máquinas virtuais do Azure.

Para proteger sua máquina virtual do Azure, implante o Azure Bastion e comece a usar RDP e SSH para se conectar às suas máquinas virtuais com seus endereços IP privados.

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.