Condividi tramite

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

  • Articolo

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

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

I clienti potrebbero 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 ottiene l'accesso. È importante valutare i requisiti di identità per isolare l'applicazione e i dati tra tenant.

Attenzione

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

La procedura di creazione del proprio IdP è complessa, costosa e difficile da implementare in modo sicuro. La procedura di creazione di un provider di identità è un antipattern. Non è una scelta consigliata.

Prima di definire una strategia di gestione 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 vengono usate per accedere a una singola applicazione o a più applicazioni all'interno di una famiglia di prodotti? Ad esempio, una famiglia di prodotti 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 Connect?
  • La soluzione fornisce solo l'autenticazione alle applicazioni basate su interfaccia utente? Oppure si fornisce anche l'accesso API ai tenant e alle terze parti?
  • I tenant dovranno eseguire la federazione con il proprio IdP e dovranno essere supportati più provider di identità diversi per ogni tenant? Ad esempio, è possibile che si disponga di tenant con Microsoft Entra ID, Auth0 e Active Directory Federation Services (ADFS), in cui ognuno esegue la federazione con la soluzione. È inoltre 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, per esempio il GDPR?
  • I tenant richiedono che le informazioni di identità si trovino in un'area geografica specifica?
  • Gli utenti della soluzione richiedono l'accesso ai dati da un tenant o da tenant multipli all'interno dell'applicazione? È necessaria la possibilità di passare rapidamente tra tenant o visualizzare informazioni consolidate da tenant multipli? Ad esempio, gli utenti che hanno eseguito l'accesso al portale di Azure possono passare facilmente tra le directory Microsoft Entra ID e sottoscrizioni diverse a cui hanno accesso.

Dopo aver stabilito i requisiti generali, è possibile pianificare dettagli e requisiti più specifici, ad esempio origini della directory utente e flussi di iscrizione/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 contenere riferimenti a identità esterne archiviate nella directory di un altro provider di identità.

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:

  • Provider di identità locale. Un provider di identità locale permette agli utenti di iscriversi al 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.
  • Provider di identità basate su social. Un provider di identità basate sui social 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 del tenant. I tenant potrebbero già disporre della propria directory Microsoft Entra ID e potrebbero voler usare la propria directory come IdP per accedere alla soluzione. Questo approccio è possibile quando la soluzione viene creata come applicazione Microsoft Entra multi-tenant.
  • Federazione con provider di identità di un tenant. I tenant potrebbero avere il proprio IdP, diverso da Microsoft Entra ID, e potrebbero volere che la soluzione si federata. La federazione consente l'accesso Single Sign-On (SSO) e ai tenant di gestire il ciclo di vita e i criteri di sicurezza dei propri utenti, indipendentemente dalla soluzione.

È consigliabile valutare se i tenant devono supportare più provider di identità. Ad esempio, potrebbe essere necessario supportare identità locali, identità di social networking e federate, tutte all'interno di un singolo tenant. Questo requisito è comune quando le aziende usano una soluzione sia per i propri dipendenti che per contraenti Possono usare la federazione per l'accesso dei propri dipendenti alla soluzione, consentendo anche l'accesso a contraenti o ad utenti guest, che non dispongono di un account nel provider di identità federato.

Salvare le informazioni sull'autenticazione e l'autorizzazione di 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 nomi e altre informazioni richieste dai tenant.
  • Informazioni necessarie per autenticare in modo sicuro gli utenti, incluse le informazioni necessarie per l'autenticazione a più fattori (MFA).
  • Informazioni specifiche del tenant, per esempio ruoli e autorizzazioni del tenant. Queste informazioni vengono utilizzate 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. La procedura di creazione di un 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 e le informazioni di autorizzazione nel livello applicazione, insieme alle informazioni sul tenant.

Stabilire 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 tenant multipli. Considerare se questo approccio è necessario per la soluzione. In caso affermativo, considerare le domande seguenti:

  • È necessario creare una singola identità utente per ogni persona oppure identità separate per ogni combinazione di utenti tenant?
    • Si raccomanda 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 che per gli utenti. Inoltre, molte delle protezioni intelligenti per le minacce offerte da un provider di identità moderno si basano su ogni persona con singolo account utente.
    • In alcune situazioni, tuttavia, un utente potrebbe dover disporre di più identità distinte. Ad esempio, se si usa il sistema sia a scopo aziendale che personale, si potrebbe voler separare gli account utente. In alternativa, se i tenant hanno requisiti rigorosi di archiviazione dei dati normativi o geografici, potrebbero richiedere di disporre di più identità in modo che possano essere conformi alle normative o alle leggi.
  • Se si usano identità per tenant, è consigliabile evitare di archiviare le credenziali più volte. 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

Considerare 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 da immettere la prima volta che accedono a un tenant. In alcune soluzioni, è possibile usare il nome di dominio degli indirizzi email di iscrizione degli utenti come modo per identificare il tenant a cui appartengono. In alternativa, è possibile usare un altro attributo del record di identità utente per eseguire il mapping dell'utente a un tenant. È 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 acceda ai dati per un singolo tenant, valutare le decisioni seguenti:

  • In che modo IdP rileva il tenant a cui accede un utente?
  • In che modo IdP comunica l'identificatore del tenant all'applicazione? In genere, al token viene aggiunta un'attestazione di identificatore del tenant.

