Approcci architetturali per l'identità in soluzioni multi-tenant

Quasi tutte le soluzioni multi-tenant richiedono un sistema di gestione identità. In questo articolo, vengono illustrati i componenti comuni dell'identità, inclusa l'autenticazione e l'autorizzazione, e viene mostrato in che modo questi componenti possono essere applicati in una soluzione multi-tenant.

Autenticazione

L'autenticazione è il processo in base al quale viene stabilita l'identità dell'utente. Quando si crea una soluzione multi-tenant, esistono considerazioni e approcci speciali per diversi aspetti del processo di autenticazione.

Federazione

Può essere necessario eseguire la federazione con altri provider di identità (IDP). La federazione può essere usata per abilitare i seguenti scenari:

• Accesso tramite social, ad esempio consentendo agli utenti di usare il proprio account Google, Facebook, GitHub o Microsoft personale.
• Directory specifiche per i tenant, come l'abilitazione dei tenant a fare federare la tua applicazione con i propri provider di identità, così non devono gestire gli account in più luoghi.

Per informazioni generali sulla federazione, consultare la sezione Modello di identità federata.

Se scegli di supportare fornitori di identità specifici per il tenant, assicurati di chiarire quali servizi e protocolli devi supportare. Ad esempio, verranno supportati il protocollo OpenID Connect e il protocollo SAML (Security Assertion Markup Language) ? Oppure verrà supportata solo la federazione con le istanze Microsoft Entra?

Quando si implementa un provider di identità, considerare eventuali limiti e scalabilità applicabili. Ad esempio, il provider di identità potrebbe essere in grado di eseguire la federazione solo con un numero limitato di altri provider di identità.

È inoltre possibile considerare la federazione come funzionalità applicabile solo ai clienti a un livello di prodotto superiore.

Autenticazione unica

Le esperienze Single sign-on consentono agli utenti di passare facilmente da un'applicazione all'altra senza dover ripetere l'autenticazione a ogni punto.

Quando gli utenti eseguono un'applicazione, l'applicazione li indirizza a un IdP. Se IdP nota una sessione esistente, rilascia un nuovo token senza richiedere agli utenti di interagire con il processo di accesso. Un modello di identità federata supporta le esperienze Single sign-on, consentendo agli utenti di utilizzare una singola identità in più applicazioni.

In una soluzione multi-tenant, è inoltre possibile abilitare un altro tipo di accesso Single Sign-On. Se gli utenti sono autorizzati a lavorare con i dati per tenant multipli, potrebbe essere necessario offrire un'esperienza semplice quando gli utenti modificano il contesto da un tenant a un altro. Considerare se è necessario supportare transizioni fluide tra tenant e, in tal caso, se il provider di identità deve riemettere i token con attestazioni specifiche per il tenant. Ad esempio, un utente che ha eseguito l'accesso al portale di Azure può passare da una directory di Microsoft Entra all'altra, il che causa la ri-autenticazione e ripubblica il token dall'istanza di Microsoft Entra appena selezionata.

Valutazione dei rischi correlati all'accesso

Le moderne piattaforme di gestione identità supportano una valutazione dei rischi durante il processo di accesso. Ad esempio, se un utente accede da una posizione o da un dispositivo insolito, il sistema di autenticazione potrebbe richiedere controlli di identità aggiuntivi, ad esempio l'autenticazione a più fattori (MFA), prima di consentire la continuazione della richiesta di accesso.

Considerare se i tenant potrebbero avere criteri di rischio diversi che devono essere applicati durante il processo di autenticazione. Ad esempio, se si dispone di alcuni tenant in un settore altamente regolamentato, questi potrebbero avere profili di rischio e requisiti diversi per i tenant che lavorano in ambienti meno regolamentati. In alternativa, è possibile scegliere di consentire ai tenant con piani tariffari più elevati di specificare criteri di accesso più restrittivi rispetto ai tenant che acquistano un livello inferiore di servizio.

Se è necessario supportare criteri di rischio diversi per ogni tenant, il sistema di autenticazione dovrà conoscere il tenant a cui l'utente accede, in modo che possa applicare i criteri corretti.

Se IdP include queste funzionalità, è consigliabile usare le funzionalità di valutazione dei rischi di accesso nativi IdP. Queste funzionalità possono essere complesse e soggette a errori da risolvere manualmente.

In alternativa, se si esegue la federazione con i provider di identità dei tenant, sarà possibile applicare i propri criteri di mitigazione degli accessi a rischio e controllare i criteri e i controlli da applicare. Tuttavia, è importante evitare di aggiungere inavvertitamente un carico non necessario all'utente, ad esempio, richiedendo due problemi di autenticazione a più fattori, uno dal provider di identità principale dell'utente e uno dal proprio. Assicuratevi di comprendere come la federazione interagisce con ogni provider di identità dei vostri tenant e le politiche che hanno applicato.

Impersonificazione

La rappresentazione consente a un utente di assumere l'identità di un altro utente, senza dover usare le sue credenziali.

In generale, la rappresentazione è una procedura pericolosa e può essere difficile da implementare e controllare. Tuttavia, in alcuni scenari, l'impersonazione è un requisito. Ad esempio, se si usa Software as a service (SaaS), il personale del supporto tecnico potrebbe dover presupporre l'identità di un utente, in modo che possa accedere come utente e risolvere un problema.

Se si sceglie di implementare l'impersonazione, considerare come controllarne l'uso. Assicurarsi che i log includano sia l'effettivo utente che ha eseguito l'azione sia l'identificatore dell'utente impersonato.

Alcune piattaforme di identità supportano la rappresentazione come funzionalità predefinita o usando un codice personalizzato. Ad esempio, in Microsoft Entra External ID è possibile aggiungere un'attestazione personalizzata per l'ID utente rappresentato oppure sostituire l'attestazione dell'identificatore del soggetto nei token rilasciati.

Autorizzazione

L'autorizzazione è il processo volto a determinare ciò che un utente è autorizzato a fare.

I dati di autorizzazione possono essere archiviati in diverse posizioni, comprese le posizioni seguenti:

• Nel proprio provider di identità. Ad esempio, se si usa Microsoft Entra ID come provider di identità, è possibile usare funzionalità come ruoli app e gruppi per archiviare le informazioni di autorizzazione. L'applicazione può quindi impiegare le attestazioni di token associate per applicare le regole di autorizzazione.
• Nella propria applicazione. È possibile creare una logica di autorizzazione personalizzata e archiviare informazioni sulle operazioni che ogni utente può eseguire in un database o in un sistema di archiviazione simile. È quindi possibile progettare controlli con granularità fine per autorizzazioni a livello di ruolo o a livello di risorsa.

Nella maggior parte delle soluzioni multi-tenant, le assegnazioni di ruoli e permessi vengono gestite dal tenant o dal cliente, non dall'utente come fornitore del sistema multi-tenant.

Per maggiori informazioni, consultare la sezione Ruoli applicazione.

Aggiungere informazioni sull'identità del locatario e sul ruolo ai token

Considerare quale parte, o parti, della soluzione devono eseguire richieste di autorizzazione, tra cui determinare se un utente è autorizzato a lavorare con i dati di un tenant specifico.

Un approccio comune consiste nel fare in modo che il sistema di identità incorpori un'asserzione di identificatore di tenant in un token. Questo approccio permette all'applicazione di esaminare l'attestazione e verificare che gli utenti lavorino con il tenant a cui sono autorizzati ad accedere. Se si usa il modello di sicurezza basato sui ruoli, sarà possibile scegliere di estendere il token con informazioni sul ruolo che un utente ha all'interno del tenant.

Tuttavia, se un singolo utente è autorizzato ad accedere a tenant multipli, potrebbe essere necessario un modo per consentire agli utenti di segnalare il tenant con cui intende lavorare durante il processo di accesso. Dopo aver selezionato il tenant attivo, l'IdP può includere la dichiarazione dell'identificatore e il ruolo corretti per quel tenant nel token che emette. È inoltre necessario considerare come gli utenti possono passare da un tenant all'altro, il che richiede l'emissione di un nuovo token.

Autorizzazione basata sull'applicazione

Un approccio alternativo consiste nel rendere il sistema identità indipendente dagli identificatori e dai ruoli del tenant. Gli utenti vengono identificati usando le credenziali o una relazione di federazione, e i token non includono un'attestazione di identificatore del tenant. Un elenco, o un database separato, contiene gli utenti a cui è stato concesso l'accesso a ogni tenant. Il livello dell'applicazione può quindi verificare se l'utente specificato è autorizzato ad accedere ai dati di un cliente specifico, basandosi sulla verifica di quell'elenco.

Usare l'ID Microsoft Entra o l'ID esterno di Microsoft Entra

Microsoft fornisce Microsoft Entra ID e Microsoft Entra External ID, che sono piattaforme di identità gestite che è possibile usare all'interno della propria soluzione multi-tenant.

Molte delle soluzioni multi-tenant sono Software as a service (SaaS). La scelta di usare Microsoft Entra ID o Microsoft Entra External ID dipende, in parte, dal modo in cui si definiscono i tenant o la base clienti.

• Se i tenant o i clienti sono organizzazioni, potrebbero già usare Microsoft Entra ID per i servizi come Microsoft 365, Microsoft Teams o per i propri ambienti Azure. È possibile creare un'applicazione multi-tenant nella directory Microsoft Entra per rendere disponibile la soluzione ad altre directory di Microsoft Entra. È inoltre possibile elencare la soluzione in Azure Marketplace e renderla facilmente accessibile alle organizzazioni che usano Microsoft Entra ID.
• Se i tenant o i clienti non usano Microsoft Entra ID o se sono singoli utenti anziché organizzazioni, è consigliabile usare Microsoft Entra External ID. Microsoft Entra External ID offre funzionalità per controllare il modo in cui gli utenti si registrano e accedono. Per esempio, è possibile limitare l'accesso alla soluzione solo agli utenti già invitati oppure consentire l'iscrizione self-service. È possibile usare il marchio personalizzato ed è possibile invitare utenti dal tenant di Microsoft Entra ID come ospiti all'ID esterno di Microsoft tramite accesso ospite, per consentire al personale di effettuare l'accesso. Microsoft Entra External ID abilita anche la federazione con altri provider di identità.
• Alcune delle soluzioni multi-tenant sono destinate a entrambe le situazioni elencate in precedenza. Alcuni tenant potrebbero avere i propri tenant Microsoft Entra, mentre altri potrebbero non averli. È possibile usare Microsoft Entra External ID per questo scenario e usare la federazione per consentire l'accesso utente dalla directory Microsoft Entra di un tenant.

Antipattern da evitare

Creazione o gestione del proprio sistema di identità

La creazione di una moderna piattaforma di gestione identità è una procedura complessa. Esistono diversi protocolli e standard da supportare, ed è facile implementare in modo errato un protocollo ed esporre una vulnerabilità di sicurezza. Gli standard e i protocolli cambiano ed è necessario aggiornare continuamente il sistema di identità per attenuare gli attacchi e supportare le funzionalità di sicurezza recenti. È inoltre importante assicurarsi che un sistema di identità sia resiliente, in quanto qualsiasi tempo di inattività può avere gravi conseguenze per il resto della soluzione. Inoltre, nella maggior parte dei casi, l'implementazione di un provider di identità non aggiunge un vantaggio all'azienda ed è semplicemente un passaggio necessario dell'implementazione di un servizio multi-tenant. È preferibile usare piuttosto un sistema di identità specializzato che venga costruito, gestito e protetto da esperti.

Quando si esegue il proprio sistema di identità, è necessario salvare gli hash delle password o altre forme di credenziali, che diventano una destinazione allettante per gli utenti malintenzionati. Anche l'hashing e il salting delle password sono spesso procedure insufficienti, perché la potenza di calcolo disponibile per gli utenti malintenzionati può rendere possibile compromettere queste forme di credenziali.

Quando si esegue un sistema di identità, si è responsabili della generazione e della distribuzione di codici OTP (MFA o password monouso). Questi requisiti indicano che è necessario un meccanismo per distribuire questi codici, usando SMS o posta elettronica. Inoltre, si è responsabili del rilevamento di attacchi mirati e di forza bruta, limitazione dei tentativi di accesso, controllo, ecc.

