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

  • Articolo

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

Nota

Vedere Considerazioni sull'architettura per l'identità in una soluzione multi-tenant per altre informazioni sui requisiti chiave e sulle decisioni da prendere prima di iniziare a creare un sistema di identità per una soluzione multi-tenant.

Authentication

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

Federazione

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

  • Accesso tramite social network, ad esempio consentendo agli utenti di usare il proprio account Microsoft google, Facebook, GitHub o personale.
  • Directory specifiche del tenant, ad esempio abilitando i tenant per la federazione dell'applicazione con i propri provider di identità, quindi non è necessario gestire gli account in più posizioni.

Per informazioni generali sulla federazione, vedere il modello di identità federata.

Se si sceglie di supportare provider di identità specifici del tenant, assicurarsi di chiarire quali servizi e protocolli è necessario supportare. Ad esempio, si supporterà il protocollo OpenID Connessione e il protocollo SAML (Security Assertion Markup Language) ? In alternativa, si supporterà solo la federazione con le istanze di Microsoft Entra?

Quando si implementa un provider di identità, prendere in considerazione eventuali limiti e scalabilità applicabili. Ad esempio, se si usa Azure Active Directory (Azure AD) B2C come provider di identità, potrebbe essere necessario distribuire criteri personalizzati per la federazione con determinati tipi di provider di identità tenant. Azure AD B2C limita il numero di criteri personalizzati che è possibile distribuire, che potrebbero limitare il numero di provider di identità specifici del tenant con cui è possibile eseguire la federazione.

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

Single Sign-On

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 visitano un'applicazione, l'applicazione li indirizza a un IdP. Se il provider di identità vede che ha 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 usare una singola identità in più applicazioni.

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

Valutazione dei rischi di accesso

Le piattaforme di gestione delle identità moderne supportano una valutazione dei rischi durante il processo di accesso. Ad esempio, se un utente accede da una posizione o 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.

Valutare 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, 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 del servizio.

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

Se il provider di identità include queste funzionalità, è consigliabile usare le funzionalità di valutazione dei rischi di accesso native del provider di identità. Queste funzionalità possono essere complesse e soggette a errori da implementare manualmente.

In alternativa, se si esegue la federazione con i provider di identità dei tenant, è possibile applicare i propri criteri di mitigazione degli accessi a rischio e controllare i criteri e i controlli da applicare. Tuttavia, è importante evitare inavvertitamente l'aggiunta di 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. Assicurarsi di comprendere in che modo la federazione interagisce con ognuno dei provider di identità dei tenant e i criteri applicati.

Rappresentazione

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

In generale, la rappresentazione è pericolosa e può essere difficile implementare e controllare. Tuttavia, in alcuni scenari, la rappresentazione è un requisito. Ad esempio, se si usa software come servizio (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 la rappresentazione, valutare come controllarne l'uso. Assicurarsi che i log includano sia l'utente effettivo che ha eseguito l'azione sia l'identificatore dell'utente rappresentato.

Alcune piattaforme di identità supportano la rappresentazione, come funzionalità predefinita o usando codice personalizzato. Ad esempio, in Azure AD B2C è 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 di determinazione delle operazioni consentite a un utente.

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

  • Nel provider di identità. Ad esempio, se si usa Microsoft Entra ID come provider di identità, è possibile usare funzionalità come ruoli e gruppi dell'app per archiviare le informazioni di autorizzazione. L'applicazione può quindi usare le attestazioni di token associate per applicare le regole di autorizzazione.
  • Nell'applicazione. È possibile creare una logica di autorizzazione personalizzata e quindi 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 l'autorizzazione a livello di ruolo o a livello di risorsa.

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

Per altre informazioni, vedere Ruoli applicazione.

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

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

Un approccio comune consiste nell'incorporare un'attestazione di identificatore di tenant in un token nel sistema di identità. Questo approccio consente 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, è 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 più tenant, 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, il provider di identità può includere l'attestazione dell'identificatore del tenant e il ruolo corretti per tale tenant, all'interno del token che emette. È anche necessario considerare come gli utenti possono passare da un tenant all'altro, che richiede l'emissione di un nuovo token.

Autorizzazione basata su applicazione

Un approccio alternativo consiste nel rendere il sistema di 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 applicazione può quindi verificare se l'utente specificato deve poter accedere ai dati per un tenant specifico, in base alla ricerca dell'elenco.

Usare Microsoft Entra ID o Azure AD B2C

Microsoft fornisce Microsoft Entra ID e Azure AD B2C, che sono piattaforme di gestione delle identità che è possibile usare all'interno della propria soluzione multi-tenant.

Molte soluzioni multi-tenant sono software as a service (SaaS). La scelta di usare Microsoft Entra ID o Azure AD B2C 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 l'ID Microsoft Entra per i servizi come Office 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. È anche 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 l'ID Entra Microsoft o se sono singoli utenti anziché organizzazioni, è consigliabile usare Azure AD B2C. Azure AD B2C offre un set di funzionalità per controllare la modalità di iscrizione e accesso degli utenti. Ad esempio, è possibile limitare l'accesso alla soluzione solo agli utenti già invitati oppure consentire l'iscrizione self-service. Usare criteri personalizzati in Azure AD B2C per controllare completamente il modo in cui gli utenti interagiscono con Identity Platform. È possibile usare personalizzazioni personalizzate ed è possibile federate Azure AD B2C con il proprio tenant di Microsoft Entra, per consentire al personale di accedere. Azure AD B2C abilita anche la federazione con altri provider di identità.
  • Alcune soluzioni multi-tenant sono destinate a entrambe le situazioni elencate in precedenza. Alcuni tenant potrebbero avere tenant Microsoft Entra e altri potrebbero non essere disponibili. È anche possibile usare Azure AD B2C per questo scenario e usare criteri personalizzati per consentire l'accesso utente dalla directory Microsoft Entra di un tenant. Tuttavia, se si usano criteri personalizzati per stabilire la federazione tra i tenant, assicurarsi di considerare i limiti per il numero di criteri personalizzati che possono essere usati da una singola directory di Azure AD B2C.

Per altre informazioni, vedere Considerazioni sull'uso di Azure Active Directory B2C in un'architettura multi-tenant.

Antipattern da evitare

Compilazione o esecuzione del proprio sistema di identità

La creazione di una piattaforma di gestione delle identità moderna è complessa. Esistono diversi protocolli e standard da supportare ed è facile implementare erroneamente un protocollo ed esporre una vulnerabilità di sicurezza. Gli standard e i protocolli cambiano ed è anche necessario aggiornare continuamente il sistema di identità per attenuare gli attacchi e supportare le funzionalità di sicurezza recenti. È anche importante assicurarsi che un sistema di identità sia resiliente, perché 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 una parte necessaria dell'implementazione di un servizio multi-tenant. È preferibile usare invece un sistema di identità specializzato che viene costruito, gestito e protetto da esperti.

Quando si esegue il proprio sistema di identità, è necessario archiviare 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 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 è anche responsabili della generazione e della distribuzione di codici OTP (MFA o password monouso). Questi requisiti indicano quindi 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 e così via.

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

Mancata considerazione dei requisiti dei tenant

I tenant spesso hanno opinioni forti sul modo in cui l'identità deve essere gestita 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 e per evitare di gestire più set di credenziali. Altri tenant potrebbero richiedere l'autenticazione a più fattori o altre forme di protezione per i processi di accesso. Se non sono stati progettati per questi requisiti, può 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 delle identità. Vedere Considerazioni sull'architettura per l'identità in una soluzione multi-tenant per comprendere alcuni requisiti specifici che spesso emergono.

Aumento di utenti e tenant

È importante considerare chiaramente come la soluzione definisce un utente e un tenant. In molte situazioni, la relazione può essere complessa. Ad esempio, un tenant può contenere più utenti e un singolo utente potrebbe aggiungere più tenant.

Assicurarsi di avere un processo chiaro per tenere traccia del contesto del tenant, all'interno dell'applicazione e delle richieste. In alcune situazioni, questo processo potrebbe 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 si usa 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 è applicabile a qualsiasi modello di tenancy, perché un'identità utente ha sempre un contesto tenant all'interno di una soluzione multi-tenant. È anche consigliabile tenere traccia del contesto del tenant quando si distribuiscono stamp indipendenti per un singolo tenant, che supporta in futuro la codebase per altre forme di multi-tenancy.

Aumento del ruolo e dell'autorizzazione delle risorse

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

Non è possibile scrivere log di controllo

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

Collaboratori

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

Autori principali:

Altri contributori:

Passaggi successivi

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