Condividi tramite

Approcci architetturali per la rete in soluzioni multi-tenant

  • Articolo

Tutte le soluzioni distribuite in Azure richiedono una rete di qualche tipo. A seconda della progettazione della soluzione e del carico di lavoro, i modi in cui si interagisce con i servizi di rete di Azure potrebbero essere diversi. In questo articolo vengono fornite considerazioni e linee guida per gli aspetti di rete delle soluzioni multi-tenant in Azure. Sono incluse informazioni sui componenti di rete di livello inferiore, ad esempio le reti virtuali, attraverso approcci di livello superiore e livello applicazione.

Nota

Azure è un ambiente multi-tenant e i componenti di rete di Azure sono progettati per la multi-tenancy. Anche se non è necessario comprendere i dettagli per progettare una soluzione personalizzata, è possibile ottenere altre informazioni su come Azure isola il traffico di rete virtuale dal traffico di altri clienti.

Considerazioni e requisiti principali

Infrastruttura e servizi della piattaforma

I problemi che si hanno per i componenti di rete variano a seconda della categoria di servizi in uso.

Servizi di infrastruttura

Ogni volta che si usano servizi di infrastruttura, ad esempio macchine virtuali o servizio Azure Kubernetes, è necessario prendere in considerazione e progettare le reti virtuali o le reti virtuali che supportano la connettività dei servizi. È anche necessario considerare gli altri livelli di sicurezza e isolamento che è necessario incorporare nella progettazione. Evitare di basarsi esclusivamente sui controlli a livello di rete.

Servizi della piattaforma

Se si usano i servizi della piattaforma di Azure, ad esempio servizio app, Azure Cosmos DB o database SQL di Azure, l'architettura specifica usata determinerà i servizi di rete necessari.

Se è necessario isolare i servizi della piattaforma da Internet, è necessario usare una rete virtuale. A seconda dei servizi specifici usati, è possibile usare endpoint privati o risorse integrate nella rete virtuale, ad esempio gateway applicazione. Tuttavia, è anche possibile scegliere di rendere disponibili i servizi della piattaforma tramite gli indirizzi IP pubblici e usare le proprie protezioni dei servizi, ad esempio firewall e controlli delle identità. In queste situazioni, potrebbe non essere necessaria una rete virtuale.

La decisione di usare reti virtuali per i servizi della piattaforma è basata su molti requisiti, inclusi i fattori seguenti:

  • Requisiti di conformità: potrebbe essere necessario soddisfare uno standard di conformità specifico. Alcuni standard richiedono la configurazione dell'ambiente Azure in modi specifici.
  • Requisiti dei tenant: anche se la propria organizzazione non ha requisiti specifici per l'isolamento o i controlli a livello di rete, i tenant potrebbero. Assicurarsi di avere una chiara comprensione del modo in cui i tenant accederanno alla soluzione e se hanno ipotesi sulla progettazione della rete.
  • Complessità: può essere più complesso comprendere e usare le reti virtuali. Assicurarsi che il team abbia una chiara comprensione dei principi coinvolti o che sia probabile che si distribuirà un ambiente non sicuro.

Assicurarsi di comprendere le implicazioni dell'uso della rete privata.

Ridimensionamento delle subnet

Quando è necessario distribuire una rete virtuale, è importante considerare attentamente il ridimensionamento e lo spazio degli indirizzi dell'intera rete virtuale e delle subnet all'interno della rete virtuale.

Assicurarsi di avere una chiara comprensione del modo in cui si distribuiranno le risorse di Azure nelle reti virtuali e il numero di indirizzi IP usati da ogni risorsa. Se si distribuiscono nodi di calcolo, server di database o altre risorse specifici del tenant, assicurarsi di creare subnet di dimensioni sufficienti per la crescita del tenant prevista e la scalabilità automatica orizzontale delle risorse.

