Progettare un'architettura multi-tenant per istituti di grandi dimensioni
È consigliabile usare un'architettura a tenant singolo per gli istituti più piccoli. Tuttavia, per le organizzazioni che hanno più di 1 milione di utenti, è consigliabile un'architettura multi-tenant per attenuare i problemi di prestazioni e le limitazioni del tenant, ad esempio la sottoscrizione e le quote di Azure ei limiti e le restrizioni del servizio Microsoft Entra.
Principi di progettazione
Quando si progetta l'architettura multi-tenant, prendere in considerazione i principi di progettazione seguenti per ridurre i costi e aumentare l'efficienza e la sicurezza:
Ridurre i costi
Ridurre la dipendenza dall'infrastruttura locale e da più provider di identità.
Consentire agli utenti di sbloccare l'account o reimpostare le password usando il servizio self-service , ad esempio Microsoft Entra reimpostazione della password self-service.
Aumentare l'efficienza
Standardizzare l'architettura, le configurazioni e i processi tra i tenant per ridurre al minimo i problemi amministrativi.
Ridurre al minimo la necessità per gli utenti di passare da un tenant a un altro
Aumentare la sicurezza
Concentrarsi sulla sicurezza dei dati degli studenti.
Seguire il principio dei privilegi minimi: concedere solo i privilegi necessari per eseguire le attività necessarie e implementare l'accesso JIT (Just in Time).
Abilitare l'accesso degli utenti esterni solo tramite Entitlement Management o Microsoft Entra collaborazione B2B.
Delegare l'amministrazione di attività specifiche a utenti specifici con accesso Just Enough (JEA) per eseguire il processo.
Motivi comuni per più tenant
È consigliabile che le organizzazioni con meno di 1 milione di utenti creino un singolo tenant, a meno che altri criteri non indichino la necessità di più tenant. Per le organizzazioni con 1 milione o più oggetti utente, è consigliabile usare più tenant con un approccio a livello di area.
La creazione di tenant separati ha gli effetti seguenti sull'ambiente EDU.
Separazione amministrativa
Può limitare l'impatto di una sicurezza amministrativa o di un errore operativo che influisce sulle risorse critiche.
Può limitare l'impatto degli account utente o dell'amministratore compromesso.
I report di utilizzo e i log di controllo sono contenuti in un tenant.
Separazione delle risorse
Privacy degli studenti. Gli oggetti utente student sono individuabili solo all'interno del tenant in cui risiede l'oggetto.
Isolamento delle risorse. Le risorse in un tenant separato non possono essere individuate o enumerate da utenti e amministratori in altri tenant.
Footprint dell'oggetto. Le applicazioni che scrivono in Microsoft Entra ID e altri servizi Microsoft Online tramite Microsoft Graph o altre interfacce di gestione possono influire solo sulle risorse nel tenant locale.
Quote. Il consumo di quote e limiti di Azure a livello di tenant è separato da quello degli altri tenant.
Separazione della configurazione
Fornisce un set separato di impostazioni a livello di tenant in grado di supportare le risorse e le applicazioni attendibili con requisiti di configurazione diversi.
Abilita un nuovo set di servizi Microsoft Online, ad esempio Office 365.
Oltre ad avere più di 1 milione di utenti, le considerazioni seguenti possono portare a più tenant.
Considerazioni amministrative
L'utente opera in base a normative che vincolano chi può amministrare l'ambiente in base a criteri quali il paese di cittadinanza, il paese di residenza o il livello di autorizzazione.
Sono presenti requisiti di conformità, ad esempio la privacy dei dati degli studenti, che richiedono la creazione di identità in aree locali specifiche.
Considerazioni sulla risorsa
Sono disponibili risorse, ad esempio per la ricerca e lo sviluppo, che è necessario proteggere dall'individuazione, dall'enumerazione o dall'acquisizione da parte degli amministratori esistenti per motivi normativi o aziendali critici.
Ciclo di sviluppo di applicazioni personalizzate che possono modificare i dati degli utenti con MS Graph o API simili su larga scala (ad esempio le applicazioni a cui viene concesso Directory.ReadWrite.All)
Considerazioni sulla configurazione
- Risorse con requisiti in conflitto con i comportamenti di sicurezza o collaborazione esistenti a livello di tenant, ad esempio tipi di autenticazione consentiti, criteri di gestione dei dispositivi, capacità di self-service o verifica dell'identità per identità esterne.
Determinare l'approccio multi-tenant
In questa sezione si considera un'università fittizia denominata School of Fine Arts con 2 milioni di studenti in 100 scuole in tutto il Stati Uniti. In queste scuole, ci sono un totale di 130.000 insegnanti e 30.000 dipendenti e personale a tempo pieno.
Quando si distribuiscono più tenant, è consigliabile un approccio a livello di area come indicato di seguito:
Iniziare dividendo la community di studenti e docenti per aree geografiche in cui ogni area contiene meno di 1 milione di utenti.
Creare un tenant Microsoft Entra per ogni area.
Effettuare il provisioning di personale, insegnanti e studenti nell'area corrispondente per ottimizzare le esperienze di collaborazione.
Perché usare le aree?
È consigliabile usare un approccio a livello di area per ridurre al minimo il numero di utenti che si spostano tra i tenant. Se è stato creato un tenant per ogni livello di scuola (ad esempio scuole secondarie, scuole medie e scuole superiori) è necessario eseguire la migrazione degli utenti alla fine di ogni anno scolastico. Se invece gli utenti rimangono nella stessa area, non è necessario spostarli tra i tenant man mano che cambiano gli attributi.
Altri vantaggi di un approccio regionale includono:
Collaborazione ottimale all'interno di ogni area
È necessario un numero minimo di oggetti guest di altri tenant
Quando un tenant ha più di 1 milione di utenti, le esperienze di gestione e gli strumenti tendono a peggiorare nel tempo. Analogamente, alcune esperienze dell'utente finale come l'uso della selezione utenti diventeranno complesse e inaffidabili.
Le organizzazioni più piccole che scelgono di distribuire più tenant senza un motivo convincente aumenteranno inutilmente il sovraccarico di gestione e il numero di migrazioni degli utenti. In questo modo saranno necessari anche passaggi per garantire esperienze di collaborazione tra i tenant.
Collaborare tra tenant usando Microsoft Entra collaborazione B2B
Microsoft Entra collaborazione B2B consente agli utenti di usare un set di credenziali per accedere a più tenant. Per gli istituti di istruzione, i vantaggi della collaborazione B2B includono:
Team di amministrazione centralizzato che gestisce più tenant
Collaborazione degli insegnanti tra aree
Onboarding di genitori e tutori con le proprie credenziali
Partnership esterne come appaltatori o ricercatori
Con la collaborazione B2B, un account utente creato in un tenant (il tenant principale) viene invitato come utente guest a un altro tenant (un tenant di risorse) e l'utente può accedere usando le credenziali del tenant principale. Gli amministratori possono anche usare la collaborazione B2B per consentire agli utenti esterni di accedere con gli account social o aziendali esistenti configurando la federazione con provider di identità come Facebook, account Microsoft, Google o un provider di identità aziendale.
Membri e guest
Gli utenti in un tenant Microsoft Entra sono membri o guest in base alla proprietà UserType. Per impostazione predefinita, gli utenti membri sono quelli nativi del tenant. Un utente di collaborazione B2B Microsoft Entra viene aggiunto come utente con UserType = Guest per impostazione predefinita. I guest hanno autorizzazioni limitate nella directory e nelle applicazioni. Ad esempio, gli utenti guest non possono esplorare le informazioni dal tenant oltre le informazioni del proprio profilo. Tuttavia, un utente guest può recuperare informazioni su un altro utente specificando il nome dell'entità utente (UPN) o objectId. Un utente guest può anche leggere le proprietà dei gruppi a cui appartiene, inclusa l'appartenenza ai gruppi, indipendentemente dall'impostazione Delle autorizzazioni utenti guest limitate .
In alcuni casi, un tenant di risorse potrebbe voler considerare gli utenti del tenant principale come membri anziché guest. in tal caso, è possibile usare le API di Gestione inviti B2B Microsoft Entra per aggiungere o invitare un utente dal tenant principale al tenant delle risorse come membro. Per altre informazioni, vedere Proprietà di un utente di collaborazione B2B Microsoft Entra.
Amministrazione centralizzata di più tenant
Eseguire l'onboarding di identità esterne usando Microsoft Entra B2B. Alle identità esterne possono quindi essere assegnati ruoli con privilegi per gestire Microsoft Entra tenant come membri di un team IT centralizzato. È anche possibile usare Microsoft Entra B2B per creare account guest per altri membri del personale, ad esempio amministratori a livello di area o distretto.
Tuttavia, i ruoli specifici del servizio, ad esempio amministratore di Exchange o amministratore di SharePoint, richiedono un account locale nativo del tenant.
I ruoli seguenti possono essere assegnati agli account B2B
Amministratore dell'applicazione
Sviluppatore dell'applicazione
Amministratore dell'autenticazione
Amministratore del keyset IEF B2C
Amministratore dei criteri IEF B2C
Amministratore dei criteri IEF dell'applicazione cloud B2C
Amministratore dei criteri IEF di Cloud Device B2C
Amministratore accesso condizionale
Amministratori dei dispositivi
Aggiunta al dispositivo
Utenti del dispositivo
Lettori di directory
Ruoli con autorizzazioni di scrittura nella directory
Account di sincronizzazione della directory
Amministratore flusso utente ID esterno
Amministratore attributo flusso utente ID esterno
Provider di identità esterno
Amministratore gruppi
Guest Inviter
Amministratore supporto tecnico
Amministratore identità ibrido
Amministratore del servizio Intune
Amministratore licenze
Amministratore password
Amministratore dell'autenticazione con privilegi
Amministratore ruolo con privilegi
Amministratore che legge i report
Utente guest con restrizioni
Amministratore della sicurezza
Ruolo con autorizzazioni di lettura per la sicurezza
Amministratore account utente
Aggiunta al dispositivo dell'area di lavoro
I ruoli di amministratore personalizzati in Microsoft Entra ID di visualizzare le autorizzazioni sottostanti dei ruoli predefiniti, in modo da poter creare e organizzare i propri ruoli personalizzati. Questo approccio consente di concedere l'accesso in modo più granulare rispetto ai ruoli predefiniti, ogni volta che sono necessari.
Di seguito è riportato un esempio che illustra il funzionamento dell'amministrazione per i ruoli amministrativi che possono essere delegati e usati in più tenant.
L'account nativo di Susie si trova nel tenant dell'area 1 e Microsoft Entra B2B viene usato per aggiungere l'account come amministratore dell'autenticazione al team IT centrale nei tenant per l'area 2 e l'area 3.
Uso di app in più tenant
Per attenuare i problemi associati all'amministrazione delle app in un ambiente multi-tenant, è consigliabile scrivere app multi-tenant. Dovrai anche verificare quale delle tue app SaaS supporta più connessioni IdP. Le app SaaS che supportano più connessioni IDP devono configurare connessioni singole in ogni tenant. Le app SaaS che non supportano più connessioni IDP potrebbero richiedere istanze indipendenti. Per altre informazioni, vedere Procedura: Accedere a qualsiasi utente Microsoft Entra usando il modello di applicazione multi-tenant.
Nota: i modelli di licenza possono variare da un'app SaaS a un'altra. rivolgersi al fornitore per determinare se saranno necessarie più sottoscrizioni in un ambiente multi-tenant.
Amministrazione per tenant
L'amministrazione per tenant è necessaria per i ruoli specifici del servizio. I ruoli specifici del servizio richiedono un account locale nativo del tenant. Oltre a disporre di un team IT centralizzato in ogni tenant, è anche necessario disporre di un team IT a livello di area in ogni tenant per gestire carichi di lavoro come Exchange, SharePoint e Teams.
I ruoli seguenti richiedono account nativi per ogni tenant
Amministratore di Azure DevOps
Amministratore di Azure Information Protection
Amministratore fatturazione
Amministratore del servizio CRM
Amministratore di conformità
Amministratore dati di conformità
Responsabile approvazione accesso Customer Lockbox
amministratore Desktop Analytics
Amministratore di Exchange
Amministratore Insight
Leader aziendale Insights
Amministratore di Kaizala
Amministratore del servizio Lync
Lettore privacy del Centro messaggi
Lettore centro messaggi
Amministratore stampante
Tecnico della stampante
Amministratore ricerca
Cerca Editor
Operatore della sicurezza
Amministratore del supporto del servizio
Amministratore SharePoint
Amministratore delle comunicazioni di Teams
Tecnico del supporto delle comunicazioni di Teams
Specialista del supporto delle comunicazioni di Teams
Amministratore del servizio Teams
Amministratori univoci in ogni tenant
Se si dispone di un team IT nativo di ogni area, è possibile che uno di questi amministratori locali gestirà l'amministrazione di Teams. Nell'esempio seguente Charles risiede nel tenant dell'area 1 e ha il ruolo di amministratore del servizio Teams. Alice e Ichiro risiedono rispettivamente nelle aree 2 e 3 e detengono lo stesso ruolo nelle rispettive aree. Ogni amministratore locale ha un singolo account nativo della propria area.
Amministrazione ruoli tra tenant
Se non si dispone di un pool di amministratori locali per ogni area, è possibile assegnare il ruolo Amministratore del servizio Teams a un solo utente. In questo scenario, come illustrato di seguito, è possibile fare in modo che Bob del team IT centrale agisca come amministratore del servizio Teams in tutti e tre i tenant creando un account locale per Bob in ogni tenant.
Delega dei ruoli di amministratore all'interno di un tenant
Le unità amministrative devono essere usate per raggruppare logicamente Microsoft Entra utenti e gruppi. La limitazione dell'ambito amministrativo tramite unità amministrative è utile nelle organizzazioni educative costituite da aree, distretti o scuole diverse.
Ad esempio, la nostra fittizia School of Fine Arts è distribuita in tre aree, ognuna delle quali contiene più scuole. Ogni area ha un team di amministratori IT che controllano l'accesso, gestiscono gli utenti e impostano i criteri per le rispettive scuole.
Ad esempio, un amministratore IT potrebbe:
Creare un au per gli utenti di ognuna delle scuole dell'area 1, per gestire tutti gli utenti dell'istituto di istruzione. (non nella foto)
Creare un'au che contiene gli insegnanti in ogni istituto di istruzione, per gestire gli account degli insegnanti.
Creare un au separato che contenga gli studenti di ogni istituto di istruzione, per gestire gli account degli studenti.
Assegnare agli insegnanti dell'istituto di istruzione il ruolo Amministratore password per l'au studenti, in modo che gli insegnanti possano reimpostare le password degli studenti, ma non reimpostare le password degli altri utenti.
I ruoli che possono essere assegnati all'ambito delle unità amministrative includono:
Amministratore dell'autenticazione
Amministratore gruppi
Amministratore supporto tecnico
Amministratore licenze
Amministratore password
Amministratore utente
Per altre informazioni, vedere Assegnare ruoli con ambito a un'unità amministrativa.
Gestione tra tenant
Le impostazioni vengono configurate singolarmente in ogni tenant. Configurare quindi come parte della creazione del tenant, laddove possibile, per ridurre al minimo la necessità di rivedere tali impostazioni. Anche se alcune attività comuni possono essere automatizzate, non esiste un portale di gestione tra tenant predefinito.
Gestione di oggetti su larga scala
Microsoft Graph (MS Graph) e Microsoft Graph PowerShell consentono di gestire gli oggetti directory su larga scala. Possono anche essere usati per gestire la maggior parte dei criteri e delle impostazioni nel tenant. Tuttavia, è necessario comprendere le considerazioni sulle prestazioni seguenti:
MS Graph limita la creazione di utenti, gruppi e modifiche all'appartenenza a 72.000 per tenant, all'ora.
Le prestazioni di MS Graph possono essere influenzate da azioni guidate dall'utente, ad esempio azioni di lettura o scrittura all'interno del tenant
Le prestazioni di MS Graph possono essere influenzate da altre attività di amministratore IT concorrenti all'interno del tenant
PowerShell, SDS, Microsoft Entra Connect e soluzioni di provisioning personalizzate aggiungono oggetti e appartenenze tramite MS Graph a velocità diverse
Operazioni successive
Se non è stata esaminata l'introduzione ai tenant di Microsoft Entra, è possibile eseguire questa operazione. Vedere: