Partilhar via


Implantação do Private Application Gateway (visualização)

Introdução

Historicamente, as SKUs do Application Gateway v2 e, até certo ponto, a v1, exigiam endereçamento IP público para permitir o gerenciamento do serviço. Esse requisito impôs várias limitações no uso de controles refinados em Grupos de Segurança de Rede e Tabelas de Rotas. Especificamente, observaram-se os seguintes desafios:

  • Todas as implantações do Application Gateways v2 devem conter configuração de IP frontend voltado para o público para habilitar a comunicação com a marca de serviço do Gateway Manager .
  • As associações do Grupo de Segurança de Rede exigem regras para permitir o acesso de entrada do GatewayManager e o acesso de saída à Internet.
  • Ao introduzir uma rota padrão (0.0.0.0/0) para encaminhar o tráfego para qualquer lugar que não seja a Internet, as métricas, o monitoramento e as atualizações do gateway resultam em um status de falha.

O Application Gateway v2 agora pode abordar cada um desses itens para eliminar ainda mais o risco de exfiltração de dados e controlar a privacidade da comunicação de dentro da rede virtual. Essas alterações incluem os seguintes recursos:

  • Endereço IP privado apenas configuração de IP frontend
    • Nenhum recurso de endereço IP público necessário
  • Eliminação do tráfego de entrada da etiqueta de serviço GatewayManager através do Network Security Group
  • Capacidade de definir uma regra Negar Todos os NSG (Grupo de Segurança de Rede) de saída para restringir o tráfego de saída para a Internet
  • Capacidade de substituir a rota padrão para a Internet (0.0.0.0/0)
  • Resolução de DNS através de resolvedores definidos na rede virtual Saiba mais, incluindo zonas DNS privadas de ligação privada.

Cada um desses recursos pode ser configurado de forma independente. Por exemplo, um endereço IP público pode ser usado para permitir a entrada de tráfego da Internet e você pode definir uma regra Negar todas as saídas na configuração do grupo de segurança de rede para evitar a exfiltração de dados.

Integração para pré-visualização pública

A funcionalidade dos novos controles de configuração de frontend IP privado, controle sobre regras NSG e controle sobre tabelas de rotas estão atualmente em visualização pública. Para participar da visualização pública, você pode optar pela experiência usando o portal do Azure, PowerShell, CLI ou API REST.

Quando você ingressa na visualização, todos os novos Application Gateways são provisionados com a capacidade de definir qualquer combinação dos recursos de configuração NSG, Tabela de Rotas ou IP privado. Se desejar desativar a nova funcionalidade e retornar à funcionalidade atual disponível em geral do Application Gateway, poderá fazê-lo cancelando o registro na visualização.

Para obter mais informações sobre recursos de visualização, consulte Configurar recursos de visualização na assinatura do Azure

Registe-se para a pré-visualização

Use as etapas a seguir para se inscrever na visualização pública para os controles de rede aprimorados do Gateway de Aplicativo por meio do portal do Azure:

  1. Inicie sessão no portal do Azure.

  2. Na caixa de pesquisa, introduza subscrições e selecione Subscrições.

    Captura de ecrã da pesquisa do portal do Azure.

  3. Selecione a ligação para o nome da sua subscrição.

    Captura de ecrã a mostrar a seleção da subscrição do Azure.

  4. No menu à esquerda, em Configurações , selecione Visualizar recursos.

    Captura de ecrã do menu de funcionalidades de pré-visualização do Azure.

  5. Você verá uma lista de recursos de visualização disponíveis e seu status de registro atual.

    Captura de ecrã da lista de funcionalidades de pré-visualização do portal do Azure.

  6. Em Visualizar recursos , digite na caixa de filtro EnableApplicationGatewayNetworkIsolation, marque o recurso e clique em Registrar.

    Captura de ecrã das funcionalidades de pré-visualização do filtro do portal do Azure.

Nota

O registro do recurso pode levar até 30 minutos para fazer a transição do status Registro para o status Registrado.

Para obter mais informações sobre recursos de visualização, consulte Configurar recursos de visualização na assinatura do Azure

Cancelar o registo a partir da pré-visualização

Para desativar a visualização pública dos controles de rede aprimorados do Application Gateway via Portal, use as seguintes etapas:

  1. Inicie sessão no portal do Azure.

  2. Na caixa de pesquisa, introduza subscrições e selecione Subscrições.

    Captura de ecrã da pesquisa do portal do Azure.

  3. Selecione a ligação para o nome da sua subscrição.

    Captura de ecrã a mostrar a seleção da subscrição do Azure.

  4. No menu à esquerda, em Configurações , selecione Visualizar recursos.

    Captura de ecrã do menu de funcionalidades de pré-visualização do Azure.

  5. Você verá uma lista de recursos de visualização disponíveis e seu status de registro atual.

    Captura de ecrã da lista de funcionalidades de pré-visualização do portal do Azure.

  6. Em Visualizar recursos , digite na caixa de filtro EnableApplicationGatewayNetworkIsolation, marque o recurso e clique em Cancelar registro.

    Captura de ecrã das funcionalidades de pré-visualização do filtro do portal do Azure.

