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 de confiança zero para aplicativos Web para inspeção e criptografia. O paradigma de confiança zero inclui muitos outros conceitos, como verificação constante da identidade dos atores ou redução mínima 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 entrada de tráfego da Internet pública. Leia outros documentos de confiança zero para obter mais aspectos da implantação de seu aplicativo com segurança, como autenticação. Para fins deste artigo, uma abordagem multicamadas funciona melhor, em que a segurança de rede compõe uma das camadas do modelo de confiança zero. Nessa camada, os dispositivos de rede inspecionam pacotes para garantir que apenas o tráfego legítimo atinja aplicativos.

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

• Os firewalls de aplicativo Web procuram padrões que indicam um ataque na camada do aplicativo Web.
• Os firewalls de 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, no qual o Gateway de Aplicativo do Azure atua antes do Firewall do Azure Premium. O diagrama a seguir ilustra esse padrão:

diagrama

Baixe um arquivo do Visio dessa arquitetura.

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

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

• O Gateway de Aplicativo descriptografa os pacotes e procura ameaças a aplicativos Web. Se não encontrar ameaças, 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:

  • inspeção de TLS (segurança da camada de transporte) descriptografa e examina os pacotes.
  • recursos de de proteção e detecção de intrusão verificam os pacotes quanto à intenção mal-intencionada.

• 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 VM (máquina virtual) do aplicativo
  • Encaminha os pacotes para a VM do aplicativo

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

• O Firewall do Aplicativo Web 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 OWASP (Open Web Application Security Project), consulte grupos de regras e regras do CRS do Firewall do Aplicativo Web.
• O Firewall do Azure Premium usa regras genéricas de detecção e prevenção de intrusão. 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 discute:

• 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 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 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 do 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 host para um endereço IP. O design de rede determina qual solução DNS funciona melhor, como seções posteriores descrevem.

Certificados digitais

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

diagrama de arquitetura

Conexões TLS

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

De clientes ao Gateway de Aplicativo

No Gateway de Aplicativo, você implanta o certificado digital que os clientes veem. Uma AC conhecida, como DigiCert ou Let's Encrypt, normalmente emite esse certificado.

Do Gateway de Aplicativo ao Firewall do Azure Premium

Para descriptografar e inspecionar o tráfego TLS, o Firewall do Azure Premium gera dinamicamente certificados. O Firewall do Azure Premium também se apresenta ao Gateway de Aplicativo como o servidor Web. Uma AC privada assina os certificados gerados pelo Firewall do Azure Premium. Para obter mais informações, consulte certificados do Firewall do Azure Premium. O Gateway de Aplicativo precisa validar esses certificados. Nas configurações HTTP do aplicativo, você configura a AC 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 AC conhecida assina os pacotes TLS do servidor Web.

Funções de componente

O Gateway de Aplicativo e o Firewall do Azure Premium manipulam certificados de forma diferente uns dos outros porque suas funções diferem:

• O Gateway de Aplicativo é um de proxy web reverso. Ele protege os servidores Web contra 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 AC pública. Use uma AC que qualquer cliente TLS aceitará.
• O Firewall do Azure Premium é um proxy Web encaminhamento ou, simplesmente, um proxy Web. Ele protege os clientes contra 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 AC privada, que assina os certificados gerados dinamicamente. Configure os clientes protegidos para confiar nessa AC 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 AC privada que o Firewall do Azure Premium usa.

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 Servidor de Rota. No entanto, há 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 premium do Azure também funciona quando configurado para inspeção do TLS: as sessões TLS de 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 provenientes 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, seções mais 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 X-Forwarded-For inserido pelo Gateway de Aplicativo.
• 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 User-Defined Rotas 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 é recomendável, pois ele tira algumas das funcionalidades do Firewall do Azure, como balanceamento de carga e stickiness.

As seções a seguir entram em detalhes para algumas das topologias mais comuns usadas com o Firewall do Azure e o Gateway de Aplicativo.

Topologia hub e 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 do Aplicativo Web pode ser um dispositivo de rede compartilhado ou um componente específico do aplicativo. Pelos seguintes motivos, 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 do Aplicativo Web. Geralmente, você precisa de 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, poderá exceder limites do Gateway de Aplicativo do Azure.
• Você poderá enfrentar problemas de controle de acesso baseado em função se implantar o Gateway de Aplicativo no hub. 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 arquiteturas tradicionais de hub e spoke, as zonas privadas 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 do Azure Premium.
• Verifique se existe um registro A para o valor que o Gateway de Aplicativo usa para 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 o Firewall do Azure Premium.
3. O Firewall do Azure Premium executa verificações de segurança nos pacotes. Se eles passarem nos testes, o Firewall premium do Azure 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 premium do Azure.
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 atinge 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 do cliente para o Gateway de Aplicativo.
3. O Gateway de Aplicativo examina os pacotes. Se eles passarem pela inspeção, uma UDR na sub-rede do Gateway de Aplicativo encaminha os pacotes para o Firewall premium do Azure.
4. O Firewall do Azure Premium executa verificações de segurança nos pacotes. Se eles passarem nos testes, o Firewall premium do Azure encaminha os pacotes para a VM do aplicativo.
5. A VM responde e define o endereço IP de destino como Gateway de Aplicativo. Uma UDR na sub-rede da VM redireciona os pacotes para o Firewall premium do Azure.
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 o serviço de rede wan virtual nessa arquitetura. Esse componente oferece muitos benefícios. Por exemplo, elimina a necessidade de UDRs mantidas 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 resultam:

• Você não pode 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 DNS ao hub seguro que contém o Firewall do Azure Premium. Para implementar a resolução DNS para o Firewall do Azure Premium, use servidores DNS em vez disso:

  • Configure o de 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 resolver os nomes que o Gateway de Aplicativo usa em cabeçalhos de Host HTTP. Para obter mais informações, consulte 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) do 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 WAN Virtual não seria capaz de injetar uma rota que corresponda ao prefixo de 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 se torna evidente 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 do Azure Premium (uma solução alternativa seria configurar manualmente 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 Gateway de Aplicativo é de uma rede local. Uma VPN site a site ou o ExpressRoute conecta essa rede à WAN Virtual. O acesso da Internet é semelhante.

1. Um cliente local se conecta à VPN.
2. A VPN encaminha os pacotes do cliente para o Gateway de Aplicativo.
3. O Gateway de Aplicativo examina os pacotes. Se eles passarem pela inspeção, a sub-rede do Gateway de Aplicativo encaminha os pacotes para o Firewall premium do Azure.
4. O Firewall do Azure Premium solicita 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 passarem nos testes, o Firewall premium do Azure encaminha os pacotes para a VM do aplicativo.
7. A VM responde e define o endereço IP de destino como Gateway de Aplicativo. A sub-rede de aplicativo redireciona os pacotes para o Firewall premium do Azure.
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 interrompem a conectividade necessária pela Microsoft 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 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 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 para a conexão de rede virtual.

Topologia do Servidor de Rota

Servidor de Rota oferece outra maneira de injetar rotas automaticamente em spokes. Com essa funcionalidade, você evita a sobrecarga administrativa de manutenção de 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 do 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ó poderá injetar rotas em um spoke se o prefixo for menor (menos específico) do que o prefixo de 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 requer o dispositivo que injeta as rotas para enviá-las pelo PROTOCOLO BGP (Border Gateway Protocol). Como o Firewall premium do Azure não dá suporte ao BGP, use uma NVA (Solução de Virtualização de Rede) de terceiros.
• A funcionalidade da 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 Gateway de Aplicativo.
3. O Gateway de Aplicativo examina os pacotes. Se eles passarem pela inspeção, a sub-rede do Gateway de Aplicativo encaminha os pacotes para um computador de back-end. Uma rota na sub-rede ApplicationGateway injetada pelo Servidor de Rota encaminharia o tráfego para uma NVA.
4. A NVA executa verificações de segurança nos pacotes. Se eles passarem nos testes, a NVA encaminha os pacotes para a VM do aplicativo.
5. A VM responde e define o endereço IP de destino como 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. Mas 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 Firewall premium do Azure 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á por padrão endereços IP privados nos intervalos RFC 1918 (10.0.0.0/8, 192.168.0.0/16 e 172.16.0.0/12) e o intervalo 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 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 Gateway de Aplicativo e a carga de trabalho.

A maneira mais fácil de forçar regras de assinatura de entrada do IDPS a serem aplicadas ao tráfego entre o Gateway de Aplicativo e a carga de trabalho é colocando o Gateway de Aplicativo 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 interno para IDPS. Por exemplo, se sua organização não usar o intervalo de 100.64.0.0/10, você poderá eliminar esse intervalo da lista de prefixos internos para 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.

Contribuintes

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• José Moreno | Engenheiro de cliente principal

Próximas etapas

• redes seguras sem de confiança
• de 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][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