Condividi tramite


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

  • 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:

  1. Iniziare dividendo la community di studenti e docenti per aree geografiche in cui ogni area contiene meno di 1 milione di utenti.

  2. Creare un tenant Microsoft Entra per ogni area.

    multi-tenant-approach.

  3. Effettuare il provisioning di personale, insegnanti e studenti nell'area corrispondente per ottimizzare le esperienze di collaborazione.

    provisioning nei tenant.

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

  • ID esterno amministratore degli attributi del flusso utente

  • 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.

amministrazione centralizzata.

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.

Immagine 7.

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.

Immagine 9.

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.

Unità amministrative.

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: