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. Esistono diverse funzionalità in servizio app per soddisfare tali esigenze. La sfida è 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 piani servizio app negli SKU prezzi Gratuito, Condiviso, Basic, Standard, Premium, PremiumV2 e PremiumV3.
  • L'ambiente del servizio app a tenant singolo ospita gli SKU isolati servizio app piani 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 quando si effettuano 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 annotate, è 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, potrebbe esserci qualche modo per risolvere il problema. La scelta della funzionalità migliore a volte supera 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 di
servizio Load Balancer interni (ILB) Endpoint privati dell'ambiente del servizio
Esporre l'app in un INDIRIZZO IP privato nella rete virtuale Endpoint privati dell'ambiente

del servizio app ILB Private IP 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 gateway applicazione DELB
con endpoint
privati gateway applicazione con endpoint
di servizio Frontdoor di Azure con restrizioni di accesso
Bilanciamento del carico del traffico alle app in aree diverse Frontdoor di Azure con restrizioni di accesso
Bilanciamento del 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 Integrazione
della rete virtuale del servizio app
Accedere alle risorse in una rete virtuale di Azure in un'area diversa integrazione della rete virtuale e peering di rete virtuale richiesta gateway di integrazione
della rete virtuale e peering
di rete virtuale
Accedere alle risorse protette con gli endpoint di servizio Integrazione
della rete virtuale del servizio app
Accedere alle risorse in una rete privata non connessa ad Azure connessioni ibride
Accedere alle risorse nei circuiti Di Azure ExpressRoute Integrazione
della rete virtuale del servizio app
Proteggere il traffico in uscita dall'app Web integrazione della rete virtuale e gruppi di
sicurezza di rete
Instradare il traffico in uscita dall'app Web Integrazione della rete virtuale e tabelle
di route 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 gratuiti e condivisi ospitano 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.

Screenshot che mostra le proprietà dell'app.

servizio app include molti endpoint usati per gestire il servizio. Tali indirizzi vengono pubblicati in un documento separato e si trovano anche nel tag del AppServiceManagement servizio IP. Il AppServiceManagement tag viene usato solo in 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 di servizio IP che contiene gli indirizzi in uscita usati da servizio app.

Diagramma che mostra servizio app traffico in ingresso e in uscita.

Indirizzo assegnato all'app

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

Diagramma che illustra l'indirizzo assegnato dall'app.

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 scalabilità di 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 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 vengono eseguite le app. Poiché i ruoli front-end sono upstream dai lavoratori, è possibile pensare alle 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 compilare un elenco di regole consentite e negate valutate nell'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 ilB, è 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.

Diagramma che illustra le restrizioni di accesso.

Endpoint privato

L'endpoint privato è un'interfaccia di rete che si 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 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 attraverso l'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 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 alla porta 443. È possibile scaricare Gestione connessione ibrida dall'interfaccia utente servizio app connessioni ibride nel portale.

Diagramma che mostra il flusso di rete Connessioni ibride.

servizio app connessioni ibride è basato 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 e una porta TCP. 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 fuori 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 dover spostare i database di supporto.
  • Fornire l'accesso con maggiore sicurezza a un singolo host e porta per 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.
  • Si tratta di 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 buco del firewall in ingresso, è popolare con gli sviluppatori. Le altre funzionalità di rete servizio app in uscita sono correlate alla Rete virtuale di Azure. Le connessioni ibride non dipendono dall'uso di una rete virtuale. Può essere usato per una vasta gamma di esigenze di rete.

servizio app connessioni ibride non è a conoscenza di ciò che si sta facendo sopra. È 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 popolari per lo sviluppo, ma vengono usate anche nelle applicazioni di produzione. È ideale per l'accesso a un servizio Web o un database, ma non è appropriato per situazioni che comportano la creazione di molte connessioni.

Integrazione della rete virtuale richiesta dal gateway

L'integrazione della rete virtuale richiesta dal gateway servizio app consente all'app di effettuare richieste in uscita in una rete virtuale di Azure. La funzionalità funziona connettendo l'host in esecuzione all'app a un gateway Rete virtuale nella rete virtuale usando una VPN da punto a sito. Quando si configura la funzionalità, l'app ottiene uno degli indirizzi da punto a sito assegnati a ogni istanza. Questa funzionalità consente di accedere alle risorse in reti virtuali classiche o di Azure Resource Manager in qualsiasi area.

Diagramma che illustra l'integrazione della rete virtuale richiesta dal gateway.

Questa funzionalità risolve il problema di accedere alle risorse in altre reti virtuali. Può essere usata anche per connettersi tramite una rete virtuale ad altre reti virtuali o locali. Non funziona con reti virtuali connesse a ExpressRoute, ma funziona con reti vpn connesse da sito a sito. È inappropriato usare questa funzionalità da un'app in un ambiente del servizio app (AMBIENTE del servizio app) perché l'ambiente del servizio app è già nella rete virtuale. Casi d'uso per questa funzionalità:

  • Accedere alle risorse nelle reti virtuali tra aree che non sono sottoposte a peering a una rete virtuale nell'area.