Analogamente, quando si lavora con i servizi gestiti, è importante comprendere come vengono usati gli indirizzi IP. Ad esempio, quando si usa servizio Azure Kubernetes con Azure Container Networking Interface (CNI), il numero di indirizzi IP utilizzati da una subnet sarà basato su fattori come il numero di nodi, la scalabilità orizzontale e il processo di distribuzione del servizio usato. Quando si usa app Azure Servizio e Funzioni di Azure con l'integrazione della rete virtuale, il numero di indirizzi IP utilizzati si basa sul numero di istanze del piano.

Esaminare le linee guida per la segmentazione delle subnet durante la pianificazione delle subnet.

Accesso pubblico o privato

Valutare se i tenant accederanno ai servizi tramite Internet o tramite indirizzi IP privati.

Per l'accesso basato su Internet (pubblico), è possibile usare regole del firewall, indirizzi IP che consentono l'elenco di indirizzi IP, segreti condivisi e chiavi e controlli basati sull'identità per proteggere il servizio.

Se è necessario abilitare la connettività al servizio usando indirizzi IP privati, è consigliabile usare collegamento privato di Azure Servizio o peering di reti virtuali tra tenant. Per alcuni scenari limitati, è anche consigliabile usare Azure ExpressRoute o Azure Gateway VPN per abilitare l'accesso privato alla soluzione. In genere, questo approccio ha senso solo quando si ha un numero ridotto di tenant e quando si distribuiscono reti virtuali dedicate per ogni tenant.

Accesso agli endpoint dei tenant

Valutare se è necessario inviare dati agli endpoint all'interno delle reti dei tenant, all'interno o all'esterno di Azure. Ad esempio, sarà necessario richiamare un webhook fornito da un cliente o inviare messaggi in tempo reale a un tenant?

Se è necessario inviare dati agli endpoint dei tenant, considerare gli approcci comuni seguenti:

  • Avviare le connessioni dalla soluzione agli endpoint dei tenant tramite Internet. Valutare se le connessioni devono provenire da un indirizzo IP statico. A seconda dei servizi di Azure usati, potrebbe essere necessario distribuire un gateway NAT, un firewall o un servizio di bilanciamento del carico.
  • Distribuire un agente per abilitare la connettività tra i servizi ospitati in Azure e le reti dei clienti, indipendentemente dalla posizione in cui si trovano.
  • Per la messaggistica unidirezionale, è consigliabile usare un servizio come Griglia di eventi di Azure, potenzialmente in combinazione con i domini eventi.

Approcci e modelli da prendere in considerazione

In questa sezione vengono descritti alcuni degli approcci di rete chiave che è possibile considerare in una soluzione multi-tenant. Si inizia descrivendo gli approcci di livello inferiore per i componenti di rete di base e quindi seguendo gli approcci che è possibile considerare per HTTP e altri problemi a livello di applicazione.

Reti virtuali specifiche del tenant con indirizzi IP selezionati dal provider di servizi

In alcune situazioni, è necessario eseguire risorse connesse alla rete virtuale dedicata in Azure per conto di un tenant. Ad esempio, è possibile eseguire una macchina virtuale per ogni tenant oppure potrebbe essere necessario usare endpoint privati per accedere a database specifici del tenant.

Valutare la possibilità di distribuire una rete virtuale per ogni tenant usando uno spazio indirizzi IP controllato dall'utente. Questo approccio consente di eseguire il peering delle reti virtuali per scopi personalizzati, ad esempio se è necessario stabilire una topologia hub-spoke per controllare centralmente il traffico in ingresso e in uscita.

Tuttavia, gli indirizzi IP selezionati dal provider di servizi non sono appropriati se i tenant devono connettersi direttamente alla rete virtuale creata, ad esempio usando il peering reti virtuali. È probabile che lo spazio indirizzi selezionato non sia compatibile con i propri spazi indirizzi.

Reti virtuali specifiche del tenant con indirizzi IP selezionati dal tenant

Se i tenant devono eseguire il peering delle proprie reti virtuali con la rete virtuale gestita per loro conto, valutare la possibilità di distribuire reti virtuali specifiche del tenant con uno spazio indirizzi IP selezionato dal tenant. Questo sistema consente a ogni tenant di assicurarsi che gli intervalli di indirizzi IP nella rete virtuale del sistema non si sovrappongano alle proprie reti virtuali. Usando intervalli di indirizzi IP non sovrapposti, è possibile assicurarsi che le reti siano compatibili per il peering.

Tuttavia, questo approccio significa che è improbabile che sia possibile eseguire il peering tra le reti virtuali dei tenant o adottare una topologia hub-spoke, perché è probabile che si verifichino intervalli di indirizzi IP sovrapposti tra reti virtuali di tenant diversi.

Topologia hub-spoke

La topologia della rete virtuale hub-spoke consente di eseguire il peering di una rete virtuale hub centralizzata con più reti virtuali spoke. È possibile controllare centralmente l'ingresso e l'uscita del traffico per le reti virtuali e controllare se le risorse nella rete virtuale di ogni spoke possono comunicare tra loro. Ogni rete virtuale spoke può anche accedere a componenti condivisi, ad esempio Firewall di Azure, e potrebbe essere in grado di usare servizi come Protezione DDoS di Azure.

Quando si usa una topologia hub-spoke, assicurarsi di pianificare i limiti, ad esempio il numero massimo di reti virtuali con peering e assicurarsi di non usare spazi indirizzi sovrapposti per la rete virtuale di ogni tenant.

La topologia hub-spoke può essere utile quando si distribuiscono reti virtuali specifiche del tenant con indirizzi IP selezionati. La rete virtuale di ogni tenant diventa spoke e può condividere le risorse comuni nella rete virtuale dell'hub. È anche possibile usare la topologia hub-spoke quando si ridimensionano le risorse condivise tra più reti virtuali a scopo di scalabilità o quando si usa il modello Stamp di distribuzione.

Suggerimento

Se la soluzione viene eseguita in più aree geografiche, in genere è consigliabile distribuire hub e risorse hub separati in ogni area. Anche se questa procedura comporta un costo più elevato delle risorse, evita il traffico che attraversa più aree di Azure inutilmente, che può aumentare la latenza delle richieste e comporta addebiti per il peering globale.

Indirizzi IP statici

Valutare se i tenant devono usare il servizio per usare indirizzi IP pubblici statici per il traffico in ingresso, il traffico in uscita o entrambi. Diversi servizi di Azure consentono indirizzi IP statici in modi diversi.

Quando si usano macchine virtuali e altri componenti dell'infrastruttura, è consigliabile usare un servizio di bilanciamento del carico o un firewall per indirizzi IP statici in ingresso e in uscita. È consigliabile usare il gateway NAT per controllare l'indirizzo IP del traffico in uscita. Per altre informazioni sull'uso del gateway NAT in una soluzione multi-tenant, vedere Considerazioni sul gateway NAT di Azure per la multi-tenancy.

Quando si usano i servizi della piattaforma, il servizio specifico usato determina se e come è possibile controllare gli indirizzi IP. Potrebbe essere necessario configurare la risorsa in modo specifico, ad esempio distribuendo una risorsa come una macchina virtuale in una rete virtuale e quindi usando un gateway NAT o un firewall. In alternativa, è possibile richiedere il set corrente di indirizzi IP usati dal servizio per il traffico in uscita. Ad esempio, servizio app fornisce un'API e un'interfaccia Web per ottenere gli indirizzi IP in uscita correnti per l'applicazione.

Agenti

Se è necessario abilitare i tenant per ricevere messaggi avviati dalla soluzione o se è necessario accedere ai dati presenti nelle reti dei tenant, è consigliabile fornire un agente (talvolta denominato gateway locale) che possa essere distribuito all'interno della rete. Questo approccio può essere efficace se le reti dei tenant si trovano in Azure, in un altro provider di servizi cloud o in locale.

