Firewall do Azure e Gateway de Aplicativo para redes virtuais

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 para os pontos de extremidade que seu aplicativo requer. Este artigo descreve Rede Virtual do Azure serviços de segurança, como a Proteção contra DDoS do Azure, o Firewall do Azure e o Gateway de Aplicativo do Azure. Ele também descreve quando usar cada serviço e opções de design de rede que as combinam.

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

• do Firewall do Azure é um firewall gerenciado de última geração que fornece recursos de nat (conversão de endereços de rede). O Firewall do Azure filtra pacotes com base em endereços IP e portas TCP (Protocolo de Controle de Transmissão) ou UDP (User Datagram Protocol). Ele pode filtrar o tráfego usando atributos baseados em aplicativo, como HTTP(S) e SQL. O Firewall do Azure também aplica a inteligência contra 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.

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

• Gateway de Aplicativo é um balanceador de carga de tráfego da Web gerenciado e proxy reverso completo HTTP(S) que pode executar criptografia e descriptografia do SSL (Secure Socket Layer). O Gateway de Aplicativo 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 do Aplicativo Web do Azure para inspecionar o tráfego da Web e detectar ataques na camada HTTP. Para obter mais informações, consulte documentação do Gateway de Aplicativo.

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

Esses serviços do Azure se complementam. Dependendo de suas necessidades, o uso de um serviço pode atender melhor às suas cargas de trabalho. No entanto, você pode usar esses serviços juntos para ajudar a fornecer a 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 aplicativo.

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

Fluxo do aplicativo	Pode ser filtrado pelo Firewall do Azure	Pode ser filtrado pelo Firewall do Aplicativo Web no Gateway de Aplicativo
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 necessários. 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 designs adequados para cenários menos comuns:

• Firewall do Azure: Use esse 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: Use esse design quando apenas os aplicativos Web estiverem na rede virtual e NSGs (grupos de segurança de rede) 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 Gateway de Aplicativo geralmente não é recomendado, portanto, ele não está incluído no fluxograma anterior.

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

• Gateway de Aplicativo em frente ao Firewall do Azure: Use esse design quando quiser que o Firewall do Azure inspecione todo o tráfego, o Firewall do 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 do TLS, esse design também dá suporte ao cenário de SSL de ponta a ponta.

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

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

• clientes de aplicativos locais.
• redes hub-and-spoke.
• implementações de do AKS (Serviço de Kubernetes do Azure).

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 NVAs (dispositivos virtuais de rede) não microsoft (NVAs).

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 do Aplicativo Web, você poderá usar o design somente do Firewall do Azure. O design neste exemplo é simples, mas você pode examinar o fluxo de pacotes para entender melhor os designs mais complexos. Nesse 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 do local 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.

Flow	Passa pelo Gateway de Aplicativo/Firewall do Aplicativo Web	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou local para o Azure	Não aplicável	Sim
Tráfego HTTP(S) do Azure para a Internet ou local	Não aplicável	Sim
Tráfego não HTTP(S) da Internet ou local para o Azure	Não aplicável	Sim
Tráfego não HTTP(S) do Azure para a Internet ou local	Não aplicável	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 FQDN (nome de domínio totalmente qualificado). 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 do TLS:

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

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

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

• Neste exemplo, o Firewall do Azure implanta automaticamente várias instâncias com o endereço IP de 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 for proveniente de uma VPN (rede virtual privada) local ou gateway de do Azure ExpressRoute 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 pressupõe que o endereço IP da instância está 192.168.100.7.

Workflow

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 de back-end do firewall, que é 192.168.100.7 neste exemplo. A regra DNAT (Conversão de Endereços de Rede de Destino) Firewall do Azure converte o endereço IP de destino para o endereço IP do aplicativo dentro da rede virtual. O Firewall do Azure também implementa SNAT (conversão de endereços de rede de origem) 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, o que inverte os endereços IP de origem e de destino. O fluxo de entrada não requer uma UDR porque o IP de origem é o endereço IP do Firewall do Azure. A UDR no diagrama de 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 Gateway de Aplicativo

Esse 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.

A principal diferença do design anterior somente do Firewall do Azure é que o Gateway de Aplicativo 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 Gateway de Aplicativo interrompe a sessão da Web do cliente e estabelece uma sessão separada com um de seus servidores de 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 local usam o endereço IP privado do gateway. Retornar o tráfego 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 internet de saída das VMs do Azure vão diretamente para a Internet.

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

Flow	Passa pelo Gateway de Aplicativo/Firewall do Aplicativo Web	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou local para o Azure	Sim	Não aplicável
Tráfego HTTP(S) do Azure para a Internet ou local	Não	Não aplicável
Tráfego não HTTP(S) da Internet ou local para o Azure	Não	Não aplicável
Tráfego não HTTP(S) do Azure para a Internet ou local	Não	Não aplicável

Arquitetura

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

Workflow

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

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

2. A solicitação para o endereço IP público do Gateway de Aplicativo é distribuída para uma instância de back-end do gateway, que é 192.168.200.7 neste exemplo. A instância do Gateway de Aplicativo 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 Gateway de Aplicativo como o endereço IP de origem. O Gateway de Aplicativo 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 Gateway de Aplicativo: 192.168.200.7
   • Endereço IP de destino: 192.168.1.4
   • cabeçalho X-Forwarded-For: ClientPIP

3. A VM responde à solicitação do aplicativo e inverte os endereços IP de origem e de destino. A VM pode alcançar o Gateway de Aplicativo, portanto, ela não precisa de uma UDR.

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

4. A instância do Gateway de Aplicativo responde ao cliente.

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

O Gateway de Aplicativo 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 à localização geográfica ou para registro em log. Para obter mais informações, consulte Como um gateway de aplicativo funciona.

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

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

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 web e não web na rede virtual. O Firewall do Aplicativo Web no Gateway de Aplicativo 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 abrange 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 Gateway de Aplicativo. As conexões HTTP(S) do Azure ou local devem ser enviadas para seu endereço IP privado. O roteamento de rede virtual padrão envia os pacotes do Gateway de Aplicativo para as VMs de destino e das VMs de destino de volta para o Gateway de Aplicativo. 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 deverá ter como destino o endereço IP público do Firewall do Azure se ele vier da Internet pública. O tráfego deverá ser enviado por meio do Firewall do Azure por UDRs se ele 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.

Flow	Passa pelo Gateway de Aplicativo/Firewall do Aplicativo Web	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou local para o Azure	Sim	Não
Tráfego HTTP(S) do Azure para a Internet ou 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 local	Não	Sim

Esse design fornece filtragem de saída muito mais granular do que usar apenas NSGs. Por exemplo, se os aplicativos precisarem de conectividade com uma conta específica do Armazenamento do Azure, você poderá usar filtros baseados em FQDN. Com filtros baseados em FQDN, os aplicativos não enviam dados para contas de armazenamento não autorizadas. Se você usar apenas NSGs, não poderá impedir esse cenário. Esse design geralmente é 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 do 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 de back-end ou obter atualizações do sistema operacional.

As etapas de fluxo de pacote para cada serviço são as mesmas das opções de design autônomas 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 se concentra na comparação com as outras opções de design. Nesta topologia, o tráfego da Web de entrada passa pelo Firewall do Azure e pelo Firewall do Aplicativo Web. O Firewall do Aplicativo Web fornece proteção na camada do aplicativo Web. O Firewall do Azure serve como um ponto de controle e registro em log central e inspeciona o tráfego entre o Gateway de Aplicativo e os servidores de back-end. Nesse design, o Gateway de Aplicativo e o Firewall do Azure não ficam em paralelo, mas ficam um na frente do outro.

Com o Firewall do Azure Premium, esse design pode dar suporte a cenários de ponta a ponta, em que o Firewall do Azure aplica a 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 à localização geográfica ou para registro em log. 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 um gateway de aplicativo funciona.

As conexões HTTP(S) de entrada da Internet precisam ser enviadas para o endereço IP público do Gateway de Aplicativo. As conexões HTTP(S) do Azure ou local devem ser enviadas para seu endereço IP privado. No Gateway de Aplicativo, as UDRs garantem que os pacotes sejam roteado 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 deverá ter como destino o endereço IP público do Firewall do Azure se ele vier da Internet pública. O tráfego deverá ser enviado por meio do Firewall do Azure por UDRs se ele 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 aspecto importante desse design é que o Firewall do Azure Premium 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 IDPS para tráfego de entrada. Como resultado, recomendamos que você modifique os prefixos privados do IDPS na política de Firewall do Azure. Essa modificação garante que a sub-rede do Gateway de Aplicativo não seja considerada uma origem interna, o que permite que assinaturas IDPS de entrada e saída sejam aplicadas ao tráfego. Você pode encontrar mais informações sobre as instruções de regra IDPS do Firewall do Azure e prefixos ip privados para IDPS em regras do IDPS do Firewall do Azure.

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

