Condividi tramite

Considerazioni architettoniche per l'identità in una soluzione multitenant

L'identità è un aspetto importante in qualsiasi soluzione multi-tenant. I componenti di identità dell'applicazione sono responsabili delle attività seguenti:

  • Verifica dell'identità di un utente, nota come autenticazione

  • Applicazione delle autorizzazioni di un utente all'interno dell'ambito di un tenant, noto come autorizzazione

I clienti potrebbero anche voler autorizzare applicazioni esterne ad accedere ai dati o integrarsi con la soluzione. L'identità di un utente determina le informazioni a cui un utente o un servizio può accedere. È importante prendere in considerazione i requisiti di identità per isolare sia l'applicazione che i dati tra i tenant.

Attenzione

I servizi di autenticazione e autorizzazione all'interno di applicazioni SaaS (Multi-Tenant e Software as a Service) vengono in genere forniti da un provider di identità esterno (IdP). Un IdP è in genere una parte integrante di una piattaforma di gestione delle identità.

La creazione di un provider di identità è complessa, costosa e difficile da proteggere. È considerato un antipattern e non lo consigliamo.

Prima di definire una strategia di identità multi-tenant, considerare i seguenti requisiti di identità di alto livello per il vostro servizio:

  • Determinare se gli utenti o le identità del carico di lavoro accedono a una singola applicazione o a più applicazioni all'interno di una famiglia di prodotti. Alcune famiglie di prodotti possono includere applicazioni distinte che condividono la stessa infrastruttura di gestione delle identità, ad esempio sistemi di vendita e piattaforme di gestione dell'inventario.

  • Valutare se la soluzione implementa standard di autenticazione e autorizzazione moderni, ad esempio OAuth2 e OpenID Connect.

  • Valutare se l'autenticazione è limitata alle applicazioni basate sull'interfaccia utente o se l'accesso api si applica anche ai tenant e ai sistemi di terze parti.

  • Determinare se i tenant devono eseguire la federazione con i propri provider di identità e se per ogni tenant devono essere supportati più provider di identità. Ad esempio, si potrebbero avere tenant con Microsoft Entra ID, Auth0 e Active Directory Federation Services in cui ogni tenant si federate con la soluzione. Identificare i protocolli federativi usati dai loro IdP perché quei protocolli determinano cosa deve supportare il vostro IdP.

  • Esaminare i requisiti di conformità applicabili che devono soddisfare, ad esempio il Regolamento generale sulla protezione dei dati (GDPR) che modellano la strategia di gestione delle identità.

  • Determinare se i tenant richiedono l'archiviazione dei dati di identità in aree geografiche specifiche per soddisfare esigenze legali, di conformità o operative.

  • Valutare se gli utenti accedono ai dati di diversi tenant nell'ambito dell'applicazione. In tal caso, potrebbe essere necessario supportare il passaggio senza soluzione di continuità tra i tenant o fornire visualizzazioni consolidate attraverso i tenant per utenti specifici. Ad esempio, gli utenti che accedono al portale di Azure possono passare facilmente tra directory ID e sottoscrizioni di Microsoft Entra diverse a cui hanno accesso.

Quando si stabiliscono i requisiti generali, è possibile iniziare a pianificare dettagli e requisiti più specifici, ad esempio origini della directory utente e flussi di iscrizione e accesso.

Directory di identità

Per consentire a una soluzione multi-tenant di autenticare e autorizzare un utente o un servizio, è necessario un luogo dove archiviare le informazioni sull'identità. Una directory può includere record autorevoli per ogni identità. Oppure può contenere riferimenti a identità esterne archiviate nella directory di un altro IdP.

Quando si progetta un sistema di gestione identità per la soluzione multi-tenant, è necessario considerare quali dei tipi di IdP seguenti potrebbero essere necessari per i tenant e i clienti:

  • IdP locale: Un IdP locale consente agli utenti di iscriversi per il servizio. Gli utenti forniscono un nome utente, un indirizzo email o un identificatore, ad esempio un numero di carta premio. Forniscono anche le credenziali, ad esempio la password. IdP archivia l'identificatore utente e le credenziali.

  • Social IdP: Un IdP social consente agli utenti di usare un'identità che ha in un social network o in un altro IdP pubblico, ad esempio Facebook, Google o un account Microsoft personale. Gli IDP di social networking vengono comunemente usati nelle soluzioni SaaS da business a consumer (B2C).

  • Directory dell'ID Microsoft Entra del tenant: In molte soluzioni SaaS business-to-business (B2B), i tenant potrebbero già avere la propria directory di Microsoft Entra ID e potrebbero voler usare la propria directory come IdP per accedere alla tua soluzione. Questo approccio è possibile quando la soluzione viene compilata come applicazione Microsoft Entra multi-tenant.

  • Federazione con IdP di un tenant: In alcune soluzioni SaaS B2B, i tenant potrebbero avere il proprio IdP, diverso dall'ID Microsoft Entra, e potrebbero volere che la soluzione sia federata con essa. La federazione abilita l'accesso Single Sign-On (SSO). Consente anche ai tenant di gestire il ciclo di vita e i criteri di sicurezza dei propri utenti indipendentemente dalla soluzione.

