Architetture di riferimento

Last reviewed 2023-02-27 UTC

Questo documento illustra le tipiche architetture che puoi utilizzare come riferimento per la gestione delle identità aziendali. I due principi fondamentali della gestione delle identità aziendali sono i seguenti:

  • Una fonte autorevole per le identità che è l'unico sistema che utilizzi per creare, gestire ed eliminare le identità per i tuoi dipendenti. Le identità gestite nel sistema di origine ufficiale potrebbero essere propagate ad altri sistemi.

  • Un provider di identità (IdP) centrale che rappresenta l'unico sistema di autenticazione e che fornisce un'esperienza Single Sign-On per i dipendenti che include applicazioni diverse.

Quando utilizzi Google Cloud o altri servizi Google, devi decidere quale sistema utilizzare come provider di identità e quale sistema utilizzare come fonte autorevole.

Utilizzo di Google come IdP

Con Cloud Identity Premium o Google Workspace, puoi impostare Google come IdP principale. Google offre un'ampia selezione di integrazioni pronte all'uso per le applicazioni di terze parti più diffuse e ti consente di 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 sia come IdP sia come fonte autorevole, come illustrato nel seguente diagramma.

Google come IdP e fonte autorevole.

  • Per gestire utenti e gruppi puoi utilizzare Cloud Identity Premium o Google Workspace.
  • Tutti i servizi Google utilizzano Cloud Identity Premium o Google Workspace come IdP.
  • Puoi configurare le applicazioni aziendali e altri servizi SaaS in modo che utilizzino Google come IdP.

Esperienza utente

In questa configurazione, per un dipendente, l'esperienza utente di accesso si presenta come la seguente:

  1. Quando richiede una risorsa protetta o l'accesso a un'applicazione aziendale, il dipendente viene reindirizzato alla schermata di accesso con Google, che richiede il proprio indirizzo email e la password.
  2. Se la verifica in due passaggi è abilitata, al dipendente viene richiesto di fornire un secondo fattore, ad esempio una chiave o un codice USB.
  3. Una volta autenticato, il dipendente viene reindirizzato alla risorsa protetta.

Vantaggi

L'utilizzo di Google come IdP e fonte autorevole presenta i seguenti vantaggi:

Quando utilizzare questa architettura

Potresti utilizzare Google come IdP e fonte autorevole nei seguenti scenari:

  • Utilizzi già Google Workspace come soluzione per la collaborazione e la produttività.
  • Non esiste un'infrastruttura on-premise o un IdP con cui devi integrarli o che vuoi mantenerli separati da tutte le tue risorse su Google (in Google Cloud, in Google Ads e così via).
  • Non è necessaria l'integrazione con un sistema informativo delle risorse umane (HRIS) per gestire le identità.

Google come IdP e una risorsa HRIS come fonte autorevole

Se utilizzi un sistema informatico delle risorse umane (HRIS) per gestire il processo di onboarding e offboarding per i tuoi dipendenti, puoi comunque utilizzare Google come IdP. Cloud Identity e Google Workspace forniscono API che consentono a HRIS e ad altri sistemi di assumere il controllo della gestione di utenti e gruppi, come mostrato nel diagramma seguente.

Google come IdP e una risorsa HRIS come fonte autorevole.

  • Puoi utilizzare l'HRIS esistente per gestire gli utenti e, facoltativamente, i gruppi. HRIS rimane l'unica fonte attendibile per la gestione delle identità ed esegue il provisioning automatico degli utenti per Cloud Identity o Google Workspace.
  • Tutti i servizi Google utilizzano Cloud Identity Premium o Google Workspace come IdP.
  • Puoi configurare 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 all'utilizzo di Google come IdP e fonte autorevole.

Vantaggi

L'utilizzo di Google come IdP e fonte autorevole offre i seguenti vantaggi:

Quando utilizzare questa architettura

Valuta la possibilità di utilizzare Google come provider di identità con una HRIS come fonte autorevole nei seguenti scenari:

  • Disponi di un HRIS o di un altro sistema che funga da fonte attendibile per le identità.
  • Utilizzi già Google Workspace come soluzione per la collaborazione e la produttività.
  • Non esiste un'infrastruttura on-premise o un IdP con cui devi eseguire l'integrazione o che vuoi mantenere separata dalla tua proprietà Google.

Utilizzo di 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.

