Firewall do Azure e Gateway de Aplicativo para redes virtuais

Gateway de Aplicação do Azure

Azure Firewall

Azure Front Door

Rede Virtual do Azure

Firewall de Aplicações Web do Azure

Para ajudar a proteger cargas de trabalho de aplicativos do Azure, use medidas de proteção, como autenticação e criptografia nos próprios aplicativos. Você pode adicionar camadas de segurança às redes virtuais que hospedam os aplicativos. Essas camadas de segurança ajudam a proteger os fluxos de entrada do aplicativo contra uso não intencional. Eles também limitam os fluxos de saída para a Internet apenas aos pontos de extremidade que seu aplicativo exige. Este artigo descreve Rede Virtual do Azure serviços de segurança, como Proteção contra DDoS do Azure, Firewall do Azure e Gateway de Aplicativo do Azure. Ele também descreve quando usar cada serviço e opções de design de rede que os combinam.

• de Proteção contra DDoS , combinada com as práticas recomendadas de design de aplicativos, fornece recursos aprimorados de mitigação de DDoS que melhoram a defesa contra ataques DDoS. Você deve habilitar a Proteção contra DDoS em todas as redes virtuais de perímetro.

• de Firewall do Azure é um firewall gerenciado de última geração que fornece recursos de conversão de endereços de rede (NAT). O Firewall do Azure filtra pacotes com base em endereços IP e portas TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol). Ele pode filtrar o tráfego usando atributos baseados em aplicativos, como HTTP(S) e SQL. O Firewall do Azure também aplica informações sobre ameaças da Microsoft para ajudar a identificar endereços IP mal-intencionados. Para obter mais informações, consulte documentação do Firewall do Azure.

• do Firewall Premium do Azure inclui todas as funcionalidades do Azure Firewall Standard, além de recursos como inspeção de segurança da camada de transporte (TLS) e sistema de deteção e prevenção de intrusão (IDPS).

• Application Gateway é um balanceador de carga de tráfego da Web gerenciado e proxy reverso completo HTTP(S) que pode executar criptografia e descriptografia SSL (Secure Socket Layer). O Application Gateway preserva o endereço IP do cliente original em um cabeçalho HTTP X-Forwarded-For. O Gateway de Aplicativo também usa o Firewall de Aplicativo Web do Azure para inspecionar o tráfego da Web e detetar ataques na camada HTTP. Para obter mais informações, consulte documentação do Application Gateway.

• do Web Application Firewall é uma adição opcional ao Application Gateway. Ele inspeciona solicitações HTTP e evita ataques de camada da Web, como injeção de SQL e scripts entre sites. Para obter mais informações, consulte documentação do Web Application Firewall.

Estes serviços do Azure complementam-se. Dependendo das suas necessidades, usar um serviço pode se adequar melhor às suas cargas de trabalho. No entanto, você pode usar esses serviços juntos para ajudar a fornecer proteção ideal nas camadas de rede e aplicativo. Use a árvore de decisão a seguir e os exemplos neste artigo para escolher a melhor opção de segurança para a rede virtual do seu aplicativo.

O Firewall do Azure e o Gateway de Aplicativo usam tecnologias diferentes para ajudar a proteger diferentes tipos de fluxos de dados.

Fluxo de aplicativos	Pode ser filtrado pelo Firewall do Azure	Pode ser filtrado pelo Web Application Firewall no Application Gateway
Tráfego HTTP(S) do local ou da Internet para o Azure (entrada)	Sim	Sim
Tráfego HTTP(S) do Azure para o local ou Internet (saída)	Sim	Não
Tráfego não-HTTP(S) (entrada ou saída)	Sim	Não

O design pode variar para cada aplicativo com base nos fluxos de rede que ele requer. O diagrama a seguir fornece uma árvore de decisão simplificada que ajuda você a escolher a abordagem recomendada para seu aplicativo. Essa escolha depende se o aplicativo é publicado via HTTP(S) ou algum outro protocolo.

Este artigo descreve os designs amplamente recomendados mostrados no fluxograma e os designs adequados para cenários menos comuns:

• Firewall do Azure apenas: Use este design quando não houver aplicativos Web na rede virtual. Ele controla o tráfego de entrada para os aplicativos e o tráfego de saída.

• Gateway de Aplicativo somente: Use este design quando apenas aplicativos Web estiverem na rede virtual e grupos de segurança de rede (NSGs) fornecer filtragem de saída suficiente. O Firewall do Azure fornece funcionalidade que pode ajudar a evitar vários cenários de ataque, como exfiltração de dados e IDPS. Como resultado, o design somente do Application Gateway geralmente não é recomendado, portanto, não é incluído no fluxograma anterior.

• o Firewall do Azure e o Gateway de Aplicativo em paralelo: Use esse design quando quiser que o Gateway de Aplicativo proteja aplicativos HTTP(S) contra ataques da Web e o Firewall do Azure proteja todas as outras cargas de trabalho e filtre o tráfego de saída. O Firewall do Azure e o Gateway de Aplicativo em paralelo é um design comum.

• Gateway de Aplicativo na frente do Firewall do Azure: Use este design quando quiser que o Firewall do Azure inspecione todo o tráfego, o Firewall de Aplicativo Web para proteger o tráfego da Web e o aplicativo para identificar o endereço IP de origem do cliente. Com a inspeção do Firewall do Azure Premium e TLS, esse design também dá suporte ao cenário SSL de ponta a ponta.

• o Firewall do Azure na frente do Application Gateway: Use esse design quando quiser que o Firewall do Azure inspecione e filtre o tráfego antes que ele chegue ao Gateway de Aplicativo. Como o Firewall do Azure não descriptografa o tráfego HTTPS, sua funcionalidade adicionada ao Gateway de Aplicativo é limitada. Este cenário não está documentado no fluxograma anterior.

As variações desses designs fundamentais são descritas mais adiante neste artigo e incluem:

• Clientes de aplicativos locais.
• Redes Hub-and-spoke.
• implementações de do Serviço Kubernetes do Azure (AKS).

Você pode adicionar outros serviços de proxy reverso, como um gateway de de Gerenciamento de API do Azure ou do Azure Front Door. Ou você pode substituir os recursos do Azure por dispositivos virtuais de rede (NVAs) não Microsoft.

Observação

Nos cenários a seguir, uma máquina virtual (VM) do Azure é usada como exemplo de uma carga de trabalho de aplicativo Web. Esses cenários também são válidos para outros tipos de carga de trabalho, como contêineres ou Aplicativos Web do Azure. Para configurações que incluem pontos de extremidade privados, considere as recomendações em cenários Firewall do Azure para inspecionar o tráfego destinado a um ponto de extremidade privado.

Design somente do Firewall do Azure

Se não houver cargas de trabalho baseadas na Web na rede virtual que possam se beneficiar do Firewall de Aplicativo Web, você poderá usar o design somente do Firewall do Azure. O design neste exemplo é simples, mas você pode revisar o fluxo de pacotes para entender melhor os designs mais complexos. Neste design, todo o tráfego de entrada é enviado para o Firewall do Azure por meio de UDRs (rotas definidas pelo usuário) para conexões de redes virtuais locais ou de outras redes virtuais do Azure. Ele é endereçado ao endereço IP público do Firewall do Azure para conexões da Internet pública, conforme mostrado no diagrama a seguir. UDRs direcionam o tráfego de saída das redes virtuais do Azure para o Firewall do Azure, conforme mostrado na caixa de diálogo a seguir.

A tabela a seguir resume os fluxos de tráfego para esse cenário.

Fluxo	Passa pelo Application Gateway/Web Application Firewall	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou no local para o Azure	N/A	Sim
Tráfego HTTP(S) do Azure para a Internet ou no local	N/A	Sim
Tráfego não-HTTP(S) da Internet ou local para o Azure	N/A	Sim
Tráfego não-HTTP(S) do Azure para a Internet ou no local	N/A	Sim

O Firewall do Azure não inspeciona o tráfego HTTP(S) de entrada. Mas ele pode aplicar regras de camada 3 e camada 4 e regras de aplicativo baseadas em nome de domínio totalmente qualificado (FQDN). O Firewall do Azure inspeciona o tráfego HTTP(S) de saída, dependendo da camada do Firewall do Azure e se você configura a inspeção TLS:

• O Firewall do Azure Standard inspeciona apenas atributos de camada 3 e camada 4 de pacotes em regras de rede e o cabeçalho HTTP do Host em regras de aplicativo.

• O Firewall Premium do Azure adiciona recursos, como inspecionar outros cabeçalhos HTTP (como o agente do usuário) e habilitar a inspeção TLS para uma análise mais profunda de pacotes. No entanto, o Firewall do Azure não é o mesmo que o Firewall de Aplicativo Web. Se você tiver cargas de trabalho da Web em sua rede virtual, recomendamos que você use o Web Application Firewall.

O exemplo de passo a passo de pacote a seguir mostra como um cliente acessa um aplicativo hospedado por VM a partir da Internet pública. O diagrama inclui apenas uma VM para simplificar. Para maior disponibilidade e escalabilidade, há várias instâncias de aplicativos por trás de um balanceador de carga. Neste design, o Firewall do Azure inspeciona as conexões de entrada da Internet pública e as conexões de saída da VM de sub-rede do aplicativo usando o UDR.

• Neste exemplo, o Firewall do Azure implanta automaticamente várias instâncias com o endereço IP front-end 192.168.100.4 e endereços internos dentro do intervalo 192.168.100.0/26. Normalmente, essas instâncias não são visíveis para o administrador do Azure. No entanto, estar ciente deles pode ser útil para solucionar problemas de rede.

• Se o tráfego vier de uma rede virtual privada (VPN) local ou gateway de da Rota Expressa do Azure em vez da Internet, o cliente iniciará a conexão com o endereço IP da VM. Ele não inicia a conexão com o endereço IP do firewall e o firewall não faz NAT de origem por padrão.

Arquitetura

O diagrama a seguir mostra o fluxo de tráfego e assume que o endereço IP da instância é 192.168.100.7.

Fluxo de trabalho

1. O cliente inicia a conexão com o endereço IP público do Firewall do Azure.

   • Endereço IP de origem: ClientPIP
   • Endereço IP de destino: AzFwPIP

2. A solicitação para o endereço IP público do Firewall do Azure é distribuída para uma instância back-end do firewall, que é 192.168.100.7 neste exemplo. A regra do Firewall do Azure Tradução de Endereço de Rede de Destino (DNAT) traduz o endereço IP de destino para o endereço IP do aplicativo dentro da rede virtual. O Firewall do Azure também implementa de conversão de endereços de rede de origem (SNAT) no pacote se ele usar DNAT. Para obter mais informações, consulte problemas conhecidos do Firewall do Azure. A VM vê os seguintes endereços IP no pacote de entrada:

   • Endereço IP de origem: 192.168.100.7
   • Endereço IP de destino: 192.168.1.4

3. A VM responde à solicitação do aplicativo, que reverte os endereços IP de origem e de destino. O fluxo de entrada não requer um UDR porque o IP de origem é o endereço IP do Firewall do Azure. O UDR no diagrama para 0.0.0.0/0 é para conexões de saída para garantir que os pacotes para a Internet pública passem pelo Firewall do Azure.

   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.100.7

4. O Firewall do Azure desfaz as operações SNAT e DNAT e fornece a resposta ao cliente.

   • Endereço IP de origem: AzFwPIP
   • Endereço IP de destino: ClientPIP

Design somente do Application Gateway

Este design descreve o cenário em que existem apenas aplicativos Web na rede virtual, e inspecionar o tráfego de saída com NSGs é suficiente para proteger os fluxos de saída para a Internet.

Observação

Não recomendamos esse design porque usar o Firewall do Azure para controlar fluxos de saída, em vez de depender apenas de NSGs, ajuda a evitar cenários de ataque, como a exfiltração de dados. Com o Firewall do Azure, você pode ajudar a garantir que suas cargas de trabalho enviem dados apenas para uma lista aprovada de URLs. Além disso, os NSGs operam apenas nas camadas 3 e 4 e não suportam FQDNs.

A principal diferença em relação ao design anterior somente do Firewall do Azure é que o Application Gateway não serve como um dispositivo de roteamento com NAT. Em vez disso, ele funciona como um proxy de aplicativo reverso completo. Essa abordagem significa que o Application Gateway interrompe a sessão da Web do cliente e estabelece uma sessão separada com um de seus servidores back-end. As conexões HTTP(S) de entrada da Internet são enviadas para o endereço IP público do Gateway de Aplicativo, e as conexões do Azure ou no local usam o endereço IP privado do gateway. O tráfego de retorno das VMs do Azure segue o roteamento de rede virtual padrão de volta para o Gateway de Aplicativo. Para obter mais informações, consulte o passo a passo do pacote mais adiante neste artigo. Os fluxos de saída da Internet das VMs do Azure vão diretamente para a Internet.

A tabela a seguir resume os fluxos de tráfego.

Fluxo	Passa pelo Application Gateway/Web Application Firewall	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou no local para o Azure	Sim	N/A
Tráfego HTTP(S) do Azure para a Internet ou no local	Não	N/A
Tráfego não-HTTP(S) da Internet ou local para o Azure	Não	N/A
Tráfego não-HTTP(S) do Azure para a Internet ou no local	Não	N/A

Arquitetura

O exemplo de passo a passo de pacote a seguir mostra como um cliente acessa o aplicativo hospedado na VM a partir da Internet pública.

Fluxo de trabalho

1. O cliente inicia a conexão com o endereço IP público do Application Gateway.

   • Endereço IP de origem: ClientPIP
   • Endereço IP de destino: AppGwPIP

2. A solicitação para o endereço IP público do Application Gateway é distribuída para uma instância back-end do gateway, que é 192.168.200.7 neste exemplo. A instância do Application Gateway que recebe a solicitação interrompe a conexão do cliente e estabelece uma nova conexão com um dos back-ends. O back-end vê a instância do Application Gateway como o endereço IP de origem. O Application Gateway insere um cabeçalho HTTP X-Forwarded-For com o endereço IP do cliente original.

   • Endereço IP de origem, que é o endereço IP privado da instância do Application Gateway: 192.168.200.7
   • Endereço IP de destino: 192.168.1.4
   • X-Forwarded-For cabeçalho: ClientPIP

3. A VM responde à solicitação do aplicativo e reverte os endereços IP de origem e de destino. A VM pode acessar o Application Gateway, portanto, não precisa de um UDR.

   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.200.7

4. A instância do Application Gateway responde ao cliente.

   • Endereço IP de origem: AppGwPIP
   • Endereço IP de destino: ClientPIP

O Application Gateway adiciona metadados aos cabeçalhos HTTP do pacote, como o cabeçalho X-Forwarded-For que contém o endereço IP do cliente original. Alguns servidores de aplicativos precisam do endereço IP do cliente de origem para fornecer conteúdo específico de geolocalização ou para registro em log. Para obter mais informações, consulte Como funciona um gateway de aplicativo.

• Neste exemplo, o endereço IP 192.168.200.7 é uma das instâncias implantadas automaticamente pelo serviço Gateway de Aplicativo. Ele tem o endereço IP front-end interno e privado 192.168.200.4. Essas instâncias individuais são normalmente invisíveis para o administrador do Azure. Mas perceber a diferença pode ser útil, como quando você soluciona problemas de rede.

• O fluxo é semelhante se o cliente vier de uma rede local através de um gateway VPN ou ExpressRoute. A diferença é que o cliente acessa o endereço IP privado do Application Gateway em vez do endereço IP público.

Observação

Para obter mais informações sobre o cabeçalho X-Forwarded-For e como preservar o nome do host em uma solicitação, consulte Preservar o host HTTP original.

Firewall do Azure e Gateway de Aplicativo em design paralelo

Devido à sua simplicidade e flexibilidade, geralmente é melhor executar o Gateway de Aplicativo e o Firewall do Azure em paralelo.

Implemente esse design se houver cargas de trabalho da Web e não da Web na rede virtual. O Web Application Firewall no Application Gateway ajuda a proteger o tráfego de entrada para as cargas de trabalho da Web. O Firewall do Azure inspeciona o tráfego de entrada para os outros aplicativos. O Firewall do Azure cobre fluxos de saída de ambos os tipos de carga de trabalho.

As conexões HTTP(S) de entrada da Internet devem ser enviadas para o endereço IP público do Application Gateway. As conexões HTTP(S) do Azure ou locais devem ser enviadas para seu endereço IP privado. O roteamento de rede virtual padrão envia os pacotes do Application Gateway para as VMs de destino e das VMs de destino de volta para o Application Gateway. Para obter mais informações, consulte o passo a passo do pacote mais adiante neste artigo.

Para conexões não-HTTP(S) de entrada, o tráfego deve ter como destino o endereço IP público do Firewall do Azure se ele vier da Internet pública. O tráfego deve ser enviado através da Firewall do Azure por UDRs se vier de outras redes virtuais do Azure ou redes locais. Todos os fluxos de saída das VMs do Azure são encaminhados para o Firewall do Azure por UDRs.

A tabela a seguir resume os fluxos de tráfego para esse cenário.

Fluxo	Passa pelo Application Gateway/Web Application Firewall	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou no local para o Azure	Sim	Não
Tráfego HTTP(S) do Azure para a Internet ou no local	Não	Sim
Tráfego não-HTTP(S) da Internet ou local para o Azure	Não	Sim
Tráfego não-HTTP(S) do Azure para a Internet ou no local	Não	Sim

Esse design fornece uma filtragem de saída muito mais granular do que apenas o uso de NSGs. Por exemplo, se os aplicativos precisarem de conectividade com uma conta de Armazenamento do Azure específica, você poderá usar filtros baseados em FQDN. Com filtros baseados em FQDN, as aplicações não enviam dados para contas de armazenamento fraudulentas. Se você usar apenas NSGs, não poderá evitar esse cenário. Esse design é frequentemente usado quando o tráfego de saída requer filtragem baseada em FQDN. Um cenário é quando você limitar o tráfego de saída de um cluster AKS.

Arquiteturas

O diagrama a seguir ilustra o fluxo de tráfego para conexões HTTP(S) de entrada de um cliente externo.

O diagrama a seguir ilustra o fluxo de tráfego para conexões de saída das VMs de rede para a Internet. Um exemplo é conectar-se a sistemas back-end ou obter atualizações do sistema operacional.

As etapas de fluxo de pacotes para cada serviço são as mesmas das opções de design autônomo anteriores.

Gateway de Aplicativo na frente do design do Firewall do Azure

Esse design é explicado com mais detalhes em rede de confiança zero para aplicativos Web com o Firewall do Azure e o Gateway de Aplicativo. Este artigo concentra-se na comparação com as outras opções de design. Nessa topologia, o tráfego da Web de entrada passa pelo Firewall do Azure e pelo Firewall de Aplicativo Web. O Web Application Firewall fornece proteção na camada de aplicativos Web. O Firewall do Azure serve como um ponto central de registro em log e controle e inspeciona o tráfego entre o Gateway de Aplicativo e os servidores back-end. Neste design, o Gateway de Aplicativo e o Firewall do Azure não ficam em paralelo, mas um na frente do outro.

Com Premium do Firewall do Azure, esse design pode dar suporte a cenários de ponta a ponta, em que o Firewall do Azure aplica inspeção TLS para executar IDPS no tráfego criptografado entre o Gateway de Aplicativo e o back-end da Web.

Esse design é adequado para aplicativos que precisam identificar endereços IP de origem do cliente de entrada. Por exemplo, ele pode ser usado para fornecer conteúdo específico de geolocalização ou para registro. O Gateway de Aplicativo na frente do design do Firewall do Azure captura o endereço IP de origem do pacote de entrada no cabeçalho X-Forwarded-For, para que o servidor Web possa ver o endereço IP original nesse cabeçalho. Para obter mais informações, consulte Como funciona um gateway de aplicativo.

As conexões HTTP(S) de entrada da Internet precisam ser enviadas para o endereço IP público do Application Gateway. As conexões HTTP(S) do Azure ou locais devem ser enviadas para seu endereço IP privado. No Gateway de Aplicativo, as UDRs garantem que os pacotes sejam roteados por meio do Firewall do Azure. Para obter mais informações, consulte o passo a passo do pacote mais adiante neste artigo.

Para conexões não-HTTP(S) de entrada, o tráfego deve ter como destino o endereço IP público do Firewall do Azure se ele vier da Internet pública. O tráfego deve ser enviado através da Firewall do Azure por UDRs se vier de outras redes virtuais do Azure ou redes locais. Todos os fluxos de saída das VMs do Azure são encaminhados para o Firewall do Azure por UDRs.

Um aspeto importante desse design é que o Firewall Premium do Azure vê o tráfego com um endereço IP de origem da sub-rede do Gateway de Aplicativo. Se essa sub-rede estiver configurada com um endereço IP privado (em 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12ou 100.64.0.0/10), o Firewall Premium do Azure tratará o tráfego do Gateway de Aplicativo como interno e não aplicará regras de IDPS para tráfego de entrada. Como resultado, recomendamos que você modifique os prefixos privados IDPS na política de Firewall do Azure. Essa modificação garante que a sub-rede do Application Gateway não seja considerada uma fonte interna, o que permite que assinaturas IDPS de entrada e saída sejam aplicadas ao tráfego. Você pode encontrar mais informações sobre direções de regras IDPS do Firewall do Azure e prefixos IP privados para IDPS em regras IDPS do Firewall do Azure.

A tabela a seguir resume os fluxos de tráfego para esse cenário.

