Funzionalità di rete del servizio app

È possibile distribuire applicazioni in Servizio app di Azure in diversi modi. Per impostazione predefinita, le app ospitate in Servizio app sono accessibili direttamente tramite Internet e possono raggiungere solo gli endpoint ospitati in Internet, ma per molte applicazioni è necessario controllare il traffico di rete in ingresso e in uscita. Sono disponibili diverse funzionalità in servizio app per soddisfare tali esigenze. La sfida consiste nel sapere quale funzionalità usare per risolvere un determinato problema. Questo articolo consente di determinare quale funzionalità usare, in base ad alcuni casi d'uso di esempio.

Esistono due tipi di distribuzione principali per Servizio app di Azure:

• Il servizio pubblico multi-tenant ospita servizio app piani negli SKU dei prezzi Gratuito, Condiviso, Basic, Standard, Premium, PremiumV2 e PremiumV3.
• Il ambiente del servizio app (AMBIENTE del servizio app) a tenant singolo ospita piani servizio app SKU isolato direttamente nella rete virtuale di Azure.

Le funzionalità usate dipendono dal fatto che si trovi nel servizio multi-tenant o in un ambiente del servizio app.

Nota

Le funzionalità di rete non sono disponibili per le app distribuite in Azure Arc.

Funzionalità di rete del servizio app multi-tenant

Servizio app di Azure è un sistema distribuito. I ruoli che gestiscono le richieste HTTP o HTTPS in ingresso sono chiamati front-end. I ruoli che ospitano il carico di lavoro del cliente sono chiamati ruoli di lavoro. Tutti i ruoli in una distribuzione di Servizio app sono presenti in una rete multi-tenant. Poiché esistono molti clienti diversi nella stessa unità di scala di Servizio app, non è possibile connettere la rete di Servizio app direttamente alla propria rete.

Invece di connettere le reti, sono necessarie funzionalità per gestire i vari aspetti della comunicazione tra applicazioni. Le funzionalità che gestiscono le richieste all'app non possono essere usate per risolvere i problemi durante l'esecuzione di chiamate dall'app . Allo stesso modo, le funzionalità che risolvono i problemi per le chiamate dall'app non possono essere usate per risolvere i problemi verso l'app.

Funzionalità in ingresso	Funzionalità in uscita
Indirizzo assegnato all'app	connessioni ibride
Restrizioni di accesso	Integrazione della rete virtuale richiesta dal gateway
Endpoint di servizio	Integrazione della rete virtuale
Endpoint privati

Oltre alle eccezioni indicate, è possibile usare tutte queste funzionalità insieme. È possibile combinare le funzionalità per risolvere i problemi.

Casi d'uso e funzionalità

Per qualsiasi caso d'uso specifico, potrebbero essere disponibili alcuni modi per risolvere il problema. La scelta della funzionalità migliore a volte va oltre il caso d'uso stesso. I casi d'uso in ingresso seguenti suggeriscono come usare le funzionalità di rete servizio app per risolvere i problemi relativi al controllo del traffico che passa all'app:

Caso d'uso in ingresso	Funzionalità
Supportare le esigenze SSL basate su IP per l'app	Indirizzo assegnato all'app
Supportare l'indirizzo in ingresso dedicato non condiviso per l'app	Indirizzo assegnato all'app
Limitare l'accesso all'app da un set di indirizzi ben definiti	Restrizioni di accesso
Limitare l'accesso all'app dalle risorse in una rete virtuale	Endpoint servizio Endpoint interni Load Balancer (ILB) Endpoint privati dell'ambiente del servizio app
Esporre l'app in un indirizzo IP privato nella rete virtuale	IP privato degli endpoint dell'ambiente del servizio app con bilanciamento del carico interno per il traffico in ingresso in un'istanza di gateway applicazione con endpoint di servizio
Proteggere l'app con un web application firewall (WAF)	gateway applicazione e l'ambiente del servizio app con bilanciamento del carico interno gateway applicazione con endpoint privati gateway applicazione con gli endpoint di servizio Frontdoor di Azure con restrizioni di accesso
Bilanciare il carico del traffico verso le app in aree diverse	Frontdoor di Azure con restrizioni di accesso
Bilanciare il carico del traffico nella stessa area	Gateway applicazione con endpoint di servizio

