Gestione delle identità e degli accessi per carichi di lavoro SaaS in Azure
L'identità dell'applicazione è un'area critica per i carichi di lavoro SaaS perché funge da prima linea di difesa per la protezione dei dati. È spesso trascurato fino a tardi in un progetto, ma molte decisioni su altri elementi dell'applicazione dipendono da una solida strategia di identità. Non sottovalutare l'importanza dell'identità per proteggere i dati dei clienti.
Nel contesto dei carichi di lavoro SaaS, esistono due tipi distinti di identità.
L'identità dell'applicazione, nota anche come gestione delle identità dei clienti e degli accessi (CIAM), consente agli utenti finali di autenticare e usare l'applicazione SaaS. Esistono due metodi principali per l'accesso degli utenti a un provider di identità dell'applicazione:
Identità federate. Gli utenti accedono con credenziali esistenti gestite da un altro provider di identità. Tale provider potrebbe essere un provider di identità di social networking, ad esempio Google, Facebook o LinkedIn, o un provider di identità aziendale usato dai clienti, ad esempio Microsoft Entra o Okta. La manutenzione dell'account dell'utente è responsabilità del provider di identità federato.
Identità locali. Gli utenti creano un account solo per l'applicazione. L'account è protetto da nome utente e password, passkey o altri metodi di autenticazione. La manutenzione dell'account dell'utente è responsabilità dell'utente.
L'identità aziendale è la soluzione di gestione delle identità usata per autenticare utenti e carichi di lavoro interni agli strumenti di produttività aziendali, agli strumenti o ai servizi interni e ai servizi di Azure. Si usa una soluzione di gestione delle identità aziendale per gli utenti interni e i carichi di lavoro per autenticarli agli strumenti di produttività aziendali, agli strumenti o ai servizi interni e ai servizi di Azure.
Fare riferimento a SE:05 Identity and access management (Se:05 Identity and Access Management).
Le identità dell'applicazione e dell'organizzazione servono scopi diversi e possono usare provider di identità diversi. Questo articolo è incentrato sulle considerazioni di progettazione per l'identità dell'applicazione, anche se è probabile che entrambi i tipi siano presenti nell'ambiente del carico di lavoro SaaS.
La gestione delle identità implica due problemi correlati: autenticazione (verifica dell'identità di un utente) e autorizzazione (concessione di autorizzazioni in base all'identità). Le prime tre sezioni di questo articolo sono incentrate sull'autenticazione per SaaS. La sezione finale illustra le considerazioni sull'autorizzazione per i provider SaaS.
Identità in un'applicazione multi-tenant
Mantenere separati i dati del tenant in un'applicazione multi-tenant è fondamentale. Tale segmentazione è basata sulla scelta dell'autenticazione e dell'autorizzazione utente efficaci. Inoltre, la scelta del modello di tenancy influisce significativamente sulle decisioni relative al provider di identità. Assegnare priorità all'identità come perimetro primario.
Per la segmentazione, fare riferimento a SE:04 Recommendations .
Considerazioni relative alla progettazione
Informazioni sui modelli di tenancy e distribuzione per l'applicazione. Potrebbero esserci sfumature che influenzano la strategia di identità. Ad esempio, è un errore che il modello Stamp di distribuzione richiede un provider di identità in ogni timbro. Per la maggior parte dei provider di identità, è spesso possibile usare un modello di isolamento alternativo.
Quando si sceglie il provider di identità per la multi-tenancy, valutare l'impatto degli errori. Le configurazioni errate possono potenzialmente arrestare l'intera applicazione per tutti i tenant. Valutare i costi generali rispetto al rischio del potenziale raggio di impatto.
Se si distribuisce la soluzione nell'ambiente Azure di un cliente e la si gestisce per suo conto, potrebbe essere necessario integrarsi con il provider di identità aziendale. Avere una chiara comprensione di questi aspetti:
- I tipi di utenti e le relative esigenze di accesso quando interagiscono con i tenant dell'applicazione. Ad esempio, l'utente A potrebbe dover accedere solo al tenant 1, ma l'utente B potrebbe dover accedere sia al tenant 1 che al tenant 2.
- Conformità alle normative di residenza dei dati, se applicabili al provider di identità. In alcuni casi, i dati archiviati da un provider di identità potrebbero essere soggetti alle normative. Molti provider di identità forniscono indicazioni e funzionalità specifiche per questo scenario. Valutare se questo scenario è rilevante per l'utente ed eseguire i passaggi necessari per garantire la conformità.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Seguire le procedure consigliate e le linee guida per il partizionamento della soluzione per più tenant. | L'isolamento del tenant consente di raggiungere gli obiettivi di sicurezza e conformità. |
| Evitare di avere più account per lo stesso utente. Un utente deve avere un singolo account con un set di credenziali, anche se ha bisogno di accedere a più tenant. Concedere l'accesso a ogni tenant in base alle esigenze anziché creare più account per lo stesso utente. | La creazione di più account per lo stesso utente aumenta i rischi per la sicurezza e può confondere gli utenti che devono ricordare più nomi utente e password per lo stesso software. |
| Quando si considera la residenza dei dati, pianificare come archiviare i dati utente in posizioni separate. Se si distribuisce un timbro di distribuzione separato per gli utenti in altre aree geografiche, potrebbe essere necessario anche provider di identità separati. Assicurarsi di avere un modo per identificare la posizione in cui vengono archiviati i dati degli utenti, in modo da poterli indirizzare all'area corretta per l'accesso, se necessario. |
Sarà possibile supportare i requisiti di conformità e migliorare l'esperienza utente instradando gli utenti all'esperienza di accesso appropriata per la propria posizione. |
Selezione del provider di identità
Ogni provider di identità offre funzionalità, limitazioni, modelli di determinazione dei prezzi e modelli di implementazione univoci. Microsoft Entra e Okta sono opzioni comuni di identità come servizio (IDaaS). Esistono anche altri provider open source, ad esempio Keycloak e Authentik.
Considerazioni relative alla progettazione
Documentare i requisiti di identità. Per iniziare, elencare le funzionalità necessarie per l'applicazione e che saranno necessarie in futuro. Le funzionalità tipiche da considerare includono:
-
- Supporto del provider di identità federato per l'integrazione con le soluzioni di gestione delle identità dei clienti. Questa funzionalità consente di evitare di creare nuove identità.
- Flusso di accesso/iscrizione personalizzabile per modificare l'aspetto per mantenere la personalizzazione. Questa funzionalità offre anche la possibilità di inserire la logica di business personalizzata nel processo di accesso/iscrizione.
- Separazione dei dati del tenant in silo distinti per mantenere l'isolamento del tenant.
- Controllare il supporto per conservare o esportare i log di accesso per la gestione della sicurezza.
Importante
Prendere in considerazione la crescita pianificata degli utenti quando si valuta il costo di una soluzione di gestione delle identità. Una soluzione potrebbe non rimanere conveniente o scalabile a lungo termine, ma potrebbe essere utile per il momento. Disporre di un piano di migrazione che è possibile usare in caso di necessità.
Ad esempio, una soluzione potrebbe essere conveniente per 500 utenti, ma non sostenibile per 5 milioni. Se richiede una configurazione minima ed è facile da migrare, può comunque essere la scelta giusta fino a quando il ridimensionamento dei costi non giustifica il passaggio a una soluzione diversa.
Eseguire ricerche approfondite sulle funzionalità del provider di identità. Assicurarsi che la soluzione di identità corrisponda all'elenco delle funzionalità necessarie. Anche se attualmente non sono necessari scenari complessi come l'identità federata, prendere in considerazione le esigenze future. Per le soluzioni SaaS business-to-business (B2B), l'identità federata sarà probabilmente necessaria.
Fattore di sovraccarico di gestione. Diversi provider di identità richiedono diversi livelli di overhead di gestione. Le soluzioni IDaaS note hanno in genere meno sovraccarico perché gestiscono l'hosting, la manutenzione e la sicurezza. Tuttavia, il sovraccarico aggiuntivo di una soluzione open source potrebbe essere utile se la soluzione è più adatta alle esigenze specifiche.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Non creare una soluzione di gestione delle identità personalizzata. L'identità è un'area altamente specializzata e la creazione di una soluzione di gestione delle identità è complessa e costosa. È difficile creare una soluzione di identità sicura e affidabile. | Si eviterà l'antipattern per creare un provider personalizzato e migliorare la sicurezza, l'affidabilità e l'efficienza operativa della soluzione. |
| Creare una matrice di funzionalità delle funzionalità offerte dai provider di identità ed eseguirne il mapping in base ai requisiti di identità. | Si garantisce la possibilità di evolversi senza essere vincolati da un set limitato di funzionalità di identità. |
| Preferisce le opzioni IDaaS rispetto alle soluzioni open source. L'hosting di una soluzione open source comporta un notevole sovraccarico operativo e rischi per la sicurezza. Tuttavia, è possibile scegliere questa opzione per soddisfare requisiti specifici per la conformità, la residenza dei dati o l'affidabilità che un provider non può soddisfare. Per altre informazioni, vedere Provider di identità IDaaS. |
L'uso di un provider di identità IDaaS consente di evitare complessità non necessarie e di concentrare le proprie attività sul core business. |
Identità federativa
L'identità federata, nota anche come Single Sign-On (SSO), consente agli utenti di accedere con le credenziali già usate altrove. È possibile abilitare l'identità federata stabilendo una relazione di trust tra il provider di identità dell'applicazione e il provider di identità esistente del cliente. L'identità federata è un requisito comune per le soluzioni SaaS, in particolare in B2B, perché i clienti preferiscono che i dipendenti usino le credenziali aziendali. Offre diversi vantaggi per le soluzioni B2B, ad esempio la gestione centralizzata delle identità e la gestione automatica del ciclo di vita. Nei prodotti SaaS B2C l'integrazione con i provider di identità social è comune per consentire agli utenti di accedere con credenziali esistenti.
Compromesso: complessità ed efficienza operativa. Usando i provider di identità federati, è possibile scaricare la complessità della gestione delle identità degli utenti. Tuttavia, si assume il costo dell'integrazione con un altro provider di identità. Decidere dove concentrare le attività operative.
Sebbene l'implementazione dell'identità federata sia inizialmente semplice, diventa più complessa man mano che aumenta il numero di provider di identità supportati. Un'attenta pianificazione è essenziale, soprattutto se ogni cliente usa un provider di identità univoco. Anche se usano lo stesso provider di identità, le relazioni di trust univoche sono spesso necessarie per ogni cliente a causa di dettagli di configurazione specifici.
Questa immagine mostra la relazione tra l'applicazione, il provider di identità dell'applicazione e i provider di identità downstream che è possibile scegliere di implementare usando la federazione delle identità.
Considerazioni relative alla progettazione
Stimare i tipi e il numero di provider di identità che è necessario supportare. Potrebbe essere necessario un numero statico di provider di identità di social networking oppure potrebbe essere necessario un provider di identità federato univoco per ogni cliente. È necessario sapere se i clienti useranno OpenID Connect (OIDC), Security Assertion Markup Language (SAML) o entrambi per l'integrazione.
Eseguire il mapping dell'esperienza di accesso. Visualizzare il flusso utente del processo di iscrizione e accesso. Prendere nota di eventuali requisiti speciali che potrebbero modificare la progettazione del flusso utente. Ad esempio:
Personalizzazione. Etichettatura bianca o domini di accesso personalizzati per cliente.
Informazioni personalizzate. Raccolta di informazioni utente aggiuntive durante l'iscrizione o l'accesso, ad esempio la selezione del tenant per gli utenti con accesso a più tenant.
Selezione del provider di identità. Se si usa un singolo provider di identità dell'applicazione con molti provider di identità federati attendibili, decidere come selezionare un provider. Questa selezione può essere eseguita manualmente tramite un pulsante o automaticamente in base alle informazioni dell'utente note. Man mano che aumenta il numero di provider, la selezione automatica diventa più pratica. Questa funzionalità è nota come Individuazione dell'area di autenticazione principale.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Scegliere un provider di identità che possa essere ridimensionato per soddisfare il numero di provider di identità federati necessari. Tenere presente i limiti rigidi del provider, che non possono essere superati. |
Si garantisce che la soluzione di gestione delle identità possa essere ridimensionata man mano che si aumentano. |
| Pianificare l'onboarding di ogni provider di identità federato e automatizzare il processo il più possibile. Questo impegno collaborativo tra l'organizzazione e i clienti prevede lo scambio di informazioni per stabilire una relazione di trust, in genere tramite protocolli OIDC o SAML. |
L'integrazione delle identità può richiedere tempo e impegno sia per l'utente che per i clienti. Pianificando il processo, si migliorerà l'efficienza operativa. |
| Riflettere la complessità e il costo dell'identità federata nei prezzi e nel modello aziendale. Consentire ai clienti di usare il proprio provider di identità aumenta la complessità operativa e i costi a causa del sovraccarico della gestione di più relazioni di trust di identità federate. È comune nelle soluzioni SaaS per le aziende pagare per un livello superiore che consente l'accesso federato. |
La federazione con il provider di identità di un cliente può essere un costo nascosto nelle soluzioni SaaS. Pianificandolo, si evitano costi imprevisti durante l'implementazione. |
| Pianificare la modalità di selezione del provider di identità di un utente durante il flusso di accesso. Prendere in considerazione l'uso dell'individuazione dell'area di autenticazione principale. Microsoft Entra ID fornisce l'individuazione dell'area di autenticazione principale predefinita. |
Sarà possibile semplificare l'esperienza del cliente e assicurarsi che gli utenti vengano indirizzati al processo di accesso corretto. |
Autorizzazione
L'autorizzazione utente è fondamentale per le applicazioni SaaS, che spesso archivia i dati per più tenant. Definire chiaramente il modo in cui gli utenti saranno autorizzati ad accedere solo ai propri dati senza accedere inavvertitamente ai dati di altri tenant. Fornire inoltre un'autorizzazione granulare all'interno di un tenant, consentendo agli utenti di leggere o accedere a determinate informazioni limitando gli aggiornamenti o l'accesso ad altri dati.
Considerazioni relative alla progettazione
Scegliere il modello di autorizzazione appropriato per il caso d'uso. Esistono due tipi principali:
- Role-based authorization. Agli utenti vengono assegnati ruoli o gruppi e funzionalità specifiche sono limitate a determinati ruoli. Ad esempio, gli amministratori possono eseguire qualsiasi azione, ma gli utenti di altri ruoli dispongono di autorizzazioni limitate.
- Autorizzazione basata sulle risorse. Ogni risorsa ha un proprio set di autorizzazioni. Un utente potrebbe essere un amministratore per una risorsa, ma non avere accesso a un altro.
Decidere dove archiviare i dati di autorizzazione. I dati di autorizzazione per l'applicazione possono essere archiviati in:
- Provider di identità. Sfruttare i gruppi o i ruoli predefiniti, visualizzando le autorizzazioni come attestazioni nel token rilasciato all'applicazione. L'applicazione può quindi applicare le regole di autorizzazione usando queste attestazioni token.
- Applicazione. Sviluppare una logica di autorizzazione personalizzata e archiviare le autorizzazioni utente in un database o in un sistema simile, consentendo controlli di autorizzazione granulari basati su ruoli o a livello di risorsa.
Compromesso: complessità, flessibilità e sicurezza. L'archiviazione dei dati di autorizzazione in un provider di identità e la visualizzazione tramite attestazioni di token è in genere più semplice rispetto alla gestione del proprio sistema di autorizzazione. Tuttavia, l'autorizzazione basata su attestazioni limita la flessibilità e è necessario accettare che le attestazioni vengano aggiornate solo quando viene riemesso un token, che può causare un ritardo nell'applicazione delle autorizzazioni modificate.Valutare l'impatto della gestione delegata. Nella maggior parte delle applicazioni SaaS, in particolare nelle applicazioni B2B, la gestione dei ruoli e delle autorizzazioni viene delegata ai clienti. Senza questa funzionalità, è possibile aumentare il sovraccarico di gestione se i clienti modificano spesso le autorizzazioni degli utenti.
Valutare l'accesso multi-tenant. In alcuni sistemi, un singolo utente potrebbe dover accedere ai dati da più tenant. Ad esempio, i consulenti potrebbero dover accedere ai dati da più tenant. Pianificare il modo in cui i clienti concedono l'accesso a questi utenti e il modo in cui il flusso di accesso supporterà la selezione e il passaggio tra i tenant.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Impedire agli utenti di accedere ai dati attraverso i limiti del tenant, a meno che tale accesso non sia consentito in modo esplicito. | L'accesso non autorizzato ai dati di un altro tenant, anche l'accesso accidentale, può essere considerato un evento imprevisto di sicurezza importante ed eroso la fiducia dei clienti nella piattaforma. Il blocco dell'accesso non necessario consente di evitare queste situazioni. |
| Se i dati sono statici e cambiano raramente, archiviarlo nel provider di identità. Se sono necessarie modifiche frequenti mentre l'utente usa il software, archiviare i dati di autorizzazione nell'applicazione. | La selezione dell'archivio dati migliore per i dati di autorizzazione migliorerà l'efficienza operativa e consentirà di soddisfare le esigenze di scalabilità. |
| Se si delega la gestione delle autorizzazioni ai clienti, fornire un metodo chiaro per gestire le autorizzazioni. Ad esempio, creare un portale Web accessibile solo agli amministratori tenant per modificare le autorizzazioni utente. | Si fornirà un maggiore controllo ai clienti ed evitare carichi operativi non necessari per il team di supporto. |
Risorse aggiuntive
La multi-tenancy è una metodologia aziendale di base per la progettazione di carichi di lavoro SaaS. Questi articoli forniscono altre informazioni sulla gestione delle identità e degli accessi:
- Considerazioni sull'architettura per l'identità nelle soluzioni multi-tenant
- Approcci architetturali per l'identità nelle soluzioni multi-tenant
Passaggio successivo
Informazioni sulla scelta del modello di hosting di calcolo, sugli aspetti operativi e su come ottimizzare le opzioni tecnologiche per soddisfare i contratti di servizio e gli obiettivi.