Flow	Passa pelo Gateway de Aplicativo/Firewall do Aplicativo Web	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou local para o Azure	Sim	Sim
Tráfego HTTP(S) do Azure para a Internet ou 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 local	Não	Sim

Para o tráfego da Web do local ou da Internet para o Azure, o Firewall do Azure inspeciona os fluxos que o Firewall do Aplicativo Web permite. Dependendo se o Gateway de Aplicativo criptografa o tráfego de back-end, que é o tráfego do Gateway de Aplicativo 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 de criptografia TLS de ponta a ponta, e o Firewall do Azure recebe tráfego criptografado. O Firewall standard do Azure ainda pode aplicar regras de inspeção, como filtragem de camada 3 e camada 4 em regras de rede ou filtragem de FQDN em regras de aplicativo, usando o cabeçalho SNI (Indicação de Nome do Servidor TLS). o Firewall do Azure Premium fornece visibilidade mais profunda com a inspeção do 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 limpo. A inspeção do 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, ela precisa da resolução de nomes para o FQDN especificado no cabeçalho host. Essa resolução de nomes pode ser executada usando zonas privadas DNS do Azure e o padrão configurações de DNS do Firewall do Azure. Ele também pode ser obtido com servidores DNS personalizados que precisam ser configurados nas configurações do Firewall do Azure. Se você não tiver acesso administrativo à rede virtual em que 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 não HTTP(S) de entrada e qualquer tráfego de saída, o Firewall do Azure fornece inspeção IDPS e inspeção de TLS quando adequado. Ele também fornece filtragem baseada em FQDN nas regras de rede com base no DNS.

Workflow

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 Gateway de Aplicativo.

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

2. A solicitação para o endereço IP público do Gateway de Aplicativo é distribuída para uma instância de back-end do gateway, que é 192.168.200.7 neste exemplo. A instância do Gateway de Aplicativo interrompe a conexão do cliente e estabelece uma nova conexão com um dos back-ends. A UDR a ser 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 Gateway de Aplicativo: 192.168.200.7
   • Endereço IP de destino: 192.168.1.4
   • cabeçalho X-Forwarded-For: ClientPIP

3. O Firewall do Azure não aplica 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, confira Intervalos de endereços IP privados do SNAT do Firewall do Azure. 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 proxies 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
   • cabeçalho X-Forwarded-For: ClientPIP

4. A VM responde à solicitação, o que inverte os endereços IP de origem e de destino. A 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 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 Gateway de Aplicativo 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 a 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 nenhuma UDR seja necessária. O endereço IP de origem dos clientes de aplicativo já está preservado no cabeçalho HTTP X-Forwarded-For pelo Gateway de Aplicativo. 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 de chegar ao Gateway de Aplicativo. Por exemplo, ele pode aplicar recursos como filtragem baseada em inteligência contra ameaças. Outro benefício é que o aplicativo obtém o mesmo endereço IP público para tráfego de entrada e de saída, independentemente do protocolo. Há três modos nos quais você pode teoricamente configurar o Firewall do Azure:

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

• Firewall do Azure com regras de aplicativo e inspeção TLS desabilitada: 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 Gateway de Aplicativo.

