Considerazioni sull'architettura per l'identità in una soluzione multi-tenant

  • Articolo

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

  • Verifica dell'utente (autenticazione).
  • Applicazione delle autorizzazioni dell'utente nell'ambito di un tenant (autorizzazione).

I clienti potrebbero anche voler autorizzare applicazioni esterne ad accedere ai propri dati o integrare la soluzione. L'identità di un utente determina le informazioni a cui un utente o un servizio otterrà l'accesso. È importante considerare i requisiti di identità per isolare l'applicazione e i dati tra tenant.

Attenzione

I servizi di autenticazione e autorizzazione, all'interno di applicazioni multi-tenant e SaaS, vengono in genere forniti da un provider di identità di terze parti (IdP). Un provider di identità è in genere una parte integrante di una piattaforma IDaaS (Identity as a Service).

La compilazione del proprio IdP è complessa, costosa e difficile da creare in modo sicuro. La creazione di un provider di identità è un antipattern. Non è consigliabile.

Prima di definire una strategia di gestione delle identità multi-tenant, è necessario considerare prima di tutto i requisiti di identità di alto livello del servizio, inclusi i requisiti seguenti:

  • Le identità utente o carico di lavoro verranno usate per accedere a una singola applicazione o a più applicazioni all'interno di una famiglia di prodotti? Ad esempio, una famiglia di prodotti al dettaglio potrebbe avere entrambe, un'applicazione punto vendita e un'applicazione di gestione dell'inventario, che condividono la stessa soluzione di identità.
  • Si prevede di implementare l'autenticazione e l'autorizzazione moderne, ad esempio OAuth2 e OpenID Connessione?
  • La soluzione fornisce solo l'autenticazione alle applicazioni basate sull'interfaccia utente? In alternativa, si fornisce anche l'accesso api ai tenant e alle terze parti?
  • I tenant dovranno eseguire la federazione con il proprio Provider di identità e dovranno essere supportati più provider di identità diversi per ogni tenant? Ad esempio, è possibile che si disponga di tenant con ID Microsoft Entra, Auth0 e Active Directory Federation Services (ADFS), in cui ognuno vuole eseguire la federazione con la soluzione. È anche necessario comprendere i protocolli federativi degli IDP dei tenant supportati, perché i protocolli influenzano i requisiti per il provider di identità.
  • Esistono requisiti di conformità specifici che devono soddisfare, ad esempio il GDPR?
  • I tenant richiedono che le informazioni di identità si trovino all'interno di un'area geografica specifica?
  • Gli utenti della soluzione richiedono l'accesso ai dati da un tenant o da più tenant all'interno dell'applicazione? È necessaria la possibilità di passare rapidamente tra tenant o visualizzare informazioni consolidate da più tenant? Ad esempio, gli utenti che hanno eseguito l'accesso all'portale di Azure possono passare facilmente tra diverse directory di Azure Active Directory e sottoscrizioni a cui hanno accesso.

Dopo aver stabilito i requisiti generali, è possibile iniziare a pianificare dettagli e requisiti più specifici, ad esempio origini della directory utente e flussi di iscrizione/accesso.

Directory Identity

Per consentire a una soluzione multi-tenant di autenticare e autorizzare un utente o un servizio, è necessario un luogo in cui 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 provider di identità.

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

  • Provider di identità locale. Un provider di identità locale consente agli utenti di iscriversi al servizio. Gli utenti forniscono un nome utente, un indirizzo di posta elettronica o un identificatore, ad esempio un numero di carta premio. Forniscono anche credenziali, ad esempio una password. IdP archivia sia l'identificatore utente che le credenziali.
  • Provider di identità social. Un provider di identità di social networking consente agli utenti di usare un'identità che ha in un social network o in un altro provider di identità pubblico, ad esempio Facebook, Google o un account Microsoft personale.
  • Usare la directory Microsoft Entra ID o Microsoft 365 del tenant. I tenant potrebbero avere già la propria directory Microsoft Entra ID o Microsoft 365 e potrebbero voler usare la propria directory come IdP per accedere alla soluzione. Questo approccio è possibile quando la soluzione viene compilata come applicazione Microsoft Entra multi-tenant.
  • Federazione con il provider di identità di un tenant. I tenant potrebbero avere il proprio IdP, diverso da Microsoft Entra ID o Microsoft 365, e potrebbero volere che la soluzione sia federata con essa. La federazione consente l'accesso Single Sign-On (SSO) e consente 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, potrebbe essere necessario supportare identità locali, identità di social networking e identità federate, tutte all'interno di un singolo tenant. Questo requisito è comune quando le aziende usano una soluzione sia per i propri dipendenti che per i terzisti. Possono usare la federazione per l'accesso dei propri dipendenti alla soluzione, consentendo anche l'accesso a terzisti o agli utenti guest, che non dispongono di un account nel provider di identità federato.

