Firewall e Gateway de Aplicativo para redes virtuais

Para proteger as cargas de trabalho de aplicativos do Azure, usamos, nos próprios aplicativos, medidas de proteção como autenticação e criptografia. Também podemos adicionar camadas de segurança às redes de máquinas virtuais (VNets) que hospedam os aplicativos. Essas camadas de segurança protegem os fluxos de entrada do aplicativo contra a utilização não intencional. Eles também limitam os fluxos de saída para a Internet apenas aos pontos de extremidade exigidos pelo seu aplicativo. Este artigo descreve serviços de segurança da Rede Virtual do Azure como a Proteção contra DDoS do Azure, o Firewall do Azure e Gateway de Aplicativo do Azure, quando usar cada um deles e as opções de design de rede que combinam ambos.

• A Proteção contra DDoS do Azure, combinada com as práticas recomendadas de design de aplicativos, fornece recursos aprimorados de mitigação de DDoS para fornecer mais defesa contra ataques de DDoS. Você deve habilitar a Proteção contra DDOS do Azure em qualquer rede virtual do perímetro.
• O Firewall do Azure é um firewall de última geração gerenciado que oferece NAT (conversão de endereços de rede). O Firewall do Azure baseia a filtragem de pacotes em endereços IP (Protocolo da Internet) e portas TCP/UDP (Protocolo de Controle de Transmissão e Protocolo de Datagrama do Usuário), ou em atributos HTTP(S) ou SQL baseados em aplicativo. O Firewall do Azure também aplica a inteligência contra ameaças da Microsoft para identificar endereços IP mal-intencionados. Para obter mais informações, confira a Documentação do Firewall do Azure.
• O Firewall do Azure Premium inclui toda a funcionalidade do Firewall do Azure Standard e outros recursos, como inspeção de TLS e IDPS (Sistema de Detecção e Proteção contra Intrusões).
• O Gateway de Aplicativo do Azure é 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 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 para inspecionar o tráfego da Web e detectar ataques na camada HTTP. Para obter mais informações, consulte a documentação do Gateway de Aplicativo.
• O WAF (Firewall de Aplicativo Web do Azure) é uma adição opcional do Gateway de Aplicativo do Azure. Ele fornece inspeção de solicitações HTTP e impede ataques mal-intencionados na camada da Web, como injeção de SQL ou Cross-Site Scripting. Para obter mais informações, consulte a documentação do Firewall de Aplicativo Web.

Esses serviços do Azure são complementares. Uma ou outra pode ser a melhor para suas cargas de trabalho, ou você pode usá-las em conjunto para uma proteção ideal nas camadas de rede e de aplicativo. Use a árvore de decisão a seguir e os exemplos oferecidos neste artigo para determinar a melhor opção de segurança para a rede virtual do seu aplicativo.

O Firewall do Azure e o Gateway de Aplicativo do Azure usam tecnologias diferentes e oferecem suporte à segurança de diferentes fluxos:

Dependendo dos fluxos de rede exigidos por um aplicativo, o design pode diferir em cada aplicativo. O diagrama a seguir oferece uma árvore de decisão simplificada que ajuda a escolher a abordagem recomendada para um aplicativo. A decisão depende de o aplicativo ser publicado via HTTP(S) ou outro protocolo:

Este artigo aborda os designs amplamente recomendados do fluxograma e outros aplicáveis a cenários menos comuns:

• Firewall do Azure sozinho, quando não há 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 sozinho, quando apenas aplicativos Web estão na rede virtual e NSGs (grupos de segurança de rede) fornecem filtragem de saída suficiente. As funcionalidades fornecidas pelo Firewall do Azure podem impedir muitos cenários de ataque (como exfiltração de dados, IDPS e assim por diante). Devido a esse motivo, o cenário do Application Gateway sozinho normalmente não é recomendado e, portanto, não está documentado e não está no fluxograma acima.
• Firewall do Azure e Gateway de Aplicativo em paralelo, um dos designs mais comuns. Use essa combinação quando quiser que o Gateway de Aplicativo do Azure proteja aplicativos HTTP(S) contra ataques na Web e o Firewall do Azure para proteger todas as outras cargas de trabalho e filtrar o tráfego de saída.
• Gateway de Aplicativo na frente do Firewall do Azure, quando você deseja que o Firewall do Azure inspecione todo o tráfego, WAF para proteger o tráfego da Web e o aplicativo para identificar o endereço IP de origem do cliente. Com o Firewall do Azure Premium e a inspeção de TLS, esse design também oferece suporte ao cenário de SSL de ponta a ponta.
• Firewall do Azure na frente do Gateway de Aplicativo, quando você deseja que o Firewall do Azure inspecione e filtre o tráfego antes que ele alcance o Gateway de Aplicativo. Como o Firewall do Azure não vai descriptografar o tráfego HTTPS, a funcionalidade que ele está adicionando ao Gateway de Aplicativo é limitada. Esse cenário não está documentado no fluxograma acima.

Na última parte deste artigo, são descritas variações dos designs fundamentais anteriores. Essas variações incluem:

• Clientes com aplicativo local.
• Redes hub e spoke.
• Implementações do AKS (Serviço de Kubernetes do Azure).

Você pode adicionar outros serviços de proxy reverso, como um gateway de Gerenciamento de API ou um serviço Azure Front Door. Também é possível substituir os recursos do Azure por soluções de virtualização de redede terceiros.

Firewall do Azure somente

Se não houver na rede virtual nenhuma carga de trabalho baseada na Web que possa se beneficiar do WAF, você só poderá usar o Firewall do Azure. O design nesse caso é simples, mas o exame do fluxo de pacotes ajudará a entender designs mais complexos. Neste design, todo o tráfego de entrada é enviado para o Firewall do Azure por meio de rotas definidas pelo usuário (UDRs) para conexões de VNets locais ou outras do Azure. Ele é endereçado ao endereço IP público do Firewall do Azure para conexões da Internet pública, como mostra o diagrama abaixo. O tráfego de saída de VNets do Azure é enviado ao firewall por meio de UDRs, como mostra a caixa de diálogo abaixo.

A tabela a seguir resume os fluxos de tráfego para este cenário:

O Firewall do Azure não inspecionará o tráfego HTTP(S) de entrada. Mas ele será capaz de aplicar regras de camada 3 & , camada 4 e regras de aplicativo baseadas em FQDN. O Firewall do Azure inspecionará o tráfego HTTP(S) de saída, dependendo da camada de Firewall do Azure e se você configurar a inspeção de TLS:

• O Firewall do Azure Standard inspecionará apenas os atributos da Camada 3 & 4 dos pacotes nas 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 Agente do Usuário) e habilitar a inspeção de TLS para análise mais profunda de pacotes. O Firewall do Azure não equivale a um Firewall de Aplicativo Web. Se você tiver cargas de trabalho da Web na sua Rede Virtual, é altamente recomendável usar o WAF.

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

• O serviço Firewall do Azure implanta várias instâncias sob as cobertas, aqui com o endereço IP front-end 192.168.100.4 e endereços internos do intervalo 192.168.100.0/26. Essas instâncias individuais normalmente são invisíveis ao administrador do Azure. Mas perceber a diferença é útil em alguns casos, como ao solucionar problemas de rede.
• Se o tráfego vier de uma VPN (rede virtual privada) local ou de um gateway 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, por padrão, o firewall não fará nenhum NAT de Origem.

Arquitetura

O diagrama a seguir mostra o fluxo de tráfego supondo que o endereço IP da instância seja 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 IP público do Firewall do Azure é distribuída para uma instância de back-end do firewall, neste caso 192.168.100.7. A regra NAT (DNAT) de Destino do Firewall do Azure converte o endereço IP de destino no endereço IP do aplicativo dentro da rede virtual. O Firewall do Azure também executa SNATs (Source NATs) do pacote, se ele executar 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, revertendo os endereços IP de origem e de destino. O fluxo de entrada não requer uma UDR (rota definida pelo usuário), pois o IP de origem é o endereço IP do Firewall do Azure. A UDR no diagrama para 0.0.0.0/0 destina-se a 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. Por fim, o Firewall do Azure desfaz as operações de SNAT e DNAT e entrega a resposta ao cliente:
   • Endereço IP de origem: AzFwPIP
   • Endereço IP de destino: ClientPIP