È consigliabile prendere in considerazione se i tenant devono supportare più provider di identità. Ad esempio, un singolo tenant potrebbe dover supportare identità locali, identità di social networking e identità federate. Questo requisito è tipico quando le aziende usano una soluzione destinata sia ai dipendenti che ai terzisti. Possono usare la federazione per concedere l'accesso ai dipendenti, consentendo anche l'accesso a terzisti o utenti che non dispongono di account nel provider di identità federato.

Memorizzare le informazioni sull'autenticazione e l'autorizzazione del tenant

In una soluzione multi-tenant, è necessario valutare dove archiviare diversi tipi di informazioni sull'identità, inclusi i tipi seguenti:

  • Informazioni dettagliate sugli account utente e di servizio, inclusi i nomi e altre informazioni necessarie ai vostri tenant.

  • Informazioni necessarie per autenticare in modo sicuro gli utenti, incluse le informazioni per l'autenticazione a più fattori (MFA).

  • Informazioni specifiche del tenant, ad esempio ruoli e autorizzazioni del tenant, per l'autorizzazione.

Attenzione

Non è raccomandabile creare personalmente processi di autenticazione. Gli IdP moderni forniscono questi servizi di autenticazione all'applicazione e includono anche altre importanti funzionalità, ad esempio MFA e accesso condizionale. Costruire il proprio provider di identità è un antipattern. Non è una scelta consigliata.

Valutare le opzioni seguenti per l'archiviazione delle informazioni sull'identità:

  • Salvare tutte le informazioni di identità e autorizzazione nella directory IdP e condividerle tra più tenant.

  • Archiviare le credenziali utente nella directory IdP. Archiviare i dati di autorizzazione nel livello applicazione, insieme alle informazioni sul tenant.

Stabilire il numero di identità per un utente

Le soluzioni multi-tenant spesso consentono a un utente o a un'identità del carico di lavoro di accedere alle risorse e ai dati dell'applicazione in più tenant. Quando è necessario questo approccio, considerare i fattori seguenti:

  • Decidere se creare una singola identità utente per ogni persona o creare identità separate per ogni combinazione di utenti tenant.

    • Usare una singola identità per ogni persona, quando possibile. Semplifica la gestione degli account sia per il provider di soluzioni che per gli utenti. Inoltre, molte delle protezioni intelligenti per le minacce fornite dai provider di identità moderni si basano sul fatto che ogni persona abbia un singolo account utente.

    • Usare più identità distinte in alcuni scenari. Ad esempio, se si usa il sistema sia a scopo aziendale che personale, si potrebbe voler separare gli account utente. Oppure se i tenant hanno requisiti rigorosi di archiviazione dei dati normativi o geografici, potrebbero richiedere a una persona di avere più identità in modo che possano essere conformi alle normative o alle leggi.

  • Evitare di archiviare le credenziali più volte se si usano identità per tenant. Gli utenti devono disporre di credenziali archiviate in una singola identità e usare funzionalità come le identità guest per fare riferimento alle stesse credenziali utente dai record di identità di più tenant.

Concedere agli utenti l'accesso ai dati tenant

Considera come intendi mappare gli utenti a un tenant. Ad esempio, durante il processo di iscrizione, è possibile fornire un codice di invito univoco che gli utenti possano immettere quando accedono a un tenant per la prima volta. In alcune soluzioni, il nome di dominio dell'indirizzo di posta elettronica di iscrizione dell'utente può identificare il tenant associato. In alternativa, è possibile usare un altro attributo del record di identità dell'utente per determinare il mapping del tenant. Questa associazione deve quindi essere archiviata in base a identificatori univoci non modificabili sia per il tenant che per l'utente.

Se la soluzione limita ogni utente ad accedere ai dati per un singolo tenant, prendere in considerazione le decisioni seguenti:

  • Determinare il modo in cui il provider di identità rileva il tenant a cui accede un utente.

  • Spiega come l'IdP comunica l'identificatore del tenant all'applicazione. In genere, al token viene aggiunta un'attestazione dell'identificatore del tenant.

Se un singolo utente deve avere accesso a più ambienti, tenere in considerazione le seguenti opzioni:

  • La soluzione deve supportare la logica necessaria per identificare gli utenti e concedere autorizzazioni appropriate nei tenant. Ad esempio, un utente potrebbe avere diritti amministrativi in un tenant, ma l'accesso limitato in un altro tenant. Si supponga, ad esempio, che un utente abbia effettuato l'iscrizione con un'identità di social networking e che sia stato concesso l'accesso a due tenant. Tenant A ha arricchito l'identità dell'utente con ulteriori informazioni. Il tenant B deve avere accesso alle informazioni arricchite?

  • Un meccanismo chiaro deve consentire agli utenti di passare da un tenant all'altro. Questo approccio garantisce un'esperienza utente uniforme e impedisce l'accesso accidentale tra tenant.

  • Le identità del workload, se usate, devono specificare il tenant a cui stanno cercando di accedere. Questo requisito può includere l'incorporamento di un contesto specifico del tenant nelle richieste di autenticazione.

  • Valutare se le informazioni specifiche del tenant archiviate nel record di identità di un utente potrebbero portare a trapelare involontariamente tra i tenant. Ad esempio, se un utente si iscrive con un'identità di social networking e ottiene l'accesso a due tenant e il tenant A arricchisce il profilo utente, determinare se il tenant B deve avere accesso a tali informazioni arricchite.

Processo di registrazione degli utenti per identità locali o identità social

Alcuni tenant potrebbero dover consentire agli utenti di iscriversi per creare un'identità nella soluzione. L'iscrizione self-service potrebbe essere necessaria se non è necessaria la federazione con il provider di identità di un tenant. Se è necessario un processo di iscrizione automatica, è necessario considerare i fattori seguenti:

  • Definire le origini di identità da cui gli utenti possono iscriversi. Ad esempio, determinare se gli utenti possono creare un'identità locale e usare anche un IdP di social networking.

  • Specificare se la soluzione consente solo domini di posta elettronica specifici se vengono usate identità locali. Ad esempio, determinare se un tenant può limitare l'iscrizione agli utenti con un @contoso.com indirizzo di posta elettronica.

  • Il nome principale dell'utente (UPN) utilizzato per identificare le identità locali deve essere chiaramente stabilito. Gli UPN comuni includono indirizzi di posta elettronica, nomi utente, numeri di telefono o identificatori di appartenenza. Poiché gli UPN possono cambiare, è consigliabile fare riferimento all'identificatore univoco non modificabile sottostante per l'autorizzazione e il controllo. Un esempio è l'ID oggetto (OID) in Microsoft Entra ID.

  • La verifica degli UPN potrebbe essere necessaria per garantire la precisione. Questo processo può includere la convalida della proprietà di un indirizzo di posta elettronica o di un numero di telefono prima di concedere l'accesso.

  • Alcune soluzioni potrebbero richiedere agli amministratori tenant di approvare l'iscrizione degli utenti. Questo processo di approvazione consente il controllo amministrativo sugli utenti che accedono a un tenant.

  • Decidere se i tenant richiedono un'esperienza di registrazione specifica del tenant o un URL specifico del tenant. Ad esempio, determinare se i tenant richiedono un'esperienza di iscrizione personalizzata quando gli utenti si registrano o la possibilità di intercettare una richiesta di iscrizione ed eseguire una convalida aggiuntiva prima di procedere.

Accesso al tenant per gli utenti che eseguono l'auto-iscrizione

Se gli utenti possono iscriversi per ottenere un'identità, definire un processo per concedere loro l'accesso a un tenant. Il flusso di iscrizione può includere un processo di concessione dell'accesso manuale o un processo automatizzato in base alle informazioni sugli utenti, ad esempio gli indirizzi di posta elettronica. È importante pianificare questo processo e considerare i fattori seguenti:

  • Definire il modo in cui il flusso di iscrizione determina che a un utente viene concesso l'accesso a un tenant specifico.

  • Definire se la soluzione revoca automaticamente l'accesso utente a un tenant quando appropriato. Ad esempio, quando gli utenti lasciano un'organizzazione, deve essere presente un processo manuale o automatizzato per rimuovere l'accesso.

  • Fornire una funzionalità di controllo utente in modo che i tenant possano esaminare quali utenti hanno accesso al proprio ambiente e comprendere le autorizzazioni assegnate.

Gestione automatizzata del ciclo di vita degli account

Un requisito comune per i clienti aziendali o delle imprese di una soluzione è un insieme di funzionalità che consenta loro di automatizzare la gestione dell'onboarding e dell'offboarding degli account. I protocolli aperti, ad esempio System for Cross-Domain Identity Management (SCIM), offrono un approccio standard del settore all'automazione. Questo processo automatizzato include in genere la creazione e la rimozione dei record di identità e la gestione delle autorizzazioni del tenant. Quando si implementa la gestione automatizzata del ciclo di vita degli account in una soluzione multi-tenant, tenere presenti i fattori seguenti:

  • Determinare se i clienti devono configurare e gestire un processo di ciclo di vita automatizzato per ogni tenant. Ad esempio, quando viene eseguito l'onboarding di un utente, potrebbe essere necessario creare l'identità all'interno di più tenant nell'applicazione, in cui ciascun tenant dispone di un diverso set di autorizzazioni.

  • Determinare se è necessario implementare SCIM o la federazione dell'offerta. La federazione consente ai tenant di mantenere il controllo sulla gestione degli utenti mantenendo la fonte di verità all'interno dei propri sistemi anziché gestire gli utenti locali nella soluzione.

Processo di autenticazione utente

Quando un utente accede a un'applicazione multi-tenant, il sistema di identità lo autentica. Quando si pianifica il processo di autenticazione, tenere presenti i fattori seguenti:

  • Alcuni tenant potrebbero richiedere la possibilità di configurare le proprie policy di autenticazione a più fattori. Ad esempio, se i tenant sono nel settore dei servizi finanziari, devono implementare criteri MFA rigorosi, mentre un piccolo rivenditore online potrebbe non avere gli stessi requisiti.

  • L'opzione per definire regole di accesso condizionale personalizzate potrebbe essere importante per i tenant. Ad esempio, tenant diversi potrebbero aver bisogno di bloccare i tentativi di accesso da aree geografiche specifiche.

  • Determinare se i tenant devono personalizzare singolarmente il processo di accesso. Ad esempio, la soluzione potrebbe dover mostrare il logo di un cliente. In alternativa, potrebbe essere necessario recuperare informazioni utente, ad esempio un numero di ricompense, da un altro sistema e restituirlo al provider di identità per arricchire il profilo utente.

  • Alcuni utenti potrebbero dover rappresentare altri utenti. Ad esempio, un membro del team di supporto potrebbe voler analizzare un problema che un altro utente ha rappresentando il proprio account utente senza dover eseguire l'autenticazione come utente.

  • L'accesso api potrebbe essere necessario per alcuni utenti o applicazioni esterne. Questi scenari possono includere la chiamata diretta delle API della soluzione, che ignora i flussi di autenticazione utente standard.

Identità dei carichi di lavoro

Nella maggior parte delle soluzioni, un'identità spesso rappresenta un utente. Alcuni sistemi multi-tenant consentono anche l'uso delle identità del carico di lavoro da parte di servizi e applicazioni per ottenere l'accesso alle risorse dell'applicazione. Ad esempio, i tenant potrebbero dover accedere a un'API fornita dalla soluzione in modo che possano automatizzare le attività di gestione.

Microsoft Entra supporta le identità di carico di lavoro e anche altri provider di identità le supportano.

Le identità dei carichi di lavoro sono simili alle identità utente, ma in genere richiedono metodi di autenticazione diversi, ad esempio chiavi o certificati. Le identità dei carichi di lavoro non usano MFA. Al contrario, le identità dei carichi di lavoro richiedono in genere altri controlli di sicurezza, come la rotazione regolare delle chiavi e la scadenza del certificato.

Se i tenant possono abilitare l'accesso all'identità di carico di lavoro alla vostra soluzione multi-tenant, è necessario considerare i fattori seguenti:

  • Determinare la modalità di creazione e gestione delle identità del carico di lavoro in ogni tenant.

  • Decidere in che modo le richieste di identità del carico di lavoro hanno come ambito il tenant.

  • Valutare se è necessario limitare il numero di identità di carico di lavoro che ciascun tenant può creare.

  • Determinare se i controlli di accesso condizionale sono necessari per le identità del carico di lavoro in ogni tenant. Ad esempio, un tenant potrebbe voler limitare l'autenticazione di un'identità di carico di lavoro dall'esterno di una regione specifica.

  • Identificare i controlli di sicurezza forniti ai tenant per garantire che le identità del carico di lavoro rimangano sicure. Ad esempio, la rotazione automatizzata delle chiavi, la scadenza della chiave, la scadenza del certificato e il monitoraggio dei rischi di accesso consentono di ridurre il rischio di uso improprio dell'identità del carico di lavoro.

Federarsi con un IdP per il Single Sign-On

Gli inquilini che dispongono già delle proprie directory utente potrebbero volere che la soluzione venga federata alle loro directory. La federazione consente alla soluzione di usare le identità nella directory anziché gestire un'altra directory con identità distinte.

La federazione è particolarmente importante quando alcuni tenant vogliono specificare i propri criteri di identità o per abilitare le esperienze SSO.

Se ci si aspetta che i tenant si federino con la vostra soluzione, considerate i fattori seguenti:

  • Prendere in considerazione il processo di configurazione della federazione per un tenant. Determinare se i clienti configurano autonomamente la federazione o se il processo richiede una configurazione e manutenzione manuale da parte del team.

  • Definire i protocolli di federazione supportati dalla soluzione.

  • Stabilire processi che impediscano a una configurazione errata di un sistema federato di concedere l'accesso a tenant non previsti.

  • Pianifica se il provider di identità di un singolo tenant debba essere federato a più tenant nella soluzione. Ad esempio, se i clienti hanno sia un tenant di formazione che uno di produzione, potrebbero dover federare lo stesso IdP con ogni tenant.

Modelli di autorizzazione

Scegliere il modello di autorizzazione più appropriato per la soluzione. Considerare gli approcci di autorizzazione comuni seguenti:

  • Autorizzazione basata sui ruoli: Gli utenti vengono assegnati ai ruoli. Alcune funzionalità dell'applicazione sono limitate a ruoli specifici. Ad esempio, un utente nel ruolo di amministratore può eseguire qualsiasi azione, mentre un utente in un ruolo inferiore potrebbe disporre di un subset di autorizzazioni in tutto il sistema.

  • Autorizzazione basata sulle risorse: La soluzione fornisce un set di risorse distinte, ognuna delle quali ha un proprio set di autorizzazioni. Un utente potrebbe essere un amministratore di una risorsa e non avere accesso a un'altra risorsa.

Questi modelli sono distinti e l'approccio selezionato influisce sull'implementazione e sulla complessità dei criteri di autorizzazione che è possibile implementare.

Entitlement e licenze

In alcune soluzioni, si può usare il licensing per utente come parte del modello di pricing commerciale. In questo scenario si forniscono livelli diversi di licenze utente con funzionalità diverse. Ad esempio, gli utenti con licenza potrebbero essere autorizzati a usare un subset delle funzionalità dell'applicazione. Le funzionalità a cui specifici utenti possono accedere, in base alle loro licenze, vengono talvolta denominate "diritti di accesso".

Il codice dell'applicazione o un sistema di diritti dedicati tiene in genere traccia e applica i diritti anziché il sistema di identità. Questo processo è simile all'autorizzazione, ma si verifica all'esterno del livello di gestione delle identità.

Scalabilità delle identità e volume di autenticazione

Man mano che le soluzioni multi-tenant aumentano, aumenta il numero di utenti e richieste di accesso che la soluzione deve elaborare. Prendere in considerazione i fattori seguenti:

  • Valutare se la directory utente viene ridimensionata per supportare il numero di utenti richiesto.

  • Valutare se il processo di autenticazione gestisce il numero previsto di accessi e di iscrizione.

  • Determinare se sono presenti picchi che il sistema di autenticazione non può gestire. Ad esempio, alle 9:00 ora del Pacifico, tutti gli utenti degli Stati Uniti occidentali potrebbero iniziare a lavorare e accedere alla soluzione, che crea un picco nelle richieste di accesso. Questi scenari sono talvolta denominati tempeste di login.

  • Determinare se un carico elevato in parti della soluzione influisce sulle prestazioni del processo di autenticazione. Ad esempio, se l'autenticazione richiede la chiamata a un'API livello applicazione, un aumento delle richieste di autenticazione potrebbe influire sulle prestazioni complessive del sistema.

  • Definisci il comportamento della soluzione se l'IdP non è più disponibile. Valutare se è necessario includere un servizio di autenticazione di backup per mantenere la continuità aziendale.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

Altri contributori:

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