Archiviare le informazioni di autenticazione e autorizzazione del tenant

In una soluzione multi-tenant è necessario considerare 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 richieste dai tenant.
  • Informazioni necessarie per autenticare in modo sicuro gli utenti, incluse le informazioni necessarie per fornire l'autenticazione a più fattori (MFA).
  • Informazioni specifiche del tenant, ad esempio ruoli e autorizzazioni del tenant. Queste informazioni vengono usate per l'autorizzazione.

Attenzione

Non è consigliabile creare personalmente processi di autenticazione. I provider di identità moderni forniscono questi servizi di autenticazione all'applicazione e includono anche altre importanti funzionalità, ad esempio MFA e accesso condizionale. La creazione di un provider di identità è un antipattern. Non è consigliabile.

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

  • Archiviare tutte le informazioni di identità e autorizzazione nella directory IdP e condividerle tra più tenant.
  • Archiviare le credenziali utente nella directory IdP e archiviare le informazioni di autorizzazione nel livello applicazione, insieme alle informazioni sul tenant.

Determinare il numero di identità per un utente

È comune che le soluzioni multi-tenant consentano a un utente o a un'identità del carico di lavoro di accedere all'applicazione e ai dati di più tenant. Valutare se questo approccio è necessario per la soluzione. In caso affermativo, è consigliabile considerare le domande seguenti:

  • È necessario creare una singola identità utente per ogni persona o creare identità separate per ogni combinazione di utenti tenant?
    • È consigliabile usare una singola identità per ogni persona, laddove possibile. Diventa difficile gestire più account utente, sia per conto dell'utente, sia come fornitore della soluzione, sia per gli utenti. Inoltre, molte delle protezioni intelligenti per le minacce offerte da un provider di identità moderno si basano su ogni persona con un singolo account utente.
    • In alcune situazioni, tuttavia, potrebbe essere necessario che un utente disponga di più identità distinte. Ad esempio, se le persone usano il sistema sia a scopo aziendale che personale, potrebbero voler separare gli account utente. In alternativa, 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.
  • Se si usano identità per tenant, evitare di archiviare le credenziali più volte. Gli utenti devono avere le 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 del tenant

Valutare il modo in cui gli utenti verranno mappati a un tenant. Ad esempio, durante il processo di iscrizione, è possibile usare un codice di invito univoco che immette la prima volta che accedono a un tenant. In alcune soluzioni, è possibile usare il nome di dominio degli indirizzi di posta elettronica di iscrizione degli utenti come modo per identificare il tenant a cui appartengono. In alternativa, è possibile usare un altro attributo del record di identità dell'utente per eseguire il mapping dell'utente a un tenant. È quindi necessario archiviare il mapping in base agli identificatori univoci non modificabili sottostanti sia per il tenant che per l'utente.

Se la soluzione è progettata in modo che un singolo utente accinga ai dati per un singolo tenant, prendere in considerazione le decisioni seguenti:

  • In che modo il provider di identità rileva il tenant a cui accede un utente?
  • In che modo il provider di identità 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ù tenant, è necessario prendere in considerazione le decisioni seguenti:

  • In che modo la soluzione identifica e concede le autorizzazioni a un utente che ha accesso a più tenant? Ad esempio, un utente può essere un amministratore in un tenant di training e avere accesso in sola lettura a un tenant di produzione? In alternativa, è possibile avere tenant separati per reparti diversi in un'organizzazione, ma è necessario mantenere identità utente coerenti in tutti i tenant?
  • In che modo un utente passa da un tenant all'altro?
  • Se si usano le identità del carico di lavoro, in che modo un'identità del carico di lavoro specifica il tenant a cui deve accedere?
  • Sono presenti informazioni specifiche del tenant archiviate nel record di identità dell'utente che potrebbero perdere informazioni tra tenant? Si supponga, ad esempio, che un utente abbia effettuato l'iscrizione con un'identità di social networking e che sia stato quindi concesso l'accesso a due tenant. Tenant A ha arricchito l'identità dell'utente con altre informazioni. Il tenant B deve avere accesso alle informazioni arricchite?

Processo di iscrizione utente per identità locali o identità di social networking

