Rede de confiança zero para aplicações Web com a Firewall do Azure e o Gateway de Aplicações

Este guia descreve uma estratégia para implementar segurança de confiança zero para aplicativos Web para inspeção e criptografia. O paradigma de confiança zero inclui muitos outros conceitos, como a verificação constante da identidade dos atores ou a redução ao mínimo do tamanho das áreas de confiança implícitas. Este artigo refere-se ao componente de criptografia e inspeção de uma arquitetura de confiança zero para o tráfego de entrada da Internet pública. Leia outros documentos de confiança zero para obter mais aspetos da implantação segura do seu aplicativo, como autenticação. Para o propósito deste artigo, uma abordagem multicamadas funciona melhor, onde a segurança de rede compõe uma das camadas do modelo de confiança zero. Nessa camada, os dispositivos de rede inspecionam os pacotes para garantir que apenas o tráfego legítimo chegue aos aplicativos.

Normalmente, diferentes tipos de dispositivos de rede inspecionam diferentes aspetos dos pacotes de rede:

• Os firewalls de aplicativos Web procuram padrões que indiquem um ataque na camada de aplicativos Web.
• Os firewalls de última geração também podem procurar ameaças genéricas.

Em algumas situações, você pode combinar diferentes tipos de dispositivos de segurança de rede para aumentar a proteção. Um guia separado, Firewall e Application Gateway para redes virtuais, descreve padrões de design que você pode usar para organizar os vários dispositivos. Este documento se concentra em um padrão comum para maximizar a segurança, no qual o Gateway de Aplicativo do Azure atua antes do Firewall Premium do Azure. O diagrama a seguir ilustra esse padrão:

Transfira um ficheiro do Visio desta arquitetura.

Essa arquitetura usa o protocolo TLS (Transport Layer Security) para criptografar o tráfego em cada etapa.

• Um cliente envia pacotes para o Application Gateway, um balanceador de carga. Ele é executado com a adição opcional Azure Web Application Firewall.

• O Application Gateway descriptografa os pacotes e procura ameaças a aplicativos Web. Se não encontrar nenhuma ameaça, ele usa princípios de confiança zero para criptografar os pacotes. Depois, liberta-os.

• O Firewall Premium do Azure executa verificações de segurança:

  • A inspeção de segurança da camada de transporte (TLS) descriptografa e examina os pacotes.
  • Os recursos de deteção e proteção contra intrusão verificam os pacotes em busca de intenções maliciosas.

• Se os pacotes passarem nos testes, o Firewall Premium do Azure executará estas etapas:

  • Criptografa os pacotes
  • Usa um serviço DNS (Sistema de Nomes de Domínio) para determinar a máquina virtual (VM) do aplicativo
  • Encaminha os pacotes para a VM do aplicativo

Vários motores de inspeção nesta arquitetura garantem a integridade do tráfego:

• O Web Application Firewall usa regras para evitar ataques na camada da Web. Exemplos de ataques incluem injeção de código SQL e scripts entre sites. Para obter mais informações sobre regras e o conjunto de regras principais do Open Web Application Security Project (OWASP), consulte Grupos de regras e regras CRS do Web Application Firewall.
• O Firewall Premium do Azure usa regras genéricas de deteção e prevenção de invasões. Essas regras ajudam a identificar arquivos mal-intencionados e outras ameaças que visam aplicativos Web.

Esta arquitetura suporta diferentes tipos de design de rede, que este artigo aborda:

• Redes tradicionais de hub e spoke
• Redes que usam a WAN Virtual do Azure como uma plataforma
• Redes que usam o Azure Route Server para simplificar o roteamento dinâmico

Azure Firewall Premium e resolução de nomes

Ao verificar se há tráfego mal-intencionado, o Firewall Premium do Azure verifica se o cabeçalho do Host HTTP corresponde ao endereço IP do pacote e à porta TCP. Por exemplo, suponha que o Application Gateway envia pacotes da Web para o endereço IP 172.16.1.4 e a porta TCP 443. O valor do cabeçalho HTTP Host deve ser resolvido para esse endereço IP.

Os cabeçalhos de host HTTP geralmente não contêm endereços IP. Em vez disso, os cabeçalhos contêm nomes que correspondem ao certificado digital do servidor. Nesse caso, o Firewall Premium do Azure usa o DNS para resolver o nome do cabeçalho do Host para um endereço IP. O design de rede determina qual solução DNS funciona melhor, como as seções posteriores descrevem.

Certificados digitais