Gateway de Aplicativo somente

Esse design aborda a situação em que há somente 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 em relação ao design anterior, com apenas o Firewall do Azure, é que o Gateway de Aplicativo não atua como dispositivo de roteamento com NAT. Ele se comporta como um proxy de aplicativo reverso completo. Ou seja, o Gateway de Aplicativo 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 precisam ser enviadas ao endereço IP público do Gateway de Aplicativo, a conexões do Azure ou locais relativas ao endereço IP privado do gateway. O tráfego de retorno das VMs do Azure seguirá o roteamento de VNet padrão de volta ao Gateway de Aplicativo (consulte a movimentação de pacotes abaixo para obter mais detalhes). 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:

Arquitetura

O exemplo de movimentação de pacotes a seguir mostra como um cliente acessa o aplicativo hospedado na VM usando a Internet pública.

Workflow

1. O cliente inicia a conexão ao endereço IP público do Gateway de Aplicativo do Azure:
   • Endereço IP de origem: ClientPIP
   • Endereço IP de destino: AppGwPIP
2. A solicitação para o IP público do Gateway de Aplicativo é distribuída para uma instância de back-end do gateway, neste caso 192.168.200.7. A instância do Gateway de Aplicativo que recebe a solicitação interrompe a conexão do cliente e estabelece uma nova, com um dos back-ends. O back-end identifica a instância do Gateway de Aplicativo como o endereço IP de origem. O Gateway de Aplicativo insere um cabeçalho X-Forwarded-For com endereço IP do cliente original.
   • Endereço IP de origem: 192.168.200.7 (o endereço IP privado da instância do Gateway de Aplicativo)
   • Endereço IP de destino: 192.168.1.4
   • Cabeçalho X-Forwarded-For: ClientPIP
3. A VM responde à solicitação do aplicativo, revertendo os endereços IP de origem e de destino. A VM já identifica como alcançar o Gateway de Aplicativo, portanto, 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. Por fim, 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 do Azure 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 o gateway de aplicativo.

• O endereço IP 192.168.200.7 é uma das instâncias que o Gateway de Aplicativo do Azure implanta de forma secreta, aqui com o endereço IP de front-end privado e interno 192.168.200.4. Essas instâncias individuais normalmente são invisíveis ao administrador do Azure. Mas perceber a diferença é útil em alguns casos, como ao solucionar problemas de rede.

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

Firewall e o Gateway de Aplicativo em paralelo

Pela simplicidade e a flexibilidade, executar o Gateway de Aplicativo e Firewall do Azure em paralelo geralmente é o melhor cenário.

Implemente esse design se houver uma combinação de cargas de trabalho Web e não Web na rede virtual. O WAF do Azure no Gateway de Aplicativo do Azure protege o tráfego de entrada para as cargas de trabalho da Web e o Firewall do Azure inspeciona o tráfego de entrada para os outros aplicativos. O Firewall do Azure abrange os fluxos de saída de ambos os tipos de carga de trabalho.

As conexões HTTP(S) de entrada da Internet precisam ser enviadas ao endereço IP público do Gateway de Aplicativo; as conexões HTTP(S) do Azure ou locais, ao seu endereço IP privado. O roteamento de VNet Standard envia os pacotes do Gateway de Aplicativo para as VMs de destino, e das VMs de destino de volta para o Gateway de Aplicativo (consulte a movimentação de pacotes abaixo para obter mais detalhes). Para conexões de entrada não HTTP(S), o tráfego deve ser destinado ao endereço IP público do Firewall do Azure (se vier da Internet pública) ou será enviado, por meio do Firewall do Azure, por UDRs (se vier de outras VNets do Azure ou redes locais). Todos os fluxos de saída de VMs do Azure serão encaminhados para o Firewall do Azure por UDRs.