Regiões e disponibilidade

A visualização do Private Application Gateway está disponível para todas as regiões de nuvem pública onde o sku do Application Gateway v2 é suportado.

Configuração de controles de rede

Após o registro na visualização pública, a configuração do NSG, Tabela de Rotas e configuração de frontend de endereço IP privado pode ser executada usando qualquer método. Por exemplo: API REST, Modelo ARM, Implantação do Bicep, Terraform, PowerShell, CLI ou Portal. Nenhuma alteração de API ou comando é introduzida com esta visualização pública.

Alterações de recursos

Depois que o gateway é provisionado, uma marca de recurso é atribuída automaticamente com o nome de EnhancedNetworkControl e o valor de True. Veja o seguinte exemplo:

Captura de ecrã da etiqueta EnhancedNetworkControl.

A tag de recurso é cosmética e serve para confirmar que o gateway foi provisionado com os recursos para configurar qualquer combinação dos recursos de gateway somente privados. A modificação ou exclusão da tag ou do valor não altera nenhum funcionamento funcional do gateway.

Gorjeta

A tag EnhancedNetworkControl pode ser útil quando os Application Gateways existentes foram implantados na assinatura antes da ativação do recurso e você gostaria de diferenciar qual gateway pode utilizar a nova funcionalidade.

Sub-rede do Application Gateway

A Sub-rede do Gateway de Aplicativo é a sub-rede dentro da Rede Virtual onde os Recursos do Gateway de Aplicativo serão implantados. Na configuração de IP Privado Frontend, é importante que essa sub-rede possa alcançar de forma privada os recursos que desejam se conectar ao seu aplicativo ou site exposto.

Conectividade de saída com a Internet

As implantações do Application Gateway que contêm apenas uma configuração IP de front-end privada (não têm uma configuração de front-end IP pública associada a uma regra de roteamento de solicitação) não são capazes de emitir tráfego destinado à Internet. Essa configuração afeta a comunicação com destinos de back-end que são acessíveis publicamente através da Internet.

Para habilitar a conectividade de saída do seu Application Gateway para um destino de back-end voltado para a Internet, você pode utilizar o NAT da Rede Virtual ou encaminhar o tráfego para um dispositivo virtual que tenha acesso à Internet.

O NAT da Rede Virtual oferece controle sobre qual endereço IP ou prefixo deve ser usado, bem como o tempo limite de ociosidade configurável. Para configurar, crie um novo Gateway NAT com um endereço IP público ou prefixo público e associe-o à sub-rede que contém o Application Gateway.

Se um dispositivo virtual for necessário para a saída da Internet, consulte a seção de controle de tabela de rotas neste documento.

Cenários comuns em que o uso de IP público é necessário:

  • Comunicação com o cofre de chaves sem o uso de pontos de extremidade privados ou pontos de extremidade de serviço
    • A comunicação de saída não é necessária para arquivos pfx carregados diretamente no Application Gateway
  • Comunicação com alvos de back-end via Internet
  • Comunicação com a Internet voltada para pontos de extremidade CRL ou OCSP

Controlo do Grupo de Segurança de Rede

Os grupos de segurança de rede associados a uma sub-rede do Application Gateway não exigem mais regras de entrada para o GatewayManager e não exigem acesso de saída à Internet. A única regra necessária é Permitir entrada do AzureLoadBalancer para garantir que as sondas de integridade possam chegar ao gateway.

A configuração a seguir é um exemplo do conjunto mais restritivo de regras de entrada, negando todo o tráfego, exceto as sondas de integridade do Azure. Além das regras definidas, regras explícitas são definidas para permitir que o tráfego do cliente chegue ao ouvinte do gateway.

Captura de ecrã das regras do grupo de segurança de entrada.

Nota

O Application Gateway exibirá um alerta solicitando para garantir que a Regra Permitir LoadBalanceRule seja especificada se uma regra DenyAll restringir inadvertidamente o acesso a testes de integridade.

Cenário de exemplo

Este exemplo mostra a criação de um NSG usando o portal do Azure com as seguintes regras:

  • Permitir tráfego de entrada para as portas 80 e 8080 para o Application Gateway a partir de solicitações de clientes originadas da Internet
  • Negar todo o outro tráfego de entrada
  • Permitir tráfego de saída para um destino de back-end em outra rede virtual
  • Permitir tráfego de saída para um destino de back-end acessível pela Internet
  • Negar todo o outro tráfego de saída

