Integração do Gateway de Aplicativo

Três variações do Serviço de Aplicativo do Azure requerem uma configuração ligeiramente diferente da integração com o Gateway de Aplicativo do Azure. As variações incluem o Serviço de Aplicativo normal (também conhecido como multilocatário), um Ambiente do Serviço de Aplicativo do balanceador de carga interno (ILB) e um Ambiente do Serviço de Aplicativo externo.

Este artigo explica como configurar o Gateway de Aplicativo com o Serviço de Aplicativo (multilocatário) usando pontos de extremidade de serviço para proteger o tráfego. O artigo também aborda considerações em torno de como usar pontos de extremidade privados e se integrar ao ILB e aos Ambientes do Serviço de Aplicativo externos. Para terminar, o artigo descreve como configurar restrições de acesso em um site do Gerenciador de Controle do Código-Fonte (SCM).

Integração com o Serviço de Aplicativo (multilocatário)

O Serviço de Aplicativo (multilocatário) tem um ponto de extremidade público voltado para a internet. Ao usar pontos de extremidade de serviço, você pode permitir o tráfego somente de uma sub-rede específica dentro de uma rede virtual do Azure e bloquear tudo o mais. No cenário a seguir, usaremos essa funcionalidade para garantir que uma instância do Serviço de Aplicativo só possa receber tráfego de uma instância específica do Gateway de Aplicativo.

Diagram that shows the internet flowing to an application gateway in an Azure virtual network and then flowing through a firewall icon to instances of apps in App Service.

Essa configuração tem duas partes, além da criação da instância do Serviço de Aplicativo e do Gateway de Aplicativo. A primeira parte consiste em habilitar os pontos de extremidade de serviço na sub-rede da rede virtual em que o Gateway de Aplicativo está implantado. Os pontos de extremidade de serviço garantem que todo o tráfego de rede que sai da sub-rede em direção ao Serviço de Aplicativo é marcado com a ID de sub-rede específica.

A segunda parte consiste em configurar uma restrição de acesso do aplicativo web específico para garantir que apenas o tráfego marcado com essa ID de sub-rede específica seja permitido. Você pode configurar a restrição de acesso usando diferentes ferramentas, dependendo da sua preferência.

Configurar serviços usando o portal do Azure

Com o portal do Azure, você segue quatro etapas para criar e configurar a instalação do Serviço de Aplicativo e do Gateway de Aplicativo. Caso já tenha recursos, você pode ignorar as primeiras etapas.

  1. Crie uma instância do Serviço de Aplicativo usando um dos guias de início rápido da documentação do Serviço de Aplicativo. Um exemplo é o guia de início rápido do .NET Core.
  2. Crie um Gateway de Aplicativo usando o guia de início rápido do portal, mas ignore a seção sobre como adicionar destinos de back-end.
  3. Configure o Serviço de Aplicativo como um back-end no Gateway de Aplicativo, mas ignore a seção sobre como restringir o acesso.
  4. Crie a restrição de acesso usando pontos de extremidade de serviço.

Agora você pode acessar o Serviço de Aplicativo por meio do Gateway de Aplicativo. Se tentar acessar o Serviço de Aplicativo diretamente, você deverá receber um erro HTTP 403 dizendo que o aplicativo web bloqueou seu acesso.

Screenshot shows the text of Error 403 - Forbidden.

Configurar serviços usando um modelo do Azure Resource Manager

O modelo de implantação do Azure Resource Manager cria um cenário completo. O cenário consiste de uma instância do Serviço de Aplicativo bloqueada com pontos de extremidade de serviço e uma restrição de acesso para receber tráfego apenas do Gateway de Aplicativo. O modelo inclui muitos padrões Inteligentes e sufixos únicos adicionados aos nomes dos recursos para garantir a simplicidade. Para substituí-los, você precisa clonar o repositório ou baixar o modelo e editá-lo.

Para aplicar o modelo, você pode usar o botão Implantar no Azure na descrição do modelo. Ou você pode usar o código apropriado do PowerShell ou da CLI do Azure.

Configurar serviços usando a CLI do Azure

A amostra da CLI do Azure cria uma instância do Serviço de Aplicativo bloqueada com pontos de extremidade de serviço e uma restrição de acesso para receber tráfego apenas do Gateway de Aplicativo. Se você precisa apenas isolar o tráfego de uma instância do Serviço de Aplicativo existente para um Gateway de Aplicativo existente, use o comando a seguir:

az webapp config access-restriction add --resource-group myRG --name myWebApp --rule-name AppGwSubnet --priority 200 --subnet mySubNetName --vnet-name myVnetName

Na configuração padrão, o comando garante a configuração da instalação do ponto de extremidade de serviço na sub-rede e a restrição de acesso no Serviço de Aplicativo.

Considerações sobre o uso de pontos de extremidade privados

Como alternativa aos pontos de extremidade de serviço, você pode usar pontos de extremidade privados para proteger o tráfego entre o Gateway de Aplicativo e o Serviço de Aplicativo (multilocatário). Você precisa garantir que o Gateway de Aplicativo possa usar o DNS para resolver o endereço IP privado dos aplicativos do Serviço de Aplicativo. Alternativamente, você pode usar o endereço IP privado no pool de back-end e substituir o nome do host nas configurações HTTP.

Diagram that shows traffic flowing to an application gateway in an Azure virtual network and then flowing through a private endpoint to instances of apps in App Service.