Quando questa funzionalità è abilitata, l'app userà il server DNS con cui è configurata la rete virtuale di destinazione. Per altre informazioni su questa funzionalità, vedere servizio app integrazione della rete virtuale.

Integrazione della rete virtuale regionale

L'integrazione della rete virtuale richiesta dal gateway è utile, ma non risolve il problema di accedere alle risorse in ExpressRoute. Oltre alla necessità di raggiungere le connessioni ExpressRoute, è necessario che le app possano effettuare chiamate ai servizi protetti dall'endpoint del servizio. Un'altra funzionalità di integrazione della rete virtuale può soddisfare queste esigenze.

La funzionalità di integrazione della rete virtuale a livello di area consente di posizionare il back-end dell'app in una subnet in una rete virtuale Resource Manager nella stessa area dell'app. Questa funzionalità non è disponibile da un ambiente del servizio app, che è 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.
  • Aiutare a proteggere tutto il traffico in uscita.
  • Forzare il tunnel tutto il traffico in uscita.

Diagramma che illustra l'integrazione della rete virtuale.

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

Ambiente del servizio app

Un ambiente del servizio app (AMBIENTE del servizio app) è una distribuzione a tenant singolo dell'Servizio app di Azure eseguita 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 è già nella rete virtuale. Se si desidera accedere alle risorse come SQL o Archiviazione di Azure sugli endpoint di servizio, abilitare gli endpoint di servizio nella subnet del servizio app. Se si desidera accedere alle risorse nella rete virtuale o negli endpoint privati nella rete virtuale, non è necessario eseguire alcuna configurazione aggiuntiva. Se si desidera accedere alle risorse in ExpressRoute, si è già presenti nella rete virtuale e non è necessario configurare alcun elemento nell'ambiente del servizio app o nelle app.

Poiché le app in un ambiente del servizio app ilB possono essere esposte in un indirizzo IP privato, è possibile aggiungere facilmente i dispositivi WAF per esporre solo le app che si desiderano per Internet e 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 servizio a tenant singolo.
  • Aumentare fino a molte più istanze di quanto sia possibile nel servizio multi-tenant.
  • Caricare i certificati client ca privati da usare dalle app con endpoint protetti da CA privati.
  • Forza TLS 1.2 in tutte le app ospitate nel sistema senza alcuna possibilità di disabilitarla a livello di app.

Diagramma che illustra un ambiente del servizio app in una rete virtuale.

L'ambiente del servizio app offre la storia migliore intorno all'hosting di app isolate e dedicate, ma comporta alcune sfide di gestione. Alcune operazioni 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 all'esterno della 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 ridimensiona 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 più elevato. Per sfruttare al meglio l'ambiente del servizio app, è consigliabile 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 verso e da tale ambiente del servizio app. Se si desidera 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, ma sono solo esempi. Comprendendo le varie funzionalità eseguite, è possibile soddisfare quasi tutte le esigenze dell'architettura di sistema.

Inserire un'app in una rete virtuale

Si potrebbe chiedersi 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 per:

  • Creazione di un gateway applicazione con indirizzi in ingresso e in uscita privati.
  • Protezione del traffico in ingresso all'app con endpoint di servizio.
  • L'uso della funzionalità di integrazione della rete virtuale consente di eseguire il back-end dell'app nella rete virtuale.

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

Creare applicazioni multilivello

Un'applicazione a più livelli è un'applicazione in cui è possibile accedere alle app back-end dell'API solo dal livello front-end. Esistono due modi per creare un'applicazione a più livelli. 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 consente all'app Web di effettuare chiamate nella rete virtuale. Dopo la connessione dell'app front-end 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 ilB e 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 DELB.
  • Ospitare sia il front-end che l'app per le API nel servizio multi-tenant.

Se si ospita sia l'app front-end che l'app per le API per un'applicazione a più livelli, è possibile:

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

    Diagramma che illustra l'uso di endpoint privati in un'app a due livelli.

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

    Diagramma che illustra l'uso degli endpoint di servizio per proteggere un'app.

Ecco alcune considerazioni utili per decidere quale metodo usare:

  • Quando si usano endpoint di servizio, è necessario proteggere il traffico all'app per le API nella 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 presenti 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. In una 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 endpoint di servizio con la subnet di integrazione. Quando si usano endpoint privati, è presente una 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 ilB, è 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 anziché usare endpoint privati:

  • È necessaria la protezione WAF nelle app LOB.
  • Si vuole bilanciare il carico in più istanze delle app LOB.

Se nessuna di queste esigenze si applica, è 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 che si inserisce 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 DNS per raggiungere tale indirizzo dall'ambiente locale. Per eseguire questa configurazione, è necessario inoltrare la zona privata DNS di Azure contenente gli endpoint privati ai server DNS locali. Le zone private DNS di Azure non supportano l'inoltro della zona, ma è possibile supportare l'inoltro della zona usando un server DNS per tale scopo. Il modello di inoltro DNS semplifica l'inoltro della zona privata DNS di Azure ai server DNS locali.

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 Porte 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