Primeiro, crie um grupo de segurança de rede. Este grupo de segurança contém as suas regras de entrada e saída.

Regras de entrada

Três regras padrão de entrada já estão provisionadas no grupo de segurança. Veja o seguinte exemplo:

Captura de ecrã das regras predefinidas do grupo de segurança.

Em seguida, crie as quatro novas regras de segurança de entrada a seguir:

  • Permitir porta de entrada 80, tcp, da Internet (qualquer)
  • Permitir porta de entrada 8080, tcp, da Internet (qualquer)
  • Permitir entrada do AzureLoadBalancer
  • Negar qualquer entrada

Para criar estas regras:

  • Selecionar regras de segurança de entrada
  • Selecione Adicionar
  • Insira as seguintes informações para cada regra no painel Adicionar regra de segurança de entrada.
  • Depois de inserir as informações, selecione Adicionar para criar a regra.
  • A criação de cada regra leva um momento.
Regra # Origem Etiqueta de serviço de origem Intervalo de portas de origem Destino Serviço Intervalos de portas Dest Protocolo Ação Prioridade Nome
1 Qualquer * Qualquer HTTP 80 TCP Permitir 1028 AllowWeb
2 Qualquer * Qualquer Personalizado 8080 TCP Permitir 1029 AllowWeb8080
3 Etiqueta de Serviço AzureLoadBalancer * Qualquer Personalizado * Qualquer Permitir 1045 AllowLB
4 Qualquer * Qualquer Personalizado * Qualquer Negar 4095 DenyAllInbound

Selecione Atualizar para revisar todas as regras quando o provisionamento estiver concluído.

Captura de tela de exemplo de regras de grupo de segurança de entrada.

Regras de saída

Três regras de saída padrão com prioridade 65000, 65001 e 65500 já estão provisionadas.

Crie as três novas regras de segurança de saída a seguir:

  • Permitir TCP 443 de 10.10.4.0/24 para back-end de destino 203.0.113.1
  • Permitir TCP 80 da origem 10.10.4.0/24 para o destino 10.13.0.4
  • Regra de trânsito DenyAll

A essas regras é atribuída uma prioridade de 400, 401 e 4096, respectivamente.

Nota

  • 10.10.4.0/24 é o espaço de endereço da sub-rede do Application Gateway.
  • 10.13.0.4 é uma máquina virtual em uma VNet emparelhada.
  • 203.0.113.1 é uma VM de destino de back-end.

Para criar estas regras:

  • Selecionar regras de segurança de saída
  • Selecione Adicionar
  • Insira as seguintes informações para cada regra no painel Adicionar regra de segurança de saída.
  • Depois de inserir as informações, selecione Adicionar para criar a regra.
  • A criação de cada regra leva um momento.
Regra # Origem Intervalos CIDR/Endereços IP de origem Intervalo de portas de origem Destino Endereços IP de destino/intervalos CIDR Serviço Intervalos de portas Dest Protocolo Ação Prioridade Nome
1 Endereços IP 10.10.4.0/24 * Endereços IP 203.0.113.1 HTTPS 443 TCP Permitir 400 AllowToBackendTarget
2 Endereços IP 10.10.4.0/24 * Endereços IP 10.13.0.4 HTTP 80 TCP Permitir 401 AllowToPeeredVnetVM
3 Qualquer * Qualquer Personalizado * Qualquer Negar 4096 DenyAll

Selecione Atualizar para revisar todas as regras quando o provisionamento estiver concluído.

Captura de tela das regras de segurança de saída para o gateway de aplicativo.

Associar NSG à sub-rede

A última etapa é associar o grupo de segurança de rede à sub-rede que contém o Application Gateway.

Captura de tela do NSG associado à sub-rede.

Resultado:

Captura de tela da visão geral do NSG.

Importante

Tenha cuidado ao definir as regras DenyAll , pois você pode negar inadvertidamente o tráfego de entrada de clientes aos quais você pretende permitir acesso. Você também pode negar inadvertidamente o tráfego de saída para o destino de back-end, fazendo com que a integridade do back-end falhe e produza respostas 5XX.

Controle de tabela de rotas

Na oferta atual do Application Gateway, a associação de uma tabela de rotas com uma regra (ou criação de regra) definida como 0.0.0.0/0 com um próximo salto como dispositivo virtual não é suportada para garantir o gerenciamento adequado do Application Gateway.

Após o registro do recurso de visualização pública, a capacidade de encaminhar o tráfego para um dispositivo virtual agora é possível por meio da definição de uma regra de tabela de rotas que define 0.0.0.0/0 com um próximo salto para o Dispositivo Virtual.

O túnel forçado ou o aprendizado da rota 0.0.0.0/0 por meio da publicidade BGP não afeta a integridade do Application Gateway e é honrado pelo fluxo de tráfego. Esse cenário pode ser aplicável ao usar VPN, Rota Expressa, Servidor de Rotas ou WAN Virtual.

Cenário de exemplo

No exemplo a seguir, criamos uma tabela de rotas e a associamos à sub-rede do Application Gateway para garantir que o acesso de saída à Internet da sub-rede saia de um dispositivo virtual. Em um nível alto, o seguinte design é resumido na Figura 1:

  • O Application Gateway está em rede virtual spoke
  • Há um dispositivo virtual de rede (uma máquina virtual) na rede de hub
  • Uma tabela de rotas com uma rota padrão (0.0.0.0/0) para o dispositivo virtual está associada à sub-rede do Application Gateway

Diagrama, por exemplo, tabela de rotas.

Figura 1: Saída de acesso à Internet por meio de dispositivo virtual

Para criar uma tabela de rotas e associá-la à sub-rede do Application Gateway:

  1. Crie uma tabela de rotas:

Captura de tela da tabela de rotas recém-criada.

  1. Selecione Rotas e crie a próxima regra de salto para 0.0.0.0/0 e configure o destino para ser o endereço IP da sua VM:

Captura de ecrã a mostrar a adição de uma rota predefinida à ferramenta virtual de rede.

  1. Selecione Sub-redes e associe a tabela de rotas à sub-rede do Application Gateway:

Captura de tela da associação da rota à sub-rede AppGW.

  1. Valide se o tráfego está passando pelo dispositivo virtual.

Limitações / Problemas conhecidos

Embora na pré-visualização pública, as seguintes limitações são conhecidas.

O suporte à configuração de link privado para encapsulamento de tráfego através de pontos de extremidade privados para o Application Gateway não é suportado com gateway somente privado.

Limitação de taxa WAF

Atualmente, não há suporte para regras personalizadas de limitação de taxa para o Application Gateway WAF v2.

Configuração de frontend IP privado apenas com AGIC

AGIC v1.7 deve ser usado para introduzir suporte apenas para IP frontend privado.

Conectividade de ponto final privado via emparelhamento de rede virtual global

Se o Application Gateway tiver um destino de back-end ou uma referência de cofre de chaves para um ponto de extremidade privado localizado em uma VNet acessível por meio de emparelhamento global de VNet, o tráfego será descartado, resultando em um status não íntegro.

Integração com o Network Watcher

As soluções de problemas de conexão e o diagnóstico NSG retornam um erro ao executar testes de verificação e diagnóstico.

Gateways de aplicativos v2 coexistentes criados antes da habilitação do controle de rede aprimorado

Se uma sub-rede compartilhar implantações do Application Gateway v2 que foram criadas antes e depois da habilitação da funcionalidade de controle de rede aprimorada, a funcionalidade NSG (Network Security Group) e Route Table será limitada à implantação anterior do gateway. Os gateways de aplicativos provisionados antes da habilitação da nova funcionalidade devem ser reprovisionados ou os gateways recém-criados devem usar uma sub-rede diferente para habilitar recursos avançados de grupo de segurança de rede e tabela de rotas.

  • Se existir um gateway implantado antes da ativação da nova funcionalidade na sub-rede, você poderá ver erros como: For routes associated to subnet containing Application Gateway V2, please ensure '0.0.0.0/0' uses Next Hop Type as 'Internet' ao adicionar entradas da tabela de rotas.
  • Ao adicionar regras de grupo de segurança de rede à sub-rede, você pode ver: Failed to create security rule 'DenyAnyCustomAnyOutbound'. Error: Network security group \<NSG-name\> blocks outgoing Internet traffic on subnet \<AppGWSubnetId\>, associated with Application Gateway \<AppGWResourceId\>. This isn't permitted for Application Gateways that have fast update enabled or have V2 Sku.

Estado de funcionamento do back-end desconhecido

Se a integridade do back-end for Desconhecido, você poderá ver o seguinte erro:

  • Não foi possível recuperar o status de integridade do back-end. Isso acontece quando um NSG/UDR/Firewall na sub-rede do gateway de aplicativo está bloqueando o tráfego nas portas 65503-65534 se houver SKU v1 e portas 65200-65535 se houver SKU v2 ou se o FQDN configurado no pool de back-end não puder ser resolvido para um endereço IP. Para saber mais visite - https://aka.ms/UnknownBackendHealth.

Este erro pode ser ignorado e será esclarecido em uma versão futura.

Próximos passos