Alcuni tenant potrebbero dover consentire agli utenti di iscriversi per ottenere 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 le domande seguenti:

  • Quali origini di identità sono consentite agli utenti di iscriversi? Ad esempio, un utente può creare un'identità locale e usare anche un provider di identità di social networking?
  • Se sono consentite solo le identità locali, saranno consentiti solo domini di posta elettronica specifici? Ad esempio, un tenant può specificare che solo gli utenti con un @contoso.com indirizzo di posta elettronica possono iscriversi?
  • Qual è il nome dell'entità utente (UPN) che deve essere usato per identificare in modo univoco ogni identità locale durante il processo di accesso? Ad esempio, un indirizzo di posta elettronica, un nome utente, un numero di telefono e un numero di carta ricompensa sono tutte scelte comuni per gli UPN. Tuttavia, gli UPN possono cambiare nel tempo. Quando si fa riferimento all'identità nelle regole di autorizzazione o nei log di controllo dell'applicazione, è consigliabile usare l'identificatore univoco non modificabile sottostante dell'identità. Microsoft Entra ID fornisce un ID oggetto (OID), che è un identificatore non modificabile.
  • Sarà necessario che un utente verifichi il proprio UPN? Ad esempio, se l'indirizzo di posta elettronica o il numero di telefono dell'utente viene usato come UPN, come si verificherà che le informazioni siano accurate?
  • Gli amministratori tenant devono approvare le operazioni di iscrizione?
  • I tenant richiedono un'esperienza di iscrizione o un URL specifici del tenant? Ad esempio, i tenant richiedono un'esperienza di iscrizione personalizzata quando gli utenti si registrano? I tenant richiedono la possibilità di intercettare una richiesta di iscrizione ed eseguire una convalida aggiuntiva prima di procedere?

Accesso al tenant per gli utenti auto-iscrizione

Quando gli utenti sono autorizzati a iscriversi per ottenere un'identità, in genere è necessario che venga concesso loro l'accesso a un tenant. Il flusso di iscrizione potrebbe includere un processo di concessione di accesso o potrebbe essere automatizzato, in base alle informazioni sugli utenti, ad esempio i relativi indirizzi di posta elettronica. È importante pianificare questo processo e considerare le domande seguenti:

  • In che modo il flusso di iscrizione determina che a un utente deve essere concesso l'accesso a un tenant specifico?
  • Se gli utenti non devono più avere accesso a un tenant, la soluzione revoca automaticamente l'accesso? Ad esempio, quando gli utenti lasciano un'organizzazione, è necessario un processo manuale o automatizzato che rimuove l'accesso dal tenant.
  • È necessario fornire ai tenant un modo per controllare gli utenti che hanno accesso ai tenant e alle relative autorizzazioni?

Gestione automatica del ciclo di vita degli account

Un requisito comune per i clienti aziendali o aziendali di una soluzione è un set di funzionalità che consente loro di automatizzare l'onboarding e l'off-onboarding 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 non solo la creazione e la rimozione dei record di identità, ma anche la gestione delle autorizzazioni del tenant. Quando si implementa la gestione automatica del ciclo di vita degli account in una soluzione multi-tenant, prendere in considerazione le domande seguenti:

  • I clienti devono configurare e gestire un processo automatizzato del ciclo di vita 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 ogni tenant ha un set di autorizzazioni diverso.
  • È necessario implementare SCIM o fornire invece la federazione dei tenant per mantenere l'origine della verità per gli utenti sotto il controllo del tenant, anziché gestire gli utenti locali?

Processo di autenticazione utente

Quando un utente accede a un'applicazione multi-tenant, il sistema di identità autentica l'utente. Quando si pianifica il processo di autenticazione, è consigliabile considerare le domande seguenti:

  • I tenant devono configurare i propri criteri di autenticazione a più fattori ?? Ad esempio, se i tenant si trovano nel settore dei servizi finanziari, devono implementare criteri di autenticazione a più fattori rigorosi, mentre un piccolo rivenditore online potrebbe non avere gli stessi requisiti.
  • I tenant devono configurare le proprie regole di accesso condizionale? Ad esempio, potrebbero essere necessari tenant diversi per bloccare i tentativi di accesso da aree geografiche specifiche.
  • I tenant devono personalizzare il processo di accesso per ogni tenant? Ad esempio, è necessario mostrare il logo di un cliente? In alternativa, le informazioni su ogni utente devono essere estratte da un altro sistema, ad esempio un numero di ricompense, e restituite al provider di identità per aggiungere al profilo utente?
  • Gli utenti devono rappresentare altri utenti? Ad esempio, un membro del team di supporto potrebbe voler analizzare un problema riscontrato da un altro utente, rappresentando il proprio account utente senza dover eseguire l'autenticazione come utente.
  • Gli utenti devono ottenere l'accesso alle API per la soluzione? Ad esempio, gli utenti o le applicazioni di terze parti potrebbero dover chiamare direttamente le API per estendere la soluzione, senza un'interfaccia utente per fornire un flusso di autenticazione.

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 alcune delle attività di gestione.

Le identità del carico di lavoro sono simili alle identità utente, ma in genere richiedono metodi di autenticazione diversi, ad esempio chiavi o certificati. Le identità del carico di lavoro non usano mfa. Al contrario, le identità del carico di lavoro richiedono in genere altri controlli di sicurezza, ad esempio la normale scadenza della chiave e del certificato.

Se i tenant si aspettano di poter abilitare l'accesso all'identità del carico di lavoro alla soluzione multi-tenant, è consigliabile considerare le domande seguenti:

  • Come verranno create e gestite le identità del carico di lavoro in ogni tenant?
  • In che modo le richieste di identità del carico di lavoro verranno limitate all'ambito del tenant?
  • È necessario limitare il numero di identità del carico di lavoro create da ogni tenant?
  • È necessario fornire controlli di accesso condizionale sulle identità del carico di lavoro per ogni tenant? Ad esempio, un tenant potrebbe voler limitare l'autenticazione di un'identità del carico di lavoro dall'esterno di un'area specifica.
  • Quali controlli di sicurezza verranno forniti ai tenant per garantire che le identità del carico di lavoro siano protette? Ad esempio, il monitoraggio automatizzato dei rischi per la chiave, la scadenza della chiave, la scadenza del certificato e il monitoraggio dei rischi di accesso sono tutti i metodi per ridurre il rischio, in cui un'identità del carico di lavoro potrebbe essere impropria.

Eseguire la federazione con un provider di identità per l'accesso Single Sign-On (SSO)

I tenant, che dispongono già di directory utente, potrebbero volere che la soluzione venga federata alle 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 l'accesso Single Sign-On (SSO).

Se si prevede che i tenant si federatino con la soluzione, è consigliabile considerare le domande seguenti:

  • Qual è il processo di configurazione della federazione per un tenant? I tenant possono configurare autonomamente la federazione oppure il processo richiede la configurazione e la manutenzione manuali da parte del team?
  • Quali protocolli di federazione verranno supportati?
  • Quali processi sono disponibili per garantire che la federazione non possa essere configurata in modo errato, per concedere l'accesso a un altro tenant?
  • Il provider di identità di un singolo tenant deve essere federato a più tenant nella soluzione? Ad esempio, se i clienti hanno sia un tenant di training che quello di produzione, potrebbe essere necessario eseguire la federazione dello stesso provider di identità in entrambi i tenant.

Modelli di autorizzazione

Decidere il modello di autorizzazione più appropriato per la soluzione. Due approcci di autorizzazione comuni sono:

  • Role-based authorization. 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 avere 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 specifico 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.

Per altre informazioni, vedere Autorizzazione basata su ruoli e basata su risorse.

Diritti e licenze

In alcune soluzioni è possibile usare le licenze per utente come parte del modello di prezzi commerciale. È possibile fornire diversi livelli di licenze utente con funzionalità diverse. Ad esempio, gli utenti con una licenza potrebbero essere autorizzati a usare un subset delle funzionalità dell'applicazione. Le funzionalità a cui è consentito l'accesso a utenti specifici, in base alle licenze, sono talvolta denominate entitlement.

Anche se il rilevamento e l'applicazione dei diritti sono simili all'autorizzazione, viene normalmente gestito dal codice dell'applicazione o da un sistema di entitlement dedicato, anziché gestito dal sistema di 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 devono essere elaborate dalla soluzione. Considerare le seguenti domande:

  • La directory utente verrà ridimensionata in base al numero di utenti necessari?
  • Il processo di autenticazione gestirà il numero previsto di accessi e di iscrizione?
  • Ci saranno picchi che il sistema di autenticazione non può gestire? Ad esempio, alle 9:00 PST, tutti gli utenti dell'area occidentale Stati Uniti potrebbero iniziare a lavorare e accedere alla soluzione, causando un picco nelle richieste di accesso. Queste situazioni sono talvolta chiamate tempeste di accesso.
  • Un carico elevato in altre parti della soluzione può influire sulle prestazioni del processo di autenticazione? Ad esempio, se il processo di autenticazione richiede la chiamata a un'API a livello di applicazione, un numero elevato di richieste di autenticazione causerà problemi per il resto della soluzione?
  • Cosa succede se il provider di identità non è più disponibile? Esiste un servizio di autenticazione di backup che può assumere il controllo per garantire la continuità aziendale, mentre il provider di identità non è disponibile?

Collaboratori

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

Autori principali:

Altri contributori:

Passaggi successivi

Vedere Approcci architetturali per l'identità nelle soluzioni multi-tenant.