I casi d'uso in uscita seguenti suggeriscono come usare le funzionalità di rete servizio app per risolvere le esigenze di accesso in uscita per l'app:

Caso d'uso in uscita	Funzionalità
Accedere alle risorse in una rete virtuale di Azure nella stessa area	Ambiente del servizio app per l'integrazione della rete virtuale
Accedere alle risorse in una rete virtuale di Azure in un'area diversa	integrazione della rete virtuale e peering di rete virtuale: integrazione della rete virtuale richiesta dall'ambiente del servizio app e peering di rete virtuale
Accedere alle risorse protette con gli endpoint di servizio	ambiente del servizio app per l'integrazione della rete virtuale
Accedere alle risorse in una rete privata non connessa ad Azure	connessioni ibride
Accedere alle risorse nei circuiti Azure ExpressRoute	ambiente del servizio app per l'integrazione della rete virtuale
Proteggere il traffico in uscita dall'app Web	integrazione della rete virtuale e gruppi di sicurezza di rete dell'ambiente del servizio app
Instradare il traffico in uscita dall'app Web	integrazione della rete virtuale e tabelle di route dell'ambiente del servizio app

Comportamento della rete predefinito

Le unità di scala di Servizio app di Azure supportano molti clienti in ogni distribuzione. I piani SKU gratuito e condiviso ospitano i carichi di lavoro dei clienti nei ruoli di lavoro multi-tenant. I piani Basic e superiori ospitano carichi di lavoro dei clienti dedicati a un solo piano di servizio app. Se si ha un piano di servizio app Standard, tutte le app del piano verranno eseguite nello stesso ruolo di lavoro. Se si aumenta il numero di istanze del ruolo di lavoro, tutte le app in tale piano di servizio app verranno replicate in un nuovo ruolo di lavoro per ogni istanza del piano di servizio app.

Indirizzi in uscita

Le macchine virtuali di lavoro vengono suddivise in gran parte dai piani di servizio app. I piani Gratuito, Condiviso, Basic, Standard e Premium usano tutti lo stesso tipo di macchina virtuale di lavoro. Il piano PremiumV2 usa un altro tipo di macchina virtuale. PremiumV3 usa un altro tipo ancora di macchina virtuale. Quando si modifica la famiglia di macchine virtuali, si ottiene un set diverso di indirizzi in uscita. Se si passa da Standard a PremiumV2, gli indirizzi in uscita cambieranno. Se si passa da PremiumV2 a PremiumV3, gli indirizzi in uscita cambieranno. In alcune unità di scala precedenti, sia gli indirizzi in ingresso che quelli in uscita cambieranno quando si passerà da Standard a PremiumV2.

Esistono molti indirizzi usati per le chiamate in uscita. Gli indirizzi in uscita usati dall'app per effettuare chiamate in uscita sono elencati nelle proprietà dell'app. Questi indirizzi sono condivisi da tutte le app in esecuzione nella stessa famiglia di macchine virtuali di lavoro nella distribuzione di Servizio app. Per visualizzare tutti gli indirizzi che l'app può usare in un'unità di scala, è disponibile una proprietà denominata possibleOutboundAddresses che consente di elencarli.

servizio app dispone di molti endpoint usati per gestire il servizio. Tali indirizzi vengono pubblicati in un documento separato e sono inclusi anche nel tag del AppServiceManagement servizio IP. Il AppServiceManagement tag viene usato solo negli ambienti servizio app in cui è necessario consentire tale traffico. I servizio app indirizzi in ingresso vengono rilevati nel tag del AppService servizio IP. Non esiste alcun tag del servizio IP che contiene gli indirizzi in uscita usati da servizio app.

Indirizzo assegnato all'app

La funzionalità dell'indirizzo assegnato dall'app è un'offshoot della funzionalità SSL basata su IP. È possibile accedervi configurando SSL con l'app. È possibile usare questa funzionalità per le chiamate SSL basate su IP. Puoi anche usarlo per assegnare all'app un indirizzo che ha solo.

Quando si usa un indirizzo assegnato dall'app, il traffico passa comunque attraverso gli stessi ruoli front-end che gestiscono tutto il traffico in ingresso nell'unità di scala servizio app. Ma l'indirizzo assegnato all'app viene usato solo dall'app. Casi d'uso per questa funzionalità:

• Supportare le esigenze SSL basate su IP per l'app.
• Impostare un indirizzo dedicato per l'app che non è condivisa.

Per informazioni su come impostare un indirizzo nell'app, vedere Aggiungere un certificato TLS/SSL in Servizio app di Azure.

Restrizioni di accesso

Le restrizioni di accesso consentono di filtrare le richieste in ingresso . L'azione di filtro viene eseguita sui ruoli front-end upstream dai ruoli di lavoro in cui sono in esecuzione le app. Poiché i ruoli front-end sono upstream dai ruoli di lavoro, è possibile considerare le restrizioni di accesso come protezione a livello di rete per le app. Per altre informazioni sulle restrizioni di accesso, vedere Panoramica delle restrizioni di accesso.

Questa funzionalità consente di creare un elenco di regole consenti e negate valutate in ordine di priorità. È simile alla funzionalità del gruppo di sicurezza di rete (NSG) nella rete di Azure. È possibile usare questa funzionalità in un ambiente del servizio app o nel servizio multi-tenant. Quando lo si usa con un ambiente del servizio app con bilanciamento del carico interno, è possibile limitare l'accesso da blocchi di indirizzi privati. Per informazioni su come abilitare questa funzionalità, vedere Configurazione delle restrizioni di accesso.

Nota

È possibile configurare fino a 512 regole di restrizione di accesso per ogni app.

Endpoint privato

L'endpoint privato è un'interfaccia di rete che consente di connettersi privatamente e in modo sicuro all'app Web tramite collegamento privato di Azure. L'endpoint privato usa un indirizzo IP privato dalla rete virtuale, portando in modo efficace l'app Web nella rete virtuale. Questa funzionalità è solo per i flussi in ingresso all'app Web. Per altre informazioni, vedere Uso di endpoint privati per l'app Web di Azure.

Alcuni casi d'uso per questa funzionalità:

• Limitare l'accesso all'app dalle risorse in una rete virtuale.
• Esporre l'app in un indirizzo IP privato nella rete virtuale.
• Proteggere l'app con un WAF.

Gli endpoint privati impediscono l'esfiltrazione dei dati perché l'unica cosa che è possibile raggiungere nell'endpoint privato è l'app con cui è configurata.

connessioni ibride

servizio app connessioni ibride consente alle app di effettuare chiamate in uscita agli endpoint TCP specificati. L'endpoint può essere locale, in una rete virtuale o in qualsiasi punto qualsiasi che consenta il traffico in uscita ad Azure sulla porta 443. Per usare la funzionalità, è necessario installare un agente di inoltro denominato Gestione connessione ibrida in un host Windows Server 2012 o versione successiva. Gestione connessione ibrida deve essere in grado di raggiungere l'inoltro di Azure sulla porta 443. È possibile scaricare Gestione connessione ibrida dall'interfaccia utente di connessioni ibride di servizio app nel portale.

servizio app connessioni ibride si basa sulla funzionalità Connessioni ibride di Inoltro di Azure. servizio app usa una forma specializzata della funzionalità che supporta solo l'esecuzione di chiamate in uscita dall'app a un host TCP e a una porta. Questo host e la porta devono essere risolti solo nell'host in cui è installato Gestione connessione ibrida.

Quando l'app, in servizio app, esegue una ricerca DNS sull'host e sulla porta definita nella connessione ibrida, il traffico reindirizza automaticamente per passare attraverso la connessione ibrida e all'esterno di Gestione connessione ibrida. Per altre informazioni, vedere servizio app Connessioni ibride.

Questa funzionalità viene comunemente usata per:

• Accedere alle risorse nelle reti private che non sono connesse ad Azure con una VPN o ExpressRoute.
• Supportare la migrazione di app locali a servizio app senza la necessità di spostare i database di supporto.
• Fornire l'accesso con maggiore sicurezza a un singolo host e porta per ogni connessione ibrida. La maggior parte delle funzionalità di rete apre l'accesso a una rete. Con Le connessioni ibride è possibile raggiungere solo l'host singolo e la porta.
• Vengono illustrati gli scenari non coperti da altri metodi di connettività in uscita.
• Eseguire lo sviluppo in servizio app in modo da consentire alle app di usare facilmente le risorse locali.

Poiché questa funzionalità consente l'accesso alle risorse locali senza un foro del firewall in ingresso, è molto diffuso per gli sviluppatori. Le altre funzionalità di rete servizio app in uscita sono correlate alla Rete virtuale di Azure. Le connessioni ibride non dipendono dall'attraversarsi di una rete virtuale. Può essere usato per un'ampia gamma di esigenze di rete.

servizio app connessioni ibride non è a conoscenza di ciò che si sta facendo. È quindi possibile usarlo per accedere a un database, a un servizio Web o a un socket TCP arbitrario in un mainframe. La funzionalità esegue essenzialmente il tunneling dei pacchetti TCP.

Le connessioni ibride sono diffuse per lo sviluppo, ma vengono usate anche nelle applicazioni di produzione. È ideale per accedere a un servizio Web o a un database, ma non è appropriato per situazioni che comportano la creazione di molte connessioni.

Integrazione della rete virtuale

servizio app'integrazione della rete virtuale consente all'app di effettuare richieste in uscita in una rete virtuale di Azure.

La funzionalità di integrazione della rete virtuale consente di posizionare il back-end dell'app in una subnet in una rete virtuale Resource Manager. La rete virtuale deve trovarsi nella stessa area dell'app. Questa funzionalità non è disponibile da un ambiente del servizio app, che si trova già in una rete virtuale. Casi d'uso per questa funzionalità:

• Accedere alle risorse in Resource Manager reti virtuali nella stessa area.
• Accedere alle risorse nelle reti virtuali con peering, incluse le connessioni tra aree.
• Accedere alle risorse protette con gli endpoint di servizio.
• Accedere alle risorse accessibili tra connessioni ExpressRoute o VPN.
• Accedere alle risorse nelle reti private senza la necessità e il costo di un gateway Rete virtuale.
• Proteggere tutto il traffico in uscita.
• Forzare il tunneling di tutto il traffico in uscita.

Per altre informazioni, vedere servizio app'integrazione della rete virtuale.

Integrazione della rete virtuale richiesta dal gateway

L'integrazione della rete virtuale richiesta dal gateway è stata la prima edizione dell'integrazione della rete virtuale in servizio app. La funzionalità funziona connettendo l'host in cui è in esecuzione l'app a un gateway Rete virtuale nella rete virtuale usando una VPN da punto a sito. Quando configuri la funzionalità, l'app ottiene uno degli indirizzi assegnati da punto a sito assegnati a ogni istanza.

L'integrazione richiesta dal gateway consente di connettersi direttamente a una rete virtuale in un'altra area senza peering e di connettersi a una rete virtuale classica. La funzionalità è limitata ai piani di Windows servizio app e non funziona con le reti virtuali connesse a ExpressRoute. È consigliabile usare l'integrazione della rete virtuale a livello di area. Per altre informazioni su questa funzionalità, vedere integrazione della rete virtuale servizio app.

Ambiente del servizio app

Un ambiente del servizio app (AMBIENTE del servizio app) è una distribuzione a tenant singolo del Servizio app di Azure in esecuzione nella rete virtuale. Alcuni casi, ad esempio, per questa funzionalità:

• Accedere alle risorse nella rete virtuale.
• Accedere alle risorse in ExpressRoute.
• Esporre le app con un indirizzo privato nella rete virtuale.
• Accedere alle risorse tra endpoint di servizio.
• Accedere alle risorse tra endpoint privati.

Con un ambiente del servizio app non è necessario usare l'integrazione della rete virtuale perché l'ambiente del servizio app si trova già nella rete virtuale. Se si vuole accedere a risorse come SQL o Archiviazione di Azure tramite endpoint di servizio, abilitare gli endpoint di servizio nella subnet dell'ambiente del servizio app. Se si vuole accedere alle risorse nella rete virtuale o negli endpoint privati nella rete virtuale, non è necessario eseguire alcuna configurazione aggiuntiva. Se si vuole accedere alle risorse in ExpressRoute, si è già nella rete virtuale e non è necessario configurare alcun elemento nell'ambiente del servizio app o nelle app in esso contenute.

Poiché le app in un ambiente del servizio app con bilanciamento del carico interno possono essere esposte in un indirizzo IP privato, è possibile aggiungere facilmente dispositivi WAF per esporre solo le app che si desiderano a Internet e proteggere il resto. Questa funzionalità consente di semplificare lo sviluppo di applicazioni multilivello.

Alcuni elementi non sono attualmente possibili dal servizio multi-tenant, ma sono possibili da un ambiente del servizio app. Di seguito sono riportati alcuni esempi:

• Ospitare le app in un servizio a tenant singolo.
• Aumentare fino a molte più istanze di quanto sia possibile nel servizio multi-tenant.
• Caricare i certificati client ca privati per l'uso da parte delle app con endpoint privati protetti dalla CA.
• Forzare TLS 1.2 in tutte le app ospitate nel sistema senza alcuna possibilità di disabilitarla a livello di app.

L'ambiente del servizio app fornisce la storia migliore per l'hosting di app isolate e dedicate, ma comporta alcune problematiche di gestione. Alcuni aspetti da considerare prima di usare un ambiente del servizio app operativo:

• Un ambiente del servizio app viene eseguito all'interno della rete virtuale, ma ha dipendenze esterne alla rete virtuale. Tali dipendenze devono essere consentite. Per altre informazioni, vedere Considerazioni sulla rete per un ambiente del servizio app.
• Un ambiente del servizio app non viene ridimensionato immediatamente come il servizio multi-tenant. È necessario prevedere le esigenze di ridimensionamento anziché il ridimensionamento reattivo.
• Un ambiente del servizio app ha un costo iniziale più elevato. Per sfruttare al meglio l'ambiente del servizio app, è necessario pianificare l'inserimento di molti carichi di lavoro in un ambiente del servizio app anziché usarlo per piccoli sforzi.
• Le app in un ambiente del servizio app non possono limitare in modo selettivo l'accesso ad alcune app nell'ambiente del servizio app e non ad altre.
• Un ambiente del servizio app si trova in una subnet e tutte le regole di rete si applicano a tutto il traffico da e verso tale ambiente del servizio app. Se si vogliono assegnare regole di traffico in ingresso per una sola app, usare le restrizioni di accesso.

Combinazione di funzionalità

Le funzionalità indicate per il servizio multi-tenant possono essere usate insieme per risolvere casi d'uso più elaborati. Di seguito sono descritti due dei casi d'uso più comuni, ma sono solo esempi. Comprendendo le varie funzionalità, è possibile soddisfare quasi tutte le esigenze dell'architettura di sistema.

Inserire un'app in una rete virtuale

Ci si potrebbe chiedere come inserire un'app in una rete virtuale. Se si inserisce l'app in una rete virtuale, gli endpoint in ingresso e in uscita per l'app si trovano all'interno della rete virtuale. Un ambiente del servizio app è il modo migliore per risolvere questo problema. È tuttavia possibile soddisfare la maggior parte delle esigenze all'interno del servizio multi-tenant combinando le funzionalità. Ad esempio, è possibile ospitare applicazioni solo Intranet con indirizzi in ingresso e in uscita privati tramite:

• Creazione di un gateway applicazione con indirizzi in ingresso e in uscita privati.
• Protezione del traffico in ingresso verso l'app con gli endpoint di servizio.
• Usando la funzionalità di integrazione della rete virtuale in modo che il back-end dell'app si trova nella rete virtuale.

Questo stile di distribuzione non offre un indirizzo dedicato per il traffico in uscita verso Internet o la possibilità di bloccare tutto il traffico in uscita dall'app. Ti darà una gran parte di ciò che si otterrebbe solo altrimenti con un ambiente del servizio app.

Creare applicazioni multilivello

Un'applicazione multilivello è un'applicazione in cui è possibile accedere alle app back-end api solo dal livello front-end. Esistono due modi per creare un'applicazione multilivello. Entrambi iniziano usando l'integrazione della rete virtuale per connettere l'app Web front-end a una subnet in una rete virtuale. In questo modo l'app Web verrà abilitata per effettuare chiamate alla rete virtuale. Dopo che l'app front-end è connessa alla rete virtuale, è necessario decidere come bloccare l'accesso all'applicazione API. È possibile:

• Ospitare sia il front-end che l'app per le API nello stesso ambiente del servizio app con bilanciamento del carico interno ed esporre l'app front-end a Internet usando un gateway applicazione.
• Ospitare il front-end nel servizio multi-tenant e il back-end in un ambiente del servizio app con bilanciamento del carico interno.
• Ospitare sia il front-end che l'app per le API nel servizio multi-tenant.

Se si ospitano sia l'app front-end che l'app per le API per un'applicazione multilivello, è possibile:

• Esporre l'applicazione API usando endpoint privati nella rete virtuale:

  

• Usare gli endpoint di servizio per garantire che il traffico in ingresso all'app per le API provenga solo dalla subnet usata dall'app Web front-end:

  

Ecco alcune considerazioni utili per decidere quale metodo usare:

• Quando si usano gli endpoint di servizio, è sufficiente proteggere il traffico verso l'app per le API alla subnet di integrazione. Gli endpoint di servizio consentono di proteggere l'app per le API, ma è comunque possibile che l'esfiltrazione dei dati dall'app front-end ad altre app nel servizio app.
• Quando si usano endpoint privati, sono disponibili due subnet in fase di riproduzione, che aggiunge complessità. Inoltre, l'endpoint privato è una risorsa di primo livello e aggiunge un sovraccarico di gestione. Il vantaggio dell'uso di endpoint privati è che non si ha la possibilità di esfiltrazione dei dati.

Entrambi i metodi funzioneranno con più front-end. Su scala ridotta, gli endpoint di servizio sono più facili da usare perché è sufficiente abilitare gli endpoint di servizio per l'app per le API nella subnet di integrazione front-end. Quando si aggiungono altre app front-end, è necessario modificare ogni app per le API per includere gli endpoint di servizio con la subnet di integrazione. Quando si usano endpoint privati, la complessità è maggiore, ma non è necessario modificare nulla nelle app per le API dopo aver impostato un endpoint privato.

Applicazioni line-of-business

Le applicazioni line-of-business (LOB) sono applicazioni interne che normalmente non sono esposte per l'accesso da Internet. Queste applicazioni vengono chiamate dall'interno delle reti aziendali in cui l'accesso può essere strettamente controllato. Se si usa un ambiente del servizio app con bilanciamento del carico interno, è facile ospitare le applicazioni line-of-business. Se si usa il servizio multi-tenant, è possibile usare endpoint privati o usare endpoint di servizio combinati con un gateway applicazione. Esistono due motivi per usare un gateway applicazione con endpoint di servizio invece di usare endpoint privati:

• È necessaria la protezione WAF nelle app line-of-business.
• Si vuole bilanciare il carico in più istanze delle app LINEB.

Se nessuna di queste esigenze è applicabile, è preferibile usare endpoint privati. Con gli endpoint privati disponibili in servizio app, è possibile esporre le app in indirizzi privati nella rete virtuale. L'endpoint privato inserito nella rete virtuale può essere raggiunto tra le connessioni ExpressRoute e VPN.

La configurazione degli endpoint privati espone le app in un indirizzo privato, ma è necessario configurare il DNS per raggiungere tale indirizzo dall'ambiente locale. Per eseguire questa configurazione, è necessario inoltrare la zona privata DNS di Azure che contiene gli endpoint privati ai server DNS locali. Le zone private di DNS di Azure non supportano l'inoltro della zona, ma è possibile supportare l'inoltro della zona usando il resolver privato DNS di Azure.

porte servizio app

Se si analizza servizio app, sono disponibili diverse porte esposte per le connessioni in ingresso. Non è possibile bloccare o controllare l'accesso a queste porte nel servizio multi-tenant. Ecco l'elenco delle porte esposte:

Uso	Porta o porte
HTTP/HTTPS	80, 443
Gestione	454, 455
FTP/FTPS	21, 990, 10001-10300
Debug remoto in Visual Studio	4020, 4022, 4024
Servizio Distribuzione Web	8172
Uso dell'infrastruttura	7654, 1221