Firewall e Gateway de Aplicação para redes virtuais

Para proteger cargas de trabalho de aplicativos do Azure, você deve usar medidas de proteção, como autenticação e criptografia, nos próprios aplicativos. Você também pode adicionar camadas de segurança às redes virtuais (VNets) que hospedam os aplicativos. Essas camadas de segurança protegem os fluxos de entrada do aplicativo contra utilização 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 os serviços de segurança da Rede Virtual do Azure, como a Proteção contra DDoS do Azure, o Firewall do Azure e o Gateway de Aplicativo do Azure, quando usar cada serviço 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 DDoS. Você deve habilitar a Proteção DDOS do Azure em qualquer rede virtual de perímetro.
• O Firewall do Azure é um firewall gerenciado de última geração que oferece NAT (conversão de endereços de rede). O Firewall do Azure baseia a filtragem de pacotes em endereços IP e portas TCP/UDP (Transmission Control Protocol) e TCP/UDP (User Datagram Protocol) ou em atributos HTTP(S) ou SQL baseados em aplicativos. O Firewall do Azure também aplica informações sobre ameaças da Microsoft para identificar endereços IP mal-intencionados. Para obter mais informações, consulte a documentação do Firewall do Azure.
• O Firewall do Azure Premium inclui todas as funcionalidades do Firewall do Azure Standard e outros recursos, como inspeção TLS e IDPS (Sistema de Deteção e Proteção de Intrusão).
• O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego da Web gerenciado e proxy reverso completo HTTP(S) que pode fazer 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 Application Gateway também usa o Web Application Firewall para inspecionar o tráfego da Web e detetar ataques na camada HTTP. Para obter mais informações, consulte a documentação do Application Gateway.
• O Firewall de Aplicativo Web do Azure (WAF) é uma adição opcional ao Gateway de Aplicativo do Azure. Ele fornece inspeção de solicitações HTTP e evita ataques mal-intencionados na camada da Web, como injeção de SQL ou scripts entre sites. Para obter mais informações, consulte a documentação do Web Application Firewall.

Estes serviços do Azure são complementares. Um ou outro pode ser melhor para suas cargas de trabalho, ou você pode usá-los juntos para uma proteção ideal nas camadas de rede e aplicativo. Use a árvore de decisão a seguir e os exemplos 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 dão suporte à securitização de fluxos diferentes:

Dependendo dos fluxos de rede que um aplicativo exige, o design pode ser diferente por 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 se o aplicativo é publicado via HTTP(S) ou algum outro protocolo:

Este artigo abordará os designs amplamente recomendados do fluxograma e outros que são aplicáveis em cenários menos comuns:

• Firewall do Azure sozinho, quando não há aplicativos Web na rede virtual. Ele controlará o tráfego de entrada para os aplicativos e o tráfego de saída.
• Somente o Application Gateway, quando apenas aplicativos Web estão na rede virtual e os 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 isolado do Application Gateway 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, que é um dos designs mais comuns. Use essa combinação quando quiser que o Gateway de Aplicativo do Azure 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.
• Gateway de Aplicativo na frente do Firewall do Azure, quando você deseja que o Firewall do Azure inspecione todo o tráfego, o WAF para proteger o tráfego da Web e o aplicativo saiba o endereço IP de origem do cliente. Com a inspeção do Firewall do Azure Premium e TLS, esse design também oferece suporte ao cenário 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 chegue ao 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. Este cenário não está documentado no fluxograma acima.

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

• Clientes de aplicativos locais.
• Redes Hub e Spoke.
• Implementações do Serviço Kubernetes do Azure (AKS).

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

Apenas Firewall do Azure

Se não houver cargas de trabalho baseadas na Web na rede virtual que possam se beneficiar do WAF, você poderá usar somente o Firewall do Azure. O design, neste caso, é simples, mas rever o 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 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, como mostra o diagrama abaixo. O tráfego de saída das VNets do Azure é enviado para o Firewall por meio de UDRs, conforme mostrado na caixa de diálogo abaixo.

A tabela a seguir resume os fluxos de tráfego para esse 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 ou 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 do Firewall do Azure e se você configurar a inspeção TLS:

• O Firewall do Azure Standard inspecionará apenas os atributos da camada 3 & camada 4 dos pacotes nas regras de rede e o cabeçalho HTTP do Host nas regras do aplicativo.
• O Firewall Premium do Azure adiciona recursos como inspecionar outros cabeçalhos HTTP (como o User-Agent) e habilitar a inspeção TLS para uma análise mais profunda de pacotes. O Firewall do Azure não é equivalente a um Firewall de Aplicativo Web. Se você tiver cargas de trabalho da Web em sua rede virtual, o uso do WAF é altamente recomendado.

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, você teria várias instâncias de aplicativos atrá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 a UDR.

