Che cos'è l'integrazione di Azure Application Gateway con Azure App Service?

Questo articolo offre una panoramica per la configurazione di Azure Application Gateway con Azure App Service usando endpoint privati per proteggere il traffico. Esaminare le considerazioni per l'uso degli endpoint di servizio e l'integrazione con un App Service Environment interno o esterno. Impostare le restrizioni di accesso in un sito di Gestione controllo del codice sorgente.

Integrazione con servizio app

È possibile utilizzare endpoint privati per proteggere il traffico tra l'Application Gateway e la tua app di Servizi App. È necessario assicurarsi che Application Gateway possa utilizzare il Domain Name System (DNS) per risolvere l'indirizzo IP privato delle app di App Service. In alternativa, è possibile usare l'indirizzo IP privato nel pool back-end ed eseguire l'override del nome host nelle impostazioni HTTP.

Il Gateway delle Applicazioni memorizza nella memoria cache i risultati della ricerca DNS. Se si usano nomi di dominio completamente qualificati (FQDN) e ci si basa sulla ricerca DNS per ottenere l'indirizzo IP privato, potrebbe essere necessario riavviare il gateway dell'applicazione. Un riavvio è necessario quando l'aggiornamento DNS o il collegamento a una zona DNS privata Azure si verifica dopo aver configurato il pool back-end.

Per riavviare il gateway dell'applicazione, arrestarlo e avviarlo con i seguenti comandi di Azure CLI. Sostituire i nomi delle risorse locali con i valori <segnaposto> nei comandi.

az network application-gateway stop --resource-group <your-resource-group> --name <your-application-gateway>
az network application-gateway start --resource-group <your-resource-group> --name <your-application-gateway>

Scopri di più su configurare un'app del Servizio App con un endpoint privato.

Considerazioni sull'uso degli endpoint di servizio

In alternativa all'uso di endpoint privati, è possibile usare gli endpoint di servizio per proteggere il traffico dal gateway applicazione. Usando gli endpoint servizi, è possibile consentire il traffico solo da una subnet specifica all'interno di una rete virtuale Azure e bloccare tutto il resto. Nello scenario seguente si usa questa funzionalità per garantire che le app del servizio app possano ricevere traffico solo da un gateway applicazione specifico.

Questa configurazione include due parti, a parte la creazione dell'istanza dell'app di App Service e del gateway dell'applicazione.

• La prima parte abilita gli endpoint di servizio nella subnet della rete virtuale dove il gateway applicativo è distribuito. Gli endpoint di servizio assicurano che tutto il traffico di rete che lascia la subnet verso il servizio app sia contrassegnato con l'ID subnet specifico.

• La seconda parte imposta una restrizione di accesso per l'app Web specifica per garantire che sia consentito solo il traffico contrassegnato con questo ID subnet specifico. È possibile configurare la restrizione di accesso usando diversi strumenti, a seconda delle preferenze.

Nel portale di Azure si seguono quattro passaggi per creare e configurare l'integrazione del servizio app e del gateway applicazione. Se si dispone di risorse esistenti, è possibile ignorare i primi e i secondi passaggi.

1. Creare un'app del App Service usando una delle procedure rapide nella documentazione di App Service. Un esempio è .NET Core Quickstart.
2. Creare un gateway applicazione usando l'avvio rapido del portale, ma ignorare la sezione relativa all'aggiunta di destinazioni back-end.
3. Configurare App Service come back-end in Application Gateway, ma ignorare la sezione relativa alla limitazione dell'accesso.
4. Creare la restrizione di accesso usando gli endpoint di servizio.

È ora possibile accedere ad App Service tramite il gateway delle applicazioni. Se si tenta di accedere direttamente al servizio app, si prevede di visualizzare un errore HTTP 403 che indica che l'app Web blocca l'accesso.

Considerazioni per un App Service Environment interno

Un ambiente del servizio app interno non è esposto a Internet. Il traffico tra l'ambiente e un gateway di applicazione è già isolato nella rete virtuale. È possibile configurare un ambiente interno e integrarlo con un gateway applicazione usando il portale di Azure.

Se si vuole assicurarsi che solo il traffico proveniente dalla subnet del gateway applicazione raggiunga il App Service Environment, è possibile configurare un gruppo di sicurezza di rete che influisce su tutte le app Web nell'ambiente. Per il gruppo di sicurezza di rete, è possibile specificare l'intervallo IP della subnet e facoltativamente le porte (80/443).

Per isolare il traffico verso una singola app Web, è necessario usare restrizioni di accesso basate su IP, perché gli endpoint di servizio non funzionano con un App Service Environment. L'indirizzo IP deve essere l'indirizzo IP privato del gateway di applicazione.

Considerazioni per un ambiente App Service esterno

Un App Service Environment esterno dispone di un bilanciatore di carico con visibilità pubblica simile alle app di App Service multi-tenant. Gli endpoint di servizio non funzionano per un App Service Environment esterno. In un App Service Environment è possibile applicare restrizioni di accesso basate su IP usando l'indirizzo IP pubblico del gateway applicazione. Per creare un App Service Environment esterno nel portale di Azure, è possibile usare un quickstart.

È anche possibile aggiungere endpoint privati alle app ospitate in un'App Service Environment esterno.

Considerazioni per un sito Kudu/SCM

Il sito SCM, noto anche come Kudu, è un sito di amministrazione esistente per ogni app Web. Non è possibile usare il proxy inverso per il sito SCM. È molto probabile che si voglia anche bloccare l'accesso a singoli indirizzi IP o a una subnet specifica.

Se si desidera usare le stesse restrizioni di accesso del sito principale, è possibile ereditare le impostazioni con il comando Azure CLI seguente:

az webapp config access-restriction set --resource-group <your-resource-group> --name <your-web-app> --use-same-restrictions-for-scm-site

Se si desidera aggiungere singole restrizioni di accesso per il sito SCM, è possibile usare il --scm-site flag con il comando :

az webapp config access-restriction add --resource-group <your-resource-group> --name <your-web-app> --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16

Considerazioni sull'uso del dominio predefinito

È possibile configurare Application Gateway per eseguire l'override del nome host con il dominio predefinito di App Service (generalmente azurewebsites.net). Questo approccio è il modo più semplice per eseguire l'integrazione perché non richiede la configurazione di un dominio personalizzato e di un certificato nel servizio app.

Il processo di conservazione dei nomi host descrive le considerazioni generali per l'override del nome host originale. Nel servizio app tenere presenti le considerazioni seguenti relative all'autenticazione e all'affinità di sessione.

Autenticazione (autenticazione semplice)

Quando si usa la funzionalità di autenticazione nel servizio app (nota anche come Easy Auth), l'app viene in genere reindirizzata alla pagina di accesso. Poiché il servizio app non conosce il nome host originale della richiesta, il reindirizzamento viene eseguito sul nome di dominio predefinito e in genere dà luogo a un errore.

Per aggirare il reindirizzamento predefinito, è possibile configurare l'autenticazione per controllare un'intestazione inoltrata e adattare il dominio di reindirizzamento al dominio originale. Il Gateway delle applicazioni usa un'intestazione denominata X-Original-Host. Usando la configurazione basata su file per specificare l'autenticazione, è possibile configurare il servizio app per adattarsi al nome host originale.

Aggiungere questa configurazione al file di configurazione:

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

Affinità di sessione

Quando si specifica l'impostazioneAffinità di sessione nelle distribuzioni a più istanze, è possibile assicurarsi che le richieste client vengano instradate alla stessa istanza per la durata della sessione. È possibile configurare l'affinità di sessione per adattare il dominio del cookie all'intestazione in ingresso dal proxy inverso.

Quando si imposta Proxy affinità di sessione come opzione su true, l'affinità di sessione cerca l'intestazione X-Original-Host o X-Forwarded-Host. Adatta il dominio del cookie al dominio presente nell'intestazione. Come procedura consigliata, quando si abilita il proxy di affinità di sessione, configurare le restrizioni di accesso sul sito per garantire che il traffico provenga dal proxy inverso.

È anche possibile configurare l'impostazione clientAffinityProxyEnabled con il comando Azure CLI seguente:

az resource update --resource-group <your-resource-group> --name <your-web-app> --resource-type "Microsoft.Web/sites" --set properties.clientAffinityProxyEnabled=true

Contenuti correlati

• Esamina la documentazione di App Service Environment
• Applicazione Web sicura con Azure Web Application Firewall
• Distribuire sito sicuro con dominio personalizzato su Azure Front Door o Application Gateway (guida)