O diagrama a seguir mostra os nomes comuns (CNs) e as autoridades de certificação (CAs) que as sessões TLS e os certificados da arquitetura usam:

Conexões TLS

Essa arquitetura contém três conexões TLS distintas. Os certificados digitais validam cada um:

Dos clientes ao Application Gateway

No Application Gateway, você implanta o certificado digital que os clientes veem. Uma autoridade de certificação bem conhecida, como DigiCert ou Let's Encrypt, normalmente emite esse certificado.

Do Gateway de Aplicativo ao Firewall Premium do Azure

Para descriptografar e inspecionar o tráfego TLS, o Firewall Premium do Azure gera certificados dinamicamente. O Azure Firewall Premium também se apresenta ao Application Gateway como o servidor Web. Uma autoridade de certificação privada assina os certificados gerados pelo Firewall Premium do Azure. Para obter mais informações, consulte Certificados Premium do Firewall do Azure. O Application Gateway precisa validar esses certificados. Nas configurações HTTP do aplicativo, você configura a autoridade de certificação raiz que o Firewall Premium do Azure usa.

Do Firewall Premium do Azure para o servidor Web

O Firewall Premium do Azure estabelece uma sessão TLS com o servidor Web de destino. O Firewall Premium do Azure verifica se uma autoridade de certificação conhecida assina os pacotes TLS do servidor Web.

Funções dos componentes

O Gateway de Aplicativo e o Firewall Premium do Azure lidam com certificados de forma diferente um do outro porque suas funções diferem:

• O Application Gateway é um proxy da Web reverso. Ele protege os servidores web de clientes mal-intencionados intercetando solicitações HTTP e HTTPS. Você declara cada servidor protegido que está no pool de back-end do Application Gateway com seu endereço IP ou nome de domínio totalmente qualificado. Os clientes legítimos devem poder aceder a cada aplicação. Assim, você configura o Application Gateway com um certificado digital assinado por uma autoridade de certificação pública. Use uma autoridade de certificação que qualquer cliente TLS aceitará.
• O Firewall Premium do Azure é um proxy da Web de encaminhamento ou, simplesmente, um proxy da Web. Ele protege os clientes de servidores Web mal-intencionados, intercetando chamadas TLS dos clientes protegidos. Quando um cliente protegido faz uma solicitação HTTP, o proxy de encaminhamento representa o servidor Web de destino gerando certificados digitais e apresentando-os ao cliente. O Firewall Premium do Azure usa uma CA privada, que assina os certificados gerados dinamicamente. Você configura os clientes protegidos para confiar nessa autoridade de certificação privada. Nessa arquitetura, o Firewall Premium do Azure protege solicitações do Gateway de Aplicativo para o servidor Web. O Gateway de Aplicativo confia na autoridade de certificação privada usada pelo Firewall Premium do Azure.

Roteamento e encaminhamento de tráfego

O roteamento será ligeiramente diferente, dependendo da topologia do seu design de rede, as seções a seguir detalharão as especificidades dos exemplos de topologia Hub e Spoke, WAN Virtual e Route Server. No entanto, existem alguns aspetos que são comuns a todas as topologias:

• O Gateway de Aplicativo do Azure sempre se comporta como um proxy, e o Firewall Premium do Azure também se comporta quando configurado para inspeção TLS: as sessões TLS dos clientes serão encerradas pelo Gateway de Aplicativo e novas sessões TLS serão criadas para o Firewall do Azure. O Firewall do Azure receberá e encerrará as sessões TLS originadas do Gateway de Aplicativo e criará novas sessões TLS para as cargas de trabalho. Esse fato tem implicações para a configuração IDPS do Firewall Premium do Azure, as seções mais abaixo contêm mais detalhes sobre isso.
• A carga de trabalho verá conexões provenientes do endereço IP de sub-rede do Firewall do Azure. O endereço IP do cliente original é preservado no cabeçalho HTTP inserido X-Forwarded-For pelo Application Gateway.
• O tráfego do Gateway de Aplicativo para a carga de trabalho normalmente é enviado para o Firewall do Azure usando mecanismos de roteamento do Azure, com Rotas Definidas pelo Usuário configuradas na sub-rede do Gateway de Aplicativo ou com rotas injetadas pela WAN Virtual do Azure ou pelo Servidor de Rotas do Azure. Embora seja possível definir explicitamente o endereço IP privado do Firewall do Azure no pool de back-end do Gateway de Aplicativo, tecnicamente não é recomendado, pois retira algumas das funcionalidades do Firewall do Azure, como balanceamento de carga e aderência.

As seções a seguir detalham algumas das topologias mais comuns usadas com o Firewall do Azure e o Gateway de Aplicativos.

Topologia hub-and-spoke

Normalmente, um design de hub e spoke implanta componentes de rede compartilhados na rede virtual do hub e componentes específicos do aplicativo nos raios. Na maioria dos sistemas, o Firewall Premium do Azure é um recurso compartilhado. Mas o Web Application Firewall pode ser um dispositivo de rede compartilhado ou um componente específico do aplicativo. Pelos seguintes motivos, geralmente é melhor tratar o Application Gateway como um componente de aplicativo e implantá-lo em uma rede virtual falada:

• Pode ser difícil solucionar problemas de alertas do Web Application Firewall. Você geralmente precisa de um conhecimento profundo do aplicativo para decidir se as mensagens que disparam esses alarmes são legítimas.
• Se você tratar o Gateway de Aplicativo como um recurso compartilhado, poderá exceder os limites do Gateway de Aplicativo do Azure.
• Você pode enfrentar problemas de controle de acesso baseado em função se implantar o Application Gateway no hub. Essa situação pode surgir quando as equipes gerenciam aplicativos diferentes, mas usam a mesma instância do Application Gateway. Em seguida, cada equipe tem acesso a toda a configuração do Application Gateway.

Com arquiteturas tradicionais de hub e spoke, as zonas privadas de DNS fornecem uma maneira fácil de usar o DNS:

• Configure uma zona privada DNS.
• Vincule a zona à rede virtual que contém o Firewall Premium do Azure.
• Verifique se existe um registro A para o valor que o Application Gateway usa para tráfego e verificações de integridade.

O diagrama a seguir mostra o fluxo de pacotes quando o Application Gateway está em uma rede virtual falada. Neste caso, um cliente se conecta a partir da Internet pública.

1. Um cliente envia uma solicitação para um servidor Web.
2. O Application Gateway interceta os pacotes do cliente e os examina. Se os pacotes passarem na inspeção, o Application Gateway enviará o pacote para a VM de back-end. Quando o pacote atinge o Azure, uma rota definida pelo usuário (UDR) na sub-rede do Gateway de Aplicativo encaminha os pacotes para o Firewall Premium do Azure.
3. O Firewall Premium do Azure executa verificações de segurança nos pacotes. Se eles passarem nos testes, o Firewall Premium do Azure encaminhará os pacotes para a VM do aplicativo.
4. A VM responde e define o endereço IP de destino para o Application Gateway. Um UDR na sub-rede VM redireciona os pacotes para o Azure Firewall Premium.
5. O Firewall Premium do Azure encaminha os pacotes para o Gateway de Aplicativo.
6. O Application Gateway responde ao cliente.

O tráfego também pode chegar de uma rede local em vez da Internet pública. O tráfego flui através de uma rede virtual privada (VPN) site a site ou através da Rota Expressa. Nesse cenário, o tráfego primeiro atinge um gateway de rede virtual no hub. O resto do fluxo de rede é o mesmo que o caso anterior.

1. Um cliente local se conecta ao gateway de rede virtual.
2. O gateway encaminha os pacotes do cliente para o Application Gateway.
3. O Application Gateway examina os pacotes. Se eles passarem na inspeção, um UDR na sub-rede do Gateway de Aplicativo encaminhará os pacotes para o Firewall Premium do Azure.
4. O Firewall Premium do Azure executa verificações de segurança nos pacotes. Se eles passarem nos testes, o Firewall Premium do Azure encaminhará os pacotes para a VM do aplicativo.
5. A VM responde e define o endereço IP de destino como Application Gateway. Um UDR na sub-rede VM redireciona os pacotes para o Azure Firewall Premium.
6. O Firewall Premium do Azure encaminha os pacotes para o Gateway de Aplicativo.
7. O Application Gateway envia os pacotes para o gateway de rede virtual.
8. O gateway responde ao cliente.

Topologia de WAN virtual

Você também pode usar o serviço de rede Virtual WAN nessa arquitetura. Este componente oferece muitos benefícios. Por exemplo, elimina a necessidade de UDRs mantidos pelo usuário em redes virtuais faladas. Em vez disso, você pode definir rotas estáticas em tabelas de rotas de hub virtual. A programação de cada rede virtual que você conecta ao hub contém essas rotas.

Quando você usa a WAN Virtual como uma plataforma de rede, duas diferenças principais resultam:

• Não é possível vincular zonas privadas DNS a um hub virtual porque a Microsoft gerencia hubs virtuais. Como proprietário da assinatura, você não tem permissões para vincular zonas DNS privadas. Como resultado, você não pode associar uma zona privada de DNS ao hub seguro que contém o Firewall Premium do Azure. Para implementar a resolução DNS para o Firewall Premium do Azure, use servidores DNS em vez disso:

  • Configure as Configurações de DNS do Firewall do Azure para usar servidores DNS personalizados.
  • Implante os servidores em uma rede virtual de serviços compartilhados que você conecta à WAN virtual.
  • Vincule uma zona privada DNS à rede virtual de serviços compartilhados. Os servidores DNS podem então resolver os nomes que o Application Gateway usa em cabeçalhos de Host HTTP. Para obter mais informações, consulte Configurações de DNS do Firewall do Azure.

• Você só pode usar a WAN Virtual para programar rotas em um spoke se o prefixo for mais curto (menos específico) do que o prefixo da rede virtual. Por exemplo, nos diagramas acima, a VNet spoke tem o prefixo 172.16.0.0/16: neste caso, a WAN Virtual não seria capaz de injetar uma rota que corresponda ao prefixo VNet (172.16.0.0/16) ou qualquer uma das sub-redes (172.16.0.0/24, 172.16.1.0/24). Em outras palavras, a WAN Virtual não pode atrair tráfego entre duas sub-redes que estão na mesma VNet. Essa limitação torna-se aparente quando o Gateway de Aplicativo e o servidor Web de destino estão na mesma rede virtual: a WAN Virtual não pode forçar o tráfego entre o Gateway de Aplicativo e o servidor Web a passar pelo Firewall Premium do Azure (uma solução alternativa seria configurar manualmente as Rotas Definidas pelo Usuário nas sub-redes do Gateway de Aplicativo e do servidor Web).

O diagrama a seguir mostra o fluxo de pacotes em um caso que usa WAN Virtual. Nessa situação, o acesso ao Application Gateway é de uma rede local. Uma VPN site a site ou ExpressRoute conecta essa rede à WAN Virtual. O acesso a partir da internet é semelhante.

1. Um cliente local se conecta à VPN.
2. A VPN encaminha os pacotes do cliente para o Application Gateway.
3. O Application Gateway examina os pacotes. Se eles passarem na inspeção, a sub-rede do Gateway de Aplicativo encaminhará os pacotes para o Firewall Premium do Azure.
4. O Firewall Premium do Azure solicita a resolução DNS de um servidor DNS na rede virtual de serviços compartilhados.
5. O servidor DNS responde à solicitação de resolução.
6. O Firewall Premium do Azure executa verificações de segurança nos pacotes. Se eles passarem nos testes, o Firewall Premium do Azure encaminhará os pacotes para a VM do aplicativo.
7. A VM responde e define o endereço IP de destino como Application Gateway. A sub-rede Aplicativo redireciona os pacotes para o Firewall Premium do Azure.
8. O Firewall Premium do Azure encaminha os pacotes para o Gateway de Aplicativo.
9. O Application Gateway envia os pacotes para a VPN.
10. A VPN responde ao cliente.

Com esse design, talvez seja necessário modificar o roteamento que o hub anuncia para as redes virtuais faladas. Especificamente, o Application Gateway v2 suporta apenas uma rota 0.0.0.0/0 que aponta para a Internet. Rotas com esse endereço que não apontam para a Internet interrompem a conectividade que a Microsoft requer para gerenciar o Application Gateway. Se o hub virtual anunciar uma rota 0.0.0.0/0, impeça que essa rota se propague para a sub-rede do Application Gateway seguindo uma destas etapas:

• Crie uma tabela de rotas com uma rota para 0.0.0.0/0 e um tipo de próximo salto de Internet. Associe essa rota à sub-rede na qual você implanta o Application Gateway.
• Se você implantar o Application Gateway em um raio dedicado, desabilite a propagação da rota padrão nas configurações da conexão de rede virtual.

Topologia do Route Server

O Route Server oferece outra maneira de injetar rotas automaticamente em raios. Com essa funcionalidade, você evita a sobrecarga administrativa de manter tabelas de rotas. O Route Server combina a WAN Virtual e as variantes hub e spoke:

• Com o Route Server, os clientes gerenciam redes virtuais de hub. Como resultado, você pode vincular a rede virtual do hub a uma zona privada DNS.
• O Route Server tem a mesma limitação que a WAN Virtual tem em relação aos prefixos de endereço IP. Você só pode injetar rotas em um spoke se o prefixo for mais curto (menos específico) do que o prefixo da rede virtual. Devido a essa limitação, o Application Gateway e o servidor Web de destino precisam estar em redes virtuais diferentes.

O diagrama a seguir mostra o fluxo de pacotes quando o Route Server simplifica o roteamento dinâmico. Observe estes pontos:

• Atualmente, o Route Server requer o dispositivo que injeta as rotas para enviá-las pelo Border Gateway Protocol (BGP). Como o Firewall Premium do Azure não oferece suporte a BGP, use um NVA (Network Virtual Appliance) de terceiros.
• A funcionalidade do NVA no hub determina se sua implementação precisa de DNS.

1. Um cliente local se conecta ao gateway de rede virtual.
2. O gateway encaminha os pacotes do cliente para o Application Gateway.
3. O Application Gateway examina os pacotes. Se eles passarem na inspeção, a sub-rede do Application Gateway encaminhará os pacotes para uma máquina de back-end. Uma rota na sub-rede ApplicationGateway injetada pelo Route Server encaminharia o tráfego para um NVA.
4. O NVA executa verificações de segurança nos pacotes. Se eles passarem nos testes, o NVA encaminhará os pacotes para a VM do aplicativo.
5. A VM responde e define o endereço IP de destino como Application Gateway. Uma rota injetada na sub-rede VM pelo Route Server redireciona os pacotes para o NVA.
6. O NVA encaminha os pacotes para o Application Gateway.
7. O Application Gateway envia os pacotes para o gateway de rede virtual.
8. O gateway responde ao cliente.

Assim como acontece com a WAN Virtual, talvez seja necessário modificar o roteamento ao usar o Route Server. Se você anunciar a rota 0.0.0.0/0, ela poderá se propagar para a sub-rede do Application Gateway. Mas o Application Gateway não oferece suporte a essa rota. Nesse caso, configure uma tabela de rotas para a sub-rede do Application Gateway. Inclua uma rota para 0.0.0.0/0 e um tipo de próximo salto nessa Internet tabela.

IDPS e endereços IP privados

Conforme explicado em Regras de IDPS do Firewall do Azure, o Firewall Premium do Azure decidirá quais regras de IDPS aplicar, dependendo dos endereços IP de origem e destino dos pacotes. O Firewall do Azure tratará os endereços IP privados padrão nos intervalos RFC 1918 (10.0.0.0/8e 192.168.0.0/16172.16.0.0/12) e RFC 6598 (100.64.0.0/10) como internos. Consequentemente, se, como nos diagramas deste artigo, o Gateway de Aplicativo for implantado em uma sub-rede em um desses intervalos (172.16.0.0/24 nos exemplos acima), o Firewall Premium do Azure considerará o tráfego entre o Gateway de Aplicativo e a carga de trabalho como interno, e somente as assinaturas IDPS marcadas para serem aplicadas ao tráfego interno ou a qualquer tráfego serão usadas. As assinaturas IDPS marcadas para serem aplicadas ao tráfego de entrada ou de saída não serão aplicadas ao tráfego entre o Application Gateway e a carga de trabalho.

A maneira mais fácil de forçar as regras de assinatura de entrada do IDPS a serem aplicadas ao tráfego entre o Application Gateway e a carga de trabalho é colocando o Application Gateway em uma sub-rede com um prefixo fora dos intervalos privados. Você não precisa necessariamente usar endereços IP públicos para essa sub-rede, mas, em vez disso, pode personalizar os endereços IP que o Firewall Premium do Azure trata como internos para IDPS. Por exemplo, se sua organização não usar o 100.64.0.0/10 intervalo, você poderá eliminá-lo da lista de prefixos internos para IDPS (consulte Intervalos IPDS privados do Firewall Premium do Azure para obter mais detalhes sobre como fazer isso) e implantar o Gateway de Aplicativo em uma sub-rede configurada com um endereço IP no 100.64.0.0/10.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Jose Moreno - Brasil | Engenheiro de Clientes Principal

Próximos passos

• Proteja as redes com confiança zero
• Encaminhamento de tráfego da rede virtual
• Como funciona um gateway de aplicativo

Recursos relacionados

• Proteja e controle cargas de trabalho com segmentação de nível de rede
• Implementar uma rede híbrida segura
• Topologia de rede Hub-spoke no Azure
• Topologia de rede Hub-spoke com WAN Virtual do Azure