Invece di creare o eseguire il proprio sistema di identità, è consigliabile usare un servizio o un componente standard. Si consideri ad esempio l'uso dell'ID Microsoft Entra o dell'ID esterno Microsoft Entra, che sono piattaforme di gestione delle identità. I fornitori di piattaforme di identità gestite si occupano di gestire l'infrastruttura per le proprie piattaforme e in genere di supportare gli standard di identità e autenticazione correnti.

Trascurare di considerare i requisiti dei tuoi inquilini

I tenant spesso hanno opinioni forti sulla modalità di gestione dell'identità per le soluzioni usate. Ad esempio, molti clienti aziendali richiedono la federazione con i propri provider di identità per abilitare le esperienze di Single Sign-On ed evitare di gestire più set di credenziali. Altri tenant possono richiedere l'autenticazione a più fattori o altre forme di protezione per i processi di accesso. Se non sono stati progettati per questi requisiti, potrebbe essere difficile riconfigurarli in un secondo momento.

Assicurarsi di comprendere i requisiti di identità dei tenant prima di finalizzare la progettazione del sistema di gestione identità. Consultare la sezione Considerazioni sull'architettura per l'identità in una soluzione multi-tenant per comprendere alcuni requisiti specifici che spesso emergono.

Confondere utenti e inquilini

È importante valutare bene in che modo la soluzione definisce un utente e un tenant. In molte situazioni, la relazione potrebbe essere complessa. Ad esempio, un tenant potrebbe contenere più utenti, e un singolo utente potrebbe partecipare a più tenant.

Assicurati di avere un processo chiaro per tenere traccia del contesto del tenant all'interno delle tue applicazioni e richieste. In alcune situazioni, questo processo può richiedere di includere un identificatore del tenant in ogni token di accesso e di convalidare l'identificatore del tenant in ogni richiesta. In altre situazioni, le informazioni di autorizzazione del tenant vengono archiviate separatamente dalle identità utente, e viene utilizzato un sistema di autorizzazione più complesso per gestire quali utenti possono eseguire le operazioni in base ai tenant.

Il rilevamento del contesto tenant di un utente o di un token si applica a qualsiasi modello di tenancy perché un'identità utente ha sempre un contesto tenant all'interno di una soluzione multi-tenant. È inoltre consigliabile tenere traccia del contesto del tenant quando si distribuiscono stamp indipendenti per un singolo tenant, che garantisce il codebase per altre forme di multi-tenancy.

Fusione dell'autorizzazione di ruoli e risorse

È importante scegliere un modello di autorizzazione appropriato per la soluzione. Gli approcci di sicurezza basati sul ruolo possono essere semplici da implementare, ma l'autorizzazione basata sulle risorse offre un controllo più granulare. Valutare i requisiti dei tenant e considerare se i tenant devono autorizzare alcuni utenti ad accedere a parti specifiche della soluzione e non ad altre parti.

Impossibile scrivere log di controllo

I log di controllo sono uno strumento importante di comprensione dell'ambiente e del modo in cui gli utenti implementano il sistema. Controllando ogni evento correlato all'identità, è spesso possibile determinare se il sistema di identità è sotto attacco, ed è possibile esaminare in che modo viene usato il sistema. Assicurarsi di scrivere e archiviare i log di controllo nel sistema di identità. Considerare se i log di controllo delle identità della soluzione devono essere resi disponibili ai tenant per esaminarli.

Collaboratori

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

Autori principali:

• John Downs | Principal Software Engineer
• Daniel Scott-Raynsford | Partner Technology Strategist
• Arsen Vladimirskiy | Ingegnere Cliente Principale, FastTrack per Azure

Altri contributori:

• Jelle Druyts | Principal Customer Engineer, FastTrack per Azure
• Landon Pierce | Senior Customer Engineer
• Sander van den Hoven | Senior Partner Technology Strategist
• Nick Ward | Senior Cloud Solution Architect

Passaggi successivi

Esaminare Considerazioni architetturali per l'identità in una soluzione multitenant.