Condividi tramite

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

Quasi tutte le soluzioni multi-tenant richiedono un sistema di gestione identità. Questo articolo descrive i componenti comuni dell'identità, tra cui l'autenticazione e l'autorizzazione, e come è possibile applicare questi componenti in una soluzione multi-tenant.

Nota

Prima di iniziare a creare un sistema di identità per una soluzione multi-tenant, vedere Considerazioni sull'architettura per l'identità in una soluzione multi-tenant.

Autenticazione

L'autenticazione è il processo che stabilisce l'identità di un utente. Quando costruisci una soluzione multi-tenant, considera i vari approcci per i diversi aspetti del processo di autenticazione.

Federazione

Potrebbe essere necessario configurare la federazione con provider di identità esterni. È possibile usare la federazione per abilitare gli scenari seguenti:

  • Accesso tramite social network, che consente agli utenti di accedere con il proprio account Microsoft Google, Facebook, GitHub o personale

  • Directory specifiche del tenant, che consentono ai tenant di federare l'applicazione con i propri IdP in modo che non debbano gestire gli account in più luoghi.

Per altre informazioni, vedere Il modello di identità federata.

Se si sceglie di supportare IdP specifici per il tenant, assicurarsi di chiarire quali servizi e protocolli la tua applicazione supporta. Ad esempio, determinare se supportare il protocollo OpenID Connect e il protocollo Security Assertion Markup Language o se limitare la federazione alle istanze di Microsoft Entra ID.

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

Valutare anche la possibilità di fornire la federazione come funzionalità applicabile solo ai clienti a un livello di prodotto superiore.

Autenticazione unica

Single Sign-On consente agli utenti di passare facilmente da un'applicazione all'altra senza dover ripetere l'autenticazione in ogni punto.

Quando gli utenti eseguono un'applicazione, l'applicazione li indirizza a un IdP. Se il provider di identità rileva una sessione esistente, rilascia un nuovo token senza richiedere agli utenti di partecipare al processo di accesso. Un modello di identità federata supporta l'accesso Single Sign-On consentendo agli utenti di usare una singola identità in più applicazioni.

In una soluzione multi-tenant è possibile abilitare un altro tipo di accesso Single Sign-On. Se gli utenti sono autorizzati ad accedere ai dati in più tenant, potrebbe essere necessario offrire un'esperienza trasparente quando gli utenti modificano il contesto da un tenant a un altro. Valutare se la soluzione deve supportare transizioni semplici tra tenant. In tal caso, valutare se il provider di identità deve riemettere i token con attestazioni specifiche del tenant. Ad esempio, quando un utente accede al portale di Azure, può passare da una directory all'altra di Microsoft Entra ID. Questa transizione attiva la riautenticazione e genera un nuovo token dall'istanza di Microsoft Entra ID 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, potrebbero avere profili di rischio e requisiti diversi rispetto ai tenant che lavorano in ambienti meno regolamentati. In alternativa, è possibile 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 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 agli IdP dei tenant, è possibile applicare i loro criteri di mitigazione degli accessi a rischio, il che consente loro di controllare le politiche di attuazione e i controlli. Ad esempio, richiedere due sfide di autenticazione a più fattori, una dall'IDP principale dell'utente e un'altra dal tuo, può rendere più difficile il processo di accesso. Assicurarsi di comprendere in che modo la federazione interagisce con gli IdP di ciascun tenant e le politiche che hanno in vigore.

Impersonificazione

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

L'imitazione è generalmente pericolosa e può essere difficile da realizzare e controllare. Tuttavia, in alcuni scenari, è necessaria la personificazione. Ad esempio, se si opera in un ambiente SaaS (Software as a Service), il personale dell'help desk potrebbe dover presupporre l'identità di un utente in modo che possa accedere come utente e risolvere un problema.

Se si implementa l'impersonificazione, considerare come controllarne l'uso. Assicurarsi che i log includano sia l'utente 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. Ad esempio, è possibile aggiungere un'attestazione personalizzata in Microsoft Entra External ID 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 tuo IdP: ad esempio, se si utilizza Microsoft Entra ID come IdP, è possibile usare funzionalità come ruoli dell'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.

  • 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 autorizzazioni a livello di ruolo o a livello di risorsa.

Nella maggior parte delle soluzioni multi-tenant, il cliente o il tenant gestisce le assegnazioni di ruolo e autorizzazioni e non il fornitore del sistema multi-tenant.

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