A tabela a seguir resume os fluxos de tráfego para este cenário:

Esse design fornece filtragem de saída muito mais granular do que os NSGs. Por exemplo, se os aplicativos precisarem de conectividade com uma Conta de Armazenamento do Azure específica, você pode usar filtros baseados em FQDN (nome de domínio totalmente qualificado). Com filtros baseados em FQDN, os aplicativos não estão enviando dados para contas de armazenamento de invasores. Esse cenário não poderia ser impedido apenas com o uso de NSGs. Esse design geralmente é usado quando o tráfego de saída requer filtragem baseada em FQDN. Um exemplo de situação é limitação do tráfego de saída de um cluster dos Serviços de Kubernetes do Azure.

Arquiteturas

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

O diagrama a seguir ilustra o fluxo de tráfego para conexões de saída de 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 pacotes para cada serviço são as mesmas das opções de design autônomo anteriores.

Gateway de Aplicativo antes do Firewall

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 documento se concentrará na comparação com as outras opções de design. Nesta topologia, o tráfego de entrada da Web passa pelo Firewall do Azure e pelo WAF. O WAF fornece proteção na camada de aplicativo Web. O Firewall do Azure atua como um ponto de registro e controle central e inspeciona o tráfego entre o Gateway de Aplicativo e os servidores de back-end. O Gateway de Aplicativo e o Firewall do Azure não estão em paralelo, mas em sequência.

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

Esse design é apropriado para aplicativos que precisam identificar endereços IP de origem do cliente de entrada, por exemplo, para fornecer conteúdo específico de geolocalização ou para registro em log. O Gateway de Aplicativo na frente 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 o gateway de aplicativo.

As conexões HTTP(S) de entrada da Internet precisam ser enviadas ao endereço IP público do Gateway de Aplicativo; as conexões HTTP(S) do Azure ou locais, ao endereço IP privado. Em UDRs do Gateway de Aplicativo, certifique-se de que os pacotes sejam roteados por meio do Firewall do Azure (confira a movimentação de pacotes abaixo para obter mais detalhes). Para conexões de entrada não HTTP(S), o tráfego deve ser destinado ao endereço IP público do Firewall do Azure (se vier da Internet pública) ou será enviado, por meio do Firewall do Azure, por UDRs (se vier de outras VNets do Azure ou redes locais). Todos os fluxos de saída de VMs do Azure serão encaminhados para o Firewall do Azure por UDRs.

Uma observação importante desse design é que o Firewall Premium do Azure verá 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/16172.16.0.0/12 ou 100.64.0.0/10), o Firewall do Azure Premium tratará o tráfego do Gateway de Aplicativo como interno e não aplicará regras de IDPS para o tráfego de entrada. Você pode encontrar mais informações sobre direções de regra de IDPS do Firewall do Azure e prefixos IP privados para IDPS em Regras de IDPS do Firewall do Azure. Consequentemente, é recomendável modificar os prefixos privados do IDPS na política do Firewall do Azure para que a sub-rede do Gateway de Aplicativo não seja considerada uma fonte interna, para aplicar assinaturas IDPS de entrada e saída ao tráfego.

A tabela a seguir resume os fluxos de tráfego para este cenário:

No caso do tráfego da Web local ou da Internet para o Azure, o Firewall do Azure inspecionará os fluxos que o WAF já permitiu. Dependendo de o Gateway de Aplicativo criptografar o tráfego de back-end (do Gateway de Aplicativo para os servidores de aplicativos), poderá haver cenários diferentes:

1. O Gateway de Aplicativo criptografa o tráfego seguindo os princípios de confiança zero (criptografia TLS de ponta a ponta) e o Firewall do Azure recebe o tráfego criptografado. Ainda assim, o Azure Firewall Standard poderá aplicar regras de inspeção, como filtragem de camada 3 & camada 4 em regras de rede ou filtragem FQDN em regras de aplicativo usando o cabeçalho TLS Server Name Indication (SNI). O Firewall do Azure Premium fornece uma visibilidade mais profunda com inspeção de TLS, como a filtragem baseada em URL.
2. Se o Gateway de Aplicativo estiver enviando tráfego não criptografado aos servidores de aplicativos, o Firewall do Azure verá o tráfego de entrada em texto sem formatação. A inspeção TLS não é necessária no Firewall do Azure.
3. Se o IDPS estiver habilitado no Firewall do Azure, ele verificará se o cabeçalho do host HTTP corresponde ao IP de destino. Com essa finalidade, ele precisará de resolução de nomes para o FQDN especificado no cabeçalho de Host. Essa resolução de nomes pode ser obtida com Zonas Privadas do DNS do Azure e as configurações padrão de DNS do Firewall do Azure, com o uso do DNS do Azure. Também é possível obtê-las com servidores DNS personalizados, que precisam ser configurados nas definições do Firewall do Azure. (Para obter mais informações, consulte Configurações de DNS do Firewall do Azure.) Se não houver acesso administrativo à Rede Virtual onde o Firewall do Azure está implantado, o último método será a única possibilidade. Um exemplo são os Firewalls do Azure implantados em Hubs Protegidos de WAN Virtual.

Arquitetura

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

Workflow

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

1. O cliente inicia a conexão ao endereço IP público do Gateway de Aplicativo do Azure:
   • Endereço IP de origem: ClientPIP
   • Endereço IP de destino: AppGwPIP
2. A solicitação para o IP público do Gateway de Aplicativo é distribuída para uma instância de back-end do gateway, neste caso 192.168.200.7. A instância do Gateway de Aplicativo interrompe a conexão do cliente e estabelece uma nova, com um dos back-ends. A UDR para 192.168.1.0/24 na sub-rede do Gateway de Aplicativo encaminha o pacote para o Firewall do Azure, preservando o IP de destino para o aplicativo Web:
   • Endereço IP de origem: 192.168.200.7 (endereço IP privado da instância do Gateway de Aplicativo)
   • Endereço IP de destino: 192.168.1.4
   • Cabeçalho X-Forwarded-For: ClientPIP
3. O Firewall do Azure não executa SNAT no tráfego que se dirige a um endereço IP privado. Ele encaminha o tráfego para a VM do aplicativo, se as regras permitirem. Para obter mais informações, consulte 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, já que o Firewall do Azure fará proxy da conexão:
   • Endereço IP de origem se o tráfego for permitido por uma regra de rede do Firewall do Azure: 192.168.200.7 (o endereço IP privado de uma das instâncias do Gateway de Aplicativo).
   • Endereço IP de origem se o tráfego for permitido por uma regra de aplicativo do Firewall do Azure: 192.168.100.7 (o endereço IP privado de uma das instâncias do Firewall do Azure).
   • Endereço IP de destino: 192.168.1.4
   • Cabeçalho X-Forwarded-For: ClientPIP
4. A VM responde à solicitação, revertendo os endereços IP de origem e de destino. A UDR para 192.168.200.0/24 captura o pacote enviado de volta para o Gateway de Aplicativo e o redireciona para o Firewall do Azure, preservando, ao mesmo tempo, o IP de destino em direção ao 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 executa SNAT para o tráfego, pois ele se destina a um endereço IP privado, e o encaminha ao Gateway de Aplicativo.
   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.200.7
6. Por fim, 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, conforme definido pela UDR para 0.0.0.0/0.

Gateway de Aplicativo após o firewall

