Integrazione del gateway applicazione

Tre varianti del servizio app Azure richiedono una configurazione leggermente diversa dell'integrazione con app Azure lication Gateway. Le varianti includono servizio app regolari (note anche come multi-tenant), un ambiente del servizio app di bilanciamento del carico interno (ILB) e un ambiente del servizio app esterno.

Questo articolo illustra come configurare gateway applicazione con servizio app (multi-tenant) usando gli endpoint di servizio per proteggere il traffico. L'articolo illustra anche le considerazioni sull'uso di endpoint privati e l'integrazione con il servizio di bilanciamento del carico interno e le ambiente del servizio app esterne. Infine, l'articolo descrive come impostare le restrizioni di accesso in un sito di Gestione controllo del codice sorgente.Finally, the article describes how to set access restrictions on a Source Control Manager (SCM) site.

Integrazione con servizio app (multi-tenant)

servizio app (multi-tenant) ha un endpoint pubblico con connessione Internet. 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 di servizio app possa ricevere traffico solo da un gateway applicazione specifico.

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.

Questa configurazione include due parti, a parte la creazione dell'istanza servizio app e del gateway applicazione. La prima parte consiste nell'abilitare gli endpoint di servizio nella 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 servizio app sia contrassegnato con l'ID subnet specifico.

La seconda parte consiste nell'impostare 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.

Configurare i servizi usando il portale di Azure

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

  1. Creare un'istanza di servizio app usando una delle guide introduttive nella documentazione di servizio app. Un esempio è la guida introduttiva a .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 in 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 alle servizio app tramite gateway applicazione. Se si tenta di accedere direttamente servizio app, si dovrebbe ricevere un errore HTTP 403 che indica che l'app Web ha bloccato l'accesso.

Screenshot shows the text of Error 403 - Forbidden.

Configurare i servizi usando un modello di Azure Resource Manager

Il modello di distribuzione azure Resource Manager crea uno scenario completo. Lo scenario è costituito da un'istanza di servizio app bloccata con gli endpoint di servizio e una restrizione di accesso per ricevere il traffico solo da gateway applicazione. Il modello include molti prefissi intelligenti e postfissi univoci aggiunti ai nomi delle risorse per renderlo semplice. Per eseguirne l'override, è necessario clonare il repository o scaricare il modello e modificarlo.

Per applicare il modello, è possibile usare il pulsante Distribuisci in Azure nella descrizione del modello. In alternativa, è possibile usare il codice appropriato di PowerShell o dell'interfaccia della riga di comando di Azure.

Configurare i servizi usando l'interfaccia della riga di comando di Azure

L'esempio dell'interfaccia della riga di comando di Azure crea un'istanza di servizio app bloccata con gli endpoint di servizio e una restrizione di accesso per ricevere il traffico solo da gateway applicazione. Se è sufficiente isolare il traffico verso un'istanza di servizio app esistente da un gateway applicazione esistente, usare il comando seguente:

az webapp config access-restriction add --resource-group myRG --name myWebApp --rule-name AppGwSubnet --priority 200 --subnet mySubNetName --vnet-name myVnetName

Nella configurazione predefinita, il comando garantisce la configurazione dell'endpoint di servizio nella subnet e la restrizione di accesso in servizio app.

Considerazioni sull'uso di endpoint privati

In alternativa agli endpoint di servizio, è possibile usare endpoint privati per proteggere il traffico tra gateway applicazione e servizio app (multi-tenant). È necessario assicurarsi che gateway applicazione possa usare DNS per risolvere l'indirizzo IP privato delle app servizio app. In alternativa, è possibile usare l'indirizzo IP privato nel pool back-end ed eseguire l'override del nome host nelle impostazioni 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.

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 privato di Azure si è verificato dopo aver configurato il pool back-end.

Per riavviare il gateway applicazione, 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

Considerazioni per un ambiente del servizio app ILB

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

Se si vuole assicurarsi che solo il traffico proveniente dalla subnet gateway applicazione raggiunga il ambiente del servizio app, è possibile configurare un gruppo di sicurezza di rete (NSG) che influisce su tutte le app Web nel ambiente del servizio app. Per il gruppo di sicurezza di rete, è possibile specificare l'intervallo ip della subnet e facoltativamente le porte (80/443). Affinché il ambiente del servizio app funzioni correttamente, assicurarsi di non eseguire l'override delle regole del gruppo di sicurezza di rete necessarie.

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 servizio app multi-tenant. Gli endpoint di servizio non funzionano per un ambiente del servizio app. Ecco perché è necessario 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 questa guida introduttiva.

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. È probabile che si voglia anche bloccarlo 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 usando il comando seguente:

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

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

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 di gateway applicazione per eseguire l'override del nome host e l'uso del dominio predefinito di servizio app (in azurewebsites.netgenere ) è il modo più semplice per configurare l'integrazione. Non richiede la configurazione di un dominio personalizzato e di un certificato in servizio app.

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

Authentication

Quando si usa la funzionalità di autenticazione in servizio app (nota anche come Easy Auth), l'app in genere reindirizza alla pagina di accesso. Poiché servizio app non conosce il nome host originale della richiesta, il reindirizzamento viene eseguito sul nome di dominio predefinito e in genere genera 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. gateway applicazione usa un'intestazione denominata X-Original-Host. Usando la configurazione basata su file per configurare l'autenticazione, è possibile configurare servizio app per adattarsi al nome host originale. Aggiungere questa configurazione al file di configurazione:

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

Affinità ARR

Nelle distribuzioni a più istanze, l'affinità ARR garantisce che le richieste client vengano instradate alla stessa istanza per la durata della sessione. L'affinità ARR non funziona con gli override del nome host. Per il funzionamento dell'affinità di sessione, è necessario configurare un dominio personalizzato e un certificato identici in servizio app e in gateway applicazione e non eseguire l'override del nome host.

Passaggi successivi

Per altre informazioni sulle ambiente del servizio app, vedere la documentazione ambiente del servizio app.

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

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