integração Gateway de Aplicação

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 discute considerações sobre o uso de pontos de extremidade de serviço e a integração com ambientes internos e externos do Serviço de Aplicativo. Finalmente, o artigo descreve como definir 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 Application Gateway e seu aplicativo do Serviço de Aplicativo. Você precisa garantir que o Application Gateway possa usar o DNS para resolver o endereço IP privado dos aplicativos do Serviço de Aplicativo. Como alternativa, você pode usar o endereço IP privado no pool de back-end e substituir o nome do host nas configurações HTTP.

O Application Gateway armazena em cache os resultados da pesquisa de DNS. Se você usar FQDNs (nomes de domínio totalmente qualificados) 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 de DNS ou o link para uma zona DNS privada do Azure tiver acontecido depois de configurar o pool de back-end.

Para reiniciar o gateway de aplicativo, pare e inicie-o 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 sobre 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 Application Gateway. Usando pontos de extremidade de serviço, você pode permitir o tráfego de apenas uma sub-rede específica em uma rede virtual do Azure e bloquear todo o resto. No cenário a seguir, você usa essa funcionalidade para garantir que uma instância do Serviço de Aplicativo possa receber tráfego apenas de um gateway de aplicativo específico.

Há duas partes nessa configuração, além de criar a instância do aplicativo Serviço de Aplicativo e o gateway de aplicativo. A primeira parte é habilitar pontos de extremidade de serviço na sub-rede da rede virtual onde o gateway de aplicativo é 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 seja marcado com o ID de sub-rede específico.

A segunda parte é definir uma restrição de acesso no aplicativo Web específico para garantir que apenas o tráfego marcado com esse ID de sub-rede específico 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 configuração do Serviço de Aplicativo e do Gateway de Aplicativo. Se tiver recursos existentes, pode ignorar os primeiros passos.

1. Crie uma instância do Serviço de Aplicativo usando um dos inícios rápidos na documentação do Serviço de Aplicativo. Um exemplo é o início rápido do .NET Core.
2. Crie um gateway de aplicativo usando o 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 Application Gateway, mas ignore a seção sobre restrição de 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 Application Gateway. Se você tentar acessar o Serviço de Aplicativo diretamente, deverá receber um erro HTTP 403 informando que o aplicativo Web está bloqueando seu acesso.

Considerações para um ambiente interno do Serviço de Aplicativo

Um Ambiente do Serviço de Aplicativo interno não está exposto à Internet. O tráfego entre a instância e um gateway de aplicativo já está isolado na rede virtual. Para configurar um Ambiente do Serviço de Aplicativo interno e integrá-lo a um gateway de aplicativo usando o portal do Azure, consulte o guia de instruções.

Se quiser garantir que apenas o tráfego da sub-rede do Gateway de Aplicativo esteja chegando ao Ambiente do Serviço de Aplicativo, você poderá configurar um NSG (grupo de segurança de rede) que afete todos os aplicativos Web no Ambiente do Serviço de Aplicativo. Para o NSG, você pode especificar o intervalo de IP da sub-rede e, opcionalmente, as portas (80/443).

Para isolar o tráfego para 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 um Ambiente do Serviço de Aplicativo. O endereço IP deve ser o IP privado do gateway de aplicativo.

Considerações para um ambiente externo do Serviço de Aplicativo

Um Ambiente do Serviço de Aplicativo externo tem um balanceador de carga voltado para o público, como aplicativos do Serviço de Aplicativo multilocatário. 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 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 este início rápido.

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

Considerações para um site Kudu/SCM

O site SCM, também conhecido como Kudu, é um site de administração que existe para cada aplicativo Web. Não é possível usar proxy reverso para o site SCM. Você provavelmente também deseja bloqueá-lo para endereços IP individuais ou uma sub-rede específica.

Se quiser usar as mesmas restrições de acesso que o site principal, você pode herdar as configurações usando o seguinte comando:

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 para o site do SCM, você pode usar o --scm-site sinalizador:

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 o uso do domínio padrão

Configurar o Application Gateway para substituir o nome do host e usar o domínio padrão do Serviço de Aplicativo (normalmente azurewebsites.net) é a maneira mais fácil de configurar a integração. Não requer a configuração de um domínio e certificado personalizados no Serviço de Aplicativo.

Este artigo discute as considerações gerais para substituir o nome de 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 normalmente redireciona para a página de entrada. Como o Serviço de Aplicativo não sabe o nome de host original da solicitação, o redirecionamento é feito no nome de domínio padrão e geralmente resulta 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 Application Gateway usa um cabeçalho chamado X-Original-Host. Usando a configuração baseada em arquivo para configurar a autenticação, você pode configurar o Serviço de Aplicativo para se adaptar ao nome de host original. Adicione esta configuração ao seu arquivo de configuração:

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

Afinidade de sessão

Em implantações de várias instâncias, a afinidade de sessão garante que as solicitações do cliente sejam roteadas para a mesma instância durante a vida da sessão. A afinidade de sessão pode ser configurada para adaptar o domínio do 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 procura X-Original-Host ou X-Forwarded-Host adapta o domínio do cookie ao domínio encontrado neste cabeçalho. Como 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 seja proveniente 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óximos passos

Para obter mais informações sobre Ambientes do Serviço de Aplicativo, consulte 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 Application Gateway, consulte este tutorial.