Se federai un account Cloud Identity o Google Workspace con un IdP esterno, puoi consentire ai dipendenti di utilizzare la propria identità e le proprie credenziali esistenti per accedere a servizi Google come Google Cloud, Google Marketing Platform e Google Ads.

IDaaS esterno come IdP e fonte autorevole

Se utilizzi un provider Identity as a Service (IDaaS) come ForgeRock, Okta o Ping Identity, puoi configurare la federazione come illustrato nel diagramma seguente.

IDaaS esterno come IdP e fonte autorevole.

  • Cloud Identity o Google Workspace utilizzano il tuo IDaaS come IdP per il Single Sign-On.
  • 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 utilizzare IDaaS come IdP.

Per saperne di più sulla federazione di Cloud Identity o Google Workspace con Okta, vedi Provisioning degli utenti Okta e Single Sign-On.

Esperienza utente

Per un dipendente, l'esperienza utente di accesso si presenta così:

  1. Quando richiede una risorsa protetta, il dipendente viene reindirizzato alla schermata di accesso con Google, che richiede l'indirizzo email.
  2. Accedi con Google ti reindirizza alla pagina di accesso del tuo IDaaS.
  3. Devi autenticarti con il tuo IDaaS. A seconda del tuo IDaaS, potrebbe richiedere un secondo fattore, come un codice.
  4. Una volta eseguita l'autenticazione, il sistema ti reindirizzerà alla risorsa protetta.

Vantaggi

L'utilizzo di un IDaaS esterno come IdP e fonte autorevole presenta i seguenti vantaggi:

  • Puoi abilitare un'esperienza Single Sign-On per i tuoi dipendenti, che si estende ai servizi Google e ad altre applicazioni integrate con IDaaS.
  • Se hai configurato il tuo IDaaS per 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

Potresti utilizzare un IDaaS esterno come IdP e fonte autorevole nei seguenti scenari:

  • Utilizzi già un provider IDaaS come ForgeRock, Okta o Ping Identity come IdP.

Best practice

Consulta le nostre best practice per federare Google Cloud con un provider di identità esterno.

Active Directory come IdP e fonte autorevole

Se utilizzi Active Directory come fonte attendibile per la gestione delle identità, puoi configurare la federazione come illustrato nel diagramma seguente.

Active Directory come IdP e fonte autorevole.

  • Utilizza Google Cloud Directory Sync per eseguire il provisioning automatico 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 per fare in modo che Active Directory rimanga la fonte attendibile.
  • Cloud Identity o Google Workspace utilizzano 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 una directory LDAP diversa con AD FS o un altro IdP conforme a SAML.

Per ulteriori informazioni su questo approccio, consulta Federazione di Google Cloud con Active Directory.

Esperienza utente

  1. Quando richiede la risorsa protetta, il dipendente viene reindirizzato alla schermata di accesso con Google, che richiede l'indirizzo email.
  2. Accedi con Google reindirizza il dipendente alla pagina di accesso di AD FS.
  3. 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.
  4. Dopo che AD FS ha autenticato il dipendente, questo viene reindirizzato alla risorsa protetta.

Vantaggi

L'utilizzo di Active Directory come IdP e fonte autorevole presenta i seguenti vantaggi:

  • Puoi abilitare un'esperienza Single Sign-On per i tuoi dipendenti, che si estende ai servizi Google e all'ambiente on-premise.
  • Se hai configurato AD FS per richiedere l'autenticazione a più fattori, questa configurazione si applica 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 Google Cloud Directory Sync sono accessibili pubblicamente, non è necessario configurare la connettività ibrida tra la rete on-premise e Google Cloud.

Quando utilizzare questa architettura

Potresti utilizzare Active Directory come IdP e fonte autorevole nei seguenti scenari:

  • Disponi già di un'infrastruttura Active Directory.
  • Vuoi fornire un'esperienza di accesso ottimale agli utenti Windows.

best practice

Tieni in considerazione queste best practice:

  • Active Directory e Cloud Identity utilizzano una struttura logica diversa. Assicurati di comprendere le differenze e valuta quale metodo per mappare domini, identità e gruppi si adatta meglio alla tua situazione. Per ulteriori informazioni, consulta la nostra guida alla federazione di Google Cloud con Active Directory.
  • Sincronizzare i gruppi oltre agli utenti. Con questo approccio, puoi configurare IAM in modo da poter utilizzare le iscrizioni ai gruppi in Active Directory per controllare chi ha accesso a determinate risorse in Google Cloud.
  • Esegui il deployment ed esponi AD FS in modo che gli utenti aziendali possano accedervi, ma non esporlo più del necessario. Anche se gli utenti aziendali devono essere in grado di accedere ad AD FS, non è previsto che ADFS 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 abilitare l'autenticazione integrata di Windows (IWA) in AD FS per consentire agli utenti di accedere automaticamente in base alle credenziali di accesso a Windows.
  • Se AD FS non è più disponibile, gli utenti potrebbero non essere in grado di utilizzare la console Google Cloud o qualsiasi altra risorsa che utilizza Google come IdP. Assicurati quindi che AD FS e i controller di dominio 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, fare affidamento su AD FS on-premise potrebbe compromettere l'intento di utilizzare Google Cloud come copia indipendente del 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 tuo dominio Active Directory esistente a Google Cloud ed esegui il deployment di Google Cloud Directory Sync per l'esecuzione su Google Cloud.
    • Eseguire server AD FS dedicati su Google Cloud. Questi server utilizzano i controller di dominio Active Directory in esecuzione su 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 scoprire di più, consulta le best practice per la federazione di Google Cloud con un provider di identità esterno.

Azure AD come IdP con Active Directory come fonte autorevole

Se sei un cliente Microsoft Office 365 o Azure, potresti aver connesso la tua Active Directory on-premise ad Azure AD. Se tutti gli account utente che potenzialmente hanno bisogno di accedere a Google Cloud sono già in fase di sincronizzazione con Azure AD, puoi riutilizzare questa integrazione federando Cloud Identity con Azure AD, come mostrato nel diagramma seguente.

Azure AD come IdP con Active Directory come fonte autorevole.

  • Puoi utilizzare Azure AD per eseguire automaticamente il provisioning di utenti e gruppi in Cloud Identity o Google Workspace. Azure AD potrebbe essere integrato con Active Directory on-premise.
  • Cloud Identity o Google Workspace utilizzano Azure AD per il Single Sign-On.
  • Le applicazioni aziendali esistenti e gli altri servizi SaaS possono continuare a utilizzare Azure AD come IdP.

Per informazioni più dettagliate su questo approccio, vedi Federazione di Google Cloud con Azure Active Directory.

Esperienza utente

  1. Quando richiede la risorsa protetta, il dipendente viene reindirizzato alla schermata di accesso con Google, che richiede l'indirizzo email.
  2. Accedi con Google li reindirizza alla pagina di accesso di AD FS.
  3. A seconda di come la sua Active Directory on-premise è connessa ad Azure AD, Azure AD potrebbe richiedere un nome utente e una password o potrebbe reindirizzarli a un AD FS on-premise.
  4. Dopo l'autenticazione con Azure AD, il dipendente viene reindirizzato alla risorsa protetta.

Vantaggi

L'utilizzo di Azure AD come IdP con Active Directory come fonte autorevole offre diversi vantaggi:

  • Abilita un'esperienza 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 per richiedere l'autenticazione a più fattori, questa configurazione si applica automaticamente a Google Cloud.
  • Non è necessario installare software aggiuntivo 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 questa struttura a un tenant Azure AD, puoi sfruttare questo lavoro di integrazione.
  • 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

Potresti utilizzare Azure AD come IdP con Active Directory come fonte autorevole nei seguenti scenari:

  • Utilizzi già Azure AD e lo hai integrato con un'infrastruttura esistente di Active Directory.
  • Vuoi fornire un'esperienza di accesso senza interruzioni agli utenti su Azure e Google Cloud.

best practice

Segui queste best practice:

  • Poiché Azure AD e Cloud Identity utilizzano una struttura logica diversa, assicurati di comprendere le differenze. Valuta il metodo di mappatura di domini, identità e gruppi più adatto alla tua situazione. Per informazioni più dettagliate, consulta federe Google Cloud con Azure AD.
  • Sincronizzare i gruppi oltre agli utenti. Con questo approccio, puoi configurare IAM in modo da utilizzare le iscrizioni ai gruppi in Azure AD per controllare chi può accedere a determinate risorse in Google Cloud.
  • Se utilizzi Google Cloud per garantire la continuità aziendale, affidare ad Azure AD per l'autenticazione potrebbe compromettere l'intento di utilizzare Google Cloud come copia indipendente del deployment.

Per scoprire di più, consulta le best practice per la federazione di Google Cloud con un provider di identità esterno.

Passaggi successivi