Se un singolo utente necessita di 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 tenant multipli? Ad esempio, è possibile che un utente sia amministratore in un tenant di training e abbia accesso in sola lettura a un tenant di produzione? Oppure è 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à dei carichi di lavoro, in che modo un'identità del carico di lavoro specifica il tenant a cui deve accedere?
  • Esistono 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 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?

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 richiesta se non è necessaria la federazione con il provider di identità di un tenant. Se è necessario un processo di iscrizione automatica, considerare le domande seguenti:

  • Da quali origini di identità possono iscriversi gli utenti? Ad esempio, un utente può creare un'identità locale e usare un provider di identità di social networking?
  • Se sono consentite solo le identità locali, sono consentiti solo domini email specifici? Ad esempio, un tenant può specificare che solo gli utenti con un @contoso.com indirizzo email possono iscriversi?
  • Qual è il nome dell'entità utente (UPN) da usare per identificare in modo univoco ogni identità locale durante il processo di accesso? Ad esempio, un indirizzo email, 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 con il 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), ovvero un identificatore non modificabile.
  • Un utente deve verificare il proprio UPN? Ad esempio, se l'indirizzo email 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 e di eseguire una convalida aggiuntiva prima di procedere?

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

Quando gli utenti sono autorizzati a iscriversi per ottenere un'identità, generalmente, è 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 email. È importante pianificare questo processo e valutare le domande seguenti:

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

Gestione automatica del ciclo di vita dell'account

Un requisito comune per i clienti 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 al settore all'automazione. Generalmente, questo processo automatizzato include 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, valutare le domande seguenti:

  • I clienti devono configurare e gestire il 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 tenant multipli nell'applicazione, in cui ogni tenant ha un set di autorizzazioni diverso.
  • È necessario implementare SCIM o fornire 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à lo autentica. Quando si pianifica il processo di autenticazione, è consigliabile valutare le domande seguenti:

  • I tenant devono configurare i propri criteri di autenticazione a più fattori (MFA)? 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.
  • I tenant devono configurare le proprie regole di accesso condizionale? Ad esempio, possono 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? Oppure 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 necessariamente eseguire l'autenticazione come utente.
  • Gli utenti devono ottenere 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 che vengano usate identità dei carichi 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 per poter automatizzare alcune delle attività di gestione.

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, ad esempio la normale scadenza della chiave e del certificato.

Se i tenant si aspettano di 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à dei carichi di lavoro in ogni tenant?
  • In che modo le richieste di identità dei carichi di lavoro verranno limitate all'ambito del tenant?
  • È necessario limitare il numero di identità dei carichi di lavoro create da ogni tenant?
  • È necessario fornire controlli di accesso condizionale sulle identità dei carichi di lavoro per ogni tenant? Ad esempio, un tenant potrebbe voler limitare l'autenticazione di un'identità dei carichi di lavoro dall'esterno di un'area specifica.
  • Quali controlli di sicurezza verranno forniti ai tenant per garantire che le identità dei carichi 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 usati per ridurre il rischio, in cui un'identità dei carichi di lavoro potrebbe essere impropria.

Eseguire la federazione con 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é di gestire un'altra directory con identità distinte.

La federazione è particolarmente importante quando alcuni tenant vogliono specificare i propri criteri di identità o abilitare l'accesso Single Sign-On (SSO).

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

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

Modelli di autorizzazione

Scegliere il modello di autorizzazione più appropriato per la soluzione. Due comuni approcci di autorizzazione 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 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 con il 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 da implementare.

Entitlement e licenze

In alcune soluzioni, è possibile usare le licenze per utente come parte del modello di prezzo commerciale. È possibile fornire diversi livelli 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 è consentito l'accesso a utenti specifici, in base alle licenze, sono a volte denominate entitlement.

Anche se il rilevamento e l'applicazione degli entitlement 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 anche il numero di utenti e richieste di accesso che devono essere elaborate dalla soluzione. Considerare le seguenti domande:

  • La directory utente viene ridimensionata in base al numero di utenti necessari?
  • Il processo di autenticazione gestisce il numero previsto di accessi e di iscrizione?
  • Ci saranno picchi che il sistema di autenticazione non sarà in grado di gestire? Ad esempio, alle ore 9:00 PST, tutti gli utenti dell'area occidentale degli Stati Uniti potrebbero iniziare a lavorare e accedere alla soluzione, causando un picco nelle richieste di accesso. Queste situazioni sono a volte chiamate picchi 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à dei problemi per il resto della soluzione?
  • Cosa succede se IdP non fosse più disponibile? Esiste un servizio di autenticazione di backup che può assumere il controllo per garantire la continuità aziendale quando IdP non è disponibile?

Collaboratori

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

Autori principali:

Altri contributori:

Passaggi successivi

Consultare la sezione Approcci architetturali per l'identità in soluzioni multi-tenant.