Fluxo	Passa pelo Application Gateway/Web Application Firewall	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou no local para o Azure	Sim	Sim
Tráfego HTTP(S) do Azure para a Internet ou no local	Não	Sim
Tráfego não-HTTP(S) da Internet ou local para o Azure	Não	Sim
Tráfego não-HTTP(S) do Azure para a Internet ou no local	Não	Sim

Para tráfego da Web local ou da Internet para o Azure, o Firewall do Azure inspeciona os fluxos permitidos pelo Firewall de Aplicativo Web. Dependendo se o Application Gateway criptografa o tráfego back-end, que é o tráfego do Application Gateway para os servidores de aplicativos, diferentes cenários podem ocorrer:

• O Gateway de Aplicativo criptografa o tráfego seguindo princípios de confiança zero, como criptografia TLS de ponta a ponta, e o Firewall do Azure recebe tráfego criptografado. O Firewall do Azure Standard ainda pode aplicar regras de inspeção, como filtragem de camada 3 e camada 4 em regras de rede ou filtragem FQDN em regras de aplicativo, usando o cabeçalho SNI (Indicação de Nome de Servidor) TLS. do Firewall Premium do Azure fornece visibilidade mais profunda com inspeção TLS, como filtragem baseada em URL.

• Se o Gateway de Aplicativo enviar tráfego não criptografado para os servidores de aplicativos, o Firewall do Azure verá o tráfego de entrada em texto não criptografado. A inspeção TLS não é necessária no Firewall do Azure.

• Se o IDPS estiver habilitado no Firewall do Azure, ele verificará se o cabeçalho do Host HTTP corresponde ao endereço IP de destino. Para executar essa verificação, ele precisa da resolução de nome para o FQDN especificado no cabeçalho do host. Essa resolução de nomes pode ser executada usando zonas privadas do DNS do Azure e as configurações padrão de DNS do Firewall do do Azure. Isso também pode ser alcançado com servidores DNS personalizados que precisam ser configurados nas configurações do Firewall do Azure. Se você não tiver acesso administrativo à rede virtual onde o Firewall do Azure está implantado, o último método será sua única opção. Um exemplo é com instâncias do Firewall do Azure implantadas em hubs protegidos por WAN Virtual do Azure.

Arquitetura

Para o restante dos fluxos, que incluem tráfego de entrada não HTTP(S) e qualquer tráfego de saída, o Firewall do Azure fornece inspeção IDPS e inspeção TLS quando apropriado. Ele também fornece filtragem baseada em FQDN em regras de rede baseadas em DNS.

Fluxo de trabalho

O tráfego de rede da Internet pública segue este fluxo:

1. O cliente inicia a conexão com o endereço IP público do Application Gateway.

   • Endereço IP de origem: ClientPIP
   • Endereço IP de destino: AppGwPIP

2. A solicitação para o endereço IP público do Application Gateway é distribuída para uma instância back-end do gateway, que é 192.168.200.7 neste exemplo. A instância do Application Gateway interrompe a conexão do cliente e estabelece uma nova conexão com um dos back-ends. O UDR a 192.168.1.0/24 na sub-rede do Gateway de Aplicativo encaminha o pacote para o Firewall do Azure e preserva o endereço IP de destino para o aplicativo Web.

   • Endereço IP de origem, que é o endereço IP privado da instância do Application Gateway: 192.168.200.7
   • Endereço IP de destino: 192.168.1.4
   • X-Forwarded-For cabeçalho: ClientPIP

3. O Firewall do Azure não aplica o SNAT ao tráfego porque o tráfego vai para um endereço IP privado. Ele encaminha o tráfego para a VM do aplicativo se as regras permitirem. Para obter mais informações, veja SNAT do Azure Firewall para intervalos de endereços IP privados. No entanto, se o tráfego atingir uma regra de aplicativo no firewall, a carga de trabalho verá o endereço IP de origem da instância de firewall específica que processou o pacote porque o Firewall do Azure faz proxy da conexão.

   • Endereço IP de origem se o tráfego for permitido por uma regra de rede do Firewall do Azure e for o endereço IP privado de uma das instâncias do Gateway de Aplicativo: 192.168.200.7
   • Endereço IP de origem se o tráfego for permitido por uma regra de aplicativo do Firewall do Azure e for o endereço IP privado de uma das instâncias do Firewall do Azure: 192.168.100.7
   • Endereço IP de destino: 192.168.1.4
   • X-Forwarded-For cabeçalho: ClientPIP

4. A VM responde à solicitação, que reverte os endereços IP de origem e de destino. O UDR para 192.168.200.0/24 captura o pacote enviado de volta ao Gateway de Aplicativo, redireciona-o para o Firewall do Azure e preserva o endereço IP de destino para o Gateway de Aplicativo.

   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.200.7

5. Novamente, o Firewall do Azure não aplica o SNAT ao tráfego porque ele vai para um endereço IP privado e encaminha o tráfego para o Gateway de Aplicativo.

   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.200.7

6. A instância do Application Gateway responde ao cliente.

   • Endereço IP de origem: AppGwPIP
   • Endereço IP de destino: ClientPIP

Os fluxos de saída das VMs para a Internet pública passam pelo Firewall do Azure, que o UDR para 0.0.0.0/0 define.

Como uma variação desse design, você pode configurar o DNAT privado no Firewall do Azure para que a carga de trabalho do aplicativo veja os endereços IP das instâncias do Firewall do Azure como a origem e nenhum UDRs seja necessário. O endereço IP de origem dos clientes do aplicativo já está preservado no cabeçalho HTTP X-Forwarded-For pelo Application Gateway. Portanto, se o Firewall do Azure aplicar DNAT ao tráfego, nenhuma informação será perdida. Para obter mais informações, consulte Filtrar o tráfego de entrada da Internet ou da intranet com o DNAT da política de Firewall do Azure usando o portal do Azure.

Firewall do Azure na frente do design do Gateway de Aplicativo

Esse design permite que o Firewall do Azure filtre e descarte o tráfego mal-intencionado antes que ele chegue ao Gateway de Aplicativo. Por exemplo, ele pode aplicar recursos como filtragem baseada em inteligência de ameaças. Outro benefício é que o aplicativo obtém o mesmo endereço IP público para tráfego de entrada e saída, independentemente do protocolo. Há três modos nos quais você pode teoricamente configurar o Firewall do Azure:

• Firewall do Azure com regras DNAT: Firewall do Azure apenas troca endereços IP na camada de endereço IP, mas não processa a carga útil. Como resultado, ele não altera nenhum dos cabeçalhos HTTP.

• Firewall do Azure com regras de aplicativo e inspeção TLS desabilitadas: Firewall do Azure pode examinar o cabeçalho SNI no TLS, mas não o descriptografa. Uma nova conexão TCP é criada do firewall para o próximo salto. Neste exemplo, é o Application Gateway.

• Firewall do Azure com regras de aplicativo e inspeção TLS habilitadas: Firewall do Azure examina o conteúdo do pacote e os descriptografa. Ele serve como um proxy HTTP e pode definir os cabeçalhos HTTP X-Forwarded-For para preservar o endereço IP. No entanto, apresenta um certificado autogerado ao cliente. Para aplicativos baseados na Internet, usar um certificado gerado automaticamente não é uma opção porque um aviso de segurança é enviado aos clientes do aplicativo a partir do navegador.

Nas duas primeiras opções, que são as únicas opções válidas para aplicativos baseados na Internet, o Firewall do Azure aplica o SNAT ao tráfego de entrada sem definir o cabeçalho X-Forwarded-For. Como resultado, o aplicativo não pode ver o endereço IP original das solicitações HTTP. Para tarefas administrativas, como solução de problemas, você pode obter o endereço IP real do cliente para uma conexão específica correlacionando-o com os logs SNAT do Firewall do Azure.

Os benefícios desse cenário são limitados porque, a menos que você use a inspeção TLS e apresente certificados autogerados aos clientes, o Firewall do Azure só vê o tráfego criptografado que vai para o Gateway de Aplicativo. Esse cenário normalmente só é possível para aplicativos internos. No entanto, pode haver cenários em que esse design seja preferido. Um cenário é se outro Firewall de Aplicativo Web existir anteriormente na rede (por exemplo, com o Azure Front Door), que pode capturar o IP de origem original no cabeçalho HTTP X-Forwarded-For. Você também pode preferir esse design se muitos endereços IP públicos forem necessários porque o Application Gateway oferece suporte a um único endereço IP.

Os fluxos de entrada HTTP(S) da Internet pública devem ter como destino o endereço IP público do Firewall do Azure. O Firewall do Azure DNAT e SNAT enviará os pacotes para o endereço IP privado do Gateway de Aplicativo. De outras redes virtuais do Azure ou redes locais, o tráfego HTTP(S) deve ser enviado para o endereço IP privado do Gateway de Aplicativo e encaminhado por meio do Firewall do Azure com UDRs. O roteamento de rede virtual padrão garante que o tráfego de retorno das VMs do Azure retorne ao Gateway de Aplicativo e do Gateway de Aplicativo ao Firewall do Azure se as regras DNAT forem usadas. Para tráfego local ou do Azure, use UDRs na sub-rede do Gateway de Aplicativo. Para obter mais informações, consulte o passo a passo do pacote mais adiante neste artigo. Todo o tráfego de saída das VMs do Azure para a Internet é enviado através do Firewall do Azure por UDRs.

A tabela a seguir resume os fluxos de tráfego para esse cenário.

Fluxo	Passa pelo Application Gateway/Web Application Firewall	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou no local para o Azure	Sim	Sim
Tráfego HTTP(S) do Azure para a Internet ou no local	Não	Sim
Tráfego não-HTTP(S) da Internet ou local para o Azure	Não	Sim
Tráfego não-HTTP(S) do Azure para a Internet ou no local	Não	Sim

Para tráfego HTTP(S) de entrada, o Firewall do Azure normalmente não descriptografa o tráfego. Em vez disso, ele aplica políticas IDPS que não exigem inspeção TLS, como filtragem baseada em endereço IP ou uso de cabeçalhos HTTP.

Arquitetura

O aplicativo não pode ver o endereço IP de origem original do tráfego da Web. O Firewall do Azure aplica o SNAT aos pacotes à medida que eles entram na rede virtual. Para evitar esse problema, use do Azure Front Door na frente do firewall. O Azure Front Door injeta o endereço IP do cliente como um cabeçalho HTTP antes de entrar na rede virtual do Azure.

Fluxo de trabalho

O tráfego de rede da Internet pública segue este fluxo:

1. O cliente inicia a conexão com o endereço IP público do Firewall do Azure.

   • Endereço IP de origem: ClientPIP
   • Endereço IP de destino: AzFWPIP