• Firewall do Azure com regras de aplicativo e inspeção de TLS habilitadas: Firewall do Azure examina o conteúdo do pacote e as 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, ele apresenta um certificado autogerado para o cliente. Para aplicativos baseados na Internet, usar um certificado autogerenciado não é uma opção porque um aviso de segurança é enviado aos clientes do aplicativo 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 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 do cliente real 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 autogerenciados para os clientes, o Firewall do Azure vê apenas o tráfego criptografado que vai para o Gateway de Aplicativo. Normalmente, esse cenário só é possível para aplicativos internos. No entanto, pode haver cenários em que esse design é preferencial. Um cenário é se outro Firewall de Aplicativo Web existir anteriormente na rede (por exemplo, com do 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 Gateway de Aplicativo dá 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 usará DNAT e SNAT nos 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 retornado das VMs do Azure volte para o Gateway de Aplicativo e do Gateway de Aplicativo para o 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 por meio do Firewall do Azure por UDRs.

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

Flow	Passa pelo Gateway de Aplicativo/Firewall do Aplicativo Web	Passa pelo Firewall do Azure
Tráfego HTTP(S) da Internet ou local para o Azure	Sim	Sim
Tráfego HTTP(S) do Azure para a Internet ou 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 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, 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 conforme 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.

Workflow

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 de back-end do firewall, que é 192.168.100.7 neste exemplo. O Firewall do Azure aplica o 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 o SNAT quando você executa o 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 Gateway de Aplicativo estabelece uma nova sessão entre a instância que manipula a conexão e um dos servidores de 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 Gateway de Aplicativo: 192.168.200.7
   • Endereço IP de destino: 192.168.1.4
   • cabeçalho X-Forwarded-For: 192.168.100.7

4. A VM responde ao Gateway de Aplicativo, que inverte 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 Gateway de Aplicativo precisa de um endereço IP público para que a Microsoft possa gerenciá-lo, mesmo que não tenha ouvintes configurados para aplicativos.

Clientes locais

Os designs anteriores mostram todos os clientes de aplicativo de entrada da Internet pública. As redes locais também acessam aplicativos. A maioria das informações e fluxos de tráfego anteriores são iguais aos dos clientes da Internet, mas há algumas diferenças notáveis:

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

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

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

• Verifique as limitações em torno de de túnel forçado para 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 poderá injetar uma rota padrão como 0.0.0.0/0 para o Gateway de Aplicativo que aponta para a rede local porque ela interrompe o tráfego de controle. Para o Gateway de Aplicativo, 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 aplicativo vêm de uma rede local conectada ao Azure por VPN ou ExpressRoute:

Mesmo que todos os clientes estejam localizados localmente 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-spoke

Os designs neste artigo se aplicam a uma topologia de hub-and-spoke. Os recursos compartilhados em uma rede virtual do 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 Gateway de Aplicativo no hub. As equipes de aplicativos geralmente gerenciam componentes como Gateways de Aplicativo ou gateways de Gerenciamento de API. Nesse cenário, esses componentes são implantados nas redes virtuais spoke.

• Preste atenção especial às UDRs nas redes spoke. 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 uma 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 poderão acabar em uma instância diferente do Firewall do Azure. Essa situação causa roteamento assimétrico. Se você tiver UDRs nas redes virtuais spoke, envie tráfego para serviços compartilhados no hub por meio do Firewall do Azure. Essas UDRs não incluem o prefixo da sub-rede do Firewall do Azure.

• A recomendação anterior se aplica igualmente à sub-rede do Gateway de Aplicativo 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 próximo salto de Virtual Network. Esse tipo de próximo salto só é válido na rede virtual local e não em 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 em que os serviços compartilhados estão localizados. No diagrama anterior, a UDR correta no spoke 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 a outros produtos e serviços do Azure.

Gateway de Gerenciamento de API

Integre serviços de proxy reverso como gateway de de Gerenciamento de API 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 designs. A principal diferença é que, em vez do proxy reverso único do Gateway de Aplicativo, há dois proxies inversos encadeados entre si.

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

AKS

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

O Firewall do Azure desempenha um papel importante na segurança do cluster do AKS. Ele fornece a funcionalidade necessária para filtrar o tráfego de saída do cluster do 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 do AKS, é melhor usar a opção de design paralelo. O Gateway de Aplicativo com o Firewall do Aplicativo Web processa solicitações de conexão de entrada para aplicativos Web no cluster. O Firewall do Azure permite apenas conexões de saída explicitamente permitidas. Para obter mais informações sobre a opção de design paralelo, consulte arquitetura de linha de base para um cluster do AKS.

Azure Front Door

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

Às vezes, você pode simplificar o design de rede virtual substituindo o Gateway de Aplicativo por um Azure Front Door descentralizado. A maioria dos designs descritos neste artigo ainda se aplicam, exceto pela opção de colocar o Firewall do Azure na frente do Azure Front Door.

Um cenário é usar o Firewall do Azure na frente do Gateway de Aplicativo em sua rede virtual. O Gateway de Aplicativo injeta o cabeçalho X-Forwarded-For com o endereço IP da instância de firewall, não 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 Link Privado do Azure no Azure Front Door Premium.

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

Outros NVAs

Os produtos da Microsoft não são a única opção para implementar o firewall do aplicativo Web ou a funcionalidade de firewall de última 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 parceiro para firewall de última geração podem fornecer mais controle e flexibilidade para configurações nat que o Firewall do Azure não dá suporte. Exemplos incluem DNAT do local ou DNAT da Internet sem SNAT.

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

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

Contribuintes

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

• José Moreno | Engenheiro de cliente principal

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

Saiba mais sobre as tecnologias de componente:

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

Recursos relacionados

Explore arquiteturas relacionadas:

• Implementar uma rede híbrida segura
• aplicativos Web gerenciados com segurança
• implantação empresarial de alta disponibilidade usando o Ambiente do Serviço de Aplicativo
• implantação do Enterprise usando o Ambiente do Serviço de Aplicativo