Scenari di gestione degli utenti multi-tenant
Questo articolo è il secondo di una serie di articoli che forniscono indicazioni per la configurazione e la gestione del ciclo di vita degli utenti negli ambienti multi-tenant di Microsoft Entra. Gli articoli seguenti della serie forniscono altre informazioni, come descritto.
- Introduzione alla gestione degli utenti multi-tenant è il primo di una serie di articoli che forniscono indicazioni per la configurazione e la gestione del ciclo di vita degli utenti negli ambienti multi-tenant di Microsoft Entra.
- Considerazioni comuni per la gestione degli utenti multi-tenant fornisce indicazioni su queste considerazioni: sincronizzazione tra tenant, oggetto directory, accesso condizionale di Microsoft Entra, controllo di accesso aggiuntivo e Office 365.
- Soluzioni comuni per la gestione degli utenti multi-tenant quando la tenancy singola non funziona per lo scenario in uso: questo articolo fornisce materiale sussidiario relativo alle problematiche seguenti: gestione automatica del ciclo di vita degli utenti, allocazione delle risorse tra tenant e condivisione di app locali tra tenant.
Il materiale sussidiario aiuta a ottenere uno stato coerente della gestione del ciclo di vita degli utenti. La gestione del ciclo di vita include il provisioning, la gestione e il deprovisioning degli utenti tra tenant usando gli strumenti di Azure disponibili che includono Collaborazione B2B Microsoft Entra e la sincronizzazione tra tenant.
Questo articolo descrive tre scenari per i quali è possibile usare le funzionalità di gestione degli utenti multi-tenant.
- Avviati dall'utente finale
- Esecuzione script
- Automatizzato
Scenario avviato dall'utente finale
Negli scenari avviati dall'utente finale, gli amministratori tenant delle risorse delegano determinate capacità agli utenti nel tenant. Gli amministratori consentono agli utenti finali di invitare utenti esterni al tenant, a un'app o a una risorsa. È possibile invitare gli utenti dal tenant principale oppure possono iscriversi singolarmente.
Ad esempio, una società di servizi professionali a livello globale collabora con subappaltatori su progetti. I subappaltatori (utenti esterni) richiedono l'accesso alle applicazioni e ai documenti dell'azienda. Gli amministratori aziendali possono delegare agli utenti finali la possibilità di invitare subappaltatori o eseguire la configurazione self-service per l'accesso alle risorse dei subappaltatori.
Account di provisioning
Ecco i modi più usati per invitare gli utenti finali ad accedere alle risorse del tenant.
- Inviti basati su applicazioni. Le applicazioni Microsoft (ad esempio Teams e SharePoint) possono abilitare gli inviti degli utenti esterni. Configurare le impostazioni degli inviti B2B sia in Microsoft Entra B2B che nelle applicazioni pertinenti.
- MyApps. Gli utenti possono invitare e assegnare utenti esterni alle applicazioni usando MyApps. L'account utente deve disporre delle autorizzazioni di approvazione dell'iscrizione self-service all'applicazione. I proprietari del gruppo possono invitare utenti esterni nei propri gruppi.
- Gestione entitlement. Consentire agli amministratori o ai proprietari delle risorse di creare pacchetti di accesso con risorse, organizzazioni esterne consentite, scadenza degli utenti esterni e criteri di accesso. Pubblicare pacchetti di accesso per abilitare l'iscrizione self-service degli utenti esterni per l'accesso alle risorse.
- Portale di Azure. Gli utenti finali con il ruolo Mittente dell'invito guest possono accedere al portale di Azure e invitare utenti esterni dal menu Utenti in Microsoft Entra ID.
- Programmatico (PowerShell, API Graph). Gli utenti finali con il ruolo Mittente dell'invito guest possono usare PowerShell o l'API Graph per invitare utenti esterni.
Riscatto degli inviti
Quando si effettua il provisioning degli account per accedere a una risorsa, gli inviti tramite e-mail vengono inviati all'indirizzo di posta elettronica dell'utente invitato.
Quando un utente invitato riceve un invito, può seguire il collegamento all'URL per il riscatto contenuto nel messaggio di posta elettronica. In questo modo, l'utente invitato può approvare o negare l'invito e, se necessario, creare un account utente esterno.
Gli utenti invitati possono anche provare ad accedere direttamente alla risorsa, definita riscatto just-in-time (JIT), se uno degli scenari seguenti è vero.
- L'utente invitato ha già un account Microsoft Entra ID o Microsoft oppure
- Gli amministratori hanno abilitato i passcode monouso tramite e-mail.
Durante il riscatto JIT, possono essere applicate le considerazioni seguenti.
- Se gli amministratori non hanno eliminato le richieste di consenso, l'utente deve fornire il consenso prima di accedere alla risorsa.
- È possibile consentire o bloccare gli inviti a utenti esterni da organizzazioni specifiche usando un elenco di elementi consentiti o un elenco di elementi bloccati.
Per altre informazioni, vedere Riscatto dell'invito di Collaborazione B2B di Microsoft Entra.
Abilitazione dell’autenticazione con passcode monouso
Negli scenari in cui si consente il B2B ad hoc, abilitare l'autenticazione con passcode monouso tramite e-mail. Questa funzionalità autentica gli utenti esterni quando non è possibile autenticarli tramite altri mezzi, ad esempio:
- Microsoft Entra ID.
- Account Microsoft.
- Account Gmail tramite Federazione Google.
- Account da un provider di identità SAML (Security Assertion Markup Language)/WS-Fed tramite federazione diretta.
Grazie all'autenticazione con passcode monouso, non è necessario creare un account Microsoft. Quando l'utente esterno riscatta un invito o accede a una risorsa condivisa, riceve un codice temporaneo all'indirizzo di posta elettronica. Quindi immette il codice per continuare ad accedere.
Gestione degli account
Nello scenario avviato dall'utente finale, l'amministratore tenant delle risorse gestisce gli account utente esterni nel tenant delle risorse (non aggiornato in base ai valori aggiornati nel tenant principale). Gli unici attributi visibili ricevuti includono l'indirizzo e-mail e il nome visualizzato.
È possibile configurare più attributi sugli oggetti utente esterni per facilitare scenari diversi (ad esempio, scenari entitlement). È possibile includere il popolamento della rubrica con i dettagli di contatto. Si consideri ad esempio gli attributi seguenti.
- HiddenFromAddressListsEnabled [ShowInAddressList]
- FirstName [GivenName]
- LastName [SurName]
- Title
- Reparto
- TelephoneNumber
È possibile impostare questi attributi per aggiungere utenti esterni all'elenco indirizzi globale (GAL) e alla ricerca utenti (ad esempio, Selezione persone di SharePoint). Altri scenari potrebbero richiedere attributi diversi (ad esempio, l'impostazione di diritti e autorizzazioni per i pacchetti di accesso, l'appartenenza a gruppi dinamica e le attestazioni SAML).
Per impostazione predefinita, l'elenco indirizzi globale nasconde gli utenti esterni invitati. Impostare gli attributi degli utenti esterni da mostrare per includerli nell'elenco indirizzi globale unificato. La sezione Considerazioni comuni sulla gestione degli utenti multi-tenant di Microsoft Exchange Online descrive come ridurre i limiti creando utenti membri esterni anziché utenti guest esterni.
Deprovisioning degli account
Gli scenari avviati dall'utente finale decentralizzano le decisioni di accesso e possono, quindi, comportare la sfida di decidere quando rimuovere un utente esterno e l'accesso associato. La gestione entitlement e le revisioni degli accessi consentono di esaminare e rimuovere gli utenti esterni esistenti e il relativo accesso alle risorse.
Quando si invitano utenti all'esterno della gestione entitlement, è necessario creare un processo separato per esaminare e gestire l'accesso. Ad esempio, se si invita direttamente un utente esterno tramite SharePoint in Microsoft 365, lo stesso non si trova all’interno del processo di gestione entitlement.
Scenario con esecuzione di script
Nello scenario con esecuzione di script gli amministratori del tenant delle risorse distribuiscono un processo pull con esecuzione di script per automatizzare l'individuazione e il provisioning degli utenti esterni.
Ad esempio, una società acquisisce un concorrente. Ogni società ha un singolo tenant di Microsoft Entra. La società vuole che gli scenari del primo giorno seguenti funzionino senza che gli utenti debbano eseguire alcuna procedura di invito o riscatto. Tutti gli utenti devono essere in grado di:
- Usare l'accesso Single Sign-On per tutte le risorse di cui è stato effettuato il provisioning.
- Individuarsi reciprocamente e trovare le risorse in un elenco indirizzi globale unificato.
- Determinare la presenza degli altri utenti e avviare la chat.
- Accedere alle applicazioni in base a gruppi di appartenenza dinamica.
In questo scenario, il tenant di ogni organizzazione è il tenant principale per i dipendenti esistenti, mentre è il tenant delle risorse per i dipendenti dell'altra organizzazione.
Account di provisioning
Con la query delta, gli amministratori tenant possono distribuire un processo pull con esecuzione di script per automatizzare l’individuazione e il provisioning di identità per supportare l'accesso alle risorse. Questo processo controlla il tenant principale per i nuovi utenti. Usa le API Graph B2B per effettuare il provisioning di nuovi utenti come utenti esterni nel tenant delle risorse, come illustrato nel diagramma della topologia multi-tenant seguente.
- Gli amministratori tenant predispongono le credenziali e l’autorizzazione per consentire la lettura a ogni tenant.
- Gli amministratori tenant automatizzano l'enumerazione e il pull degli utenti con ambito nel tenant delle risorse.
- Usare l'API Microsoft Graph con autorizzazioni concesse per leggere gli utenti ed effettuare il provisioning degli stessi con l'API di invito.
- Il provisioning iniziale può leggere gli attributi di origine e applicarli all'oggetto utente di destinazione.
Gestione degli account
L'organizzazione delle risorse può aumentare i dati del profilo per supportare scenari di condivisione aggiornando gli attributi dei metadati dell'utente nel tenant delle risorse. Tuttavia, se è necessaria una sincronizzazione in corso, una soluzione sincronizzata potrebbe rappresentare un'opzione migliore.
Deprovisioning degli account
La query delta può segnalare quando è necessario eseguire il deprovisioning di un utente esterno. La gestione entitlement e le revisioni degli accessi possono fornire un modo per esaminare e rimuovere gli utenti esterni esistenti e il loro accesso alle risorse.
Se si invitano utenti all'esterno della gestione entitlement, creare un processo separato per esaminare e gestire l'accesso degli utenti esterni. Ad esempio, se si invita l’utente esterno direttamente tramite SharePoint in Microsoft 365, lo stesso non si trova all’interno del processo di gestione entitlement.
Scenario automatizzato
La condivisione sincronizzata tra tenant è il più complesso dei criteri descritti in questo articolo. Questo modello consente opzioni di gestione e deprovisioning più automatizzate rispetto a quelle avviate dall'utente finale o con esecuzione di script.
Negli scenari automatizzati, gli amministratori del tenant delle risorse usano un sistema di provisioning delle identità per automatizzare i processi di provisioning e deprovisioning. Negli scenari all'interno dell'istanza del cloud commerciale di Microsoft, è disponibile la sincronizzazione tra tenant. Negli scenari che si estendono su istanze di cloud sovrano Microsoft, sono necessari altri approcci perché la sincronizzazione tra tenant non supporta ancora il cross-cloud.
Ad esempio, all'interno di un'istanza del cloud commerciale di Microsoft, un conglomerato multinazionale/regionale ha più filiali con i requisiti seguenti.
- Ognuna ha il proprio tenant di Microsoft Entra e deve collaborare.
- Oltre a sincronizzare nuovi utenti tra i tenant, sincronizzare automaticamente gli aggiornamenti degli attributi e automatizzare il deprovisioning.
- Se un dipendente non è più in una filiale, rimuovere il relativo account da tutti gli altri tenant durante la sincronizzazione successiva.
In uno scenario esteso e cross-cloud, un appaltatore di base industriale per la difesa (DIB) ha una filiale basata sulla difesa e una basata sul commercio. Queste hanno requisiti di regolamentazione concorrenti:
- L'azienda per la difesa USA risiede in un tenant del cloud sovrano degli Stati Uniti, ad esempio Microsoft 365 US Government GCC High e Azure Government.
- L'azienda commerciale risiede in un tenant di Microsoft Entra separato in Commerciale, ad esempio un ambiente Microsoft Entra in esecuzione nel cloud globale di Azure.
Per agire come una singola azienda distribuita in un'architettura tra cloud, tutti gli utenti si sincronizzano con entrambi i tenant. Questo approccio consente la disponibilità unificata dell'elenco indirizzi globale in entrambi i tenant e potrebbe garantire che gli utenti sincronizzati automaticamente con entrambi i tenant includano diritti e restrizioni per applicazioni e contenuti. Esempi di requisiti includono:
- I dipendenti statunitensi potrebbero avere accesso universale a entrambi i tenant.
- I dipendenti non statunitensi vengono visualizzati nell'elenco indirizzi globale unificato di entrambi i tenant, ma non hanno accesso al contenuto protetto nel tenant GCC High.
Questo scenario richiede la sincronizzazione automatica e la gestione delle identità per configurare gli utenti in entrambi i tenant, associandoli ai criteri appropriati di protezione dei dati ed entitlement.
Il B2B tra cloud richiede di configurare le impostazioni di accesso tra tenant per ogni organizzazione con cui si vuole collaborare nell'istanza cloud remota.
Account di provisioning
Questa sezione descrive tre tecniche per automatizzare il provisioning degli account nello scenario automatizzato.
Tecnica 1: usare la funzionalità di sincronizzazione tra tenant predefinita in Microsoft Entra ID
Questo approccio funziona solo quando tutti i tenant da sincronizzare si trovano nella stessa istanza cloud (ad esempio da Commerciale a Commerciale).
Tecnica 2: effettuare il provisioning degli account con Microsoft Identity Manager
Usare una soluzione di gestione delle identità e degli accessi (IAM) esterna, ad esempio Microsoft Identity Manager (MIM), come motore di sincronizzazione.
Questa distribuzione avanzata usa MIM come motore di sincronizzazione. MIM chiama l'API Microsoft Graph ed Exchange Online PowerShell. Le implementazioni alternative possono includere l'offerta di servizi gestiti di Servizi di sincronizzazione di Active Directory (ADSS) ospitati nel cloud da Microsoft Industry Solutions. Esistono offerte non Microsoft che possono essere creare da zero con altre offerte IAM (ad esempio SailPoint, Omada e OKTA).
Si esegue una sincronizzazione tra cloud delle identità (utenti, contatti e gruppi) da un tenant a un altro, come illustrato nel diagramma seguente.
Le considerazioni esterne all'ambito di questo articolo includono l'integrazione di applicazioni locali.
Tecnica 3: effettuare il provisioning degli account con Microsoft Entra Connect
Questa tecnica si applica solo alle organizzazioni complesse che gestiscono tutte le identità in Servizi di dominio Active Directory (AD DS) tradizionali basati su Windows Server. L'approccio usa Microsoft Entra Connect come motore di sincronizzazione, come illustrato nel diagramma seguente.
A differenza della tecnica MIM, tutte le origini di identità (utenti, contatti e gruppi) provengono da Servizi di dominio Active Directory (AD DS) tradizionali basati su Windows Server. La directory di Servizi di dominio Active Directory è in genere una distribuzione locale per un'organizzazione complessa che gestisce identità per più tenant. L'identità solo su cloud non rientra nell'ambito di questa tecnica. Tutte le identità devono trovarsi in Servizi di dominio Active Directory per essere incluse nell'ambito della sincronizzazione.
A livello concettuale, questa tecnica sincronizza un utente in un tenant principale come utente membro interno (comportamento predefinito). In alternativa, potrebbe sincronizzare un utente in un tenant delle risorse come utente esterno (comportamento personalizzato).
Microsoft supporta questa doppia tecnica utente di sincronizzazione con considerazioni accurate sulle modifiche apportate alla configurazione di Microsoft Entra Connect. Ad esempio, se si apportano modifiche alla configurazione secondo la procedura guidata, è necessario documentare le modifiche se occorre ricompilare la configurazione durante un evento di supporto.
Per impostazione predefinita, Microsoft Entra Connect non può sincronizzare un utente esterno. È necessario potenziarlo con un processo esterno (ad esempio uno script di PowerShell) per convertire gli utenti da account interni ad account esterni.
I vantaggi di questa tecnica includono la sincronizzazione dell'identità con gli attributi archiviati in Servizi di dominio Active Directory da parte di Microsoft Entra Connect. La sincronizzazione può includere attributi della rubrica, attributi del manager, appartenenze a gruppi e altri attributi di identità ibrida in tutti i tenant all'interno dell'ambito. Esegue il deprovisioning dell'identità in allineamento con Servizi di dominio Active Directory. Non richiede una soluzione IAM più complessa per gestire l'identità cloud per questa attività specifica.
Esiste una relazione uno-a-uno di Microsoft Entra Connect per tenant. Ogni tenant ha una propria configurazione di Microsoft Entra Connect che è possibile modificare singolarmente per supportare la sincronizzazione dell'account utente membro o esterno.
Scelta della topologia appropriata
La maggior parte dei clienti usa una delle topologie seguenti in scenari automatizzati.
- Una topologia mesh consente la condivisione di tutte le risorse in tutti i tenant. Gli utenti vengono creati da altri tenant in ogni tenant delle risorse come utenti esterni.
- Una topologia tenant a risorsa singola usa un tenant singolo (il tenant delle risorse), in cui gli utenti da altri tenant sono utenti esterni.
Fare riferimento alla tabella seguente come albero delle decisioni durante la progettazione della soluzione. Seguendo la tabella, i diagrammi illustrano entrambe le topologie per determinare quale sia la scelta giusta per l'organizzazione.
Confronto tra topologie mesh e tenant a risorsa singola
Considerazione | Topologia mesh | Tenant a risorsa singola |
---|---|---|
Ogni azienda ha un tenant Microsoft Entra separato con utenti e risorse | Sì | Sì |
Posizione delle risorse e collaborazione | ||
Le app condivise e altre risorse rimangono nel tenant principale corrente | Sì | No. È possibile condividere solo app e altre risorse nel tenant delle risorse. Non è possibile condividere app e altre risorse rimanenti in altri tenant. |
Tutti visualizzabili negli elenchi indirizzi globali di singole società (elenco indirizzi globale unificato) | Sì | No |
Accesso alle risorse e amministrazione | ||
È possibile condividere TUTTE le applicazioni connesse a Microsoft Entra ID in tutte le società. | Sì | No. Vengono condivise solo le applicazioni nel tenant delle risorse. Non è possibile condividere le applicazioni rimanenti in altri tenant. |
Amministrazione delle risorse globali | Continuare a livello di tenant. | Consolidato nel tenant delle risorse. |
Licenze: Office 365 SharePoint in Microsoft 365, elenco indirizzi globale unificato, accesso Teams a tutti i guest di supporto; tuttavia, altri scenari di Exchange Online non lo sono. | Continua a livello di tenant. | Continua a livello di tenant. |
Licenze: Microsoft Entra ID (Premium) | I primi 50.000 utenti attivi mensili sono gratuiti (per tenant). | I primi 50.000 utenti attivi mensili sono gratuiti. |
License: app Software as a Service (SaaS) | Rimanere nei singoli tenant, potrebbe richiedere licenze per utente per tenant. | Tutte le risorse condivise risiedono nel tenant a risorsa singola. È possibile esaminare il consolidamento delle licenze nel singolo tenant, se appropriato. |
Topologia mesh
Il diagramma seguente illustra la topologia mesh.
In una topologia mesh, ogni utente in ciascun tenant principale viene sincronizzato con ognuno degli altri tenant, che diventano tenant delle risorse.
- È possibile condividere qualsiasi risorsa all'interno di un tenant con utenti esterni.
- Ogni organizzazione può visualizzare tutti gli utenti nel conglomerato. Nel diagramma precedente sono presenti quattro elenchi indirizzi globali unificati, ognuno dei quali contiene gli utenti home e gli utenti esterni degli altri tre tenant.
Considerazioni comuni per la gestione degli utenti multi-tenant fornisce informazioni sul provisioning, sulla gestione e sul deprovisioning degli utenti in questo scenario.
Topologia mesh per cross-cloud
È possibile usare la topologia mesh in un numero limitato di due tenant, ad esempio nello scenario di un appaltatore di base industriale per la difesa che sfrutta una soluzione di cloud sovrano su più cloud. Come per la topologia mesh, ogni utente in ciascun tenant principale viene sincronizzato con l’altro tenant, che diventa un tenant delle risorse. Nel diagramma della sezione Tecnica 3, l'utente interno del tenant commerciale pubblico viene sincronizzato con il tenant GCC High sovrano degli Stati Uniti come account utente esterno. Allo stesso tempo, l'utente interno GCC High viene sincronizzato con Commerciale come account utente esterno.
Il diagramma illustra anche i percorsi di archiviazione dei dati. La categorizzazione e la conformità dei dati non rientrano nell'ambito di questo articolo, ma è possibile includere diritti e restrizioni ad applicazioni e contenuti. Il contenuto potrebbe includere le posizioni in cui sono memorizzati i dati di proprietà di un utente interno, come quelli archiviati in una casella di posta elettronica di Exchange Online o in OneDrive. Il contenuto potrebbe trovarsi nel tenant principale e non nel tenant delle risorse. I dati condivisi possono risiedere in uno dei tenant. È possibile limitare l'accesso al contenuto tramite il controllo di accesso e i criteri di accesso condizionale.
Topologia del tenant a risorsa singola
Il diagramma seguente illustra la topologia del tenant a risorsa singola.
In una topologia tenant a risorsa singola, gli utenti e i relativi attributi vengono sincronizzati con il tenant delle risorse (Società A nel diagramma precedente).
- Tutte le risorse condivise tra le organizzazioni membro devono risiedere nel tenant a risorsa singola. Se più filiali hanno sottoscrizioni alle stesse app SaaS, è possibile consolidare tali sottoscrizioni.
- Solo l'elenco indirizzi globale nel tenant delle risorse visualizza gli utenti di tutte le società.
Gestione degli account
Questa soluzione rileva e sincronizza le modifiche apportate agli attributi dagli utenti del tenant di origine agli utenti esterni del tenant delle risorse. È possibile usare questi attributi per prendere decisioni di autorizzazione, ad esempio quando si usano gruppi di apparenenza dinamica.
Deprovisioning degli account
Automazione rileva l'eliminazione di oggetti nell'ambiente di origine ed elimina l'oggetto utente esterno associato nell'ambiente di destinazione.
Considerazioni comuni per la gestione degli utenti multi-tenant fornisce ulteriori informazioni sul provisioning, sulla gestione e sul deprovisioning degli utenti in questo scenario.
Passaggi successivi
- Introduzione alla gestione degli utenti multi-tenant è il primo di una serie di articoli che forniscono indicazioni per la configurazione e la gestione del ciclo di vita degli utenti negli ambienti multi-tenant di Microsoft Entra.
- Considerazioni comuni per la gestione degli utenti multi-tenant fornisce indicazioni su queste considerazioni: sincronizzazione tra tenant, oggetto directory, accesso condizionale di Microsoft Entra, controllo di accesso aggiuntivo e Office 365.
- Soluzioni comuni per la gestione degli utenti multi-tenant quando la tenancy singola non funziona per lo scenario in uso: questo articolo fornisce indicazioni per problematiche di gestione automatica del ciclo di vita degli utenti e allocazione delle risorse tra tenant e condivisione di app locali tra tenant.