• O serviço de 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 são normalmente invisíveis para o administrador do Azure. Mas notar a diferença é útil em alguns casos, como na solução de problemas de rede.
• Se o tráfego vier de uma rede virtual privada (VPN) local ou do gateway 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 fará nenhum NAT de origem por padrão.

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.

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 IP público do Firewall do Azure é distribuída para uma instância back-end do firewall, neste caso 192.168.100.7. A regra de NAT de Destino do Firewall do Azure (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 origina NATs (SNATs) do pacote se ele fizer 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 destino. O fluxo de entrada não requer uma rota definida pelo usuário (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. Finalmente, 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

Somente gateway de aplicativo

Este design abrange a situação em que existem apenas aplicações 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 um dispositivo de roteamento com NAT. Ele se comporta como um proxy de aplicativo reverso completo. Ou seja, 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 precisam ser enviadas para o endereço IP público do Gateway de Aplicativo, conexões do Azure ou locais para o endereço IP privado do gateway. O tráfego de retorno das VMs do Azure seguirá o roteamento de VNet padrão de volta para o Gateway de Aplicativo (consulte o passo a passo do pacote mais abaixo para obter mais detalhes). Os fluxos de internet de saída das VMs do Azure irão diretamente para a Internet.

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

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 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 Application Gateway é distribuída para uma instância back-end do gateway, neste caso 192.168.200.7. 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: 192.168.200.7 (o endereço IP privado da instância do Application Gateway)
   • 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 destino. A VM já sabe como 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. Por fim, a instância do Application Gateway 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 um gateway de aplicativo.

• O endereço IP é uma das instâncias que o serviço Gateway de Aplicativo do Azure implanta sob as cobertas, aqui com o endereço 192.168.200.7 192.168.200.4IP front-end privado interno. Essas instâncias individuais são normalmente invisíveis para o administrador do Azure. Mas notar a diferença é útil em alguns casos, como na solução de 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 público.

Firewall e Application Gateway em paralelo

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

Implemente esse design se houver uma combinação de cargas de trabalho da Web e não da 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 cobrirá 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, conexões HTTP(S) do Azure ou locais para seu endereço IP privado. O roteamento de VNet padrão enviará os pacotes do Application Gateway para as VMs de destino, bem como das VMs de destino de volta para o Application Gateway (consulte o passo a passo do pacote mais abaixo para obter mais detalhes). Para conexões não-HTTP(S) de entrada, o tráfego deve ser direcionado ao endereço IP público do Firewall do Azure (se vier da Internet pública) ou será enviado através 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 esse cenário:

Esse design oferece uma 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ê poderá usar filtros baseados em FQDN (nome de domínio totalmente qualificado). Com filtros baseados em FQDN, as aplicações não estão a enviar dados para contas de armazenamento não autorizadas. Esse cenário não poderia ser evitado apenas com o uso de NSGs. Esse design é frequentemente usado quando o tráfego de saída requer filtragem baseada em FQDN. Um exemplo de situação é ao limitar o tráfego de saída de um cluster dos Serviços Kubernetes do Azure.

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.

Application Gateway 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 Aplicativos, este documento se concentrará 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 WAF. O WAF fornece proteção na camada de aplicação Web. O Firewall do Azure atua 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. O Gateway de Aplicativo e o Firewall do Azure não estão em paralelo, mas um após o outro.

Com o Firewall Premium 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 é apropriado para aplicativos que precisam conhecer os endereços IP de origem do cliente de entrada, por exemplo, para servir conteúdo específico de geolocalização ou para registro. 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 um gateway de aplicativo.

As conexões HTTP(S) de entrada da Internet precisam ser enviadas para o endereço IP público do Gateway de Aplicativo, conexões HTTP(S) do Azure ou locais para o endereço IP privado. A partir do Gateway de Aplicativo, os UDRs garantirão que os pacotes sejam roteados pelo Firewall do Azure (consulte o passo a passo do pacote mais abaixo para obter mais detalhes). Para conexões não-HTTP(S) de entrada, o tráfego deve ser direcionado ao endereço IP público do Firewall do Azure (se vier da Internet pública) ou será enviado através 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 Premium do Azure tratará o tráfego do Gateway de Aplicativo como interno e não aplicará regras IDPS para tráfego de entrada. 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. 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 como 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 esse cenário:

Para tráfego da Web local ou da Internet para o Azure, o Firewall do Azure inspecionará fluxos que o WAF já permitiu. Dependendo se o Application Gateway criptografa o tráfego de back-end (tráfego do Application Gateway para os servidores de aplicativos), você terá diferentes cenários potenciais:

1. O Gateway de Aplicativo criptografa o tráfego seguindo princípios de confiança zero (criptografia TLS de ponta a ponta) e o Firewall do Azure receberá tráfego criptografado. Ainda assim, o Firewall Standard do Azure poderá aplicar regras de inspeção, como filtragem de camada 3 ou 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. O Firewall Premium do Azure fornece visibilidade mais profunda com inspeção TLS, como filtragem baseada em URL.
2. Se o Gateway de Aplicativo estiver enviando 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.
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 nome para o FQDN especificado no cabeçalho do host. Essa resolução de nomes pode ser obtida com as Zonas Privadas do DNS do Azure e as configurações padrão do DNS do Firewall do Azure usando o DNS do Azure. Isso também pode ser alcançado com servidores DNS personalizados que precisam ser configurados nas configuraçõ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 é a única possibilidade. Um exemplo é com 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 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 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 Application Gateway é distribuída para uma instância back-end do gateway, neste caso 192.168.200.7. 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 para na sub-rede do Gateway de Aplicativo encaminha o pacote para o Firewall do Azure, preservando o IP de destino para 192.168.1.0/24 o aplicativo Web:
   • Endereço IP de origem: 192.168.200.7 (endereço IP privado da instância do Application Gateway)
   • Endereço IP de destino: 192.168.1.4
   • Cabeçalho X-Forwarded-For: ClientPIP
3. O Firewall do Azure não SNAT o tráfego, porque o tráfego está indo 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, consulte Azure Firewall SNAT. 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 destino. O UDR para capturar o pacote enviado de volta ao Gateway de Aplicativo e o redireciona para o Firewall do Azure, preservando o IP de destino para 192.168.200.0/24 o Gateway de Aplicativo.
   • Endereço IP de origem: 192.168.1.4
   • Endereço IP de destino: 192.168.200.7
5. Aqui, novamente, o Firewall do Azure não SNAT o tráfego, uma vez que ele está indo 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. Por fim, 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, conforme definido pelo UDR para 0.0.0.0/0.

Application Gateway após firewall

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. No entanto, o Firewall do Azure SNATs o tráfego de entrada, portanto, o aplicativo não terá visibilidade para o endereço IP original das solicitações HTTP. De uma perspetiva 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.

Há um benefício limitado nesse cenário, porque o Firewall do Azure verá apenas o tráfego criptografado indo para o Gateway de Aplicativo. Pode haver cenários em que esse design seja preferido. Um caso é se outro WAF estiver mais cedo na rede (por exemplo, com o Azure Front Door), o que poderia capturar o IP de origem original no X-Forwarded-For cabeçalho HTTP. Ou o design é preferido se muitos endereços IP públicos forem necessários.

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 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 IP privado do Gateway de Aplicativo e encaminhado por meio do Firewall do Azure com UDRs. O roteamento de VNet padrão garantirá que o tráfego de retorno 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 o tráfego local, UDRs locais ou do Azure na sub-rede do Gateway de Aplicativo devem ser usados (consulte o passo a passo do pacote mais abaixo para obter mais detalhes). Todo o tráfego de saída das VMs do Azure para a Internet será enviado através do Firewall do Azure por UDRs.

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

Para tráfego HTTP(S) de entrada, o Firewall do Azure normalmente não descriptografa o tráfego. Em vez disso, aplicaria políticas IDPS que não exigem inspeção TLS, como filtragem baseada em 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 SNATs os 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 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 IP público do Firewall do Azure é distribuída para uma instância back-end do firewall, neste caso 192.168.100.7. O Firewall do Azure DNATs a porta Web, geralmente TCP 443, para o endereço IP privado da instância do Gateway de Aplicativo. O Firewall do Azure também SNATs ao fazer DNAT. Para obter mais informações, consulte Problemas conhecidos do Firewall do Azure:
   • Endereço IP de origem: 192.168.100.7 (o endereço IP privado da instância do Firewall do Azure)
   • Endereço IP de destino: 192.168.200.4
3. O Application Gateway estabelece uma nova sessão entre a instância que manipula 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: 192.168.200.7 (o endereço IP privado da instância do Application Gateway)
   • Endereço IP de destino: 192.168.1.4
   • Cabeçalho X-Forwarded-For: 192.168.100.7
4. A VM responde ao Application Gateway, invertendo os endereços IP de origem e 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 o , o Firewall do Azure vê o endereço IP interno do Gateway de Aplicativo .4 como .7o IP de origem:
   • Endereço IP de origem: 192.168.200.4
   • Endereço IP de destino: 192.168.100.7
6. Finalmente, 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 Application Gateway não tenha ouvintes configurados para aplicativos, ele ainda precisa de um endereço IP público para que a Microsoft possa gerenciá-lo.

Clientes 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 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 WAF usa o endereço IP privado do Application Gateway.
• O Firewall do Azure não oferece suporte a DNAT para endereços IP privados. É por isso que 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 do túnel forçado para o Gateway de Aplicativo do Azure e para o 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 Application Gateway, que aponta para a rede local, ou interromperá o tráfego de controle. Para o Gateway de Aplicativo do Azure, a rota padrão precisa 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 Rota Expressa:

Mesmo que todos os clientes estejam localizados no local 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 que a Microsoft gerencie os serviços.

Topologia hub-and-spoke

Os designs neste artigo ainda se aplicam em uma topologia hub e 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

Considerações

Algumas considerações para essa topologia incluem:

• 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, 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 nos exemplos anteriores, ele deve enviar o 192.168.100.7 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 acima), os pacotes de retorno podem acabar em uma instância diferente do Firewall do Azure, causando roteamento assimétrico. Certifique-se de que, se você tiver UDRs nas VNets spoke para enviar tráfego para 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 Application Gateway e a quaisquer outros Dispositivos Virtuais de Rede ou proxies reversos que possam ser implantados na VNet 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 salto seguinte de Virtual Network. Esse tipo de próximo salto só é válido na VNet local e não entre emparelhamentos de VNet. Para obter mais informações sobre rotas definidas pelo usuário e tipos de próximo salto, consulte Roteamento de tráfego de rede virtual.

Encaminhamento assimétrico

O diagrama abaixo mostra como um spoke envia de volta o tráfego SNATted de volta para o ALB de um 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, mas apenas com as sub-redes onde os serviços compartilhados estão localizados. No exemplo, a UDR correta no falado deve conter apenas 192.168.1.0/24. Ele não deve conter todo o 192.168.0.0/16, como marcado em vermelho.

Integração com outros produtos do Azure

Você pode integrar o Firewall do Azure e o Gateway de Aplicativo do Azure com 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 designs anteriores para fornecer funcionalidades como limitação de API ou proxy de autenticação. A integração de um gateway de gerenciamento de API não altera muito os designs. A principal diferença é que, em vez do único proxy reverso do Application Gateway, há dois proxies reversos encadeados um atrás do outro.

Para obter mais informações, consulte o Guia de Design para integrar o Gerenciamento de API e o Application Gateway em uma rede virtual e o padrão de aplicativo API Gateways for Microservices.

Azure Kubernetes Service

Para cargas de trabalho em execução em um cluster AKS, você pode implantar o Gateway de Aplicativo do Azure independentemente do cluster. Ou você pode integrá-lo ao cluster AKS usando o Controlador de Entrada do Gateway de Aplicativo do Azure. Ao configurar determinados objetos 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 oferece 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 Controlar o tráfego de saída para nós de cluster 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 WAF 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. Consulte Arquitetura de linha de base para um cluster do Serviço Kubernetes do Azure (AKS) para obter um exemplo da opção de design paralelo.

Azure Front Door

A funcionalidade do Azure Front Door sobrepõe-se parcialmente ao Azure Application Gateway. Por exemplo, ambos os serviços oferecem firewall de aplicativos Web, descarregamento de SSL e roteamento baseado em URL. Uma diferença principal é que, enquanto o Azure Application Gateway está dentro de 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 aqui permanece válida, exceto pela opção de colocar o Firewall do Azure na frente da Porta da Frente do Azure.

Um caso de uso interessante é usar o Firewall do Azure na frente do Application Gateway em sua rede virtual. Conforme descrito anteriormente, o cabeçalho injetado pelo Application Gateway conterá o endereço IP da instância de firewall, não o X-Forwarded-For 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 X-Forwarded-For cabeçalho antes que o tráfego entre na rede virtual e atinja o 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 quando usar cada um, consulte Perguntas frequentes sobre o Azure Front Door.

Outras ferramentas virtuais de rede

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 dispositivos virtuais de rede (NVAs). Os conceitos e designs são essencialmente os mesmos deste artigo, mas há algumas considerações importantes:

• Os NVAs de parceiros para firewall de próxima geração podem oferecer mais controle e flexibilidade para configurações de NAT sem suporte do Firewall do Azure. 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 configurações ativas-ativas e de dimensionamento automático, para que esses dispositivos não sejam um gargalo para aplicativos executados na rede virtual.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

• Jose Moreno - Brasil | Engenheiro de Clientes Principal

Próximos passos

Saiba mais sobre as tecnologias de componentes:

• O que é o Azure Application Gateway?
• O que é o Firewall do Azure?
• O que é o Azure Front Door?
• Azure Kubernetes Service
• O que é a Rede Virtual do Azure?
• O que é o Azure Web Application Firewall?

Recursos relacionados

Explore arquiteturas relacionadas:

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