Determinare quali parti della soluzione devono gestire le richieste di autorizzazione. Valutare se consentire a un utente di accedere ai dati da 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, è possibile estendere il token per includere informazioni sul ruolo dell'utente 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 che l'utente seleziona il tenant attivo, il provider di identità può emettere un token che includa la rivendicazione dell'identificatore del locatario e il ruolo appropriato per quel locatario. È 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 tramite le credenziali o una relazione di federazione e i token non includono un'attestazione di identificatore del tenant. Un elenco separato o un database gestisce i record di cui agli utenti viene concesso l'accesso a ogni tenant. Il livello applicazione verifica quindi se un utente specificato è autorizzato ad accedere ai dati per un tenant specifico in base a tale elenco.

Usare l'ID Microsoft Entra o l'ID esterno

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

Molte soluzioni multi-tenant funzionano come SaaS. La scelta di usare Microsoft Entra ID o ID esterno dipende in parte dal modo in cui si definiscono i tenant o la base clienti.

Importante

Azure AD B2C supporta anche molti degli scenari descritti in questo articolo. Tuttavia, a partire dal 1° maggio 2025, non è più disponibile per l'acquisto per nuovi clienti, quindi non è consigliabile per le nuove soluzioni. Per altre informazioni, vedere Domande frequenti su Azure AD B2C.

Antipattern da evitare

Creazione o gestione del proprio sistema di identità

La creazione di una moderna piattaforma di gestione identità è una procedura complessa. Richiede il supporto per una serie di protocolli e standard e un'implementazione non corretta può introdurre vulnerabilità di sicurezza. Poiché gli standard e i protocolli cambiano, è necessario aggiornare continuamente il sistema di identità per attenuare gli attacchi e incorporare le funzionalità di sicurezza più 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. Nella maggior parte degli scenari, l'implementazione di un IdP non è direttamente vantaggiosa per l'azienda, ma è necessaria per implementare un servizio multitenant. È preferibile usare un sistema di identità specializzato che gli esperti creano, operano e proteggono.

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 insufficienti perché gli utenti malintenzionati hanno una potenza di calcolo sufficiente per compromettere queste credenziali.

Quando si esegue un sistema di identità, si è responsabili della generazione e della distribuzione di codici MFA o password monouso. È necessario un meccanismo per inviare questi codici tramite SMS o posta elettronica. Si è anche responsabili del rilevamento di attacchi mirati e di forza bruta, di limitazione dei tentativi di accesso e di gestione dei log di controllo.

Anziché creare o gestire il proprio sistema di identità, è consigliabile usare un servizio o un componente predefinito. Si considerino ad esempio piattaforme di identità gestite come Microsoft Entra ID o ID esterno. I fornitori di queste piattaforme sono responsabili del funzionamento dell'infrastruttura e in genere garantiscono il supporto per gli standard di identità e autenticazione correnti.

Trascurare di considerare i requisiti dei tuoi inquilini

I tenant hanno spesso preferenze avanzate su come gestire l'identità nelle soluzioni usate. Ad esempio, molti clienti aziendali richiedono la federazione con i propri provider di identità per abilitare l'accesso Single Sign-On ed evitare di gestire più set di credenziali. Altri tenant potrebbero richiedere l'autenticazione a più fattori o misure di sicurezza aggiuntive per il processo di accesso. Se non si considerano questi requisiti durante la progettazione, aggiungerli in un secondo momento può essere difficile.

Assicurarsi di comprendere i requisiti di identità dei tenant prima di finalizzare la progettazione del sistema di identità. Per altre informazioni sui requisiti specifici, vedere Considerazioni sull'architettura per l'identità in una soluzione multi-tenant.

Confondere utenti e inquilini

È importante valutare bene in che modo la soluzione definisce un utente e un tenant. In molti scenari la relazione può 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 degli inquilini all'interno della tua applicazione e delle richieste. In alcuni scenari, questo processo richiede di includere un identificatore del tenant in ogni token di accesso e convalidarlo in ogni richiesta. In altri casi, le informazioni di autorizzazione del tenant vengono archiviate separatamente dalle identità utente. Questo approccio richiede un sistema di autorizzazione più complesso per gestire quali utenti possono eseguire operazioni specifiche all'interno di ogni tenant.

Il rilevamento del contesto del 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. È consigliabile tenere traccia del contesto del tenant quando si distribuiscono istanze indipendenti per un singolo tenant, il che consente alla codebase di supportare in futuro altre forme di multitenancy.

Fusione dell'autorizzazione di ruoli e risorse

È importante scegliere un modello di autorizzazione adatto alla soluzione. La sicurezza basata sui ruoli è semplice da implementare, ma l'autorizzazione basata sulle risorse offre un controllo più granulare. Valutare i requisiti dei tenant e determinare se devono autorizzare alcuni utenti ad accedere solo a parti specifiche della soluzione.

Impossibile 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 in che modo viene usato il sistema. Assicurarsi di scrivere e archiviare i log di controllo all'interno del sistema di identità. Considerare se i log di controllo delle identità della soluzione devono essere resi disponibili ai tenant per esaminarli.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

Altri contributori:

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.