2. A solicitação para o endereço IP público do Firewall do Azure é distribuída para uma instância back-end do firewall, que é 192.168.100.7 neste exemplo. O Firewall do Azure aplica DNAT à porta Web, geralmente TCP 443, ao endereço IP privado da instância do Gateway de Aplicativo. O Firewall do Azure também aplica SNAT quando você executa DNAT. Para obter mais informações, consulte problemas conhecidos do Firewall do Azure.

   • Endereço IP de origem, que é o endereço IP privado da instância do Firewall do Azure: 192.168.100.7
   • Endereço IP de destino: 192.168.200.4

3. O Application Gateway estabelece uma nova sessão entre a instância que lida com a conexão e um dos servidores back-end. O endereço IP original do cliente não está no pacote.

   • Endereço IP de origem, que é o endereço IP privado da instância do Application Gateway: 192.168.200.7
   • Endereço IP de destino: 192.168.1.4
   • X-Forwarded-For cabeçalho: 192.168.100.7

4. A VM responde ao Application Gateway, que reverte os endereços IP de origem e de destino:

   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.200.7

5. O Gateway de Aplicativo responde ao endereço IP de origem SNAT da instância do Firewall do Azure. O Firewall do Azure vê o endereço IP interno do Gateway de Aplicativo, .4, como o endereço IP de origem, mesmo que a conexão venha de uma instância específica do Gateway de Aplicativo, como .7.

   • Endereço IP de origem: 192.168.200.4
   • Endereço IP de destino: 192.168.100.7

6. O Firewall do Azure desfaz SNAT e DNAT e responde ao cliente.

   • Endereço IP de origem: AzFwPIP
   • Endereço IP de destino: ClientPIP

O Application Gateway precisa de um endereço IP público para que a Microsoft possa gerenciá-lo, mesmo que não tenha ouvintes configurados para aplicativos.

Observação

Uma rota padrão para 0.0.0.0/0 na sub-rede do Gateway de Aplicativo que aponta para o Firewall do Azure não é suportada porque quebra o tráfego do plano de controle que o Gateway de Aplicativo requer para funcionar corretamente.

Clientes locais

Todos os designs anteriores mostram clientes de aplicativos de entrada da Internet pública. As redes locais também acessam aplicativos. A maioria das informações anteriores e fluxos de tráfego são os mesmos que para clientes de Internet, mas existem algumas diferenças notáveis:

• Um gateway VPN ou gateway de Rota Expressa fica na frente do Firewall do Azure ou do Gateway de Aplicativo.

• O Web Application Firewall usa o endereço IP privado do Application Gateway.

• O Firewall do Azure não oferece suporte a DNAT para endereços IP privados, portanto, você deve usar UDRs para enviar tráfego de entrada para o Firewall do Azure a partir dos gateways VPN ou ExpressRoute.

• Certifique-se de verificar as advertências em torno de encapsulamento forçado para do Gateway de Aplicativo e para do Firewall do Azure. Mesmo que sua carga de trabalho não precise de conectividade de saída com a Internet pública, você não pode injetar uma rota padrão, como 0.0.0.0/0 para o Application Gateway, que aponta para a rede local porque interrompe o tráfego de controle. Para o Application Gateway, a rota padrão precisa apontar para a Internet pública.

Arquitetura

O diagrama a seguir mostra o design paralelo do Gateway de Aplicativo e do Firewall do Azure. Os clientes de aplicativos vêm de uma rede local conectada ao Azure por VPN ou Rota Expressa:

Mesmo que todos os clientes estejam localizados no local ou no Azure, o Gateway de Aplicativo e o Firewall do Azure precisam ter endereços IP públicos. Esses endereços IP públicos permitem que a Microsoft gerencie os serviços.

Topologia hub-and-spoke

Os designs neste artigo se aplicam a uma topologia de hub-and-spoke. Recursos compartilhados em uma rede virtual de hub central se conectam a aplicativos em redes virtuais spoke separadas por meio de emparelhamentos de rede virtual.

Arquitetura

• O Firewall do Azure é implantado na rede virtual do hub central. O diagrama anterior mostra como implantar o Application Gateway no hub. As equipes de aplicativos geralmente gerenciam componentes como gateways de aplicativos ou gateways de gerenciamento de API. Nesse cenário, esses componentes são implantados nas redes virtuais faladas.

• Preste especial atenção aos UDRs nas redes faladas. Quando um servidor de aplicativos em um spoke recebe tráfego de uma instância específica do Firewall do Azure, como o endereço IP 192.168.100.7 nos exemplos anteriores, ele deve enviar o tráfego de retorno de volta para a mesma instância. Se um UDR no spoke definir o próximo salto de tráfego endereçado ao hub para o endereço IP do Firewall do Azure (192.168.100.4 nos diagramas anteriores), os pacotes de retorno podem acabar em uma instância diferente do Firewall do Azure. Esta situação provoca um encaminhamento assimétrico. Se tiver UDRs nas redes virtuais faladas, certifique-se de que envia tráfego para serviços partilhados no hub através da Firewall do Azure. Essas UDRs não incluem o prefixo da sub-rede do Firewall do Azure.

• A recomendação anterior aplica-se igualmente à sub-rede do Application Gateway e a quaisquer outros NVAs ou proxies reversos que possam ser implantados na rede virtual do hub.

• Não é possível definir o próximo salto para as sub-redes do Gateway de Aplicativo ou do Firewall do Azure por meio de rotas estáticas com um tipo de Virtual Networkde salto seguinte. Este tipo de salto seguinte só é válido na rede virtual local e não entre emparelhamentos de rede virtual. Para obter mais informações sobre UDRs e tipos de próximo salto, consulte Roteamento de tráfego de rede virtual.

Roteamento assimétrico

O diagrama a seguir mostra como um spoke envia o tráfego SNAT de volta para o balanceador de carga do Azure do Firewall do Azure. Essa configuração causa roteamento assimétrico.

Para resolver esse problema, defina UDRs no spoke sem a sub-rede do Firewall do Azure e apenas com as sub-redes onde os serviços compartilhados estão localizados. No diagrama anterior, o UDR correto no falado deve conter apenas 192.168.1.0/24. Ele não deve conter todo o intervalo 192.168.0.0/16, que está marcado em vermelho.

Integração com outros produtos do Azure

Você pode integrar o Firewall do Azure e o Gateway de Aplicativo com outros produtos e serviços do Azure.

Gateway de gerenciamento de API

Integre serviços de proxy reverso, como API Management gateway, nos designs anteriores para fornecer funcionalidades como limitação de API ou proxy de autenticação. A integração do gateway de gerenciamento de API não afeta significativamente os projetos. A principal diferença é que, em vez do proxy reverso único do Application Gateway, há dois proxies reversos encadeados um atrás do outro.

Para obter mais informações, consulte o guia de design de para integrar o Gerenciamento de API e o Application Gateway em um de rede virtual e o padrão de aplicativo gateways de API para microsserviços.

Azure Kubernetes Service (AKS)

Para cargas de trabalho executadas em um cluster AKS, você pode implantar o Application Gateway independentemente do cluster. Ou você pode integrá-lo ao cluster AKS usando o Application Gateway Ingress Controller. Quando você configura objetos específicos nos níveis do Kubernetes, como serviços e ingressos, o Application Gateway se adapta automaticamente sem precisar de etapas manuais extras.

O Firewall do Azure desempenha um papel importante na segurança do cluster AKS. Ele fornece a funcionalidade necessária para filtrar o tráfego de saída do cluster AKS com base no FQDN, não apenas no endereço IP. Para obter mais informações, consulte Limitar o tráfego de rede com o Firewall do Azure no AKS.

Quando você combina o Gateway de Aplicativo e o Firewall do Azure para proteger um cluster AKS, é melhor usar a opção de design paralelo. O Application Gateway com Web Application Firewall processa solicitações de conexão de entrada para aplicativos Web no cluster. O Firewall do Azure permite apenas conexões de saída permitidas explicitamente. Para obter mais informações sobre a opção de design paralelo, consulte Arquitetura de linha de base para um cluster AKS.

Azure Front Door (porta de entrada do Azure)

Azure Front Door tem funcionalidade que se sobrepõe ao Application Gateway em várias áreas. Ambos os serviços fornecem firewall de aplicativos Web, descarregamento de SSL e roteamento baseado em URL. No entanto, uma diferença fundamental é que, enquanto o Application Gateway opera em uma rede virtual, o Azure Front Door é um serviço global e descentralizado.

Às vezes, você pode simplificar o design de rede virtual substituindo o Gateway de Aplicativo por uma Porta de Entrada do Azure descentralizada. A maioria dos designs descritos neste artigo ainda se aplicam, exceto para a opção de colocar o Firewall do Azure na frente da Porta da Frente do Azure.

Um cenário é usar o Firewall do Azure na frente do Gateway de Aplicativo em sua rede virtual. O Application Gateway injeta o cabeçalho X-Forwarded-For com o endereço IP da instância de firewall, não com o endereço IP do cliente. Uma solução alternativa é usar o Azure Front Door na frente do firewall para injetar o endereço IP do cliente como um cabeçalho X-Forwarded-For antes que o tráfego entre na rede virtual e atinja o Firewall do Azure. Você também pode proteger sua origem com o Azure Private Link no Azure Front Door Premium.

Para obter mais informações sobre as diferenças entre os dois serviços ou quando usar cada um, consulte Perguntas frequentes sobre o Azure Front Door.

Outros NVA

Os produtos da Microsoft não são a única opção para implementar o firewall de aplicativos Web ou a funcionalidade de firewall de próxima geração no Azure. Uma ampla gama de parceiros da Microsoft fornece NVAs. Os conceitos e designs são essencialmente os mesmos deste artigo, mas há algumas considerações importantes:

• NVAs de parceiros para firewalls de próxima geração podem fornecer mais controle e flexibilidade para configurações NAT que o Firewall do Azure não suporta. Os exemplos incluem DNAT do local ou DNAT da Internet sem SNAT.

• Os NVAs gerenciados pelo Azure, como o Gateway de Aplicativo e o Firewall do Azure, reduzem a complexidade, em comparação com os NVAs em que os usuários precisam lidar com escalabilidade e resiliência em muitos dispositivos.

• Ao usar NVAs no Azure, use ativo-ativo e o dimensionamento automático configurações para que esses dispositivos não sejam um gargalo para aplicativos executados na rede virtual.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• Jose Moreno - Brasil | Engenheiro de Clientes Principal

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos

Saiba mais sobre as tecnologias de componentes:

• O que é o Application Gateway?
• O que é o Firewall do Azure?
• O que é o Azure Front Door?
• AKS
• O que é Rede Virtual?
• O que é Web Application Firewall?
• Arquitetura de linha de base para um cluster AKS

Recursos relacionados

Explore arquiteturas relacionadas:

• Implementar uma rede híbrida segura
• Aplicações Web geridas de forma segura
• software multilocatário como um serviço no Azure
• implantação corporativa usando o Ambiente do Serviço de Aplicativo
• Implantação corporativa de alta disponibilidade usando o Ambiente do Serviço de Aplicativo

Para ajudar a proteger cargas de trabalho de aplicativos do Azure, use medidas de proteção, como autenticação e criptografia nos próprios aplicativos. Você pode adicionar camadas de segurança às redes virtuais que hospedam os aplicativos. Essas camadas de segurança ajudam a proteger os fluxos de entrada do aplicativo contra uso não intencional. Eles também limitam os fluxos de saída para a Internet apenas aos pontos de extremidade que seu aplicativo exige. Este artigo descreve Rede Virtual do Azure serviços de segurança, como Proteção contra DDoS do Azure, Firewall do Azure e Gateway de Aplicativo do Azure. Ele também descreve quando usar cada serviço e opções de design de rede que os combinam.

• de Proteção contra DDoS , combinada com as práticas recomendadas de design de aplicativos, fornece recursos aprimorados de mitigação de DDoS que melhoram a defesa contra ataques DDoS. Você deve habilitar a Proteção contra DDoS em todas as redes virtuais de perímetro.

• de Firewall do Azure é um firewall gerenciado de última geração que fornece recursos de conversão de endereços de rede (NAT). O Firewall do Azure filtra pacotes com base em endereços IP e portas TCP (Transmission Control Protocol) ou UDP (User Datagram Protocol). Ele pode filtrar o tráfego usando atributos baseados em aplicativos, como HTTP(S) e SQL. O Firewall do Azure também aplica informações sobre ameaças da Microsoft para ajudar a identificar endereços IP mal-intencionados. Para obter mais informações, consulte documentação do Firewall do Azure.

• do Firewall Premium do Azure inclui todas as funcionalidades do Azure Firewall Standard, além de recursos como inspeção de segurança da camada de transporte (TLS) e sistema de deteção e prevenção de intrusão (IDPS).

• Application Gateway é um balanceador de carga de tráfego da Web gerenciado e proxy reverso completo HTTP(S) que pode executar criptografia e descriptografia SSL (Secure Socket Layer). O Application Gateway preserva o endereço IP do cliente original em um cabeçalho HTTP X-Forwarded-For. O Gateway de Aplicativo também usa o Firewall de Aplicativo Web do Azure para inspecionar o tráfego da Web e detetar ataques na camada HTTP. Para obter mais informações, consulte documentação do Application Gateway.

• do Web Application Firewall é uma adição opcional ao Application Gateway. Ele inspeciona solicitações HTTP e evita ataques de camada da Web, como injeção de SQL e scripts entre sites. Para obter mais informações, consulte documentação do Web Application Firewall.

Estes serviços do Azure complementam-se. Dependendo das suas necessidades, usar um serviço pode se adequar melhor às suas cargas de trabalho. No entanto, você pode usar esses serviços juntos para ajudar a fornecer proteção ideal nas camadas de rede e aplicativo. Use a árvore de decisão a seguir e os exemplos neste artigo para escolher a melhor opção de segurança para a rede virtual do seu aplicativo.

O Firewall do Azure e o Gateway de Aplicativo usam tecnologias diferentes para ajudar a proteger diferentes tipos de fluxos de dados.

Fluxo de aplicativos	Pode ser filtrado pelo Firewall do Azure	Pode ser filtrado pelo Web Application Firewall no Application Gateway
Tráfego HTTP(S) do local ou da Internet para o Azure (entrada)	Sim	Sim
Tráfego HTTP(S) do Azure para o local ou Internet (saída)	Sim	Não
Tráfego não-HTTP(S) (entrada ou saída)	Sim	Não

O design pode variar para cada aplicativo com base nos fluxos de rede que ele requer. O diagrama a seguir fornece uma árvore de decisão simplificada que ajuda você a escolher a abordagem recomendada para seu aplicativo. Essa escolha depende se o aplicativo é publicado via HTTP(S) ou algum outro protocolo.

Este artigo descreve os designs amplamente recomendados mostrados no fluxograma e os designs adequados para cenários menos comuns:

• Firewall do Azure apenas: Use este design quando não houver aplicativos Web na rede virtual. Ele controla o tráfego de entrada para os aplicativos e o tráfego de saída.

• Gateway de Aplicativo somente: Use este design quando apenas aplicativos Web estiverem na rede virtual e grupos de segurança de rede (NSGs) fornecer filtragem de saída suficiente. O Firewall do Azure fornece funcionalidade que pode ajudar a evitar vários cenários de ataque, como exfiltração de dados e IDPS. Como resultado, o design somente do Application Gateway geralmente não é recomendado, portanto, não é incluído no fluxograma anterior.

• o Firewall do Azure e o Gateway de Aplicativo em paralelo: Use esse design quando quiser que o Gateway de Aplicativo proteja aplicativos HTTP(S) contra ataques da Web e o Firewall do Azure proteja todas as outras cargas de trabalho e filtre o tráfego de saída. O Firewall do Azure e o Gateway de Aplicativo em paralelo é um design comum.

• Gateway de Aplicativo na frente do Firewall do Azure: Use este design quando quiser que o Firewall do Azure inspecione todo o tráfego, o Firewall de Aplicativo Web para proteger o tráfego da Web e o aplicativo para identificar o endereço IP de origem do cliente. Com a inspeção do Firewall do Azure Premium e TLS, esse design também dá suporte ao cenário SSL de ponta a ponta.

• o Firewall do Azure na frente do Application Gateway: Use esse design quando quiser que o Firewall do Azure inspecione e filtre o tráfego antes que ele chegue ao Gateway de Aplicativo. Como o Firewall do Azure não descriptografa o tráfego HTTPS, sua funcionalidade adicionada ao Gateway de Aplicativo é limitada. Este cenário não está documentado no fluxograma anterior.

As variações desses designs fundamentais são descritas mais adiante neste artigo e incluem:

• Clientes de aplicativos locais.
• Redes Hub-and-spoke.
• implementações de do Serviço Kubernetes do Azure (AKS).

Você pode adicionar outros serviços de proxy reverso, como um gateway de de Gerenciamento de API do Azure ou do Azure Front Door. Ou você pode substituir os recursos do Azure por dispositivos virtuais de rede (NVAs) não Microsoft.

Observação

Nos cenários a seguir, uma máquina virtual (VM) do Azure é usada como exemplo de uma carga de trabalho de aplicativo Web. Esses cenários também são válidos para outros tipos de carga de trabalho, como contêineres ou Aplicativos Web do Azure. Para configurações que incluem pontos de extremidade privados, considere as recomendações em cenários Firewall do Azure para inspecionar o tráfego destinado a um ponto de extremidade privado.

Design somente do Firewall do Azure

Se não houver cargas de trabalho baseadas na Web na rede virtual que possam se beneficiar do Firewall de Aplicativo Web, você poderá usar o design somente do Firewall do Azure. O design neste exemplo é simples, mas você pode revisar o fluxo de pacotes para entender melhor os designs mais complexos. Neste design, todo o tráfego de entrada é enviado para o Firewall do Azure por meio de UDRs (rotas definidas pelo usuário) para conexões de redes virtuais locais ou de outras redes virtuais do Azure. Ele é endereçado ao endereço IP público do Firewall do Azure para conexões da Internet pública, conforme mostrado no diagrama a seguir. UDRs direcionam o tráfego de saída das redes virtuais do Azure para o Firewall do Azure, conforme mostrado na caixa de diálogo a seguir.

A tabela a seguir resume os fluxos de tráfego para esse cenário.

Fluxo	Passa pelo Application Gateway/Web Application Firewall	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou no local para o Azure	N/A	Sim
Tráfego HTTP(S) do Azure para a Internet ou no local	N/A	Sim
Tráfego não-HTTP(S) da Internet ou local para o Azure	N/A	Sim
Tráfego não-HTTP(S) do Azure para a Internet ou no local	N/A	Sim

O Firewall do Azure não inspeciona o tráfego HTTP(S) de entrada. Mas ele pode aplicar regras de camada 3 e camada 4 e regras de aplicativo baseadas em nome de domínio totalmente qualificado (FQDN). O Firewall do Azure inspeciona o tráfego HTTP(S) de saída, dependendo da camada do Firewall do Azure e se você configura a inspeção TLS:

• O Firewall do Azure Standard inspeciona apenas atributos de camada 3 e camada 4 de pacotes em regras de rede e o cabeçalho HTTP do Host em regras de aplicativo.

• O Firewall Premium do Azure adiciona recursos, como inspecionar outros cabeçalhos HTTP (como o agente do usuário) e habilitar a inspeção TLS para uma análise mais profunda de pacotes. No entanto, o Firewall do Azure não é o mesmo que o Firewall de Aplicativo Web. Se você tiver cargas de trabalho da Web em sua rede virtual, recomendamos que você use o Web Application Firewall.

O exemplo de passo a passo de pacote a seguir mostra como um cliente acessa um aplicativo hospedado por VM a partir da Internet pública. O diagrama inclui apenas uma VM para simplificar. Para maior disponibilidade e escalabilidade, há várias instâncias de aplicativos por trás de um balanceador de carga. Neste design, o Firewall do Azure inspeciona as conexões de entrada da Internet pública e as conexões de saída da VM de sub-rede do aplicativo usando o UDR.

• Neste exemplo, o Firewall do Azure implanta automaticamente várias instâncias com o endereço IP front-end 192.168.100.4 e endereços internos dentro do intervalo 192.168.100.0/26. Normalmente, essas instâncias não são visíveis para o administrador do Azure. No entanto, estar ciente deles pode ser útil para solucionar problemas de rede.

• Se o tráfego vier de uma rede virtual privada (VPN) local ou gateway de da Rota Expressa do Azure em vez da Internet, o cliente iniciará a conexão com o endereço IP da VM. Ele não inicia a conexão com o endereço IP do firewall e o firewall não faz NAT de origem por padrão.

Arquitetura

O diagrama a seguir mostra o fluxo de tráfego e assume que o endereço IP da instância é 192.168.100.7.

Fluxo de trabalho

1. O cliente inicia a conexão com o endereço IP público do Firewall do Azure.

   • Endereço IP de origem: ClientPIP
   • Endereço IP de destino: AzFwPIP

2. A solicitação para o endereço IP público do Firewall do Azure é distribuída para uma instância back-end do firewall, que é 192.168.100.7 neste exemplo. A regra do Firewall do Azure Tradução de Endereço de Rede de Destino (DNAT) traduz o endereço IP de destino para o endereço IP do aplicativo dentro da rede virtual. O Firewall do Azure também implementa de conversão de endereços de rede de origem (SNAT) no pacote se ele usar DNAT. Para obter mais informações, consulte problemas conhecidos do Firewall do Azure. A VM vê os seguintes endereços IP no pacote de entrada:

   • Endereço IP de origem: 192.168.100.7
   • Endereço IP de destino: 192.168.1.4

3. A VM responde à solicitação do aplicativo, que reverte os endereços IP de origem e de destino. O fluxo de entrada não requer um UDR porque o IP de origem é o endereço IP do Firewall do Azure. O UDR no diagrama para 0.0.0.0/0 é para conexões de saída para garantir que os pacotes para a Internet pública passem pelo Firewall do Azure.

   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.100.7

4. O Firewall do Azure desfaz as operações SNAT e DNAT e fornece a resposta ao cliente.

   • Endereço IP de origem: AzFwPIP
   • Endereço IP de destino: ClientPIP

Design somente do Application Gateway

Este design descreve o cenário em que existem apenas aplicativos Web na rede virtual, e inspecionar o tráfego de saída com NSGs é suficiente para proteger os fluxos de saída para a Internet.

Observação

Não recomendamos esse design porque usar o Firewall do Azure para controlar fluxos de saída, em vez de depender apenas de NSGs, ajuda a evitar cenários de ataque, como a exfiltração de dados. Com o Firewall do Azure, você pode ajudar a garantir que suas cargas de trabalho enviem dados apenas para uma lista aprovada de URLs. Além disso, os NSGs operam apenas nas camadas 3 e 4 e não suportam FQDNs.

A principal diferença em relação ao design anterior somente do Firewall do Azure é que o Application Gateway não serve como um dispositivo de roteamento com NAT. Em vez disso, ele funciona como um proxy de aplicativo reverso completo. Essa abordagem significa que o Application Gateway interrompe a sessão da Web do cliente e estabelece uma sessão separada com um de seus servidores back-end. As conexões HTTP(S) de entrada da Internet são enviadas para o endereço IP público do Gateway de Aplicativo, e as conexões do Azure ou no local usam o endereço IP privado do gateway. O tráfego de retorno das VMs do Azure segue o roteamento de rede virtual padrão de volta para o Gateway de Aplicativo. Para obter mais informações, consulte o passo a passo do pacote mais adiante neste artigo. Os fluxos de saída da Internet das VMs do Azure vão diretamente para a Internet.

A tabela a seguir resume os fluxos de tráfego.

Fluxo	Passa pelo Application Gateway/Web Application Firewall	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou no local para o Azure	Sim	N/A
Tráfego HTTP(S) do Azure para a Internet ou no local	Não	N/A
Tráfego não-HTTP(S) da Internet ou local para o Azure	Não	N/A
Tráfego não-HTTP(S) do Azure para a Internet ou no local	Não	N/A

Arquitetura

O exemplo de passo a passo de pacote a seguir mostra como um cliente acessa o aplicativo hospedado na VM a partir da Internet pública.

Fluxo de trabalho

1. O cliente inicia a conexão com o endereço IP público do Application Gateway.

   • Endereço IP de origem: ClientPIP
   • Endereço IP de destino: AppGwPIP

2. A solicitação para o endereço IP público do Application Gateway é distribuída para uma instância back-end do gateway, que é 192.168.200.7 neste exemplo. A instância do Application Gateway que recebe a solicitação interrompe a conexão do cliente e estabelece uma nova conexão com um dos back-ends. O back-end vê a instância do Application Gateway como o endereço IP de origem. O Application Gateway insere um cabeçalho HTTP X-Forwarded-For com o endereço IP do cliente original.

   • Endereço IP de origem, que é o endereço IP privado da instância do Application Gateway: 192.168.200.7
   • Endereço IP de destino: 192.168.1.4
   • X-Forwarded-For cabeçalho: ClientPIP

3. A VM responde à solicitação do aplicativo e reverte os endereços IP de origem e de destino. A VM pode acessar o Application Gateway, portanto, não precisa de um UDR.

   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.200.7

4. A instância do Application Gateway responde ao cliente.

   • Endereço IP de origem: AppGwPIP
   • Endereço IP de destino: ClientPIP

O Application Gateway adiciona metadados aos cabeçalhos HTTP do pacote, como o cabeçalho X-Forwarded-For que contém o endereço IP do cliente original. Alguns servidores de aplicativos precisam do endereço IP do cliente de origem para fornecer conteúdo específico de geolocalização ou para registro em log. Para obter mais informações, consulte Como funciona um gateway de aplicativo.

• Neste exemplo, o endereço IP 192.168.200.7 é uma das instâncias implantadas automaticamente pelo serviço Gateway de Aplicativo. Ele tem o endereço IP front-end interno e privado 192.168.200.4. Essas instâncias individuais são normalmente invisíveis para o administrador do Azure. Mas perceber a diferença pode ser útil, como quando você soluciona problemas de rede.

• O fluxo é semelhante se o cliente vier de uma rede local através de um gateway VPN ou ExpressRoute. A diferença é que o cliente acessa o endereço IP privado do Application Gateway em vez do endereço IP público.

Observação

Para obter mais informações sobre o cabeçalho X-Forwarded-For e como preservar o nome do host em uma solicitação, consulte Preservar o host HTTP original.

Firewall do Azure e Gateway de Aplicativo em design paralelo

Devido à sua simplicidade e flexibilidade, geralmente é melhor executar o Gateway de Aplicativo e o Firewall do Azure em paralelo.

Implemente esse design se houver cargas de trabalho da Web e não da Web na rede virtual. O Web Application Firewall no Application Gateway ajuda a proteger o tráfego de entrada para as cargas de trabalho da Web. O Firewall do Azure inspeciona o tráfego de entrada para os outros aplicativos. O Firewall do Azure cobre fluxos de saída de ambos os tipos de carga de trabalho.

As conexões HTTP(S) de entrada da Internet devem ser enviadas para o endereço IP público do Application Gateway. As conexões HTTP(S) do Azure ou locais devem ser enviadas para seu endereço IP privado. O roteamento de rede virtual padrão envia os pacotes do Application Gateway para as VMs de destino e das VMs de destino de volta para o Application Gateway. Para obter mais informações, consulte o passo a passo do pacote mais adiante neste artigo.

Para conexões não-HTTP(S) de entrada, o tráfego deve ter como destino o endereço IP público do Firewall do Azure se ele vier da Internet pública. O tráfego deve ser enviado através da Firewall do Azure por UDRs se vier de outras redes virtuais do Azure ou redes locais. Todos os fluxos de saída das VMs do Azure são encaminhados para o Firewall do Azure por UDRs.

A tabela a seguir resume os fluxos de tráfego para esse cenário.

Fluxo	Passa pelo Application Gateway/Web Application Firewall	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou no local para o Azure	Sim	Não
Tráfego HTTP(S) do Azure para a Internet ou no local	Não	Sim
Tráfego não-HTTP(S) da Internet ou local para o Azure	Não	Sim
Tráfego não-HTTP(S) do Azure para a Internet ou no local	Não	Sim

Esse design fornece uma filtragem de saída muito mais granular do que apenas o uso de NSGs. Por exemplo, se os aplicativos precisarem de conectividade com uma conta de Armazenamento do Azure específica, você poderá usar filtros baseados em FQDN. Com filtros baseados em FQDN, as aplicações não enviam dados para contas de armazenamento fraudulentas. Se você usar apenas NSGs, não poderá evitar esse cenário. Esse design é frequentemente usado quando o tráfego de saída requer filtragem baseada em FQDN. Um cenário é quando você limitar o tráfego de saída de um cluster AKS.

Arquiteturas

O diagrama a seguir ilustra o fluxo de tráfego para conexões HTTP(S) de entrada de um cliente externo.

O diagrama a seguir ilustra o fluxo de tráfego para conexões de saída das VMs de rede para a Internet. Um exemplo é conectar-se a sistemas back-end ou obter atualizações do sistema operacional.

As etapas de fluxo de pacotes para cada serviço são as mesmas das opções de design autônomo anteriores.

Gateway de Aplicativo na frente do design do Firewall do Azure

Esse design é explicado com mais detalhes em rede de confiança zero para aplicativos Web com o Firewall do Azure e o Gateway de Aplicativo. Este artigo concentra-se na comparação com as outras opções de design. Nessa topologia, o tráfego da Web de entrada passa pelo Firewall do Azure e pelo Firewall de Aplicativo Web. O Web Application Firewall fornece proteção na camada de aplicativos Web. O Firewall do Azure serve como um ponto central de registro em log e controle e inspeciona o tráfego entre o Gateway de Aplicativo e os servidores back-end. Neste design, o Gateway de Aplicativo e o Firewall do Azure não ficam em paralelo, mas um na frente do outro.

Com Premium do Firewall do Azure, esse design pode dar suporte a cenários de ponta a ponta, em que o Firewall do Azure aplica inspeção TLS para executar IDPS no tráfego criptografado entre o Gateway de Aplicativo e o back-end da Web.

Esse design é adequado para aplicativos que precisam identificar endereços IP de origem do cliente de entrada. Por exemplo, ele pode ser usado para fornecer conteúdo específico de geolocalização ou para registro. O Gateway de Aplicativo na frente do design do Firewall do Azure captura o endereço IP de origem do pacote de entrada no cabeçalho X-Forwarded-For, para que o servidor Web possa ver o endereço IP original nesse cabeçalho. Para obter mais informações, consulte Como funciona um gateway de aplicativo.

As conexões HTTP(S) de entrada da Internet precisam ser enviadas para o endereço IP público do Application Gateway. As conexões HTTP(S) do Azure ou locais devem ser enviadas para seu endereço IP privado. No Gateway de Aplicativo, as UDRs garantem que os pacotes sejam roteados por meio do Firewall do Azure. Para obter mais informações, consulte o passo a passo do pacote mais adiante neste artigo.

Para conexões não-HTTP(S) de entrada, o tráfego deve ter como destino o endereço IP público do Firewall do Azure se ele vier da Internet pública. O tráfego deve ser enviado através da Firewall do Azure por UDRs se vier de outras redes virtuais do Azure ou redes locais. Todos os fluxos de saída das VMs do Azure são encaminhados para o Firewall do Azure por UDRs.

Um aspeto importante desse design é que o Firewall Premium do Azure vê o tráfego com um endereço IP de origem da sub-rede do Gateway de Aplicativo. Se essa sub-rede estiver configurada com um endereço IP privado (em 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12ou 100.64.0.0/10), o Firewall Premium do Azure tratará o tráfego do Gateway de Aplicativo como interno e não aplicará regras de IDPS para tráfego de entrada. Como resultado, recomendamos que você modifique os prefixos privados IDPS na política de Firewall do Azure. Essa modificação garante que a sub-rede do Application Gateway não seja considerada uma fonte interna, o que permite que assinaturas IDPS de entrada e saída sejam aplicadas ao tráfego. Você pode encontrar mais informações sobre direções de regras IDPS do Firewall do Azure e prefixos IP privados para IDPS em regras IDPS do Firewall do Azure.

A tabela a seguir resume os fluxos de tráfego para esse cenário.

Fluxo	Passa pelo Application Gateway/Web Application Firewall	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou no local para o Azure	Sim	Sim
Tráfego HTTP(S) do Azure para a Internet ou no local	Não	Sim
Tráfego não-HTTP(S) da Internet ou local para o Azure	Não	Sim
Tráfego não-HTTP(S) do Azure para a Internet ou no local	Não	Sim

Para tráfego da Web local ou da Internet para o Azure, o Firewall do Azure inspeciona os fluxos permitidos pelo Firewall de Aplicativo Web. Dependendo se o Application Gateway criptografa o tráfego back-end, que é o tráfego do Application Gateway para os servidores de aplicativos, diferentes cenários podem ocorrer:

• O Gateway de Aplicativo criptografa o tráfego seguindo princípios de confiança zero, como criptografia TLS de ponta a ponta, e o Firewall do Azure recebe tráfego criptografado. O Firewall do Azure Standard ainda pode aplicar regras de inspeção, como filtragem de camada 3 e camada 4 em regras de rede ou filtragem FQDN em regras de aplicativo, usando o cabeçalho SNI (Indicação de Nome de Servidor) TLS. do Firewall Premium do Azure fornece visibilidade mais profunda com inspeção TLS, como filtragem baseada em URL.

• Se o Gateway de Aplicativo enviar tráfego não criptografado para os servidores de aplicativos, o Firewall do Azure verá o tráfego de entrada em texto não criptografado. A inspeção TLS não é necessária no Firewall do Azure.

• Se o IDPS estiver habilitado no Firewall do Azure, ele verificará se o cabeçalho do Host HTTP corresponde ao endereço IP de destino. Para executar essa verificação, ele precisa da resolução de nome para o FQDN especificado no cabeçalho do host. Essa resolução de nomes pode ser executada usando zonas privadas do DNS do Azure e as configurações padrão de DNS do Firewall do do Azure. Isso também pode ser alcançado com servidores DNS personalizados que precisam ser configurados nas configurações do Firewall do Azure. Se você não tiver acesso administrativo à rede virtual onde o Firewall do Azure está implantado, o último método será sua única opção. Um exemplo é com instâncias do Firewall do Azure implantadas em hubs protegidos por WAN Virtual do Azure.

Arquitetura

Para o restante dos fluxos, que incluem tráfego de entrada não HTTP(S) e qualquer tráfego de saída, o Firewall do Azure fornece inspeção IDPS e inspeção TLS quando apropriado. Ele também fornece filtragem baseada em FQDN em regras de rede baseadas em DNS.

Fluxo de trabalho

O tráfego de rede da Internet pública segue este fluxo:

1. O cliente inicia a conexão com o endereço IP público do Application Gateway.

   • Endereço IP de origem: ClientPIP
   • Endereço IP de destino: AppGwPIP

2. A solicitação para o endereço IP público do Application Gateway é distribuída para uma instância back-end do gateway, que é 192.168.200.7 neste exemplo. A instância do Application Gateway interrompe a conexão do cliente e estabelece uma nova conexão com um dos back-ends. O UDR a 192.168.1.0/24 na sub-rede do Gateway de Aplicativo encaminha o pacote para o Firewall do Azure e preserva o endereço IP de destino para o aplicativo Web.

   • Endereço IP de origem, que é o endereço IP privado da instância do Application Gateway: 192.168.200.7
   • Endereço IP de destino: 192.168.1.4
   • X-Forwarded-For cabeçalho: ClientPIP

3. O Firewall do Azure não aplica o SNAT ao tráfego porque o tráfego vai para um endereço IP privado. Ele encaminha o tráfego para a VM do aplicativo se as regras permitirem. Para obter mais informações, veja SNAT do Azure Firewall para intervalos de endereços IP privados. No entanto, se o tráfego atingir uma regra de aplicativo no firewall, a carga de trabalho verá o endereço IP de origem da instância de firewall específica que processou o pacote porque o Firewall do Azure faz proxy da conexão.

   • Endereço IP de origem se o tráfego for permitido por uma regra de rede do Firewall do Azure e for o endereço IP privado de uma das instâncias do Gateway de Aplicativo: 192.168.200.7
   • Endereço IP de origem se o tráfego for permitido por uma regra de aplicativo do Firewall do Azure e for o endereço IP privado de uma das instâncias do Firewall do Azure: 192.168.100.7
   • Endereço IP de destino: 192.168.1.4
   • X-Forwarded-For cabeçalho: ClientPIP

4. A VM responde à solicitação, que reverte os endereços IP de origem e de destino. O UDR para 192.168.200.0/24 captura o pacote enviado de volta ao Gateway de Aplicativo, redireciona-o para o Firewall do Azure e preserva o endereço IP de destino para o Gateway de Aplicativo.

   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.200.7

5. Novamente, o Firewall do Azure não aplica o SNAT ao tráfego porque ele vai para um endereço IP privado e encaminha o tráfego para o Gateway de Aplicativo.

   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.200.7

6. A instância do Application Gateway responde ao cliente.

   • Endereço IP de origem: AppGwPIP
   • Endereço IP de destino: ClientPIP

Os fluxos de saída das VMs para a Internet pública passam pelo Firewall do Azure, que o UDR para 0.0.0.0/0 define.

Como uma variação desse design, você pode configurar o DNAT privado no Firewall do Azure para que a carga de trabalho do aplicativo veja os endereços IP das instâncias do Firewall do Azure como a origem e nenhum UDRs seja necessário. O endereço IP de origem dos clientes do aplicativo já está preservado no cabeçalho HTTP X-Forwarded-For pelo Application Gateway. Portanto, se o Firewall do Azure aplicar DNAT ao tráfego, nenhuma informação será perdida. Para obter mais informações, consulte Filtrar o tráfego de entrada da Internet ou da intranet com o DNAT da política de Firewall do Azure usando o portal do Azure.

Firewall do Azure na frente do design do Gateway de Aplicativo

Esse design permite que o Firewall do Azure filtre e descarte o tráfego mal-intencionado antes que ele chegue ao Gateway de Aplicativo. Por exemplo, ele pode aplicar recursos como filtragem baseada em inteligência de ameaças. Outro benefício é que o aplicativo obtém o mesmo endereço IP público para tráfego de entrada e saída, independentemente do protocolo. Há três modos nos quais você pode teoricamente configurar o Firewall do Azure:

• Firewall do Azure com regras DNAT: Firewall do Azure apenas troca endereços IP na camada de endereço IP, mas não processa a carga útil. Como resultado, ele não altera nenhum dos cabeçalhos HTTP.

• Firewall do Azure com regras de aplicativo e inspeção TLS desabilitadas: Firewall do Azure pode examinar o cabeçalho SNI no TLS, mas não o descriptografa. Uma nova conexão TCP é criada do firewall para o próximo salto. Neste exemplo, é o Application Gateway.

• Firewall do Azure com regras de aplicativo e inspeção TLS habilitadas: Firewall do Azure examina o conteúdo do pacote e os descriptografa. Ele serve como um proxy HTTP e pode definir os cabeçalhos HTTP X-Forwarded-For para preservar o endereço IP. No entanto, apresenta um certificado autogerado ao cliente. Para aplicativos baseados na Internet, usar um certificado gerado automaticamente não é uma opção porque um aviso de segurança é enviado aos clientes do aplicativo a partir do navegador.

Nas duas primeiras opções, que são as únicas opções válidas para aplicativos baseados na Internet, o Firewall do Azure aplica o SNAT ao tráfego de entrada sem definir o cabeçalho X-Forwarded-For. Como resultado, o aplicativo não pode ver o endereço IP original das solicitações HTTP. Para tarefas administrativas, como solução de problemas, você pode obter o endereço IP real do cliente para uma conexão específica correlacionando-o com os logs SNAT do Firewall do Azure.

Os benefícios desse cenário são limitados porque, a menos que você use a inspeção TLS e apresente certificados autogerados aos clientes, o Firewall do Azure só vê o tráfego criptografado que vai para o Gateway de Aplicativo. Esse cenário normalmente só é possível para aplicativos internos. No entanto, pode haver cenários em que esse design seja preferido. Um cenário é se outro Firewall de Aplicativo Web existir anteriormente na rede (por exemplo, com o Azure Front Door), que pode capturar o IP de origem original no cabeçalho HTTP X-Forwarded-For. Você também pode preferir esse design se muitos endereços IP públicos forem necessários porque o Application Gateway oferece suporte a um único endereço IP.

Os fluxos de entrada HTTP(S) da Internet pública devem ter como destino o endereço IP público do Firewall do Azure. O Firewall do Azure DNAT e SNAT enviará os pacotes para o endereço IP privado do Gateway de Aplicativo. De outras redes virtuais do Azure ou redes locais, o tráfego HTTP(S) deve ser enviado para o endereço IP privado do Gateway de Aplicativo e encaminhado por meio do Firewall do Azure com UDRs. O roteamento de rede virtual padrão garante que o tráfego de retorno das VMs do Azure retorne ao Gateway de Aplicativo e do Gateway de Aplicativo ao Firewall do Azure se as regras DNAT forem usadas. Para tráfego local ou do Azure, use UDRs na sub-rede do Gateway de Aplicativo. Para obter mais informações, consulte o passo a passo do pacote mais adiante neste artigo. Todo o tráfego de saída das VMs do Azure para a Internet é enviado através do Firewall do Azure por UDRs.

A tabela a seguir resume os fluxos de tráfego para esse cenário.

Fluxo	Passa pelo Application Gateway/Web Application Firewall	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou no local para o Azure	Sim	Sim
Tráfego HTTP(S) do Azure para a Internet ou no local	Não	Sim
Tráfego não-HTTP(S) da Internet ou local para o Azure	Não	Sim
Tráfego não-HTTP(S) do Azure para a Internet ou no local	Não	Sim

Para tráfego HTTP(S) de entrada, o Firewall do Azure normalmente não descriptografa o tráfego. Em vez disso, ele aplica políticas IDPS que não exigem inspeção TLS, como filtragem baseada em endereço IP ou uso de cabeçalhos HTTP.

Arquitetura

O aplicativo não pode ver o endereço IP de origem original do tráfego da Web. O Firewall do Azure aplica o SNAT aos pacotes à medida que eles entram na rede virtual. Para evitar esse problema, use do Azure Front Door na frente do firewall. O Azure Front Door injeta o endereço IP do cliente como um cabeçalho HTTP antes de entrar na rede virtual do Azure.

Fluxo de trabalho

O tráfego de rede da Internet pública segue este fluxo:

1. O cliente inicia a conexão com o endereço IP público do Firewall do Azure.

   • Endereço IP de origem: ClientPIP
   • Endereço IP de destino: AzFWPIP

2. A solicitação para o endereço IP público do Firewall do Azure é distribuída para uma instância back-end do firewall, que é 192.168.100.7 neste exemplo. O Firewall do Azure aplica DNAT à porta Web, geralmente TCP 443, ao endereço IP privado da instância do Gateway de Aplicativo. O Firewall do Azure também aplica SNAT quando você executa DNAT. Para obter mais informações, consulte problemas conhecidos do Firewall do Azure.

   • Endereço IP de origem, que é o endereço IP privado da instância do Firewall do Azure: 192.168.100.7
   • Endereço IP de destino: 192.168.200.4

3. O Application Gateway estabelece uma nova sessão entre a instância que lida com a conexão e um dos servidores back-end. O endereço IP original do cliente não está no pacote.

   • Endereço IP de origem, que é o endereço IP privado da instância do Application Gateway: 192.168.200.7
   • Endereço IP de destino: 192.168.1.4
   • X-Forwarded-For cabeçalho: 192.168.100.7

4. A VM responde ao Application Gateway, que reverte os endereços IP de origem e de destino:

   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.200.7

5. O Gateway de Aplicativo responde ao endereço IP de origem SNAT da instância do Firewall do Azure. O Firewall do Azure vê o endereço IP interno do Gateway de Aplicativo, .4, como o endereço IP de origem, mesmo que a conexão venha de uma instância específica do Gateway de Aplicativo, como .7.

   • Endereço IP de origem: 192.168.200.4
   • Endereço IP de destino: 192.168.100.7

6. O Firewall do Azure desfaz SNAT e DNAT e responde ao cliente.

   • Endereço IP de origem: AzFwPIP
   • Endereço IP de destino: ClientPIP

O Application Gateway precisa de um endereço IP público para que a Microsoft possa gerenciá-lo, mesmo que não tenha ouvintes configurados para aplicativos.

Observação

Uma rota padrão para 0.0.0.0/0 na sub-rede do Gateway de Aplicativo que aponta para o Firewall do Azure não é suportada porque quebra o tráfego do plano de controle que o Gateway de Aplicativo requer para funcionar corretamente.

Clientes locais

Todos os designs anteriores mostram clientes de aplicativos de entrada da Internet pública. As redes locais também acessam aplicativos. A maioria das informações anteriores e fluxos de tráfego são os mesmos que para clientes de Internet, mas existem algumas diferenças notáveis:

• Um gateway VPN ou gateway de Rota Expressa fica na frente do Firewall do Azure ou do Gateway de Aplicativo.

• O Web Application Firewall usa o endereço IP privado do Application Gateway.

• O Firewall do Azure não oferece suporte a DNAT para endereços IP privados, portanto, você deve usar UDRs para enviar tráfego de entrada para o Firewall do Azure a partir dos gateways VPN ou ExpressRoute.

• Certifique-se de verificar as advertências em torno de encapsulamento forçado para do Gateway de Aplicativo e para do Firewall do Azure. Mesmo que sua carga de trabalho não precise de conectividade de saída com a Internet pública, você não pode injetar uma rota padrão, como 0.0.0.0/0 para o Application Gateway, que aponta para a rede local porque interrompe o tráfego de controle. Para o Application Gateway, a rota padrão precisa apontar para a Internet pública.

Arquitetura

O diagrama a seguir mostra o design paralelo do Gateway de Aplicativo e do Firewall do Azure. Os clientes de aplicativos vêm de uma rede local conectada ao Azure por VPN ou Rota Expressa:

Mesmo que todos os clientes estejam localizados no local ou no Azure, o Gateway de Aplicativo e o Firewall do Azure precisam ter endereços IP públicos. Esses endereços IP públicos permitem que a Microsoft gerencie os serviços.

Topologia hub-and-spoke

Os designs neste artigo se aplicam a uma topologia de hub-and-spoke. Recursos compartilhados em uma rede virtual de hub central se conectam a aplicativos em redes virtuais spoke separadas por meio de emparelhamentos de rede virtual.

Arquitetura

• O Firewall do Azure é implantado na rede virtual do hub central. O diagrama anterior mostra como implantar o Application Gateway no hub. As equipes de aplicativos geralmente gerenciam componentes como gateways de aplicativos ou gateways de gerenciamento de API. Nesse cenário, esses componentes são implantados nas redes virtuais faladas.

• Preste especial atenção aos UDRs nas redes faladas. Quando um servidor de aplicativos em um spoke recebe tráfego de uma instância específica do Firewall do Azure, como o endereço IP 192.168.100.7 nos exemplos anteriores, ele deve enviar o tráfego de retorno de volta para a mesma instância. Se um UDR no spoke definir o próximo salto de tráfego endereçado ao hub para o endereço IP do Firewall do Azure (192.168.100.4 nos diagramas anteriores), os pacotes de retorno podem acabar em uma instância diferente do Firewall do Azure. Esta situação provoca um encaminhamento assimétrico. Se tiver UDRs nas redes virtuais faladas, certifique-se de que envia tráfego para serviços partilhados no hub através da Firewall do Azure. Essas UDRs não incluem o prefixo da sub-rede do Firewall do Azure.

• A recomendação anterior aplica-se igualmente à sub-rede do Application Gateway e a quaisquer outros NVAs ou proxies reversos que possam ser implantados na rede virtual do hub.

• Não é possível definir o próximo salto para as sub-redes do Gateway de Aplicativo ou do Firewall do Azure por meio de rotas estáticas com um tipo de Virtual Networkde salto seguinte. Este tipo de salto seguinte só é válido na rede virtual local e não entre emparelhamentos de rede virtual. Para obter mais informações sobre UDRs e tipos de próximo salto, consulte Roteamento de tráfego de rede virtual.

Roteamento assimétrico

O diagrama a seguir mostra como um spoke envia o tráfego SNAT de volta para o balanceador de carga do Azure do Firewall do Azure. Essa configuração causa roteamento assimétrico.

Para resolver esse problema, defina UDRs no spoke sem a sub-rede do Firewall do Azure e apenas com as sub-redes onde os serviços compartilhados estão localizados. No diagrama anterior, o UDR correto no falado deve conter apenas 192.168.1.0/24. Ele não deve conter todo o intervalo 192.168.0.0/16, que está marcado em vermelho.

Integração com outros produtos do Azure

Você pode integrar o Firewall do Azure e o Gateway de Aplicativo com outros produtos e serviços do Azure.

Gateway de gerenciamento de API

Integre serviços de proxy reverso, como API Management gateway, nos designs anteriores para fornecer funcionalidades como limitação de API ou proxy de autenticação. A integração do gateway de gerenciamento de API não afeta significativamente os projetos. A principal diferença é que, em vez do proxy reverso único do Application Gateway, há dois proxies reversos encadeados um atrás do outro.

Para obter mais informações, consulte o guia de design de para integrar o Gerenciamento de API e o Application Gateway em um de rede virtual e o padrão de aplicativo gateways de API para microsserviços.

Azure Kubernetes Service (AKS)

Para cargas de trabalho executadas em um cluster AKS, você pode implantar o Application Gateway independentemente do cluster. Ou você pode integrá-lo ao cluster AKS usando o Application Gateway Ingress Controller. Quando você configura objetos específicos nos níveis do Kubernetes, como serviços e ingressos, o Application Gateway se adapta automaticamente sem precisar de etapas manuais extras.

O Firewall do Azure desempenha um papel importante na segurança do cluster AKS. Ele fornece a funcionalidade necessária para filtrar o tráfego de saída do cluster AKS com base no FQDN, não apenas no endereço IP. Para obter mais informações, consulte Limitar o tráfego de rede com o Firewall do Azure no AKS.

Quando você combina o Gateway de Aplicativo e o Firewall do Azure para proteger um cluster AKS, é melhor usar a opção de design paralelo. O Application Gateway com Web Application Firewall processa solicitações de conexão de entrada para aplicativos Web no cluster. O Firewall do Azure permite apenas conexões de saída permitidas explicitamente. Para obter mais informações sobre a opção de design paralelo, consulte Arquitetura de linha de base para um cluster AKS.

Azure Front Door (porta de entrada do Azure)

Azure Front Door tem funcionalidade que se sobrepõe ao Application Gateway em várias áreas. Ambos os serviços fornecem firewall de aplicativos Web, descarregamento de SSL e roteamento baseado em URL. No entanto, uma diferença fundamental é que, enquanto o Application Gateway opera em uma rede virtual, o Azure Front Door é um serviço global e descentralizado.

Às vezes, você pode simplificar o design de rede virtual substituindo o Gateway de Aplicativo por uma Porta de Entrada do Azure descentralizada. A maioria dos designs descritos neste artigo ainda se aplicam, exceto para a opção de colocar o Firewall do Azure na frente da Porta da Frente do Azure.

Um cenário é usar o Firewall do Azure na frente do Gateway de Aplicativo em sua rede virtual. O Application Gateway injeta o cabeçalho X-Forwarded-For com o endereço IP da instância de firewall, não com o endereço IP do cliente. Uma solução alternativa é usar o Azure Front Door na frente do firewall para injetar o endereço IP do cliente como um cabeçalho X-Forwarded-For antes que o tráfego entre na rede virtual e atinja o Firewall do Azure. Você também pode proteger sua origem com o Azure Private Link no Azure Front Door Premium.

Para obter mais informações sobre as diferenças entre os dois serviços ou quando usar cada um, consulte Perguntas frequentes sobre o Azure Front Door.

Outros NVA

Os produtos da Microsoft não são a única opção para implementar o firewall de aplicativos Web ou a funcionalidade de firewall de próxima geração no Azure. Uma ampla gama de parceiros da Microsoft fornece NVAs. Os conceitos e designs são essencialmente os mesmos deste artigo, mas há algumas considerações importantes:

• NVAs de parceiros para firewalls de próxima geração podem fornecer mais controle e flexibilidade para configurações NAT que o Firewall do Azure não suporta. Os exemplos incluem DNAT do local ou DNAT da Internet sem SNAT.

• Os NVAs gerenciados pelo Azure, como o Gateway de Aplicativo e o Firewall do Azure, reduzem a complexidade, em comparação com os NVAs em que os usuários precisam lidar com escalabilidade e resiliência em muitos dispositivos.

• Ao usar NVAs no Azure, use ativo-ativo e o dimensionamento automático configurações para que esses dispositivos não sejam um gargalo para aplicativos executados na rede virtual.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• Jose Moreno - Brasil | Engenheiro de Clientes Principal

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos

Saiba mais sobre as tecnologias de componentes:

• O que é o Application Gateway?
• O que é o Firewall do Azure?
• O que é o Azure Front Door?
• AKS
• O que é Rede Virtual?
• O que é Web Application Firewall?
• Arquitetura de linha de base para um cluster AKS

Recursos relacionados

Explore arquiteturas relacionadas:

• Implementar uma rede híbrida segura
• Aplicações Web geridas de forma segura
• software multilocatário como um serviço no Azure
• implantação corporativa usando o Ambiente do Serviço de Aplicativo
• Implantação corporativa de alta disponibilidade usando o Ambiente do Serviço de Aplicativo