Esse design permite que o Firewall do Azure filtre e descarte o tráfego mal-intencionado antes que ele alcance o Gateway de Aplicativo. Por exemplo, ele pode aplicar recursos como filtragem de ameaças baseada em inteligência. Outro benefício é que o aplicativo obtém o mesmo endereço IP público para o tráfego de entrada e de saída, independentemente do protocolo. No entanto, o Firewall do Azure executa SNAT do tráfego de entrada, então o aplicativo não terá visibilidade para o endereço IP original das solicitações HTTP. De uma perspectiva de administração, por exemplo, para fins de solução de problemas, você pode obter o IP do cliente real para uma conexão específica correlacionando-o com os logs SNAT do Firewall do Azure.

O benefício nesse cenário é limitado, pois o Firewall do Azure verá apenas o tráfego criptografado que se dirige ao Gateway de Aplicativo. Pode haver cenários em que esse design seja preferencial. Um caso é se outro WAF estiver 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. Outro caso é a necessidade de vários endereços IP públicos.

Os fluxos de entrada HTTP(S) da Internet pública devem ter como destino o endereço IP público do Firewall do Azure, e o Firewall do Azure deverá executar DNAT (e SNAT) dos pacotes para o endereço IP privado do Gateway de Aplicativo. De outras redes locais ou VNets do Azure, o tráfego HTTP(S) deve ser enviado ao IP privado do Gateway de Aplicativo e encaminhado por meio do Firewall do Azure com UDRs. O roteamento de VNet Standard garantirá que o tráfego de retorno das VMs do Azure volte ao Gateway de Aplicativo e, se as regras DNAT tiverem sido usadas, vá do Gateway de Aplicativo para o Firewall do Azure. Para o tráfego do local ou de UDRs do Azure no Gateway de Aplicativo, deve ser usada uma sub-rede (consulte a movimentação de pacotes abaixo para obter mais detalhes). Todo o tráfego de saída das VMs do Azure para a Internet será enviado por meio do Firewall do Azure pelas UDRs.

A tabela a seguir resume os fluxos de tráfego para este cenário:

No caso do tráfego de entrada HTTP(S), o Firewall do Azure normalmente não o descriptografaria. Em vez disso, ele aplicaria políticas IDPS que não exigissem inspeção de TLS, como a filtragem baseada em IP ou o uso de cabeçalhos HTTP.

Arquitetura

O aplicativo não pode ver o endereço IP de origem do tráfego da Web; o Firewall do Azure executa SNATs dos pacotes à medida que eles entram na rede virtual. Para evitar esse problema, use o Azure Front Door na frente do firewall. O Azure Front Door injeta o endereço IP do cliente como 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 IP público do Firewall do Azure é distribuída para uma instância de back-end do firewall, neste caso 192.168.100.7. O Firewall do Azure executa DNAT da porta da Web, geralmente TCP 443, para o endereço IP privado da instância do Gateway de Aplicativo. O Firewall do Azure também executa SNAT ao fazer DNAT. Para obter mais informações, consulte Problemas conhecidos do Firewall do Azure:
   • Endereço IP de origem: 192.168.100.7 (endereço IP privado da instância do Firewall do Azure)
   • 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: 192.168.200.7 (o endereço IP privado da instância do Gateway de Aplicativo)
   • 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, revertendo 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. Mesmo que a conexão seja proveniente de uma instância específica do Gateway de Aplicativo, como .7, o Firewall do Azure vê o endereço IP interno do Gateway de Aplicativo .4 como o IP de origem:
   • Endereço IP de origem: 192.168.200.4
   • Endereço IP de destino: 192.168.100.7
6. Por fim, o Firewall do Azure desfaz o SNAT e o DNAT e responde ao cliente:
   • Endereço IP de origem: AzFwPIP
   • Endereço IP de destino: ClientPIP

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

Cientes locais

Todos os designs anteriores mostram clientes de aplicativos provenientes da Internet pública. As redes locais também acessam aplicativos. A maioria das informações e dos fluxos de tráfego anteriores são as mesmas dos clientes da Internet, mas há algumas diferenças importantes:

• Um gateway de VPN ou gateway de ExpressRoute fica na frente do Firewall do Azure ou do Gateway de Aplicativo.
• O WAF usa o endereço IP privado do Gateway de Aplicativo.
• O Firewall do Azure não oferece suporte a DNAT para endereços IP privados. Por isso, você deve usar UDRs para enviar tráfego de entrada ao Firewall do Azure dos gateways de VPN ou do ExpressRoute.
• Certifique-se de verificar as limitações em relação ao túnel forçado para o Gateway de Aplicativo do Azure e o Firewall do Azure. Mesmo que sua carga de trabalho não precise de conectividade de saída para a Internet pública, você não pode injetar uma rota padrão como 0.0.0.0/0 para o Gateway de Aplicativo que aponta para a rede local, ou interromperá o tráfego de controle. No caso do Gateway de Aplicativo do Azure, a rota padrão deve apontar para a Internet pública.

Arquitetura

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

Mesmo que todos os clientes atuem localmente ou no Azure, o Gateway de Aplicativo do Azure e o Firewall do Azure precisam ter endereços IP públicos. Os endereços IP públicos permitem à Microsoft gerenciar os serviços.

Topologia hub-spoke

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

Arquitetura

Considerações

Algumas considerações sobre essa topologia:

• O Firewall do Azure é implantado na rede virtual do hub central. O diagrama acima mostra a prática de implantar o Application Gateway no hub. No entanto, as equipes de aplicativos geralmente gerenciam componentes como Gateways de Aplicativo do Azure ou gateways de Gerenciamento de API do Azure. Neste caso, estes componentes são implantados nas redes virtuais spoke.
• Atente especialmente às UDRs nas redes spoke: quando um servidor de aplicativos em um spoke recebe o tráfego de uma instância específica do Firewall do Azure, como o endereço 192.168.100.7 nos exemplos anteriores, deve devolver o tráfego de retorno à 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 acima), os pacotes de retorno poderão ir para outra instância do Firewall do Azure, causando roteamento assimétrico. Certifique-se de que, se você tiver UDRs em VNets do spoke para enviar tráfego a serviços compartilhados no hub por meio do Firewall do Azure, essas UDRs não incluirão o prefixo da sub-rede do Firewall do Azure.
• A recomendação anterior aplica-se igualmente à sub-rede do Gateway de Aplicativo e a quaisquer outras Soluções de Virtualização de Rede ou a proxies reversos que possam ser implantados na VNet do hub.
• Você não pode 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 do próximo salto Virtual Network. Esse tipo de próximo salto só é válido na VNet local e não entre emparelhamentos de VNet. Para saber mais sobre rotas definidas pelo usuário 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 no qual ocorreu SNAT de volta ao ALB de um Firewall do Azure. Esta configuração causa roteamento assimétrico:

Para resolver esse problema, defina UDRs no spoke sem a sub-rede do Firewall do Azure, mas apenas com as sub-redes em que os serviços compartilhados estão localizados. No exemplo, a UDR correta no spoke deve conter apenas 192.168.1.0/24. Ela não deve conter o 192.168.0.0/16 inteiro, conforme marcado em vermelho.

Integração com outros serviços do Azure

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

Gateway de Gerenciamento de API

Integre serviços de proxy reverso, como o gateway de Gerenciamento de API, aos projetos anteriores para fornecer funcionalidade como limitação de API ou proxy de autenticação. A integração de um gateway de Gerenciamento de API não altera significativamente os designs. A principal diferença é que, em vez do proxy reverso único do Gateway de Aplicativo, há dois proxies reversos encadeados por trás um do outro.

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.

Serviço de Kubernetes do Azure

Para cargas de trabalho executadas em um cluster AKS, é possível implantar o Gateway de Aplicativo do Azure independentemente do cluster. Você também pode integrá-lo ao cluster AKS usando o Controlador de Entrada do Gateway de Aplicativo do Azure. Na configuração de determinados objetos nos níveis do Kubernetes (como serviços e entradas), o Gateway de Aplicativo se adapta automaticamente, sem necessidade de etapas manuais adicionais.

