Questo documento presenta architetture tipiche che puoi utilizzare come riferimento per la gestione delle identità aziendali. I due principi fondamentali della gestione dell'identità aziendale sono i seguenti:
Un'origine attendibile per le identità, ovvero l'unico sistema che utilizzi per creare, gestire ed eliminare le identità dei tuoi dipendenti. Le identità gestite nel sistema di origine autorevole potrebbero essere propagate ad altri sistemi.
Un provider di identità (IdP) centrale che è l'unico sistema per l'autenticazione e che fornisce un'esperienza di Single Sign-On per i tuoi dipendenti che si estende alle applicazioni.
Quando utilizzi Google Cloud o altri servizi Google, devi decidere quale sistema utilizzare come provider di identità e quale sistema utilizzare come origine attendibile.
Utilizza Google come IdP
Utilizzando Cloud Identity Premium o Google Workspace, puoi impostare Google come IdP principale. Google fornisce un'ampia selezione di integrazioni pronte all'uso per le applicazioni di terze parti più diffuse e puoi utilizzare protocolli standard come SAML, OAuth e OpenID Connect per integrare le tue applicazioni personalizzate.
Google come IdP e origine autorevole
Puoi utilizzare Cloud Identity Premium o Google Workspace sia come IdP sia come origine attendibile, come mostrato nel seguente diagramma.
- Utilizzi Cloud Identity Premium o Google Workspace per gestire utenti e gruppi.
- Tutti i servizi Google utilizzano Cloud Identity Premium o Google Workspace come IdP.
- Configuri le applicazioni aziendali e altri servizi SaaS in modo che utilizzino Google come IdP.
Esperienza utente
In questa configurazione, l'esperienza utente di accesso per un dipendente è la seguente:
- Quando richiede una risorsa protetta o l'accesso a un'applicazione aziendale, il dipendente viene reindirizzato alla schermata Accedi con Google, che richiede l'indirizzo email e la password.
- Se la verifica in due passaggi è attiva, al dipendente viene chiesto di fornire un secondo fattore, ad esempio una chiave USB o un codice.
- Una volta autenticato, il dipendente viene reindirizzato alla risorsa protetta.
Vantaggi
L'utilizzo di Google come IdP e origine attendibile offre i seguenti vantaggi:
- Puoi sfruttare appieno le funzionalità di autenticazione a più fattori e di gestione dei dispositivi mobili di Google.
- Non hai bisogno di un IdP aggiuntivo, il che potrebbe farti risparmiare denaro.
Quando utilizzare questa architettura
Prendi in considerazione l'utilizzo di Google come IdP e origine attendibile nei seguenti scenari:
- Utilizzi già Google Workspace come soluzione di collaborazione e produttività.
- Non esiste un'infrastruttura on-premise o un IdP con cui devi eseguire l'integrazione o che vuoi mantenere separato da tutte le tue risorse su Google (in Google Cloud, in Google Ads e così via).
- Non è necessaria l'integrazione con un sistema di informazioni sulle risorse umane (HRIS) per gestire le identità.
Google come IdP con un HRIS come fonte attendibile
Se utilizzi un sistema informatico per le risorse umane (HRIS) per gestire il processo di onboarding e offboarding dei tuoi dipendenti, puoi comunque utilizzare Google come IdP. Cloud Identity e Google Workspace forniscono API che consentono ai sistemi HRIS e ad altri sistemi di assumere il controllo della gestione di utenti e gruppi, come mostrato nel diagramma seguente.
- Utilizzi il tuo HRIS esistente per gestire gli utenti e, facoltativamente, i gruppi. L'HRIS rimane la Single Source Of Truth per la gestione delle identità ed esegue automaticamente il provisioning degli utenti per Cloud Identity o Google Workspace.
- Tutti i servizi Google utilizzano Cloud Identity Premium o Google Workspace come IdP.
- Configuri le applicazioni aziendali e altri servizi SaaS in modo che utilizzino Google come IdP.
Esperienza utente
Per un dipendente, l'esperienza utente di accesso equivale a utilizzare Google come IdP e origine attendibile.
Vantaggi
L'utilizzo di Google come IdP e origine attendibile offre i seguenti vantaggi:
- Puoi ridurre al minimo l'overhead amministrativo riutilizzando i flussi di lavoro HRIS esistenti.
- Puoi sfruttare appieno le funzionalità di autenticazione a più fattori e di gestione dei dispositivi mobili di Google.
- Non hai bisogno di un IdP aggiuntivo, il che potrebbe farti risparmiare denaro.
Quando utilizzare questa architettura
Prendi in considerazione l'utilizzo di Google come IdP con un HRIS come origine attendibile nei seguenti scenari:
- Hai un sistema HRIS o un altro sistema esistente che funge da fonte attendibile per le identità.
- Utilizzi già Google Workspace come soluzione di collaborazione e produttività.
- Non esiste un'infrastruttura on-premise o un IdP con cui devi eseguire l'integrazione o che vuoi mantenere separato dal tuo ambiente Google.
Utilizza un IdP esterno
Se la tua organizzazione utilizza già un IdP come Active Directory, Microsoft Entra ID (precedentemente Azure AD), ForgeRock, Okta o Ping Identity, puoi integrare Google Cloud con questo IdP esterno utilizzando la federazione.
Federando un account Cloud Identity o Google Workspace con un IdP esterno, puoi consentire ai dipendenti di utilizzare l'identità e le credenziali esistenti per accedere ai servizi Google come Google Cloud, Google Marketing Platform e Google Ads.
IDaaS esterno come IdP e origine autorevole
Se utilizzi un provider di Identity as a Service (IDaaS) come ForgeRock, Okta o Ping Identity, puoi configurare la federazione come illustrato nel seguente diagramma.
- Cloud Identity o Google Workspace utilizza l'IDaaS come IdP per il Single Sign-On.
- L'IDaaS esegue automaticamente il provisioning di utenti e gruppi per Cloud Identity o Google Workspace.
- Le applicazioni aziendali esistenti e altri servizi SaaS possono continuare a utilizzare il tuo IDaaS come IdP.
Per scoprire di più sulla federazione di Cloud Identity o Google Workspace con Okta, consulta Provisioning degli utenti e Single Sign-On di Okta.
Esperienza utente
Per un dipendente, l'esperienza utente di accesso è la seguente:
- Quando richiede una risorsa protetta, il dipendente viene reindirizzato alla schermata Accedi con Google, che gli chiede di inserire il proprio indirizzo email.
- Accedi con Google ti reindirizza alla pagina di accesso del tuo IDaaS.
- Esegui l'autenticazione con il tuo IDaaS. A seconda dell'IDaaS, potrebbe essere necessario fornire un secondo fattore, ad esempio un codice.
- Dopo l'autenticazione, viene eseguito il reindirizzamento alla risorsa protetta.
Vantaggi
L'utilizzo di un IDaaS esterno come IdP e origine attendibile presenta i seguenti vantaggi:
- Attivi un'esperienza di Single Sign-On per i tuoi dipendenti che si estende ai servizi Google e ad altre applicazioni integrate con il tuo IDaaS.
- Se hai configurato l'IDaaS in modo da richiedere l'autenticazione a più fattori, questa configurazione viene applicata automaticamente a Google Cloud.
- Non è necessario sincronizzare le password o altre credenziali con Google.
- Puoi utilizzare la versione senza costi di Cloud Identity.
Quando utilizzare questa architettura
Prendi in considerazione l'utilizzo di un IDaaS esterno come IdP e origine attendibile nei seguenti scenari:
- Utilizzi già un provider IDaaS come ForgeRock, Okta o Ping Identity come IdP.
Best practice
Consulta le nostre best practice per la federazione di Google Cloud con un provider di identità esterno.
Active Directory come IdP e origine attendibile
Se utilizzi Active Directory come fonte di riferimento per la gestione delle identità, puoi configurare la federazione come illustrato nel seguente diagramma.
- Utilizzi Google Cloud Directory Sync (GCDS) per eseguire automaticamente il provisioning di utenti e gruppi da Active Directory per Cloud Identity o Google Workspace. Google Cloud Directory Sync è uno strumento senza costi fornito da Google che implementa il processo di sincronizzazione e può essere eseguito su Google Cloud o nel tuo ambiente on-premise. La sincronizzazione è unidirezionale, quindi Active Directory rimane la fonte di riferimento.
- Cloud Identity o Google Workspace utilizza Active Directory Federation Services (AD FS) per il Single Sign-On.
- Le applicazioni aziendali esistenti e altri servizi SaaS possono continuare a utilizzare AD FS come IdP.
Per una variante di questo pattern, puoi anche utilizzare Active Directory Lightweight Directory Services (AD LDS) o un altro servizio di directory LDAP con AD FS o un altro IdP conforme a SAML.
Per saperne di più su questo approccio, consulta Federazione di Google Cloud con Active Directory.
Esperienza utente
- Quando richiede la risorsa protetta, il dipendente viene reindirizzato alla schermata di accesso di Google, che gli chiede di inserire il suo indirizzo email.
- Accedi con Google reindirizza il dipendente alla pagina di accesso di AD FS.
- A seconda della configurazione di AD FS, il dipendente potrebbe visualizzare una schermata di accesso che richiede il nome utente e la password di Active Directory. In alternativa, AD FS potrebbe tentare di far accedere automaticamente il dipendente in base ai suoi dati di accesso di Windows.
- Dopo che AD FS ha autenticato il dipendente, quest'ultimo viene reindirizzato alla risorsa protetta.
Vantaggi
L'utilizzo di Active Directory come IdP e origine attendibile offre i seguenti vantaggi:
- Attivi un'esperienza di Single Sign-On per i tuoi dipendenti che si estende ai servizi Google e al tuo ambiente on-premise.
- Se hai configurato AD FS in modo da richiedere l'autenticazione a più fattori, questa configurazione viene applicata automaticamente a Google Cloud.
- Non è necessario sincronizzare le password o altre credenziali con Google.
- Puoi utilizzare la versione senza costi di Cloud Identity.
- Poiché le API utilizzate da GCDS sono accessibili pubblicamente, non è necessario configurare la connettività ibrida tra la rete on-premise e Google Cloud.
Quando utilizzare questa architettura
Prendi in considerazione l'utilizzo di Active Directory come IdP e origine attendibile nei seguenti scenari:
- Hai un'infrastruttura Active Directory esistente.
- Vuoi offrire un'esperienza di accesso fluida agli utenti Windows.
Best practice
Prendi in esame queste best practice:
- Active Directory e Cloud Identity utilizzano una struttura logica diversa. Assicurati di comprendere le differenze e valuta quale metodo di mappatura di domini, identità e gruppi è più adatto alla tua situazione. Per saperne di più, consulta la nostra guida sulla federazione di Google Cloud con Active Directory.
- Sincronizzare i gruppi oltre agli utenti. Con questo approccio, puoi configurare IAM in modo da utilizzare le iscrizioni ai gruppi in Active Directory per controllare chi ha accesso a quali risorse inGoogle Cloud.
- Esegui il deployment ed esponi AD FS in modo che gli utenti aziendali possano accedervi, ma non esporlo più del necessario. Sebbene gli utenti aziendali debbano essere in grado di accedere ad AD FS, non è necessario che AD FS sia raggiungibile da Cloud Identity o Google Workspace o da qualsiasi applicazione di cui è stato eseguito il deployment su Google Cloud.
- Valuta la possibilità di attivare l'autenticazione IWA (Integrated Windows Authentication) in AD FS per consentire agli utenti di accedere automaticamente in base ai dati di accesso di Windows.
- Se AD FS non è disponibile, gli utenti potrebbero non essere in grado di utilizzare la consoleGoogle Cloud o qualsiasi altra risorsa che utilizza Google come IdP. Assicurati quindi che AD FS e i domain controller su cui si basa AD FS siano sottoposti a deployment e dimensionati in modo da soddisfare i tuoi obiettivi di disponibilità.
Se utilizzi Google Cloud per garantire la continuità aziendale, l'affidamento a un AD FS on-premise potrebbe compromettere l'intento di utilizzare Google Cloud come copia indipendente del tuo deployment. In questo caso, valuta la possibilità di eseguire il deployment delle repliche di tutti i sistemi pertinenti su Google Cloudin uno dei seguenti modi:
- Estendi il tuo dominio Active Directory esistente a Google Cloud ed esegui il deployment di GCDS per l'esecuzione suGoogle Cloud.
- Esegui server AD FS dedicati su Google Cloud. Questi server utilizzano i domain controller Active Directory in esecuzione suGoogle Cloud.
- Configura Cloud Identity in modo che utilizzi i server AD FS di cui è stato eseguito il deployment su Google Cloud per il Single Sign-On.
Per saperne di più, consulta le best practice per la federazione di Google Cloud con un provider di identità esterno.
Entra ID come IdP con Active Directory come origine attendibile
Se sei un cliente Microsoft 365 o Azure, potresti aver collegato la tua Active Directory on-premise a Entra ID. Se tutti gli account utente che potrebbero aver bisogno di accedere a Google Cloud sono già sincronizzati con Entra ID, puoi riutilizzare questa integrazione federando Cloud Identity con Entra ID, come mostrato nel seguente diagramma.
- Utilizzi Entra ID per eseguire automaticamente il provisioning di utenti e gruppi in Cloud Identity o Google Workspace. Entra ID stesso potrebbe essere integrato con un'istanza Active Directory on-premise.
- Cloud Identity o Google Workspace utilizzano Entra ID per il Single Sign-On.
- Le applicazioni aziendali esistenti e altri servizi SaaS possono continuare a utilizzare Entra ID come IdP.
Per informazioni più dettagliate su questo approccio, consulta Federazione di Google Cloud con Microsoft Entra ID.
Esperienza utente
- Quando richiede la risorsa protetta, il dipendente viene reindirizzato alla schermata Accedi con Google, che gli chiede di inserire il suo indirizzo email.
- Accedi con Google li reindirizza alla pagina di accesso di AD FS.
- A seconda di come Active Directory on-premise è connesso a Entra ID, Entra ID potrebbe richiedere un nome utente e una password o reindirizzare l'utente ad AD FS on-premise.
- Dopo l'autenticazione con Entra ID, il dipendente viene reindirizzato alla risorsa protetta.
Vantaggi
L'utilizzo di Entra ID come IdP con Active Directory come origine attendibile offre diversi vantaggi:
- Attivi un'esperienza di Single Sign-On per i tuoi dipendenti che si estende ai servizi Google, a Entra e al tuo ambiente on-premise.
- Se hai configurato Entra ID in modo che richieda l'autenticazione a più fattori, questa configurazione viene applicata automaticamente a Google Cloud.
- Non è necessario installare software aggiuntivo on-premise.
- Se Active Directory on-premise utilizza più domini o foreste e hai impostato una configurazione Entra ID Connect personalizzata per mappare questa struttura a un tenant Entra ID, puoi sfruttare questo lavoro di integrazione.
- Non è necessario sincronizzare le password o altre credenziali con Google.
- Puoi utilizzare la versione senza costi di Cloud Identity.
- Puoi visualizzare la console Google Cloud come riquadro nel portale di Office 365.
- Poiché le API utilizzate da Entra ID sono accessibili pubblicamente, non è necessario configurare la connettività ibrida tra Entra e Google Cloud.
Quando utilizzare questa architettura
Prendi in considerazione l'utilizzo di Entra ID come IdP con Active Directory come origine attendibile nei seguenti scenari:
- Utilizzi già Entra ID e lo hai integrato con un'infrastruttura Active Directory esistente.
- Vuoi offrire un'esperienza di accesso fluida agli utenti su Entra e Google Cloud.
Best practice
Segui queste best practice:
- Poiché Entra ID e Cloud Identity utilizzano una struttura logica diversa, assicurati di comprendere le differenze. Valuta quale metodo di mappatura di domini, identità e gruppi è più adatto alla tua situazione. Per informazioni più dettagliate, consulta Federazione di Google Cloud con Microsoft Entra ID.
- Sincronizzare i gruppi oltre agli utenti. Con questo approccio, puoi configurare IAM in modo da utilizzare le iscrizioni ai gruppi in Entra ID per controllare chi ha accesso a quali risorse inGoogle Cloud.
- Se utilizzi Google Cloud per garantire la continuità aziendale, l'affidamento a Entra ID per l'autenticazione potrebbe compromettere l'intento di utilizzare Google Cloud come copia indipendente del tuo deployment.
Per saperne di più, consulta le best practice per la federazione di Google Cloud con un provider di identità esterno.
Passaggi successivi
- Scopri di più sulla federazione con Active Directory.
- Scopri come configurare la federazione con Entra ID.
- Consulta le nostre best practice per la pianificazione di account e organizzazioni e per la federazione di Google Cloud con un provider di identità esterno.