Funzionalità di rete di 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, Per molte applicazioni, è necessario controllare il traffico di rete in ingresso e in uscita. Esistono diverse funzionalità in Servizio app per soddisfare tali esigenze. La sfida consiste nel sapere quale funzionalità usare per risolvere un determinato problema. Usare questo articolo per determinare quale funzionalità usare, in base a casi d'uso di esempio.

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

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

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

Funzionalità di rete di 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 del servizio app esistono 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 rete.

Invece di connettere le reti, sono necessarie funzionalità per gestire i vari aspetti della comunicazione delle applicazioni. Le funzionalità che gestiscono le richieste all' app non possono essere usate per risolvere i problemi quando si effettuano chiamate dall'app. Analogamente, le funzionalità che risolvono i problemi per le chiamate dalla tua app non possono essere usate per risolvere i problemi verso l'app.

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 di Servizio app per risolvere i problemi relativi al controllo del traffico verso l'app:

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

Comportamento di 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 vengono 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 vengono 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 ancora un altro tipo di macchina virtuale. E PremiumV4 usa ancora un altro tipo 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 cambiano. Se si passa da PremiumV2 a PremiumV3, gli indirizzi in uscita cambiano. In alcune unità di scala precedenti, sia gli indirizzi in ingresso sia quelli in uscita cambiano quando si passa da Standard a PremiumV2.

Esistono numerosi 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. Tutte le app eseguite nella stessa famiglia di macchine virtuali di lavoro nella distribuzione del servizio app condividono questi indirizzi. Se si vogliono visualizzare tutti gli indirizzi che l'app potrebbe usare in un'unità di scala, è presente una proprietà denominata possibleOutboundAddresses che li elenca.

Servizio app dispone di molti endpoint usati per gestire il servizio. Tali indirizzi vengono pubblicati in un documento separato e sono inclusi anche nel AppServiceManagementtag del servizio IP. Il tag AppServiceManagementviene usato solo in ambienti del servizio app in cui è necessario consentire tale traffico. Gli indirizzi in ingresso del Servizio app vengono rilevati nel AppServicetag del servizio IP. Non esiste alcun tag del servizio IP che contiene gli indirizzi in uscita usati dal servizio app.

Indirizzo assegnato all'app

La funzionalità dell'indirizzo assegnato dall'app è una funzionalità SSL basata su IP. Per accedervi, configurare SSL con l'app. È possibile usare questa funzionalità per le chiamate SSL basate su IP. Può essere usato anche per assegnare all'app un indirizzo che ha solo questo.

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 del servizio app. 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 nel 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 vengono eseguite 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, vedere Restrizioni di accesso del servizio app di Azure.

Questa funzionalità consente di creare un elenco di regole di autorizzazione e negazione 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 altre informazioni, vedere Configurare le restrizioni di accesso del servizio app di Azure.

Endpoint privato

L'endpoint privato è un'interfaccia di rete che connette 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 le app del servizio App.

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. L'unica cosa che è possibile raggiungere nell'endpoint privato è l'app con cui è configurato.

Perimetro di sicurezza di rete

Il perimetro di sicurezza della rete di Azure è un servizio che fornisce un perimetro sicuro per la comunicazione dei servizi PaaS (Platform as a Service). Questi servizi PaaS possono comunicare tra loro all'interno del perimetro. Possono anche comunicare con risorse esterne al perimetro usando regole di accesso in ingresso e in uscita pubbliche.

L'imposizione delle regole NSP usa principalmente la sicurezza basata sull'identità. Questo approccio non può essere completamente applicato nei servizi della piattaforma come servizi app e funzioni che consentono di distribuire il codice e usare l'identità per rappresentare la piattaforma. Se è necessario comunicare con i servizi PaaS che fanno parte di un NSP, aggiungere l'integrazione della rete virtuale alle istanze di servizio app o Funzioni. Comunicare con le risorse PaaS usando endpoint privati.

connessioni ibride

Connessioni ibride del servizio app consente alle app di effettuare chiamate in uscita agli endpoint TCP specificati. L'endpoint può essere locale, in una rete virtuale o in qualsiasi posizione 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 delle connessioni ibride di servizio app nel portale.