O Firewall do Azure tem papel importante na segurança do cluster do AKS. Ele oferece a funcionalidade necessária para filtrar o tráfego de saída do cluster AKS com base no FQDN, e não apenas no endereço IP. Para obter mais informações, confira Controlar o tráfego de saída para nós de cluster AKS.

Ao combinar o Gateway de Aplicativo e o Firewall do Azure para proteger um cluster AKS, é melhor usar a opção de design paralelo. O Gateway de Aplicativo com WAF processa solicitações de conexão de entrada para aplicativos Web no cluster. O Firewall do Azure aceita apenas conexões de saída explicitamente permitidas. Consulte Arquitetura de linha de base para um cluster do Serviço de Kubernetes do Azure (AKS) para obter um exemplo da opção de design paralelo.

Porta da frente do Azure

A funcionalidade Azure Front Door se sobrepõe parcialmente ao Gateway de Aplicativo do Azure. Por exemplo, os dois serviços oferecem firewall de aplicativo Web, descarregamento de SSL e roteamento baseado em URL. Uma diferença importante é que, embora o Gateway de Aplicativo do Azure esteja em uma rede virtual, o Azure Front Door é um serviço global e descentralizado.

Às vezes, é possível simplificar o design de rede virtual substituindo o Gateway de Aplicativo por um Azure Front Door descentralizado. A maioria dos designs descritos aqui permanece válida, exceto pela opção de colocar o Firewall do Azure na frente do Azure Front Door.

Um caso de uso interessante é usar o Firewall do Azure na frente do Gateway de Aplicativo na sua rede virtual. Como descrito anteriormente, o cabeçalho X-Forwarded-For injetado pelo Gateway de Aplicativo conterá o endereço IP da instância do 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 chegue ao Firewall do Azure. Uma segunda opção é proteger sua origem com o Private Link no Azure Front Door Premium.

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

Outras soluções de virtualização de rede

Os produtos Microsoft não são a única opção de implementação da funcionalidade de firewall de aplicativo Web ou firewall de última geração no Azure. Uma ampla variedade de parceiros da Microsoft fornece NVAs (soluções de virtualização de rede). Os conceitos e designs são essencialmente os mesmos descritos neste artigo, mas há algumas considerações importantes:

• NVAs de parceiros para firewalls de próxima geração podem oferecer mais controle e flexibilidade para configurações de NAT sem suporte por parte do Firewall do Azure. Os exemplos incluem DNAT do local ou da Internet sem SNAT.
• NVAs gerenciadas pelo Azure (como o Gateway de Aplicativo e o Firewall do Azure) reduzem a complexidade, em comparação com NVAs nas quais os usuários precisam lidar com escalabilidade e resiliência em vários dispositivos.
• Ao usar o NVAs no Azure, use configurações de ativo-ativo e dimensionamento automático, para que esses dispositivos não sejam um gargalo para aplicativos em execução na rede virtual.

Colaboradores

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

Autor principal:

• Jose Moreno | Engenheiro de Clientes Principal

Próximas etapas

Saiba mais sobre as tecnologias dos componentes:

• O que é o Gateway de Aplicativo do Azure?
• O que é o Firewall do Azure?
• O que é o Azure Front Door?
• Serviço de Kubernetes do Azure
• O que é a Rede Virtual do Azure?
• O que é o Firewall de Aplicativo Web do Azure?

Recursos relacionados

Explorar arquiteturas relacionadas:

• Implementar uma rede híbrida segura
• Aplicativos web gerenciados com segurança
• Proteger seu bot de canal do Microsoft Teams canal e seu aplicativo Web por trás de um firewall
• Portal da saúde do consumidor no Azure
• Considerações de segurança para aplicativos de IaaS altamente confidenciais no Azure
• SaaS multilocatário no Azure
• Implantação empresarial usando o Ambiente dos Serviços de Aplicativos
• Implantação empresarial de alta disponibilidade usando o Ambiente do Serviço de Aplicativo
• Arquitetura de linha de base de um cluster do AKS (Serviço de Kubernetes do Azure)