L'agente avvia una connessione in uscita a un endpoint specificato e controlla e mantiene attive le connessioni a esecuzione prolungata o esegue il polling intermittente. Prendere in considerazione l'uso di Inoltro di Azure per stabilire e gestire le connessioni dall'agente al servizio. Quando l'agente stabilisce la connessione, esegue l'autenticazione e include alcune informazioni sull'identificatore del tenant in modo che il servizio possa eseguire il mapping della connessione al tenant corretto.

Gli agenti semplificano in genere la configurazione di sicurezza per i tenant. Può essere complesso e rischioso aprire le porte in ingresso, soprattutto in un ambiente locale. Un agente evita la necessità che i tenant prendano questo rischio.

Esempi di servizi Microsoft che forniscono agenti per la connettività alle reti dei tenant includono:

collegamento privato di Azure servizio offre connettività privata dall'ambiente Azure di un tenant alla soluzione. I tenant possono anche usare collegamento privato servizio con la propria rete virtuale per accedere al servizio da un ambiente locale. Azure instrada in modo sicuro il traffico al servizio usando indirizzi IP privati.

Per altre informazioni su collegamento privato e multi-tenancy, vedere Multitenancy e collegamento privato di Azure.

Nomi di dominio, sottodomini e TLS

Quando si lavora con i nomi di dominio e tls (Transport-Layer Security) in una soluzione multi-tenant, esistono alcune considerazioni. Esaminare le considerazioni relative ai nomi di multi-tenancy e di dominio.

Modelli di routing del gateway e offload del gateway

Il modello di routing del gateway e il modello di offload del gateway comportano la distribuzione di un proxy inverso o un gateway di livello 7. I gateway sono utili per fornire servizi di base per un'applicazione multi-tenant, incluse le funzionalità seguenti:

  • Routing delle richieste a back-end o indicatori di distribuzione specifici del tenant.
  • Gestione dei nomi di dominio specifici del tenant e dei certificati TLS.
  • Controllo delle richieste di minacce alla sicurezza tramite un web application firewall (WAF).
  • Memorizzazione nella cache delle risposte per migliorare le prestazioni.

Azure offre diversi servizi che possono essere usati per raggiungere alcuni o tutti questi obiettivi, tra cui Frontdoor di Azure, app Azure lication Gateway e Azure Gestione API. È anche possibile distribuire una soluzione personalizzata usando software come NGINX o HAProxy.

Se si prevede di distribuire un gateway per la soluzione, è consigliabile creare prima un prototipo completo che includa tutte le funzionalità necessarie e verificare che i componenti dell'applicazione continuino a funzionare come previsto. È anche necessario comprendere come il componente gateway verrà ridimensionato per supportare il traffico e l'aumento del tenant.

Modello di hosting del contenuto statico

Il modello di hosting di contenuti statici prevede la gestione del contenuto Web da un servizio di archiviazione nativo del cloud e l'uso di una rete per la distribuzione di contenuti (CDN) per memorizzare nella cache il contenuto.

È possibile usare Frontdoor di Azure o un'altra rete CDN per i componenti statici della soluzione, ad esempio applicazioni JavaScript a pagina singola e per contenuti statici come file di immagine e documenti.

A seconda della modalità di progettazione della soluzione, è anche possibile memorizzare nella cache file o dati specifici del tenant all'interno di una rete CDN, ad esempio risposte API in formato JSON. Questa procedura consente di migliorare le prestazioni e la scalabilità della soluzione, ma è importante valutare se i dati specifici del tenant sono sufficientemente isolati per evitare perdite di dati tra tenant. Si consideri come si prevede di eliminare contenuti specifici del tenant dalla cache, ad esempio quando i dati vengono aggiornati o viene distribuita una nuova versione dell'applicazione. Includendo l'identificatore del tenant nel percorso URL, è possibile controllare se si elimina un file specifico, tutti i file correlati a un tenant specifico o tutti i file per tutti i tenant.

Antipattern da evitare

Non è possibile pianificare la connettività della rete virtuale

Distribuendo le risorse nelle reti virtuali, si ha un notevole controllo sul flusso del traffico attraverso i componenti della soluzione. Tuttavia, l'integrazione della rete virtuale introduce anche complessità, costi e altri fattori da considerare. Questo effetto è particolarmente vero con i componenti PaaS (Platform as a Service).

È importante testare e pianificare la strategia di rete, in modo da individuare eventuali problemi prima di implementarlo in un ambiente di produzione.

Non pianificare i limiti

Azure applica una serie di limiti che influiscono sulle risorse di rete. Questi limiti includono i limiti delle risorse di Azure e i limiti fondamentali del protocollo e della piattaforma. Ad esempio, quando si crea una soluzione multi-tenant su larga scala nei servizi della piattaforma, ad esempio servizio app Azure e Funzioni di Azure, potrebbe essere necessario prendere in considerazione il numero di connessioni TCP e porte SNAT. Quando si lavora con macchine virtuali e servizi di bilanciamento del carico, è necessario considerare anche le limitazioni per le regole in uscita e per le porte SNAT.

Subnet di piccole dimensioni

È importante considerare le dimensioni di ogni subnet per consentire il numero di risorse o istanze di risorse che verranno distribuite, soprattutto quando si ridimensiona. Quando si lavora con le risorse PaaS (Platform as a Service), assicurarsi di comprendere in che modo la configurazione e la scalabilità della risorsa influiscono sul numero di indirizzi IP necessari nella subnet.

Segmentazione di rete non corretta

Se la soluzione richiede reti virtuali, valutare come configurare la segmentazione di rete per consentire di controllare i flussi di traffico in ingresso e in uscita (nord-sud) e i flussi all'interno della soluzione (est-ovest). Decidere se i tenant devono avere reti virtuali personalizzate o se si distribuiranno risorse condivise nelle reti virtuali condivise. La modifica dell'approccio può essere difficile, quindi assicurarsi di prendere in considerazione tutti i requisiti e quindi selezionare un approccio che funzionerà per gli obiettivi di crescita futuri.

Basarsi solo sui controlli di sicurezza a livello di rete

Nelle soluzioni moderne è importante combinare la sicurezza a livello di rete con altri controlli di sicurezza e non è consigliabile basarsi solo su firewall o segmentazione di rete. Questa operazione è talvolta denominata rete zero-trust. Usare i controlli basati sull'identità per verificare il client, il chiamante o l'utente a ogni livello della soluzione. Prendere in considerazione l'uso di servizi che consentono di aggiungere altri livelli di protezione. Le opzioni disponibili dipendono dai servizi di Azure usati. Nel servizio Azure Kubernetes prendere in considerazione l'uso di una mesh di servizi per l'autenticazione TLS reciproca e i criteri di rete per controllare il traffico east-west. In servizio app è consigliabile usare il supporto predefinito per le restrizioni di autenticazione e autorizzazione e accesso.

Riscrittura delle intestazioni host senza test

Quando si usa il modello di offload del gateway, è possibile riscrivere l'intestazione Host delle richieste HTTP. Questa procedura può semplificare la configurazione del servizio applicazione Web back-end eseguendo l'offload del dominio personalizzato e della gestione TLS nel gateway.

Tuttavia, Host le riscritture dell'intestazione possono causare problemi per alcuni servizi back-end. Se l'applicazione genera reindirizzamenti HTTP o cookie, la mancata corrispondenza nei nomi host può interrompere la funzionalità dell'applicazione. In particolare, questo problema può verificarsi quando si usano servizi back-end che sono stessi multi-tenant, ad esempio servizio app Azure, Funzioni di Azure e App Azure Spring. Per altre informazioni, vedere la procedura consigliata per la conservazione dei nomi host.

Assicurarsi di testare il comportamento dell'applicazione con la configurazione del gateway che si prevede di usare.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autore principale:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi