Integrazione del gateway applicazione

Questo articolo illustra come configurare gateway applicazione con servizio app usando endpoint privati per proteggere il traffico. L'articolo illustra anche le considerazioni relative all'uso degli endpoint di servizio e all'integrazione con ambiente del servizio app interne ed esterne. Infine, l'articolo descrive come impostare le restrizioni di accesso in un sito di Gestione controllo del codice sorgente (SCM).

Integrazione con servizio app

È possibile usare endpoint privati per proteggere il traffico tra gateway applicazione e l'app servizio app. È necessario assicurarsi che il gateway applicazione possa usare DNS per risolvere l'indirizzo IP privato delle app del servizio app. In alternativa, è possibile usare l'indirizzo IP privato nel pool back-end ed eseguire l'override del nome host nelle impostazioni HTTP.

Il gateway applicazione memorizza nella cache i risultati della ricerca DNS. Se si usano nomi di dominio completi (FQDN) e si fa affidamento sulla ricerca DNS per ottenere l'indirizzo IP privato, potrebbe essere necessario riavviare il gateway applicazione se l'aggiornamento DNS o il collegamento a una zona DNS privata di Azure è avvenuto dopo la configurazione del pool back-end.

Per riavviare il gateway, arrestarlo e avviarlo usando l'interfaccia della riga di comando di Azure:

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

Altre informazioni sulla configurazione di un'app servizio app con endpoint privato.

Considerazioni sull'uso degli endpoint di servizio

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

Questa configurazione include due parti, a parte la creazione dell'istanza dell'app servizio app e del gateway applicazione. La prima parte consiste nell'abilitare gli endpoint di servizio della subnet della rete virtuale in cui viene distribuito il gateway applicazione. 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 consiste nell'impostare una restrizione di accesso dell'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.

Con il portale di Azure, si seguono quattro passaggi per creare e configurare la configurazione del servizio app e del gateway applicazione. Se si dispone di risorse esistenti, è possibile ignorare i primi passaggi.

1. Creare un'istanza del servizio app usando un avvio rapido presente nella documentazione del servizio app. Un esempio è l'avvio rapido di .NET Core.
2. Creare un gateway applicazione usando l'avvio rapido del portale, ma ignorare la sezione relativa all'aggiunta di destinazioni back-end.
3. Configurare servizio app come back-end nel gateway applicazione, ma ignorare la sezione relativa alla limitazione dell'accesso.
4. Creare la restrizione di accesso usando gli endpoint di servizio.

È ora possibile accedere al servizio app tramite il gateway applicazione. Se si tenta di accedere direttamente servizio app, si dovrebbe ricevere un errore HTTP 403 che indica che l'app Web blocca l'accesso.

Considerazioni per un ambiente del servizio app interno

Un ambiente del servizio app interno non è esposto a Internet. Il traffico tra l'istanza e un gateway applicazione è già isolato nella rete virtuale. Per configurare un ambiente del servizio app interno e integrarlo con un gateway applicazione usando il portale di Azure, vedere la guida pratica.

Se si vuole garantire che solo il traffico proveniente dalla subnet del gateway applicazione raggiunga l'ambiente del servizio app, è possibile configurare un gruppo di sicurezza di rete (NSG) che influisca su tutte le app Web nell'ambiente del servizio app. Per il gruppo di sicurezza di rete (NSG), è 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 ambiente del servizio app. L'indirizzo IP deve essere l'indirizzo IP privato del gateway applicazione.

Considerazioni per un ambiente del servizio app esterno

Un ambiente del servizio app esterno dispone di un servizio di bilanciamento del carico pubblico, ad esempio app multi-tenant servizio app. Gli endpoint di servizio non funzionano per un ambiente del servizio app. Con ambiente del servizio app è possibile usare restrizioni di accesso basate su IP usando l'indirizzo IP pubblico del gateway applicazione. Per creare un ambiente del servizio app esterno usando il portale di Azure, è possibile seguire questo avvio rapido.

È anche possibile aggiungere endpoint privati alle app ospitate in un ambiente del servizio app 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 vogliono usare le stesse restrizioni di accesso del sito principale, è possibile ereditare le impostazioni usando il comando seguente:

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

Se si vogliono aggiungere restrizioni di accesso individuali per il sito SCM, è possibile usare il flag --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

Considerazioni sull'uso del dominio predefinito

La configurazione del gateway applicazione per eseguire l'override del nome host e usare il dominio predefinito del servizio app (in genere azurewebsites.net) è il modo più semplice per configurare l'integrazione. Non richiede la configurazione di un dominio personalizzato e di un certificato nel servizio app.

Questo articolo illustra le considerazioni generali per l'override del nome host originale. Nel servizio app esistono due scenari in cui è necessario prestare attenzione a questa configurazione.

Autenticazione

Quando si usa la funzionalità di autenticazione nel servizio app (nota anche come Easy Auth), l'app viene in genere reindirizza 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 applicazione usa un'intestazione denominata X-Original-Host. Usando la configurazione basata su file per configurare 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

Nelle distribuzioni a istanze multiple, l'affinità di sessione garantisce che le richieste client vengano instradate alla stessa istanza per la durata della sessione. L'affinità di sessione può essere configurata per adattare il dominio del cookie all'intestazione in ingresso dal proxy inverso. Configurando il proxy di affinità di sessione su true, l'affinità di sessione cerca X-Original-Host o X-Forwarded-Host adatta il dominio del cookie al dominio presente in questa intestazione. Come procedura consigliata quando si abilita il proxy di affinità di sessione, è necessario configurare le restrizioni di accesso nel sito per assicurarsi che il traffico provena dal proxy inverso.

È anche possibile configurare clientAffinityProxyEnabled usando il comando seguente:

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

Passaggi successivi

Per altre informazioni sugli ambienti del servizio app, vedere la documentazione dell'ambiente del servizio app.

Per proteggere ulteriormente l'app Web, è possibile trovare informazioni su Web application firewall di Azure nel gateway applicazione nella documentazione di Web application firewall di Azure.

Per distribuire un sito sicuro e resiliente con un dominio personalizzato nel servizio app usando il servizio Frontdoor di Azure o il gateway applicazione, vedere questa esercitazione.