Configuração de infraestrutura do Gateway de Aplicativo
A infraestrutura do Gateway de Aplicativo do Azure inclui a rede virtual, sub-redes, NSGs (grupos de segurança de rede) e UDRs (rotas definidas pelo usuário).
Rede virtual e sub-rede dedicada
Um gateway de aplicativo é uma implantação dedicada em sua rede virtual. Dentro de sua rede virtual, exige-se a presença de uma sub-rede dedicada para o gateway de aplicativo. Você pode ter várias instâncias de uma implantação específica do Gateway de Aplicativo em uma sub-rede. Você também pode implantar outros gateways de aplicativo na sub-rede. Mas você não pode implantar nenhum outro recurso na sub-rede do Gateway de Aplicativo. Não é possível misturar SKUs do Gateway de Aplicativo v1 e v2 na mesma sub-rede.
Observação
As políticas de ponto de extremidade de serviço de rede virtual atualmente não têm suporte em uma sub-rede do Gateway de Aplicativo.
Tamanho da sub-rede
O Gateway de Aplicativo usa um endereço IP privado por instância, além de outro endereço IP privado caso um IP front-end privado esteja configurado.
O Azure também reserva cinco endereços IP em cada sub-rede para uso interno. São os quatro primeiros endereços e os últimos endereços IP. Por exemplo, considere 15 instâncias do Gateway de Aplicativo sem IP de front-end privado. Você precisa de pelo menos 20 endereços IP para esta sub-rede. Você precisa de 5 para uso interno e 15 para as instâncias do Gateway de Aplicativo.
Considere uma sub-rede que tenha 27 instâncias do Gateway de Aplicativo e um endereço IP para um IP de front-end privado. Neste caso, você precisa de 33 endereços IP. Você precisa de 27 para as instâncias do Gateway de Aplicativo, um para o front-end privado e 5 para uso interno.
O Gateway de Aplicativo (SKU Standard ou WAF) pode oferecer suporte a até 32 instâncias (32 endereços IP de instância + 1 configuração de IP de front-end privado + 5 Azure reservado). Recomendamos um tamanho mínimo de sub-rede de /26.
O Gateway de Aplicativo (Standard_v2 ou WAF_v2 SKU) pode dar suporte a até 125 instâncias (125 endereços IP de instância + 1 configuração de IP de front-end privado + 5 Azure reservados). Recomendamos um tamanho mínimo de sub-rede de /24.
Para determinar a capacidade disponível de uma sub-rede que tenha gateways de aplicativos existentes provisionados, pegue o tamanho da sub-rede e subtraia os cinco endereços IP reservados da sub-rede reservados pela plataforma. Em seguida, pegue cada gateway e subtraia a contagem máxima de instâncias. Para cada gateway que tenha uma configuração IP de front-end privada, subtraia mais um endereço IP por gateway.
Por exemplo, veja como calcular o endereçamento disponível para uma sub-rede com três gateways de tamanhos variados:
- Gateway 1: máximo de 10 instâncias. Usa uma configuração de IP de front-end privado.
- Gateway 2: máximo de 2 instâncias. Nenhuma configuração de IP de front-end privado.
- Gateway 3: máximo de 15 instâncias. Usa uma configuração de IP de front-end privado.
- Tamanho da sub-rede: /24
- Tamanho da sub-rede /24 = 256 endereços IP - 5 reservados da plataforma = 251 endereços disponíveis
- 251: Gateway 1 (10) - 1 configuração IP de frontend privado = 240
- 240: Gateway 2 (2) = 238
- 238: Gateway 3 (15) - 1 configuração de IP de frontend privado = 222
Importante
Embora uma sub-rede /24 não seja necessária por implantação de SKU do Gateway de Aplicativo v2, é altamente recomendável fazê-la. Uma sub-rede /24 garante que o Gateway de Aplicativo v2 tenha espaço suficiente para o dimensionamento automático de atualizações de expansão e manutenção.
Você deve garantir que a sub-rede v2 do Gateway de Aplicativo tenha espaço de endereço suficiente para acomodar o número de instâncias necessárias para atender ao tráfego máximo esperado. Se você especificar a contagem máxima de instâncias, a sub-rede deverá ter capacidade para pelo menos esse número de endereços. Para planejamento de capacidade em torno da contagem de instâncias, consulte Detalhes da contagem de instâncias.
A sub-rede chamada GatewaySubnet é reservada para gateways VPN. Os recursos do Gateway de Aplicativo v1 que usam a sub-rede GatewaySubnet precisam ser movidos para uma sub-rede diferente ou migrados para a SKU v2 antes de 30 de setembro de 2023, para evitar falhas no plano de controle e inconsistências de plataforma. Para obter informações sobre como alterar a sub-rede de uma instância existente do Gateway de Aplicativo, consulte Perguntas frequentes sobre o Gateway de Aplicativo.
Dica
Os endereços IP são alocados desde o início do espaço de sub-rede definido para instâncias de gateway. À medida que as instâncias são criadas e removidas devido à criação de gateways ou eventos de dimensionamento, pode se tornar difícil entender qual é o próximo endereço disponível na sub-rede. Para poder determinar o próximo endereço a ser usado para um gateway futuro e ter um tema de endereçamento contíguo para IPs de front-end, considere atribuir endereços IP de front-end da metade superior do espaço de subconjunto definido.
Por exemplo, se o espaço de endereço de sub-rede for 10.5.5.0/24, considere definir a configuração IP de front-end privado de seus gateways começando com 10.5.5.254 e, em seguida, seguindo com 10.5.5.253, 10.5.5.252, 10.5.5.251 e assim por diante para gateways futuros.
É possível alterar a sub-rede de uma instância existente do Gateway de Aplicativo na mesma rede virtual. Para fazer essa alteração, use o Azure PowerShell ou a CLI do Azure. Para obter mais informações, consulte Perguntas frequentes do Gateway de Aplicativo.
Servidores DNS para resolução de nomes
O recurso de rede virtual oferece suporte à configuração servidor DNS que permite que você escolha entre servidores DNS padrão ou personalizados fornecidos pelo Azure. As instâncias do gateway de aplicativo também respeitam essa configuração de DNS para qualquer resolução de nome. Depois de alterar essa configuração, você deve reiniciar (Stop e Start) o gateway do aplicativo para que essas alterações entrem em vigor nas instâncias.
Quando uma instância do Gateway de Aplicativo emite uma consulta DNS, ela usa o valor do servidor que responde primeiro.
Observação
Se você usar servidores DNS personalizados na rede virtual do Gateway de Aplicativo, o servidor DNS deverá ser capaz de resolver nomes públicos da Internet. O Gateway de Aplicativo requer esse recurso.
Permissão de rede virtual
O recurso Gateway de Aplicativo é implantado dentro de uma rede virtual, portanto, também realizamos uma verificação para verificar a permissão no recurso de rede virtual fornecido. Essa validação é executada durante operações de criação e gerenciamento e também se aplica às identidades gerenciadas para o Controlador de Entrada do Gateway de Aplicativo.
Verifique seu controle de acesso baseado em função do Azure para verificar se os usuários e entidades de serviço que operam gateways de aplicativo têm pelo menos as seguintes permissões na rede virtual ou sub-rede:
- Microsoft.Network/virtualNetworks/subnets/join/action
- Microsoft.Network/virtualNetworks/subnets/read
Você pode usar as funções internas, como Colaborador de rede, que já dão suporte a essas permissões. Se uma função interna não fornecer a permissão correta, você poderá criar e atribuir uma função personalizada. Saiba mais sobre como Gerenciar permissões de sub-rede.
Permissões
Dependendo se você estar criando novos recursos ou usando os existentes, adicione as permissões apropriadas da seguinte lista:
| Recurso | Status do recurso | Permissões necessárias do Azure |
|---|---|---|
| Sub-rede | Criar novo | Microsoft.Network/virtualNetworks/subnets/write Microsoft.Network/virtualNetworks/subnets/join/action |
| Sub-rede | Usar existente | Microsoft.Network/virtualNetworks/subnets/read Microsoft.Network/virtualNetworks/subnets/join/action |
| Endereços IP | Criar novo | Microsoft.Network/publicIPAddresses/write Microsoft.Network/publicIPAddresses/join/action |
| Endereços IP | Usar existente | Microsoft.Network/publicIPAddresses/read Microsoft.Network/publicIPAddresses/join/action |
| ApplicationGatewayWebApplicationFirewallPolicies | Criar nova/Atualizar existente | Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/write Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/join/action |
Para obter mais informações, consulte Permissões do Azure para sistema de rede e Permissões de rede virtual.
Escopo de funções
No processo de definição de função personalizada, você pode especificar um escopo de atribuição de função em quatro níveis: grupo de gerenciamento, assinatura, grupo de recursos e recursos. Para conceder acesso, você atribui funções a usuários, grupos, entidades de serviço ou identidades gerenciadas em um determinado escopo. Esses escopos são estruturados em uma relação pai-filho, com cada nível de hierarquia tornando o escopo mais específico. Você pode atribuir funções em qualquer um desses níveis de escopo e o nível selecionado determina a ampla aplicação da função. Por exemplo, uma função atribuída no nível da assinatura pode ser propagar para todos os recursos dentro dessa assinatura, enquanto uma função atribuída no nível do grupo de recursos só se aplicará aos recursos dentro desse grupo específico. Saiba mais sobre o nível do escopo. Para obter mais informações, consulte Níveis de escopo.
Observação
Talvez seja necessário reservar tempo suficiente para a atualização de cache do Azure Resource Manager após as alterações de atribuição de função.
Identificar usuários afetados ou entidades de serviço para sua assinatura
Ao visitar o Assistente do Azure para sua conta, você pode verificar se sua assinatura tem usuários ou entidades de serviço com permissão insuficiente. Os detalhes dessa recomendação são os seguintes:
Título: Atualizar permissão de rede virtual de usuários do Gateway de Aplicativo
Categoria: Confiabilidade
Impacto: Alto
Usar o sinalizador temporário do Controle de Exposição de Recursos do Azure (AFEC)
Como uma extensão temporária, introduzimos um Controle de Exposição de Recursos do Azure (Controle de Exposição de Recursos) de nível de assinatura. Você pode se registrar no AFEC e usá-lo até corrigir as permissões para todos os seus usuários e entidades de serviço. Registre-se para o recurso seguindo as mesmas etapas de um registro de versão prévia do recurso para sua assinatura do Azure.
Nome: Microsoft.Network/DisableApplicationGatewaySubnetPermissionCheck
Descrição: Desabilitar a verificação de permissão de sub-rede do gateway de aplicativo
ProviderNamespace: Microsoft.Network
EnrollmentType: AutoApprove
Observação
Sugerimos usar a provisão AFEC apenas como mitigação provisória até que você atribua a permissão correta. Você deve priorizar a correção das permissões para todos os usuários aplicáveis (e entidades de serviço) e, em seguida, cancelar o registro desse sinalizador AFEC para reintroduzir a verificação de permissão no recurso de rede virtual. Recomendamos que você não dependa desse método AFEC permanentemente, pois ele será removido no futuro.
Gerenciador de Rede Virtual do Azure
O Gerenciador de Rede Virtual do Azure é um serviço de gerenciamento que permite agrupar, configurar, implantar e gerenciar redes virtuais globalmente em assinaturas. Com o Gerenciador de Rede Virtual, você pode definir grupos de rede para identificar e segmentar logicamente suas redes virtuais. Depois disso, você pode determinar as configurações de conectividade e segurança desejadas e aplicá-las em todas as redes virtuais selecionadas em grupos de rede de uma só vez.
A configuração da regra de administrador de segurança no Gerenciador de Rede Virtual do Azure permite definir políticas de segurança em escala e aplicá-las a várias redes virtuais de uma só vez.
Observação
As regras de administrador de segurança do Gerenciador de Rede Virtual do Azure só se aplicam às sub-redes do Gateway de Aplicativo que contêm gateways de aplicativo com o isolamento de rede habilitado. As sub-redes com gateways de aplicativo que têm o isolamento de rede desabilitado não têm regras de administrador de segurança.
Grupos de segurança de rede
Você pode usar NSGs para sua sub-rede do Gateway de Aplicativo, mas esteja ciente de alguns pontos e restrições importantes.
Importante
Essas limitações do NSG são relaxadas quando você usa implantação do Private Gateway de Aplicativo (visualização).
Regras de segurança necessárias
Para usar um NSG com seu gateway de aplicativo, você precisa criar ou manter algumas regras de segurança essenciais. Você pode definir sua prioridade na mesma ordem.
Regras de entrada
Tráfego de cliente: permita o tráfego de entrada dos clientes esperados (como IP de origem ou intervalo de IP) e para o destino como o prefixo IP de sub-rede inteiro do gateway de aplicativo e as portas de acesso de entrada. Por exemplo, se você tiver ouvintes configurados para as portas 80 e 443, deverá permitir essas portas. Você também pode definir essa regra como Any.
| Origem | Portas de origem | Destino | Portas de destino | Protocolo | Access |
|---|---|---|---|---|---|
<as per need> |
Qualquer | <Subnet IP Prefix> |
<listener ports> |
TCP | Allow |
Depois de configurar ouvintes públicos e privados ativos (com regras) com o mesmo número de porta, o gateway de aplicativo altera o Destino de todos os fluxos de entrada para os IPs front-end do gateway. Essa alteração ocorre mesmo para ouvintes que não estão compartilhando nenhuma porta. Você deve incluir os endereços IP públicos e privados de front-end do gateway no Destino da regra de entrada ao usar a mesma configuração de porta.
| Origem | Portas de origem | Destino | Portas de destino | Protocolo | Access |
|---|---|---|---|---|---|
<as per need> |
Qualquer | <Public and Private frontend IPs> |
<listener ports> |
TCP | Allow |
Portas de infraestrutura: Permita solicitações de entrada da origem como a etiqueta de serviço GatewayManager e Qualquer destino. O intervalo de portas de destino difere com base na SKU e é necessário para comunicar o status da integridade do back-end. Essas portas são protegidas/bloqueadas por certificados do Azure. As entidades externas não podem iniciar alterações nesses pontos de extremidade sem certificados apropriados.
- V2: Portas 65200-65535
- V1: Portas 65503-65534
| Origem | Portas de origem | Destino | Portas de destino | Protocolo | Access |
|---|---|---|---|---|---|
| GatewayManager | Qualquer | Qualquer | <as per SKU given above> |
TCP | Allow |
Investigação do Balanceador de Carga do Azure: permita o tráfego de entrada da origem como a marca de serviço AzureLoadBalancer. Essa regra é criada por padrão para NSGs. Você não deve substituí-lo por uma regra manual Negar para garantir operações suaves do gateway de aplicativo.
| Origem | Portas de origem | Destino | Portas de destino | Protocolo | Access |
|---|---|---|---|---|---|
| AzureLoadBalancer | Qualquer | Qualquer | Qualquer | Qualquer | Allow |
Você pode bloquear todo o outro tráfego de entrada usando uma regra Negar tudo
Regras de saída
Saída para a Internet: Permitir tráfego de saída para a Internet para todos os destinos. Essa regra é criada por padrão para NSGs. Você não deve substituí-lo por uma regra manual Negar para garantir operações suaves do gateway de aplicativo. As regras NSG de saída que negam qualquer conectividade de saída não devem ser criadas.
| Origem | Portas de origem | Destino | Portas de destino | Protocolo | Access |
|---|---|---|---|---|---|
| Qualquer | Qualquer | Internet | Qualquer | Qualquer | Allow |
Observação
Os Gateways de Aplicativo que não têm o isolamento de rede habilitado não permitem que o tráfego seja enviado entre VNets emparelhadas quando a opção Permitir o tráfego para a rede virtual remota está desabilitada.
Rotas definidas pelo usuário com suporte
O controle de granularidade sobre a sub-rede do Gateway de Aplicativo por meio de regras de tabela de rotas é possível na visualização pública. Para obter mais informações, consulte Implantação do Gateway de Aplicativo Privado (visualização).
Com a funcionalidade atual, existem algumas restrições:
Importante
Usar UDRs na sub-rede do Gateway de Aplicativo pode fazer com que o status de integridade na exibição de integridade do back-end seja exibido como desconhecido. Isso também pode causar falha na geração de logs e métricas do Gateway de Aplicativo. Recomendamos não usar UDRs na sub-rede do Gateway de Aplicativo para que você possa exibir a integridade, os logs e as métricas do back-end.
v1: Para a SKU v1, os UDRs são suportados na sub-rede do Gateway de Aplicativo se não alterarem a comunicação de solicitação/resposta de ponta a ponta. Por exemplo, você pode configurar uma UDR na sub-rede do Gateway de Aplicativo que aponte para um dispositivo de firewall para inspeção de pacotes. Mas verifique se o pacote pode atingir o destino pretendido após a inspeção. Não fazer isso poderá resultar em uma investigação de integridade ou em um comportamento de roteamento de tráfego incorreto. Rotas aprendidas ou rotas padrão 0.0.0.0/0 que são propagadas pelo Azure ExpressRoute ou gateways VPN na rede virtual também estão incluídas.
v2: Para a SKU v2, há cenários com e sem suporte.
Cenários de v2 com suporte
Aviso
Uma configuração incorreta da tabela de rotas pode resultar no roteamento assimétrico no Gateway de Aplicativo v2. Certifique-se de que todo o tráfego do plano de gerenciamento/controle seja enviado diretamente para a Internet e não por meio de um dispositivo virtual. As verificações de registros em log, métricas e CRL também podem ser afetadas.
Cenário 1: UDR para desabilitar a propagação de rota do BGP (Border Gateway Protocol) para a sub-rede do Gateway de Aplicativo
Às vezes, a rota do gateway padrão (0.0.0.0/0) é anunciada por meio dos gateways de VPN ou ExpressRoute associados à rede virtual do Gateway de Aplicativo. Esse comportamento interrompe o tráfego do plano de gerenciamento, que requer um caminho direto para a internet. Nesses cenários, você pode usar um UDR para desabilitar a propagação de rota BGP.
Para desativar a propagação de rota BGP:
- Crie um recurso de tabela de rotas no Azure.
- Desabilite o parâmetro de Propagação de rota do gateway de rede virtual.
- Associe a tabela de rotas à sub-rede apropriada.
Habilitar a UDR para esse cenário não deve interromper nenhuma configuração existente.
Cenário 2: UDR para direcionar 0.0.0.0/0 para a Internet
Você pode criar um UDR para enviar tráfego 0.0.0.0/0 diretamente para a Internet.
Cenário 3: UDR para o Serviço de Kubernetes do Azure (AKS) com kubenet
Se você estiver usando kubenet com AKS e Gateway de Aplicativo do controlador de entrada, precisará de uma tabela de rotas para permitir que o tráfego enviado para os pods do Gateway de Aplicativo seja roteado para o nó correto. Você não precisará usar uma tabela de rotas se usar a Interface de Rede de Contêiner do Azure.
Para usar a tabela de rotas para permitir que o kubenet funcione:
Vá para o grupo de recursos criado pelo AKS. O nome do grupo de recursos deve começar com
MC_.Localize a tabela de rotas criada pelo AKS nesse grupo de recursos. A tabela de rotas deve ser preenchida com as seguintes informações:
- O prefixo de endereço deve ser o intervalo de IP dos pods que você deseja alcançar no AKS.
- O próximo tipo de salto deve ser dispositivo virtual.
- O endereço do próximo salto deve ser o endereço IP do nó que hospeda os pods.
Associe essa tabela de rotas à sub-rede do Gateway de Aplicativo.
Cenários sem suporte da v2
Cenário 1: UDR para dispositivos virtuais
Não há suporte para qualquer cenário em que 0.0.0.0/0 precise ser redirecionado por meio de uma solução de virtualização, uma rede virtual hub/spoke ou local (encapsulamento forçado) para v2.