Firewall e Gateway de Aplicativo 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 VNets (redes virtuais) 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 para apenas 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, quando usar cada serviço e opções de design de rede que combinam ambos.

• a Proteção contra DDoS do Azure, combinada com as práticas recomendadas de design do aplicativo, fornece recursos avançados de mitigação de DDoS para fornecer mais defesa contra ataques DDoS. Você deve habilitar proteção contra DDOS do Azure em qualquer rede virtual de perímetro.
• do 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 (Protocolo de Internet) e portas TCP/UDP (Protocolo de Controle de Transmissão e Protocolo de Datagrama de 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, consulte a documentação do Firewall do Azure .
• Premium do Firewall do Azure inclui todas as funcionalidades do Firewall standard do Azure e outros recursos, como IDPS (Sistema de Detecção e Proteção contra Intrusões e Inspeção de TLS).
• gateway de aplicativo do Azure é um balanceador de carga de tráfego web gerenciado e proxy reverso completo HTTP(S) que pode fazer criptografia e descriptografia da SSL (Secure Socket Layer). O gateway de aplicativo preserva o endereço IP do cliente original em um cabeçalho HTTP deForwarded-For X. 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 .
• WAF (Firewall de Aplicativo Web) do Azure é 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 script entre sites. Para obter mais informações, consulte a documentação do Firewall do Aplicativo Web .

Esses serviços do Azure são complementares. Uma ou outra pode ser melhor para suas cargas de trabalho ou você pode usá-las juntas para uma proteção ideal nas camadas de rede e de 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 aplicativo.

O Firewall do Azure e o Gateway de Aplicativo do Azure usam tecnologias diferentes e dão suporte à proteção de fluxos diferentes:

Dependendo dos fluxos de rede que um aplicativo requer, 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 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.
• Gateway de Aplicativo sozinho, quando apenas os 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 evitar muitos cenários de ataque (como exfiltração de dados, IDPS e assim por diante). Devido a esse motivo, o cenário do Gateway de Aplicativo 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 para proteger todas as outras cargas de trabalho e filtrar o tráfego de saída.
• Gateway de Aplicativo em frente ao Firewall do Azure, quando você quiser que o Firewall do Azure inspecione todo o tráfego, o WAF para proteger o tráfego da Web e o aplicativo para saber 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, quando você quiser que o Firewall do Azure inspecione e filtre o tráfego antes que ele chegue ao Gateway de Aplicativo. Como o Firewall do Azure não 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, as variações dos designs fundamentais anteriores são descritas. Essas variações incluem:

• clientes de aplicativos locais.
• de redes hub e spoke do .
• 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 ou do Azure Front Door. Ou você pode substituir os recursos do Azure por dispositivos virtuais de rede de terceiros.

Somente 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 nesse caso é simples, mas revisar o fluxo de pacotes ajudará a entender 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 VNets 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 este cenário:

O Firewall do Azure não inspecionará o tráfego HTTP(S) de entrada. Mas ele poderá aplicar as regras de camada 3 & camada 4 e as 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 do TLS:

• O Firewall standard do Azure 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 do Azure Premium adiciona recursos como inspecionar outros cabeçalhos HTTP (como o User-Agent) e habilitar a inspeção do TLS para uma análise de pacote mais profunda. 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 será altamente recomendado.

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, você teria várias instâncias de aplicativo por trá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 de sub-rede do aplicativo usando a UDR.

• O serviço firewall do Azure implanta várias instâncias nas capas, 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 para o administrador do Azure. Mas perceber a diferença é útil em alguns casos, como ao 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 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 de back-end do firewall, nesse caso 192.168.100.7. A regra DO DNAT (Firewall do Azure De destino) converte o endereço IP de destino para o endereço IP do aplicativo dentro da rede virtual. O Firewall do Azure também OS NATs (SNATs) de origem o 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 endereços IP de origem e de destino. O fluxo de entrada não requer umade UDR (rota definida pelo usuário), porque o IP de origem é o endereço IP do Firewall do Azure. A 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. Por fim, 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

Esse design aborda a situação 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 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 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 precisam ser enviadas para o endereço IP público do Gateway de Aplicativo, conexões do Azure ou local para o endereço IP privado do gateway. Retornar o tráfego das VMs do Azure seguirá o roteamento de VNet padrão de volta para o Gateway de Aplicativo (confira o passo a passo do pacote para obter mais detalhes). Os fluxos de internet de saída das VMs do Azure serão diretamente para a Internet.

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

Arquitetura

O exemplo de caminhada de pacote a seguir mostra como um cliente acessa o aplicativo hospedado por VM 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 Gateway de Aplicativo é distribuída para uma instância de back-end do gateway, nesse 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 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: 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 endereços IP de origem e de destino. A VM já sabe como acessar 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 à localização geográfica ou para registro em log. Para obter mais informações, consulte Como um gateway de aplicativo funciona.

• O endereço IP 192.168.200.7 é uma das instâncias que o serviço do Gateway de Aplicativo do Azure implanta nas capas, aqui com 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 é ú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 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 público.

Firewall e Gateway de Aplicativo em paralelo

Devido à sua simplicidade e flexibilidade, a execução do Gateway de Aplicativo e do 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 abrangerá 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 das conexões HTTP(S) do Gateway de Aplicativo do Azure ou local para seu endereço IP privado. O roteamento de VNet padrão enviará os pacotes do Gateway de Aplicativo para as VMs de destino, bem como das VMs de destino de volta para o Gateway de Aplicativo (veja o 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 proveniente da Internet pública) ou será enviado por meio do Firewall do Azure por UDRs (se proveniente de outras VNets do Azure ou redes locais). Todos os fluxos de saída das 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 NSGs. Por exemplo, se os aplicativos precisarem de conectividade com uma Conta de Armazenamento do Azure específica, você poderá usar FQDN (nome de domínio totalmente qualificado)filtros baseados em. Com filtros baseados em FQDN, os aplicativos não estão enviando dados para contas de armazenamento não autorizadas. Esse cenário não pôde ser evitado apenas usando NSGs. Esse design geralmente é usado onde o tráfego de saída requer filtragem baseada em FQDN. Um exemplo de situação é quando limitando o 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 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 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 da Web de entrada 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 controle e registro em log 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 um após o 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 é apropriado para aplicativos que precisam saber os endereços IP de origem do cliente de entrada, por exemplo, para fornecer conteúdo específico à localização geográfica 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 encaminhado para, 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 das conexões HTTP(S) do Gateway de Aplicativo do Azure ou local para o endereço IP privado. Nas UDRs do Gateway de Aplicativo, verifique se os pacotes são roteado por meio do Firewall do Azure (confira o passo a passo do pacote 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 proveniente da Internet pública) ou será enviado por meio do Firewall do Azure por UDRs (se proveniente de outras VNets do Azure ou redes locais). Todos os fluxos de saída das VMs do Azure serão encaminhados para o Firewall do Azure por UDRs.

Uma observação importante desse design é que o Firewall do Azure Premium 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/16, 172.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 as instruções de regra IDPS do Firewall do Azure e prefixos ip privados para IDPS em regras do IDPS do Firewall do Azure. Consequentemente, é recomendável modificar os prefixos privados IDPS na política de Firewall do Azure para que a sub-rede do Gateway de Aplicativo não seja considerada como uma origem 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:

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

1. O Gateway de Aplicativo criptografa o tráfego seguindo princípios de confiança zero (de 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 & 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) do TLS. o Firewall do Azure Premium fornece visibilidade mais profunda com a inspeção do 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 limpo. A inspeção do 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 host. Essa resolução de nomes pode ser obtida com zonas privadas DNS do Azure e as configurações de DNS do Firewall do Azure padrão usando o DNS do Azure. Ele também pode ser obtido 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 em que o Firewall do Azure é implantado, o último método é a única possibilidade. Um exemplo é com firewalls do Azure implantados em Hubs Seguros de WAN Virtual.

Arquitetura

Para o restante dos fluxos (tráfego não HTTP(S) de entrada e qualquer tráfego de saída), o Firewall do Azure fornecerá inspeção IDPS e inspeção de TLS, quando apropriado. Ele também fornece filtragem baseada em FQDN nas regras de rede com base no 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 Gateway de Aplicativo é distribuída para uma instância de back-end do gateway, nesse caso 192.168.200.7. 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, 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 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 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 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 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. Aqui novamente, o Firewall do Azure não SNAT o tráfego, pois 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 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 firewall

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. No entanto, o Firewall do Azure SNATs o tráfego de entrada, portanto, o aplicativo não terá visibilidade do 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.

Há um benefício limitado nesse cenário, pois o Firewall do Azure só verá o tráfego criptografado indo para o Gateway de Aplicativo. Pode haver cenários em que esse design é preferencial. Um caso é se outro WAF estiver anteriormente na rede (por exemplo, com ado Azure Front Door), que pode capturar o IP de origem original no cabeçalho HTTP X-Forwarded-For. Ou o design é preferencial 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) os pacotes para o endereço IP privado do Gateway de Aplicativo. De outras VNets 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 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 o tráfego de UDRs locais ou do Azure na sub-rede do Gateway de Aplicativo deve ser usado (confira o passo a passo do pacote mais para baixo 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 por UDRs.

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

Para tráfego HTTP(S) de entrada, o Firewall do Azure normalmente não descriptografaria 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 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.

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 de back-end do firewall, nesse 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 Gateway de Aplicativo estabelece uma nova sessão entre a instância que está tratando 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 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 venha de uma instância específica do Gateway de Aplicativo, como .7, o Firewall do Azure verá 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 SNAT e 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 ainda precisará de um endereço IP público para que a Microsoft possa gerenciá-lo.

Clientes locais

Os designs anteriores mostram todos os clientes de aplicativo provenientes 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 de 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 WAF 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. É por isso que 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 o do Gateway de Aplicativo do Azure e para odo 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 ou você 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 Gateway de Aplicativo do Azure e o design paralelo 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 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 e spoke

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

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 Gateway de Aplicativo no hub. As equipes de aplicativos geralmente gerenciam componentes como Gateways de Aplicativo do Azure ou gateways de Gerenciamento de API do Azure. Nesse caso, 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 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 acima), os pacotes de retorno poderão acabar em uma instância diferente do Firewall do Azure, causando roteamento assimétrico. Verifique se você tem UDRs nas VNets spoke para enviar 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 aplica-se igualmente à sub-rede do Gateway de Aplicativo 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 próximo salto de Virtual Network. Esse tipo de próximo salto só é válido na VNet local e não em 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.

Roteamento assimétrico

O diagrama abaixo mostra como um spoke envia de volta o tráfego SNATted para o ALB de um Firewall do Azure. Essa configuração causa o 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. 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 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 de um gateway de Gerenciamento de API não altera muito os designs. A principal diferença é que, em vez do proxy reverso do Gateway de Aplicativo único, há dois proxies reversos encadeados um atrás do outro.

Para obter mais informações, consulte o Guia de Design do 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 em execução em um cluster do AKS, você pode implantar o Gateway de Aplicativo do Azure independentemente do cluster. Ou você pode integrá-lo ao cluster do AKS usando o do Controlador de Entrada do Gateway de Aplicativo do Azure. Ao configurar determinados objetos 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 oferece 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 Control egress traffic for AKS cluster nós.

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 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 explicitamente permitidas. Consulte arquitetura de linha de base para um cluster do AKS (Serviço de Kubernetes do Azure) para obter um exemplo da opção de design paralelo.

Azure Front Door

funcionalidade de do Azure Front Door se sobrepõe parcialmente ao Gateway de Aplicativo do Azure. Por exemplo, ambos os serviços oferecem firewall de aplicativo Web, descarregamento de SSL e roteamento baseado em URL. Uma das principais diferenças é que, embora o Gateway de Aplicativo do Azure esteja 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 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 em sua rede virtual. Conforme descrito anteriormente, o cabeçalho X-Forwarded-For injetado pelo Gateway de Aplicativo conterá 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. Uma segunda opção é Proteger sua Origem com Link Privado 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 dispositivos virtuais de rede

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 (dispositivos virtuais de rede). 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 oferecer mais controle e flexibilidade para configurações nat sem suporte pelo Firewall do Azure. 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 NVAs, em que os usuários precisam lidar com escalabilidade e resiliência em muitos dispositivos.
• Ao usar NVAs no Azure, use ativo-ativo e configurações de dimensionamento automático, portanto, esses dispositivos não são um gargalo para aplicativos em execução na rede virtual.

Contribuintes

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

Autor principal:

• José Moreno | Engenheiro de cliente principal

Próximas etapas

Saiba mais sobre as tecnologias de componente:

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

Recursos relacionados

Explore arquiteturas relacionadas:

• Implementar uma rede híbrida segura
• aplicativos Web gerenciados com segurança
• Proteger o bot de canal do Microsoft Teams e o aplicativo Web por trás de uma de firewall
• considerações de segurança para aplicativos IaaS altamente confidenciais no Azure
• SaaS Multilocatário no Azure
• implantação do Enterprise usando o Ambiente dos Serviços de Aplicativo
• implantação empresarial de alta disponibilidade usando o Ambiente dos Serviços de Aplicativo
• arquitetura de linha de base para um cluster do AKS (Serviço de Kubernetes do Azure)