Questo documento presenta le architetture tipiche che puoi utilizzare come riferimento per la gestione delle identità aziendali. Ecco due principi fondamentali della gestione dell'identità aziendale:
Un'origine attendibile per le identità, ovvero l'unico sistema che utilizzi per creare, gestire ed eliminare le identità dei tuoi dipendenti. La le identità gestite nel sistema di origine autorevole potrebbero essere propagate ad altri sistemi.
Un identity provider (IdP) centrale che è l'unico sistema di autenticazione e che offre ai dipendenti un'esperienza di Single Sign-On che copre tutte le applicazioni.
Quando utilizzi Google Cloud o altri servizi Google, devi decidere quale sistema utilizzare come provider di identità e quale come fonte attendibile.
Utilizzare Google come IdP
Utilizzando Cloud Identity Premium o Google Workspace puoi impostare Google come IdP principale. Google offre un'ampia selezione di integrazioni pronte all'uso per le più diffuse applicazioni di terze parti ed è possibile utilizzare protocolli standard come SAML OAuth, e OpenID Connect per integrare le tue applicazioni personalizzate.
Google come IdP e fonte autorevole
Puoi utilizzare Cloud Identity Premium o Google Workspace come entrambi IdP e come fonte autorevole, come nel diagramma seguente.
- Utilizzi Cloud Identity Premium o Google Workspace per gestire utenti e gruppi.
- Tutti i servizi Google utilizzano Cloud Identity Premium o Google Workspace come provider di identità.
- Configura le applicazioni aziendali e altri servizi SaaS in modo da utilizzare Google come IdP.
Esperienza utente
In questa configurazione, per un dipendente, l'esperienza utente relativa all'accesso ha il seguente aspetto: questo:
- In caso di richiesta di una risorsa protetta o dell'accesso a un'azienda il dipendente viene reindirizzato alla schermata di accesso con Google, richiede l'indirizzo email e la password.
- Se Verifica in due passaggi è abilitato, al dipendente viene chiesto di fornire un secondo fattore come Chiave USB o codice.
- Quando il dipendente viene autenticato, viene reindirizzato alla risorsa protetta.
Vantaggi
L'utilizzo di Google come provider di identità e come fonte attendibile presenta 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'altra IdP, il che potrebbe farti risparmiare.
Quando utilizzare questa architettura
Prendi in considerazione l'utilizzo di Google come IdP e fonte autorevole nei seguenti scenari aggiuntivi:
- Utilizzi già Google Workspace come collaborazione soluzione di produttività.
- Non esiste un'infrastruttura on-premise o un provider di identità con cui devi integrarti o che vuoi mantenere separata da tutte le tue risorse su Google (in Google Cloud, in Google Ads e così via).
- Per gestire le identità non è necessaria l'integrazione con un sistema informativo per le risorse umane (HRIS).
Google come IdP con un sistema HR come fonte attendibile
Se utilizzi un sistema informatico delle risorse umane (HRIS) per gestire l'onboarding e offboarding per i tuoi dipendenti, puoi comunque usare Google come o provider di identità. 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 seguente diagramma.
- Utilizza il tuo sistema di gestione delle risorse umane esistente per gestire gli utenti e, facoltativamente, i gruppi. Il sistema HR rimane la singola fonte attendibile per la gestione delle identità e 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.
- Configura le applicazioni aziendali e altri servizi SaaS in modo da utilizzare Google come IdP.
Esperienza utente
Per un dipendente, l'esperienza utente di accesso è equivalente all'utilizzo di Google come IdP e come fonte autorevole.
Vantaggi
L'utilizzo di Google come IdP e fonte autorevole offre i seguenti vantaggi:
- Puoi ridurre al minimo il carico amministrativo riutilizzando i flussi di lavoro HR existentes.
- Puoi sfruttare appieno le funzionalità autenticazione a più fattori e gestione dei dispositivi mobili le funzionalità di machine learning.
- Non hai bisogno di un IdP aggiuntivo, il che potrebbe farti risparmiare.
Quando utilizzare questa architettura
Valuta la possibilità di utilizzare Google come tuo IdP con un sistema HR come fonte attendibile nei seguenti scenari:
- Disponi di un HRIS o di un altro sistema esistente che funge da una fonte autorevole per le identità.
- Utilizzi già Google Workspace come soluzione di collaborazione e produttività.
- Non è necessario gestire un'infrastruttura on-premise o un IdP integrare o mantenere separata dal tuo account Google .
Usa un IdP esterno
Se la tua organizzazione utilizza già un IdP come Active Directory, 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 provider di identità esterno, puoi consentire ai dipendenti di utilizzare le loro credenziali e la loro identità esistenti per accedere ai servizi Google come Google Cloud, Google Marketing Platform e Google Ads.
IDaaS esterno come IdP e come fonte attendibile
Se utilizzi un provider IDaaS (Identity as a Service) come ForgeRock, Okta o Ping Identity, puoi configurare la federazione come illustrato nel diagramma seguente.
- Cloud Identity o Google Workspace utilizza il tuo 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 gli altri servizi SaaS possono continuare a il tuo IDaaS come IdP.
Per scoprire di più sulla federazione di Cloud Identity o Google Workspace con Okta, vedi Provisioning degli utenti e Single Sign-On Okta.
Esperienza utente
Per un dipendente, l'esperienza utente relativa all'accesso ha il seguente aspetto:
- Quando richiede una risorsa protetta, il dipendente viene reindirizzato alla Schermata Accedi con Google, che richiede l'indirizzo email dell'utente.
- Accedi con Google ti reindirizza alla pagina di accesso del tuo IDaaS.
- Esegui l'autenticazione con il tuo IDaaS. A seconda del tuo IDaaS, potresti dover fornire un secondo fattore, ad esempio un codice.
- Una volta eseguita l'autenticazione, il sistema ti reindirizzerà nuovamente risorsa.
Vantaggi
L'utilizzo di un IDaaS esterno come provider di identità e come origine attendibile presenta i seguenti vantaggi:
- Attiva 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 il tuo IDaaS in modo da richiedere l'autenticazione a più fattori, la configurazione viene applicata automaticamente a Google Cloud.
- Non è necessario sincronizzare password o altre credenziali con Google.
- Puoi utilizzare la versione gratuita di Cloud Identity.
Quando utilizzare questa architettura
Prendi in considerazione l'utilizzo di un IDaaS esterno come IdP e fonte autorevole nel i 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 come origine attendibile
Se usi Active Directory come fonte attendibile per la gestione delle identità, puoi configurare la federazione come illustrato nel diagramma seguente.
- 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 gratuito 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 Active Directory rimane la fonte attendibile.
- Cloud Identity o Google Workspace utilizza Active Directory Federation Services (AD FS) per il Single Sign-On.
- Le applicazioni aziendali esistenti e gli 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'altra directory LDAP con AD FS o un altro IdP conforme a SAML.
Per ulteriori informazioni su questo approccio, consulta Google Cloud federato con Active Directory.
Esperienza utente
- Dopo aver richiesto la risorsa protetta, il dipendente viene reindirizzato alla schermata di accesso di Google, dove gli viene chiesto 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 al suo accesso a Windows.
- Dopo che AD FS ha autenticato il dipendente, quest'ultimo viene reindirizzato nuovamente a la risorsa protetta.
Vantaggi
L'utilizzo di Active Directory come IdP e fonte autorevole prevede quanto segue vantaggi:
- Puoi abilitare un'esperienza Single Sign-On per i dipendenti che si estende nei servizi Google e nell'ambiente on-premise.
- Se hai configurato AD FS in modo che richieda l'autenticazione a più fattori, questa configurazione viene applicata automaticamente a Google Cloud.
- Non è necessario sincronizzare password o altre credenziali con Google.
- Puoi utilizzare la versione gratuita di Cloud Identity.
- Poiché le API utilizzate da GCDS sono pubblicamente accessibili, non è necessario configurare la connettività ibrida tra la rete on-premise e Google Cloud.
Quando utilizzare questa architettura
Valuta la possibilità di utilizzare Active Directory come IdP e come origine attendibile nei seguenti scenari:
- Disponi di un'infrastruttura Active Directory.
- Vuoi offrire agli utenti Windows un'esperienza di accesso senza interruzioni.
Best practice
Prendi in considerazione queste best practice:
- Active Directory e Cloud Identity utilizzano una logica alla struttura del centro di costo. Assicurati di comprendere le differenze e valuta quale metodo di mappatura di domini, identità e gruppi è più adatto alla tua situazione. Per ulteriori informazioni, consulta le nostre guida alla federazione di Google Cloud con Active Directory.
- Sincronizzare i gruppi oltre agli utenti. Con questo approccio, puoi definire di IAM per poter utilizzare le appartenenze ai gruppi in stato Directory per controllare chi ha accesso a quali risorse in in Google Cloud.
- Esegui il deployment e l'esposizione di AD FS in modo che gli utenti aziendali possano accedervi, ma esporli più del necessario. Sebbene gli utenti aziendali debbano essere in grado di per accedere ad AD FS, non è necessario che AD FS sia raggiungibile Cloud Identity o Google Workspace oppure da qualsiasi applicazione di cui è stato eseguito il deployment in Google Cloud.
- Valuta la possibilità di abilitare Integrated Windows Authentication (IWA) in AD FS per consente agli utenti di accedere automaticamente in base all'accesso a Windows.
- Se AD FS non è più disponibile, gli utenti potrebbero non essere in grado di utilizzare Console Google Cloud o qualsiasi altra risorsa che utilizza Google come IdP. Quindi assicurati il deployment di AD FS e dei controller di dominio su cui si basa AD FS per soddisfare i tuoi obiettivi di disponibilità.
Se utilizzi Google Cloud per garantire la continuità aziendale, l'utilizzo di un AD FS on-premise potrebbe minare l'intenzione 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 Cloud in uno dei seguenti modi:
- Estendi il dominio Active Directory esistente a Google Cloud ed eseguire il deployment di GCDS in Google Cloud.
- Esegui server AD FS dedicati su Google Cloud. Questi server utilizza i controller di dominio Active Directory in esecuzione in Google Cloud.
- Configura Cloud Identity per utilizzare i server AD FS di cui è stato eseguito il deployment in Google Cloud per il Single Sign-On.
Per saperne di più, consulta Best practice per la federazione di Google Cloud con un provider di identità esterno.
Azure AD come IdP con Active Directory come origine attendibile
Se sei un cliente di Microsoft Office 365 o Azure, potresti aver collegato dalla tua Active Directory on-premise ad Azure AD. Se tutti gli account utente che potenzialmente hanno bisogno di accedere a Google Cloud sono già sincronizzati con Azure AD, puoi riutilizzare questa integrazione federando Cloud Identity con Azure AD, come mostrato nel seguente diagramma.
- Puoi usare Azure AD per eseguire automaticamente il provisioning di utenti e gruppi Cloud Identity o Google Workspace. Lo stesso Azure AD integrati con un'Active Directory on-premise.
- Cloud Identity o Google Workspace utilizzano Azure AD per il singolo l'accesso.
- Le applicazioni aziendali esistenti e altri servizi SaaS possono continuare a utilizzare Azure AD come provider di identità.
Per ulteriori informazioni su questo approccio, consulta Google Cloud federato con Azure Active Directory.
Esperienza utente
- Dopo aver richiesto la risorsa protetta, il dipendente viene reindirizzato alla schermata di accesso a Google, dove gli viene chiesto il suo indirizzo email.
- Accedi con Google li reindirizza alla pagina di accesso di AD FS.
- A seconda di come è connesso l'Active Directory on-premise Azure AD, Azure AD potrebbe richiedere un nome utente e una password, potrebbe reindirizzarli a un AD FS on-premise.
- Una volta autenticato il dipendente con Azure AD, viene reindirizzato nuovamente alla risorsa protetta.
Vantaggi
L'utilizzo di Azure AD come IdP con Active Directory come origine attendibile offre diversi vantaggi:
- Attiva un'esperienza di Single Sign-On per i tuoi dipendenti che si estende ai servizi Google, ad Azure e al tuo ambiente on-premise.
- Se hai configurato Azure AD in modo che richieda l'autenticazione a più fattori, questa configurazione viene applicata automaticamente a Google Cloud.
- Non è necessario installare software aggiuntivi on-premise.
- Se la tua Active Directory on-premise utilizza più domini o foreste e hai impostato una configurazione personalizzata di Azure AD Connect per mappare struttura a un tenant Azure AD, puoi sfruttare questa integrazione al lavoro.
- Non è necessario sincronizzare password o altre credenziali con Google.
- Puoi utilizzare la versione gratuita di Cloud Identity.
- Puoi visualizzare la console Google Cloud come riquadro nel portale di Office 365.
- Poiché le API utilizzate da Azure AD sono accessibili pubblicamente, non è necessario configurare la connettività ibrida tra Azure e Google Cloud.
Quando utilizzare questa architettura
Valuta la possibilità di utilizzare Azure AD come IdP con Active Directory come origine attendibile nei seguenti scenari:
- Utilizzi già Azure AD e lo hai integrato con un componente Infrastruttura di directory.
- Vuoi offrire un'esperienza di accesso senza problemi agli utenti su Azure e Google Cloud.
Best practice
Segui queste best practice:
- Poiché Azure AD e Cloud Identity utilizzano una logica struttura, 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 Eseguire la federazione di Google Cloud con Azure AD.
- Sincronizzare i gruppi oltre agli utenti. Con questo approccio, puoi definire di IAM per poter usare le appartenenze ai gruppi in Azure AD per controllare chi ha accesso a quali risorse in in Google Cloud.
- Se utilizzi Google Cloud per garantire la continuità aziendale, l'utilizzo di Azure AD per l'autenticazione potrebbe minare lo scopo di utilizzare Google Cloud come copia indipendente del tuo deployment.
Per saperne di più, consulta 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 Azure AD.
- Consulta le nostre best practice per la pianificazione di account e organizzazioni e per federare Google Cloud con un provider di identità esterno.