integração Gateway de Aplicação

Três variações do Serviço de Aplicativo do Azure exigem uma configuração ligeiramente diferente da integração com o Gateway de Aplicativo do Azure. As variações incluem o Serviço de Aplicativo regular (também conhecido como multilocatário), um Ambiente de Serviço de Aplicativo de balanceador de carga interno (ILB) e um Ambiente de 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 discute considerações sobre o uso de pontos de extremidade privados e a integração com ILB e ambientes 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 (multilocatário)

O Serviço de Aplicativo (multilocatário) tem um ponto de extremidade público voltado para a Internet. 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.

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.

Há duas partes nessa configuração, além de criar a instância do 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.

Configurar serviços usando o portal do Azure

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 que diz 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 em 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 somente do Application Gateway. O modelo inclui muitos padrões inteligentes e postfixes exclusivos adicionados aos nomes de recursos para mantê-lo simples. 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 PowerShell apropriado ou o código da CLI do Azure.

Configurar serviços usando a CLI do Azure

O exemplo de CLI do Azure cria uma instância do Serviço de Aplicativo que é bloqueada com pontos de extremidade de serviço e uma restrição de acesso para receber tráfego somente do Gateway de Aplicativo. Se você só precisar isolar o tráfego para uma instância existente do Serviço de Aplicativo de um gateway de aplicativo existente, use o seguinte comando:

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 do ponto de extremidade do 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 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.

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 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

Considerações para um ambiente do ILB App Service

Um ambiente de serviço de aplicativo ILB 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 ILB 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 que o Ambiente do Serviço de Aplicativo funcione corretamente, certifique-se de não substituir as regras NSG necessárias.

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 de 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 este início rápido.

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 ARR

Em implantações de várias instâncias, a afinidade ARR garante que as solicitações do cliente sejam roteadas para a mesma instância durante a vida da sessão. A afinidade 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 certificado personalizados idênticos no Serviço de Aplicativo e no Gateway de Aplicativo e não substituir o nome do host.

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.