Rede de confiança zero para aplicativos Web com o Firewall do Azure e o Gateway de Aplicativo

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 do tamanho das áreas de confiança implícitas ao mínimo. Este artigo refere-se ao componente de criptografia e inspeção de uma arquitetura de confiança zero para tráfego de entrada da Internet pública. Leia outros documentos de confiança zero para obter mais aspectos da implantação segura de seu aplicativo, como autenticação. Para a finalidade deste artigo, uma abordagem de várias camadas 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 alcance os aplicativos.

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

• Os firewalls do aplicativo Web procuram padrões que indicam um ataque na camada do aplicativo Web.
• Os firewalls da próxima 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 Gateway de Aplicativo para redes virtuais, descreve os 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, na qual o Gateway de Aplicativo do Azure age antes do Firewall do Azure Premium. O seguinte diagrama ilustra esse processo:

Baixe um Arquivo Visio dessa arquitetura.

Essa arquitetura usa o protocolo TLS para criptografar o tráfego em cada etapa.

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

• O Gateway de Aplicativo descriptografa os pacotes e procura ameaças a aplicativos Web. Se não encontrar nenhuma ameaça, ele usará princípios de confiança zero para criptografar os pacotes. Em seguida, ele os libera.

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

  • A inspeção de TLS (Transport Layer Security) descriptografa e examina os pacotes.
  • Os recursos de detecção de intrusão e proteção verificam os pacotes por más intenções.

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

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

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

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

Essa arquitetura dá suporte a diferentes tipos de design de rede, que este artigo aborda:

• Redes de Hub e spoke tradicionais
• Redes que usam a WAN Virtual do Azure como uma plataforma
• Redes que usam o Servidor de Rota do Azure para simplificar o roteamento dinâmico

Firewall do Azure Premium e resolução de nomes

Ao verificar o tráfego mal-intencionado, o Firewall do Azure Premium verifica se o cabeçalho de host HTTP corresponde ao endereço IP do pacote e à porta TCP. Por exemplo, suponha que o Gateway de Aplicativo envie pacotes da Web para o endereço IP 172.16.1.4 e a porta TCP 443. O valor do cabeçalho de host HTTP 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 do Azure Premium usa o DNS para resolver o nome do cabeçalho de host para um endereço IP. O design de rede determina qual solução de DNS funciona melhor, conforme descrito nas seções posteriores.

Certificados digitais

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

Conexões TLS

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

De clientes para o Gateway de Aplicativo

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

Do Gateway de Aplicativo para o Firewall do Azure Premium

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

Do Firewall do Azure Premium para o servidor Web

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

Funções de componente

O Gateway de aplicativo e o Firewall do Azure Premium lida com certificados de forma diferente, pois suas funções diferem:

• O Gateway de Aplicativo é um proxy Web reverso. Ele protege servidores Web de clientes mal-intencionados interceptando solicitações HTTP e HTTPS. Você declara cada servidor protegido que está no pool de back-end do Gateway de Aplicativo com seu endereço IP ou nome de domínio totalmente qualificado. Os clientes legítimos devem ser capazes de acessar cada aplicativo. Portanto, você configura o Gateway de Aplicativo 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 do Azure Premium é um proxy Web progressivo ou, simplesmente, um proxy Web. Ele protege clientes de servidores Web mal-intencionados interceptando 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 do Azure Premium usa uma autoridade de certificação privada, que assina os certificados gerados dinamicamente. Você configura os clientes protegidos para confiar nessa autoridade de certificação privada. Nessa arquitetura, o Firewall do Azure Premium protege as solicitações do Gateway de Aplicativo para o servidor Web. O Gateway de Aplicativo confia na autoridade de certificação privada que o Firewall do Azure Premium usa.

Roteamento e encaminhamento de tráfego

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

• O Gateway de Aplicativo do Azure sempre se comporta como um proxy, e o Firewall do Azure Premium 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 do IDPS do Firewall do Azure Premium, as seções abaixo contêm mais detalhes sobre isso.
• A carga de trabalho verá conexões provenientes do endereço IP da 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, ele não é tecnicamente 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 Aplicativo.

Topologia hub-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 spokes. Na maioria dos sistemas, o Firewall do Azure Premium é um recurso compartilhado. Mas o Firewall de Aplicativo Web pode ser um dispositivo de rede compartilhado ou um componente específico do aplicativo. Pelos motivos a seguir, geralmente é melhor tratar o Gateway de Aplicativo como um componente de aplicativo e implantá-lo em uma rede virtual spoke:

• Pode ser difícil solucionar problemas de alertas do Firewall de Aplicativo Web. Geralmente, você precisa de um conhecimento aprofundado 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, você pode exceder os limites do Gateway de Aplicativo do Azure.
• Você pode enfrentar problemas de controle de acesso baseado em função se implantar o Gateway de Aplicativo do Azure. Essa situação pode surgir quando as equipes gerenciam aplicativos diferentes, mas usam a mesma instância do Gateway de Aplicativo. Cada equipe tem acesso a toda a configuração do Gateway de Aplicativo.

Com as arquiteturas de Hub e Spoke tradicionais, as zonas privadas do DNS fornecem uma maneira fácil de usar o DNS:

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

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

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

O tráfego também pode chegar de uma rede local em vez da Internet pública. O tráfego flui por meio de uma VPN (rede virtual privada) site a site ou por meio do ExpressRoute. Nesse cenário, o tráfego primeiro alcança um gateway de rede virtual no hub. O restante 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 de cliente para o Gateway de Aplicativo.
3. O Gateway de Aplicativo examina os pacotes. Se eles passarem na inspeção, uma UDR na sub-rede do Gateway de Aplicativo encaminhará os pacotes para o Firewall do Azure Premium.
4. O Firewall do Azure Premium executa verificações de segurança nos pacotes. Se eles passam nos testes, o Firewall do Azure Premium encaminha os pacotes para a VM do aplicativo.
5. A VM responde e define o endereço IP de destino para o Gateway de Aplicativo. Uma UDR na sub-rede da VM redireciona os pacotes para o Firewall do Azure Premium.
6. O Firewall do Azure Premium encaminha os pacotes para o Gateway de Aplicativo.
7. O Gateway de Aplicativo envia os pacotes para o gateway de rede virtual.
8. O gateway responde ao cliente.

Topologia de WAN virtual

Você também pode usar a WAN Virtual do serviço de rede nessa arquitetura. Esse componente oferece muitos benefícios. Por exemplo, elimina a necessidade de UDRs mantidos pelo usuário em redes virtuais spoke. 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 ocorrem:

• Você não pode vincular zonas privadas DNS a um hub virtual porque a Microsoft gerencia hubs virtuais. Como o 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 DNS ao hub seguro que contém o Firewall do Azure Premium. Para implementar a resolução DNS para Firewall do Azure Premium, use servidores DNS em vez disso:

  • Configure as Configurações de DNS do Firewall do Azure 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 resolver os nomes que o Gateway de Aplicativo usa em cabeçalhos de host HTTP. Para obter mais informações, confira Configurações de DNS do Firewall do Azure.

• Você só poderá usar a WAN Virtual para programar rotas em um spoke se o prefixo for menor (menos específico) que o prefixo de rede virtual. Por exemplo, nos diagramas acima, a VNet spoke tem o prefixo 172.16.0.0/16: nesse caso, a Virtual WAN não seria capaz de injetar uma rota que corresponda ao prefixo VNet (172.16.0.0/16) ou a 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 se torna 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 a WAN Virtual. Nessa situação, o acesso ao Gateway de Aplicativo é de uma rede local. Uma VPN site a site ou ExpressRoute conecta essa rede à WAN Virtual. O acesso da Internet é semelhante.