Il Servizio app Connessione 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 attraversare la connessione ibrida e uscire da 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 a una 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 e la porta specifici.
• 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 diffusa tra gli sviluppatori. Le altre funzionalità di rete del servizio app in uscita sono correlate alla Rete virtuale di Azure. Le Connessione ibride non dipendono dall'attraversamento di una rete virtuale. Può essere usato per un'ampia gamma di esigenze di rete.

Servizio app Connessione ibride non è a conoscenza di ciò che si sta facendo. È 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. Possono essere 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

Integrazione della rete virtuale del servizio app 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 di 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 nelle reti virtuali di Resource Manager 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 di rete virtuale.
• Contribuire a proteggere tutto il traffico in uscita.
• Forzare il tunneling di tutto il traffico in uscita.

Per altre informazioni, vedere Integrazione della rete virtuale nel servizio app di Azure.

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à usa una VPN da punto a sito per connettere l'host in cui viene eseguita l'app a un gateway Rete virtuale nella rete virtuale. Quando si configura 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 Servizio app di Windows e non funziona con le reti virtuali connesse a ExpressRoute. È consigliabile usare l'integrazione della rete virtuale a livello di area. Per altre informazioni, vedere Configurare l'integrazione della rete virtuale richiesta dal gateway.

Ambiente del servizio app

Un ambiente del servizio app (ASE) è una distribuzione a tenant singolo di Servizio app di Azure eseguita nella rete virtuale di Azure. Alcuni casi d'uso 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 gli 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 sugli 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 nulla nell'ambiente del servizio app o nelle app in esso contenute.

Poiché le app in un ILB ASE possono essere esposte in un indirizzo IP privato, è possibile aggiungere dispositivi WAF per esporre solo alcune app a Internet. La mancata esposizione di altri consente di mantenere il resto sicuro. Questa funzionalità consente di semplificare lo sviluppo di applicazioni multilivello.

Alcune cose 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 singolo servizio tenant.
• Aumentare fino a molte più istanze di quelle possibili nel servizio multi-tenant.
• Caricare i certificati client della CA privata 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 offre la storia migliore per l'hosting di app isolate e dedicate. L'approccio comporta alcune sfide di gestione. Alcuni aspetti da considerare prima di usare un ambiente del servizio app:

• Un ambiente del servizio app viene eseguito all'interno della rete virtuale, ma presenta 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é ridimensionare in modo reattivo.
• Un ambiente del servizio app ha un costo iniziale superiore. Per sfruttare al meglio l'ambiente del servizio app, è necessario pianificare l'inserimento di molti carichi di lavoro in un unico ambiente del servizio app anziché usarla 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. Tutte le regole di rete si applicano a tutto il traffico da e verso l'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. Due dei casi d'uso più comuni sono descritti qui come 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 trovi 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. Fornisce una gran parte di ciò che altrimenti si potrebbe ottenere solo con un ambiente del servizio app.

Creare applicazioni multilivello

Un'applicazione multilivello è un'applicazione in cui è possibile accedere alle applicazioni API back-end 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 può effettuare chiamate alla rete virtuale. Dopo che l'app front-end è connessa alla rete virtuale, decidere come bloccare l'accesso all'applicazione API. È possibile:

• Ospitare sia l'applicazione front-end sia API nello stesso ILB ASE ed esporre l'applicazione 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 avere l'esfiltrazione dei dati dall'app front-end ad altre app nel servizio app.
• Quando si usano endpoint privati, sono in gioco due subnet, che aggiungono 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 di dati.

Entrambi i metodi funzionano 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 situazione è più complessa, 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 controllato rigorosamente. Se si usa un ambiente del servizio app di Azure 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 line-of-business.

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 di endpoint privati espone le app in un indirizzo privato. È necessario configurare il DNS per raggiungere tale indirizzo dall'ambiente locale. Per eseguire questa configurazione, 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 del servizio app

Se si analizza Servizio app, vengono trovate 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: