Condividi tramite

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

  • Articolo

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.

Nota

Consultare la sezione Considerazioni sull'architettura per l'identità in una soluzione multi-tenant per maggiori informazioni sui requisiti chiave e sulle decisioni da prendere prima di iniziare a creare un sistema di identità per 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 del tenant, ad esempio abilitando i tenant per la federazione dell'applicazione con i propri provider di identità, di conseguenza, non è necessario gestire gli account in più posizioni.

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

Se si sceglie di supportare provider di identità specifici del tenant, assicurarsi di chiarire quali servizi e protocolli devono essere supportati. 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, se si utilizza 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 e che potrebbero limitare il numero di provider di identità specifici del tenant con cui è possibile eseguire la federazione.

È inoltre 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 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 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, 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. Assicurarsi di comprendere come interagisce la federazione 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 dover usare le sue credenziali.

In generale, la rappresentazione è una procedura pericolosa e può essere difficile da implementare e controllare. Tuttavia, in alcuni scenari, la rappresentazione rappresenta 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 la rappresentazione, assicurarsi di sapere come controllarne l'uso. Assicurarsi che i log includano sia l'utente corrente che ha eseguito l'azione sia l'identificatore dell'utente rappresentato.

Alcune piattaforme di identità supportano la rappresentazione come funzionalità predefinita o usando un codice personalizzato. Per 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 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à tenant 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 nell'incorporare un'attestazione di identificatore di tenant in un token nel sistema identità. 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, il provider di identità potrà includere l'attestazione dell'identificatore del tenant e il ruolo corretti per tale tenant, all'interno del 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 applicazione può quindi verificare se l'utente specificato può 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, Microsoft Entra External ID e Azure AD B2C, che sono piattaforme di gestione identità 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, Microsoft Entra External 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 Microsoft Entra ID 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 in 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 o Azure AD B2C. Sia Microsoft Entra External ID che Azure AD B2C forniscono un set di funzionalità per controllare il modo in cui gli utenti eseguono l'iscrizione e l'accesso. Per esempio, è possibile limitare l'accesso alla soluzione solo agli utenti già invitati oppure consentire l'iscrizione self-service. Usare i criteri personalizzati in Azure AD B2C per controllare completamente in che modo gli utenti interagiscono con la piattaforma identità. È possibile usare marchi personalizzati ed è possibile federare 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 identità.
  • Alcune delle soluzioni multi-tenant sono destinate a entrambe le situazioni elencate in precedenza. Alcuni tenant potrebbero avere propri tenant Microsoft Entra, e altri potrebbero non essere disponibili. È inoltre 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 valutare i limiti per il numero di criteri personalizzati che possono essere usati da una singola directory di Azure AD B2C.

Per maggiori informazioni, consultare la sezione Considerazioni sull'uso di Azure Active Directory B2C in un'architettura multi-tenant.

Antipattern da evitare

Creazione o esecuzione 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. Ad esempio, valutare l'uso di Microsoft Entra ID o Azure AD B2C, ovvero 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.

Mancato soddisfacimento dei requisiti dei tenant

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.

Utenti e tenant confluenti

È 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 aggiungere più tenant.

Assicurarsi di disporre di un processo chiaro per tenere traccia del contesto del tenant, all'interno dell'applicazione e delle 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.

Autorizzazione ruolo e risorse confluente

È 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 da esaminare.

Collaboratori

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

Autori principali:

Altri contributori:

Passaggi successivi

Consultare la sezione Considerazioni sull'architettura per l'identità in una soluzione multi-tenant.