Approcci architetturali per l'integrazione dei tenant e l'accesso ai dati

È comune che i sistemi si integrino insieme, anche attraverso i limiti dell'organizzazione. Quando si compila una soluzione multi-tenant, potrebbero essere necessari requisiti per inviare i dati ai sistemi dei tenant o per ricevere dati da tali sistemi. In questo articolo vengono illustrate le considerazioni e gli approcci principali per la progettazione e lo sviluppo di integrazioni per una soluzione multi-tenant.

Nota

Se si forniscono più punti di integrazione, è consigliabile considerare ognuno in modo indipendente. Spesso, diversi punti di integrazione hanno requisiti diversi e sono progettati in modo diverso, anche se si connettono gli stessi sistemi in diversi modi.

Considerazioni e requisiti principali

Direzione del flusso di dati

È importante comprendere la direzione in cui vengono trasmessi i dati. La direzione del flusso di dati influisce su diversi aspetti dell'architettura, ad esempio la modalità di gestione dell'identità e della topologia di rete della soluzione. Esistono due flussi di dati comuni:

• Esportare, ovvero i flussi di dati dal sistema multi-tenant ai sistemi dei singoli tenant.
• Importare, ovvero i dati provengono dai sistemi dei tenant nel sistema multi-tenant.

È anche importante considerare la direzione del flusso di dati di rete, che non corrisponde necessariamente alla direzione del flusso di dati logico. Ad esempio, è possibile avviare una connessione in uscita a un tenant in modo da poter importare i dati dal sistema del tenant.

Accesso completo o delegato dall'utente

In molti sistemi, l'accesso a determinati dati è limitato a utenti specifici. I dati a cui un utente può accedere potrebbero non corrispondere ai dati a cui un altro utente può accedere. È importante considerare se si prevede di usare set di dati completi o se i set di dati importati o esportati si basano su ciò che un utente specifico ha l'autorizzazione per accedere.

Si consideri, ad esempio, Microsoft Power BI, un servizio multi-tenant che fornisce report e business intelligence sugli archivi dati di proprietà del cliente. Quando si configura Power BI, si configurano le origini dati per il pull dei dati da database, API e altri archivi dati. È possibile configurare gli archivi dati in due modi diversi:

• Importare tutti i dati dall'archivio dati sottostante. Questo approccio richiede che Power BI venga fornito con le credenziali per un'identità in grado di accedere all'archivio dati completo. Gli amministratori di Power BI possono quindi configurare separatamente le autorizzazioni per i dati importati dopo l'importazione in Power BI. Power BI applica le autorizzazioni.
• Importare un subset di dati dall'archivio dati sottostante, in base alle autorizzazioni di un utente. Quando un utente crea l'origine dati, usa le credenziali e le autorizzazioni associate. Il sottoinsieme esatto di dati importati da Power BI dipende dal livello di accesso dell'utente che ha creato l'origine dati.

Entrambi gli approcci hanno casi d'uso validi, quindi è importante comprendere chiaramente i requisiti dei tenant.

Se si lavora con set di dati completi, il sistema di origine considera effettivamente il sistema di destinazione come sottosistema attendibile. Per questo tipo di integrazione, è anche consigliabile usare un'identità del carico di lavoro anziché un'identità utente. Un'identità del carico di lavoro è un'identità di sistema che non corrisponde a un singolo utente. All'identità del carico di lavoro viene concesso un livello elevato di autorizzazione per i dati nel sistema di origine.

In alternativa, se si usano dati con ambito utente, potrebbe essere necessario usare un approccio come la delega per accedere al subset di dati corretto dal set di dati. Il sistema di destinazione ottiene quindi in modo efficace la stessa autorizzazione di un utente specifico. Per altre informazioni sulla delega utente, vedere l'approccio di accesso utente delegato di seguito. Se si usa la delega, valutare come gestire gli scenari in cui un utente viene deprovisionato o le relative autorizzazioni cambiano.

Batch o in tempo reale

Valutare se si useranno dati in tempo reale o se i dati verranno inviati in batch.

Per le integrazioni in tempo reale, questi approcci sono comuni:

• La richiesta/risposta è la posizione in cui un client avvia una richiesta a un server e riceve una risposta. In genere, le integrazioni di richiesta/risposta vengono implementate usando API o webhook. Le richieste potrebbero essere sincrone, in cui attendono il riconoscimento e una risposta. In alternativa, le richieste possono essere asincrone, usando un modello simile al modello Di richiesta/risposta asincrona per attendere una risposta.
• La comunicazione ad accoppiamento libero è spesso abilitata tramite componenti di messaggistica progettati per l'accoppiamento libero dei sistemi. Ad esempio, bus di servizio di Azure offre funzionalità di accodamento messaggi e Griglia di eventi di Azure e Hub eventi offrono funzionalità di eventing. Questi componenti vengono spesso usati come parte delle architetture di integrazione.

Al contrario, le integrazioni batch vengono spesso gestite tramite un processo in background, che potrebbe essere attivato in determinati momenti del giorno. In genere, le integrazioni batch vengono eseguite tramite un percorso di gestione temporanea, ad esempio un contenitore di archiviazione BLOB, perché i set di dati scambiati possono essere di grandi dimensioni.

Volume dei dati

È importante comprendere il volume di dati che si scambiano tramite un'integrazione, perché queste informazioni consentono di pianificare la capacità complessiva del sistema. Quando si pianifica la capacità del sistema, tenere presente che i diversi tenant potrebbero avere volumi di dati diversi da scambiare.

Per le integrazioni in tempo reale, è possibile misurare il volume come numero di transazioni in un periodo di tempo specificato. Per le integrazioni batch, è possibile misurare il volume come numero di record scambiati o la quantità di dati in byte.

Formati di dati

Quando i dati vengono scambiati tra due parti, è importante che entrambi abbiano una chiara comprensione del modo in cui i dati verranno formattati e strutturati. Considerare le parti seguenti del formato dati:

• Formato di file, ad esempio JSON, Parquet, CSV o XML.
• Schema, ad esempio l'elenco di campi che verranno inclusi, formati di data e valori Null dei campi.

Quando si usa un sistema multi-tenant, se possibile, è consigliabile standardizzare e usare lo stesso formato di dati per tutti i tenant. In questo modo, è possibile evitare di dover personalizzare e ripetere i componenti di integrazione per i requisiti di ogni tenant. In alcune situazioni, tuttavia, potrebbe essere necessario usare formati di dati diversi per comunicare con tenant diversi e pertanto potrebbe essere necessario implementare più integrazioni. Vedere la sezione Componenti di integrazione componibili per un approccio che consente di semplificare questo tipo di situazione.

Accesso ai sistemi dei tenant

Alcune integrazioni richiedono di stabilire una connessione ai sistemi o agli archivi dati del tenant. Quando ci si connette ai sistemi del tenant, è necessario considerare attentamente i componenti di rete e identità della connessione.

Accesso alla rete

Prendere in considerazione la topologia di rete per l'accesso al sistema del tenant, che potrebbe includere le opzioni seguenti:

• Connettersi attraverso Internet. Se ci si connette attraverso Internet, come verrà protetta la connessione e come verranno crittografati i dati? Se i tenant prevedono di limitare in base agli indirizzi IP, assicurarsi che i servizi di Azure usati dalla soluzione possano supportare gli indirizzi IP statici per le connessioni in uscita. Si consideri ad esempio l'uso del gateway NAT per fornire indirizzi IP statici, se necessario. Se è necessaria una VPN, valutare come scambiare le chiavi in modo sicuro con i tenant.
• Gli agenti, distribuiti nell'ambiente di un tenant, possono fornire un approccio flessibile e consentono di evitare la necessità di consentire connessioni in ingresso.
• Gli inoltri, ad esempio Inoltro di Azure, offrono anche un approccio per evitare connessioni in ingresso.

Per altre informazioni, vedere le linee guida sugli approcci di rete per la multi-tenancy.

Autenticazione

Si consideri come eseguire l'autenticazione con ogni tenant quando si avvia una connessione. Considerare gli approcci seguenti:

• Segreti, ad esempio chiavi API o certificati. È importante pianificare la gestione sicura delle credenziali dei tenant. La perdita dei segreti dei tenant potrebbe causare un grave incidente di sicurezza, che potrebbe influire su molti tenant.
• Token Microsoft Entra, in cui si usa un token rilasciato dalla directory Microsoft Entra del tenant. Il token può essere rilasciato direttamente al carico di lavoro usando una registrazione dell'applicazione Microsoft Entra multi-tenant o un'entità servizio specifica. In alternativa, il carico di lavoro può richiedere l'autorizzazione delegata per accedere alle risorse per conto di un utente specifico all'interno della directory del tenant.

Indipendentemente dall'approccio selezionato, assicurarsi che i tenant seguano il principio dei privilegi minimi ed evitare di concedere al sistema autorizzazioni non necessarie. Ad esempio, se il sistema deve leggere solo i dati dall'archivio dati di un tenant, l'identità usata dal sistema non deve avere autorizzazioni di scrittura.

Accesso dei tenant ai sistemi

Se i tenant devono connettersi al sistema, è consigliabile fornire API dedicate o altri punti di integrazione, che è quindi possibile modellare come parte della superficie della soluzione.

In alcune situazioni, è possibile decidere di fornire ai tenant l'accesso diretto alle risorse di Azure. Considerare attentamente le ramificazioni e assicurarsi di comprendere come concedere l'accesso ai tenant in modo sicuro. Ad esempio, è possibile usare uno degli approcci seguenti:

• Usare il modello di passeggino, che prevede l'uso di misure di sicurezza come le firme di accesso condiviso per concedere l'accesso limitato a determinate risorse di Azure.
• Usare risorse dedicate per i punti di integrazione, ad esempio un account di archiviazione dedicato. È consigliabile mantenere separate le risorse di integrazione dalle risorse di sistema principali. Questo approccio consente di ridurre al minimo il raggio di un evento imprevisto di sicurezza. Garantisce inoltre che, se un tenant avvia accidentalmente un numero elevato di connessioni alla risorsa e esaurisce la capacità, il resto del sistema continua a essere eseguito.

Conformità

Quando si inizia a interagire direttamente con i dati dei tenant o trasmetterli, è fondamentale avere una chiara conoscenza dei requisiti di governance e conformità dei tenant.

Approcci e modelli da prendere in considerazione

Esporre le API

Le integrazioni in tempo reale in genere comportano l'esposizione delle API ai tenant o ad altre parti da usare. Le API richiedono considerazioni speciali, soprattutto se usate da parti esterne. Prendere in considerazione le domande seguenti:

• Chi ha concesso l'accesso all'API?
• Come si autenticano gli utenti dell'API?
• Esiste un limite al numero di richieste che un utente dell'API può effettuare per un periodo di tempo?
• Come si forniscono informazioni sulle API e sulla documentazione per ogni API? Ad esempio, è necessario implementare un portale per sviluppatori?

È consigliabile usare un gateway API, ad esempio Azure Gestione API, per gestire questi problemi e molti altri. I gateway API offrono un'unica posizione per implementare i criteri seguiti dalle API e semplificano l'implementazione dei sistemi API back-end. Per altre informazioni su come Gestione API supporta l'architettura multi-tenant, vedere Usare Azure Gestione API in una soluzione multi-tenant.

Modello di passepartout

In alcuni casi, un tenant potrebbe richiedere l'accesso diretto a un'origine dati, ad esempio Archiviazione di Azure. Prendere in considerazione il modello Di passeparte per condividere i dati in modo sicuro e limitare l'accesso all'archivio dati.

Ad esempio, è possibile usare questo approccio durante l'esportazione batch di un file di dati di grandi dimensioni. Dopo aver generato il file di esportazione, è possibile salvarlo in un contenitore BLOB in Archiviazione di Azure e quindi generare una firma di accesso condiviso di sola lettura associata al tempo. Questa firma può essere fornita al tenant, insieme all'URL del BLOB. Il tenant può quindi scaricare il file da Archiviazione di Azure fino alla scadenza della firma.

Analogamente, è possibile generare una firma di accesso condiviso con autorizzazioni per scrivere in un BLOB specifico. Quando si fornisce una firma di accesso condiviso a un tenant, questi possono scrivere i dati nel BLOB. Usando l'integrazione di Griglia di eventi per Archiviazione di Azure, l'applicazione può quindi ricevere una notifica per elaborare e importare il file di dati.

Webhooks

I webhook consentono di inviare eventi ai tenant in un URL fornito dall'utente. Quando si dispone di informazioni da inviare, si avvia una connessione al webhook del tenant e si includono i dati nel payload della richiesta HTTP.

Se si sceglie di creare un sistema di eventi webhook personalizzato, è consigliabile seguire lo standard CloudEvents per semplificare i requisiti di integrazione dei tenant.

In alternativa, è possibile usare un servizio come Griglia di eventi di Azure per fornire funzionalità webhook. Griglia di eventi funziona in modo nativo con CloudEvents e supporta i domini eventi, utili per le soluzioni multi-tenant.

Nota

Ogni volta che si effettuano connessioni in uscita ai sistemi dei tenant, tenere presente che ci si connette a un sistema esterno. Seguire le procedure cloud consigliate, tra cui l'uso del modello Di ripetizione dei tentativi, il modello interruttore e il modello Bulkhead per assicurarsi che i problemi nel sistema del tenant non vengano propagati al sistema.

Accesso utente delegato

Quando si accede ai dati dagli archivi dati di un tenant, valutare se è necessario usare l'identità di un utente specifico per accedere ai dati. In questo caso, l'integrazione è soggetta alle stesse autorizzazioni dell'utente. Questo approccio viene spesso definito accesso delegato.

Si supponga, ad esempio, che il servizio multi-tenant esegua modelli di Machine Learning sui dati dei tenant. È necessario accedere alle istanze di servizi di ogni tenant, ad esempio Azure Synapse Analytics, Archiviazione di Azure, Azure Cosmos DB e altri. Ogni tenant ha la propria directory Microsoft Entra. Alla soluzione può essere concesso l'accesso delegato all'archivio dati, in modo da poter recuperare i dati a cui un utente specifico può accedere.

L'accesso delegato è più semplice se l'archivio dati supporta l'autenticazione di Microsoft Entra. Molti servizi di Azure supportano le identità di Microsoft Entra.

Si supponga, ad esempio, che l'applicazione Web multi-tenant e i processi in background debbano accedere Archiviazione di Azure usando le identità utente dei tenant dall'ID Microsoft Entra. È possibile eseguire i passaggi seguenti:

1. Creare una registrazione dell'applicazione Microsoft Entra multi-tenant che rappresenta la soluzione.
2. Concedere all'applicazione l'autorizzazione delegata per accedere Archiviazione di Azure come utente connesso.
3. Configurare l'applicazione per autenticare gli utenti usando Microsoft Entra ID.

Dopo l'accesso di un utente, Microsoft Entra ID rilascia all'applicazione un token di accesso di breve durata che può essere usato per accedere Archiviazione di Azure per conto dell'utente e rilascia un token di aggiornamento di lunga durata. Il sistema deve archiviare il token di aggiornamento in modo sicuro, in modo che i processi in background possano ottenere nuovi token di accesso e continuare ad accedere Archiviazione di Azure per conto dell'utente.

Messaggistica

La messaggistica consente la comunicazione asincrona ad accoppiamento libero tra sistemi o componenti. La messaggistica viene comunemente usata negli scenari di integrazione per separare i sistemi di origine e di destinazione. Per altre informazioni sulla messaggistica e sulla multi-tenancy, vedere Approcci architetturali per la messaggistica nelle soluzioni multi-tenant.

Quando si usa la messaggistica come parte di un'integrazione con i sistemi dei tenant, valutare se è consigliabile usare firme di accesso condiviso per bus di servizio di Azure o Hub eventi di Azure. Le firme di accesso condiviso consentono di concedere l'accesso limitato alle risorse di messaggistica a terze parti, senza consentire loro di accedere al resto del sottosistema di messaggistica.

In alcuni scenari, è possibile fornire contratti di servizio diversi o garanzie di qualità del servizio (QoS) a tenant diversi. Ad esempio, un subset dei tenant potrebbe prevedere che le richieste di esportazione dei dati vengano elaborate più rapidamente rispetto ad altre. Usando il modello di coda priorità, è possibile creare code separate per livelli di priorità diversi, con istanze di lavoro diverse per assegnarle le priorità di conseguenza.

Componenti di integrazione componibili

In alcuni casi potrebbe essere necessario integrarsi con molti tenant diversi, ognuno dei quali usa formati di dati diversi o tipi diversi di connettività di rete.

Un approccio comune all'integrazione consiste nel compilare e testare singoli passaggi che eseguono i tipi di azioni seguenti:

• Recuperare dati da un archivio dati.
• Trasformare i dati in un formato o uno schema specifico.
• Trasmettere i dati utilizzando un particolare trasporto di rete o un tipo di destinazione noto.

In genere, questi singoli elementi vengono compilati usando servizi come Funzioni di Azure e App per la logica di Azure. Si definisce quindi il processo di integrazione complessivo usando uno strumento come App per la logica o Azure Data Factory e richiama ognuno dei passaggi predefiniti.

Quando si lavora con scenari di integrazione multi-tenant complessi, può essere utile definire una libreria di passaggi di integrazione riutilizzabili. È quindi possibile creare flussi di lavoro per ogni tenant per comporre insieme le parti applicabili, in base ai requisiti di tale tenant. In alternativa, potrebbe essere possibile esporre alcuni dei set di dati o dei componenti di integrazione direttamente ai tenant, in modo che possano creare flussi di lavoro di integrazione personalizzati da essi.

Analogamente, potrebbe essere necessario importare dati da tenant che usano un formato di dati diverso o un trasporto diverso ad altri utenti. Un buon approccio per questo scenario consiste nel creare connettori specifici del tenant. I connettori sono flussi di lavoro che normalizzano e importano i dati in un formato e un percorso standardizzati e quindi attivano il processo di importazione condiviso principale.

Se è necessario compilare codice o logica specifica del tenant, prendere in considerazione il modello Livello anti-danneggiamento. Il modello consente di incapsulare componenti specifici del tenant, mantenendo al tempo stesso il resto della soluzione inconsapevole della complessità aggiunta.

Se si usa un modello tariffario a livelli, è possibile scegliere di richiedere che i tenant con un piano tariffario basso seguano un approccio standard con un set limitato di formati di dati e trasporti. I piani tariffari più elevati possono consentire una maggiore personalizzazione o flessibilità nei componenti di integrazione offerti.

Antipattern da evitare

• Esposizione degli archivi dati primari direttamente ai tenant. Quando i tenant accedono agli archivi dati primari, può diventare più difficile proteggere tali archivi dati e potrebbero causare accidentalmente problemi di prestazioni che influiscono sulla soluzione. Evitare di fornire credenziali agli archivi dati ai clienti e non replicare direttamente i dati dal database primario alle repliche in lettura dei clienti dello stesso sistema di database. Creare invece archivi dati di integrazione dedicati e usare il modello Di passeparte key per esporre i dati.
• Esposizione di API senza un gateway API. Le API hanno problemi specifici per il controllo di accesso, la fatturazione e la misurazione. Anche se inizialmente non si prevede di usare i criteri API, è consigliabile includere un gateway API in anticipo. In questo modo, se è necessario personalizzare i criteri API in futuro, non è necessario apportare modifiche di rilievo agli URL da cui dipende una terza parte.
• Accoppiamento stretto non necessario. L'accoppiamento libero, ad esempio usando approcci di messaggistica , può offrire una gamma di vantaggi per la sicurezza, l'isolamento delle prestazioni e la resilienza. Quando possibile, è consigliabile accoppiare liberamente le integrazioni con terze parti. Se è necessario accoppiare strettamente a terze parti, assicurarsi di seguire procedure consigliate come il modello Retry, il modello Circuit Breaker e il modello Bulkhead.
• Integrazioni personalizzate per tenant specifici. Le funzionalità o il codice specifici del tenant possono rendere la soluzione più difficile da testare. Rende inoltre più difficile modificare la soluzione in futuro, perché è necessario comprendere più percorsi di codice. Provare invece a creare componenti componibili che astraggono i requisiti per qualsiasi tenant specifico e riutilizzarli in più tenant con requisiti simili.

Collaboratori

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

Autori principali:

• John Downs | Principal Software Engineer
• Arsen Vladimirintune | Principal Customer Engineer, FastTrack per Azure

Altro collaboratore:

• Will Velida | Customer Engineer 2, FastTrack per Azure

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

Passaggi successivi

Vedere Approcci architetturali per la messaggistica nelle soluzioni multi-tenant.