O Gateway de Aplicativo armazena em cache os resultados da pesquisa DNS. Se você usar nomes de domínio totalmente qualificados (FQDNs) e depender da pesquisa de DNS para obter o endereço IP privado, talvez seja necessário reiniciar o Gateway de Aplicativo se a atualização do DNS ou o estabelecimento de um link para uma zona de DNS privada do Azure tiverem ocorrido depois de você ter configurado o pool de back-end.

Para reiniciar o Gateway de Aplicativo, pare-o e o inicie usando a CLI do Azure:

az network application-gateway stop --resource-group myRG --name myAppGw
az network application-gateway start --resource-group myRG --name myAppGw

Considerações sobre um Ambiente do Serviço de Aplicativo do ILB

Um Ambiente do Serviço de Aplicativo do ILB não fica exposto à internet. O tráfego entre a instância e um Gateway de Aplicativo já está isolado para a rede virtual. Para configurar um Ambiente do Serviço de Aplicativo ILB e integrá-o a um Gateway de Aplicativo usando o portal do Azure, confira o guia de instruções.

Se quiser garantir que apenas o tráfego da sub-rede do Gateway de Aplicativo acesse o Ambiente do Serviço de Aplicativo, você pode configurar um grupo de segurança de rede (NSG) que afete todos os aplicativos web no Ambiente do Serviço de Aplicativo. Para o NSG, você pode especificar o intervalo de IP de sub-rede e, opcionalmente, as portas (80/443). Para que o Ambiente do Serviço de Aplicativo funcione corretamente, certifique-se de não substituir as regras de NSG necessárias.

Para isolar o tráfego direcionado a um aplicativo web individual, você precisa usar restrições de acesso baseadas em IP, porque os pontos de extremidade de serviço não funcionam com o Ambiente do Serviço de Aplicativo. O endereço IP deve ser o IP privado da instância do Gateway de Aplicativo.

Considerações sobre um Ambiente de Serviço de Aplicativo externo

O Ambiente do Serviço de Aplicativo externo tem um balanceador de carga voltado para o público, como o Serviço de Aplicativo multilocatário. Os pontos de extremidade de serviço não funcionam para um Ambiente do Serviço de Aplicativo. É por isso que você precisa usar restrições de acesso baseadas em IP usando o endereço IP público do Gateway de Aplicativo. Para criar um Ambiente do Serviço de Aplicativo externo usando o portal do Azure, você pode seguir esse guia de início rápido.

Considerações sobre um site do Kudu/SCM

O site do SCM, também conhecido como Kudu, é um site de administrador que existe para todos os aplicativos web. Não é possível usar o proxy reverso para o site do SCM. Você provavelmente também vai querer bloqueá-lo com endereços IP individuais ou uma sub-rede específica.

Se quiser usar as mesmas restrições de acesso que o site principal, você poderá herdar as configurações usando o comando a seguir:

az webapp config access-restriction set --resource-group myRG --name myWebApp --use-same-restrictions-for-scm-site

Se quiser adicionar restrições de acesso individuais ao site do SCM, você poderá usar o sinalizador --scm-site:

az webapp config access-restriction add --resource-group myRG --name myWebApp --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16

Considerações sobre como usar o domínio padrão

Configurar o Gateway de Aplicativo para substituir o nome do host e usar o domínio padrão do Serviço de Aplicativo (de modo geral azurewebsites.net) é a maneira mais fácil de configurar a integração. O processo não requer a configuração de um domínio personalizado nem um certificado no Serviço de Aplicativo.

Este artigo gira em torno das considerações gerais para substituir o nome do host original. No Serviço de Aplicativo, há dois cenários em que você precisa prestar atenção com essa configuração.

Autenticação

Quando você usa o recurso de autenticação no Serviço de Aplicativo (também conhecido como Easy Auth), seu aplicativo de modo geral irá redirecionar para a página de login. Como o Serviço de Aplicativo não sabe o nome do host original da solicitação, o redirecionamento é feito com o nome de domínio padrão e costuma resultar em um erro.

Para contornar o redirecionamento padrão, você pode configurar a autenticação para inspecionar um cabeçalho encaminhado e adaptar o domínio de redirecionamento ao domínio original. O Gateway de Aplicativo usa um cabeçalho chamado X-Original-Host. Ao usar a configuração baseada em arquivo para configurar a autenticação, você pode configurar o Serviço de Aplicativo para se adaptar ao nome do host original. Adicione essa configuração ao arquivo de configuração:

{
    ...
    "httpSettings": {
        "forwardProxy": {
            "convention": "Custom",
            "customHostHeaderName": "X-Original-Host"
        }
    }
    ...
}

Afinidade ARR

Em implantações com várias instâncias, a afinidade de ARR garante que as solicitações do cliente sejam roteadas para a mesma instância durante toda a vida útil da sessão. A afinidade de ARR não funciona com substituições de nome de host. Para que a afinidade de sessão funcione, você precisa configurar um domínio e um certificado personalizados idênticos no Serviço de Aplicativo e no Gateway de Aplicativo e não substituir o nome do host.

Próximas etapas

Para obter mais informações sobre Ambientes do Serviço de Aplicativo, confira a documentação do Ambiente do Serviço de Aplicativo.

Para proteger ainda mais seu aplicativo web, você pode encontrar informações sobre o Firewall de Aplicativo Web do Azure no Gateway de Aplicativo na documentação do Firewall de Aplicativo Web do Azure.

Para implantar um site seguro e resiliente com um domínio personalizado no Serviço de Aplicativo usando o Azure Front Door ou o Gateway de Aplicativo, confira esse tutorial.