Integração do Gateway de Aplicativo

Este artigo explica como configurar o Gateway de Aplicativo com o Serviço de Aplicativo usando pontos de extremidade privados para proteger o tráfego. O artigo também aborda considerações em torno de como usar pontos de extremidade privados e se integrar aos Ambientes do Serviço de Aplicativo externos e internos. 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

Você pode usar pontos de extremidade privados para proteger o tráfego entre o Gateway de Aplicativo e seu aplicativo do Serviço de Aplicativo. 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.

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

Saiba mais sobre como configurar um aplicativo do Serviço de Aplicativo com ponto de extremidade privado.

Considerações para o uso de pontos de extremidade de serviço

Como alternativa aos pontos de extremidade privados, você pode usar pontos de extremidade de serviço para proteger o tráfego do Gateway de Aplicativo. 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.

Essa configuração tem duas partes, além da criação da instância de aplicativo 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.

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 está bloqueando seu acesso.

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

Um Ambiente do Serviço de Aplicativo interno 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 interno 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 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 aplicativos do Serviço de Aplicativo. Os pontos de extremidade de serviço não funcionam para um Ambiente do Serviço de Aplicativo. Com o Ambiente do Serviço de Aplicativo, você pode usar restrições de acesso baseadas em IP usando o endereço 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.

Você também pode adicionar pontos de extremidade privados a aplicativos hospedados em um Ambiente externo do Serviço de Aplicativo.

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 de sessão

Em implantações com várias instâncias, a afinidade de sessão 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 sessão pode ser configurada para adaptar o domínio de cookie ao cabeçalho de entrada do proxy reverso. Ao configurar o proxy de afinidade de sessão como “true”, a afinidade de sessão irá procurar X-Original-Host ou X-Forwarded-Host e adaptará o domínio de cookie ao domínio encontrado neste cabeçalho. Como uma prática recomendada, ao habilitar o proxy de afinidade de sessão, você deve configurar suas restrições de acesso no site para garantir que o tráfego venha do proxy reverso.

Você também pode configurar clientAffinityProxyEnabled usando o seguinte comando:

az resource update --resource-group myRG --name myWebApp --resource-type "Microsoft.Web/sites" --set properties.clientAffinityProxyEnabled=true

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.