1. Um cliente local se conecta à VPN.
2. A VPN encaminha os pacotes de cliente para o Gateway de Aplicativo.
3. O Gateway de Aplicativo examina os pacotes. Se eles passarem na inspeção, uma sub-rede do Gateway de Aplicativo encaminhará os pacotes para o Firewall do Azure Premium.
4. O Firewall do Azure Premium 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 do Azure Premium executa verificações de segurança nos pacotes. Se eles passam nos testes, o Firewall do Azure Premium encaminha os pacotes para a VM do aplicativo.
7. A VM responde e define o endereço IP de destino para o Gateway de Aplicativo. A sub-rede Aplicativo redireciona os pacotes para o Azure Firewall Premium.
8. O Firewall do Azure Premium encaminha os pacotes para o Gateway de Aplicativo.
9. O Gateway de Aplicativo 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 spoke. Especificamente, o Gateway de Aplicativo v2 dá suporte apenas a uma rota 0.0.0.0/0 que aponta para a Internet. As rotas com esse endereço que não apontam para a Internet quebram a conectividade que a Microsoft requer para gerenciar o Gateway de Aplicativo. Se o hub virtual anunciar uma rota 0.0.0.0/0, impeça que essa rota se propague para a sub-rede do Gateway de Aplicativo realizando 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 em que você implanta o Gateway de Aplicativo.
• Se você implantar o Gateway de Aplicativo em um spoke dedicado, desabilite a propagação da rota padrão nas configurações da conexão de rede virtual.

Topologia do Servidor de Rotas

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

• Com o Servidor de Rota, os clientes gerenciam redes virtuais de hub. Como resultado, você pode vincular a rede virtual do hub a uma zona privada DNS.
• O Servidor de Rota 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 Gateway de Aplicativo e o servidor Web de destino precisam estar em redes virtuais diferentes.

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

• Atualmente, o Servidor de Rota exige que o dispositivo que injeta as rotas as envie pelo BGP (Border Gateway Protocol). Como o Firewall do Azure Premium dá suporte ao BGP, use uma NVA (solução de virtualização de rede) de terceiros.
• A funcionalidade da NVA no hub determina se a sua implementação precisa de DNS.

1. Um cliente local se conecta ao gateway de rede virtual.
2. O gateway encaminha os pacotes de cliente para o Gateway de Aplicativo.
3. O Gateway de Aplicativo examina os pacotes. Se eles passarem na inspeção, uma sub-rede do Gateway de Aplicativo encaminhará os pacotes para o computador de back-end. Uma rota na sub-rede do Gateway de Aplicativo injetada pelo Servidor de Rota encaminha o tráfego para uma NVA.
4. A NVA executa verificações de segurança nos pacotes. Se eles passarem nos testes, a NVA encaminhará os pacotes para a VM do aplicativo.
5. A VM responde e define o endereço IP de destino para o Gateway de Aplicativo. Uma rota injetada na sub-rede da VM pelo Servidor de Rota redireciona os pacotes para a NVA.
6. A NVA encaminha os pacotes para o Gateway de Aplicativo.
7. O Gateway de Aplicativo 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 Servidor de Rota. Se você anunciar a rota 0.0.0.0/0, ela poderá se propagar para a sub-rede do Gateway de Aplicativo. No entanto, o Gateway de Aplicativo não dá suporte a essa rota. Nesse caso, configure uma tabela de rotas para a sub-rede do Gateway de Aplicativo. Inclua uma rota para 0.0.0.0/0 e um tipo de próximo salto de Internet nessa tabela.

IDPS e endereços IP privados

Conforme explicado em Regras de IDPS do Firewall do Azure, o Azure Firewall Premium decidirá quais regras de IDPS serão aplicadas, dependendo dos endereços IP de origem e de 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/16 172.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 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 do Azure Premium 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 do IDPS (consulte Intervalos IPDS privados do Firewall do Azure Premium 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.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• Jose Moreno | Engenheiro de Clientes Principal

Próximas etapas

• Proteger redes com confiança zero
• Roteamento de tráfego de rede virtual
• Como um gateway de aplicativo funciona

Recursos relacionados

• Proteger e controlar 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 a WAN Virtual do Azure