Panoramica della gestione delle identità Google

Last reviewed 2024-06-26 UTC

Tutti i servizi Google, tra cui Google Cloud, Google Marketing Platform e Google Ads, si basano su Accedi con Google per autenticare gli utenti. Questo documento spiega il modello di dominio su cui si basa Google Sign-In per l'autenticazione e la gestione dell'identità. Il modello di dominio ti aiuta a capire come funziona Accedi con Google in un contesto aziendale, come di identità e di come facilitare l'integrazione provider di identità (IdP) esterno. Il seguente diagramma mostra come queste entità interagire.

Panoramica del modello di dominio.

Come mostra questo diagramma, al centro del modello c'è l'identità Google, utilizzata da Accedi con Google. L'identità Google è legata a una serie di Altre entità pertinenti nel contesto della gestione delle identità:

  • Google per i consumatori contiene le entità pertinenti per l'utilizzo dei servizi Google incentrati sui consumatori, come Gmail.
  • Google per le organizzazioni contiene entità gestite da Cloud Identity o Google Workspace. Queste entità sono le più pertinenti per la gestione delle identità aziendali.
  • Google Cloud contiene le entità specifiche di in Google Cloud.
  • Esterno contiene entità pertinenti se integri Google con un IdP esterno.

Le frecce continue nel diagramma indicano che le entità si riferiscono l'una all'altra o che si contendono a vicenda. Al contrario, delle frecce tratteggiate indicano una relazione di federazione.

Identità Google

Le identità, gli utenti e gli account utente svolgono un ruolo fondamentale nella gestione dell'identità. I tre termini sono strettamente correlati e a volte vengono persino utilizzati in modo intercambiabile. Tuttavia, nel contesto della gestione delle identità, vale la pena per distinguere tra i concetti:

  • Un'identità è un nome che identifica in modo univoco la persona a interagire con un servizio Google. Google utilizza gli indirizzi email per che non ha uno scopo specifico. L'indirizzo email di una persona è considerato la sua identità Google.

    Il processo di verifica dell'associazione tra una persona e un'identità è chiamato autenticazione o accesso e richiede alla persona di dimostrare che si tratta effettivamente della sua identità.

    Una persona potrebbe avere più indirizzi email. Poiché i servizi Google utilizzano un indirizzo email come identità, una persona del genere viene considerata come avere più identità.

  • Un account utente è una struttura di dati che tiene traccia di attributi, attività e configurazioni da applicare ogni volta che una determinata identità interagisce con un servizio Google. Gli account utente non vengono creati al volo, ma devono essere di cui deve essere eseguito il provisioning prima del primo accesso.

    Gli account utente sono identificati da un ID non esposto esternamente. Utente o API richiedono quindi di fare riferimento all'account utente indirettamente dalla sua identità associata, ad esempio alice@gmail.com. Nonostante questo passaggio indiretto, tutti i dati e i dettagli di configurazione sono associati all'account dell'utente, non all'identità.

Nella maggior parte dei casi, esiste una relazione uno a uno tra gli account utente e le loro identità, il che li rende facili da confondere. Tuttavia, non sempre è come illustrato nei seguenti casi limite:

  • La relazione tra account utente e identità non è fissa. Puoi modificare l'indirizzo email principale di un account utente, associa un'identità diversa all'utente.

    In qualità di amministratore di Cloud Identity o Google Workspace, puoi persino scambiare gli indirizzi email principali di due utenti. Ad esempio, se scambi gli indirizzi email principali di Alice (alice@example.com) e di Bob (bob@example.com), Alice utilizzerà l'account utente precedente di Bob e Bob utilizzerà l'account utente precedente di Alice. Poiché i dati e le è associata all'account utente e non all'identità. Alice ora utilizzerà anche la configurazione e i dati esistenti di Roberto ora userebbe la configurazione e i dati di Alice). La figura seguente mostra questa relazione.

    Relazione tra le identità di Roberto e Alice.

    In una configurazione non federata, dovrai anche reimpostare le password per poter Alice e Roberto per scambiare gli account utente. In un'installazione federata in cui Alice e Bob utilizza un IdP esterno per eseguire l'autenticazione, la reimpostazione delle password non sarebbe necessaria.

  • La relazione tra identità e utenti potrebbe non essere 1:1. R account consumer possono essere intenzionalmente associati a più identità, come mostrato nel diagramma seguente.

    È anche possibile che un'identità si riferisca a due account utente diversi. Ti consigliamo di evitare questa situazione, ma può verificarsi nel caso di un account utente in conflitto. In questo caso, durante l'autenticazione viene mostrata una schermata di scelta in cui l'utente deve selezionare l'account utente da utilizzare.

    Alice: utente e identità non sempre sono 1:1.

Google distingue due tipi di account utente: account utente consumer e account utente gestiti. Le sezioni seguenti trattano entrambi i tipi degli account utente e delle entità correlate in modo più dettagliato.

Google per i consumatori

Se possiedi un indirizzo email Gmail come alice@gmail.com, il tuo indirizzo Gmail è un account consumer. Analogamente, se utilizzi il link Crea account nella pagina di accesso di Google e durante la registrazione fornisci un indirizzo email personalizzato di tua proprietà, ad esempio alice@example.com, l'account risultante è anche un account consumer.

Account consumer

Gli account consumer vengono creati in modalità self-service e sono destinati principalmente all'uso per scopi privati. La persona che ha creato l'account consumer dispone di controllo dell'account e qualsiasi dato creato mediante quest'ultimo. L'indirizzo email utilizzato dalla persona durante la registrazione diventa l'indirizzo email principale dell'account del consumatore e ne rappresenta l'identità. Questa persona può aggiungere indirizzi email all'account del consumatore. Questi indirizzi email fungono da identità aggiuntive e possono essere utilizzati anche per accedere.

Quando un account consumer utilizza un indirizzo email principale che corrisponde al dominio principale o secondario di un account Cloud Identity o Google Workspace, l'account consumer viene definito anche account utente non gestito.

Un account consumer può essere membro di un numero qualsiasi di gruppi.

Google per le organizzazioni

Se la tua organizzazione usa i servizi Google, è preferibile usare la gestione dell'account Google Cloud. Questi account sono chiamati gestiti perché il loro ciclo di vita e la loro configurazione possono essere controllati completamente dall'organizzazione.

Gli account utente gestiti sono una funzionalità di Cloud Identity Google Workspace.

Account Cloud Identity o Google Workspace

Un account Cloud Identity o Google Workspace è l'account di primo livello contenitore per utenti, gruppi, configurazione e dati. Cloud Identity o Google Workspace viene creato quando un'azienda si registra Cloud Identity o Google Workspace e corrisponde alla nozione di tenant.

Cloud Identity e Google Workspace condividono lo stesso concetto completamente gestita. Entrambi i prodotti utilizzano lo stesso insieme di API e strumenti di amministrazione e condividono il concetto di account come contenitore per utenti e gruppi. Questo contenitore è identificato da un nome di dominio. Per gestire gli utenti, gruppi e autenticazione, i due prodotti possono essere considerati equivalenti.

Un account contiene gruppi e una o più unità organizzative.

Unità organizzativa

Un'unità organizzativa (OU) è un sottocontenitore per gli account utente che consente di segmentare gli account utente definiti nell'account Cloud Identity o Google Workspace in insiemi indipendenti per semplificarne la gestione.

Le unità organizzative sono organizzate in modo gerarchico. Ogni Cloud Identity Google Workspace ha una UO principale, in cui puoi creare altre UO in base alle esigenze. Puoi anche nidificare le UO.

Cloud Identity e Google Workspace consentono di applicare configurazioni per UO, ad esempio assegnazione licenze o Verifica in due passaggi. Queste impostazioni vengono applicate automaticamente a tutti gli utenti dell'UO e vengono anche ereditate dalle UO secondarie. Le unità organizzative svolgono quindi un ruolo fondamentale nella gestione Configurazione di Cloud Identity e Google Workspace.

Un account utente non può appartenere a più di un'unità organizzativa, il che le rende diverse dai gruppi. Sebbene le OU siano utili per applicare la configurazione agli account utente, non sono destinate a essere utilizzate per la gestione dell'accesso. Per gestire l'accesso, ti consigliamo di utilizzare i gruppi.

Anche se le UO assomigliano cartelle Google Cloud, le due entità hanno scopi diversi e non sono correlate a un'altra.

Account utente gestito

Gli account utente gestiti funzionano in modo simile agli account utente consumer, ma possono essere completamente controllati dagli amministratori di Cloud Identity Account Google Workspace.

L'identità di un account utente gestito è definita dal relativo indirizzo email principale. L'indirizzo email principale deve utilizzare un dominio che corrisponda a uno dei domini principali, secondari o di alias aggiunti all'account Cloud Identity o Google Workspace. Gli account utente gestiti possono avere indirizzi email alias e un indirizzo email di recupero, ma questi indirizzi non sono considerati identità e non possono essere utilizzati per la firma in. Ad esempio, se Alice utilizza alice@example.com come indirizzo email principale e ha configurato ally@example.com come indirizzo email alias e alice@gmail.com come indirizzo email di recupero, poi l'unico indirizzo email, Alice che puoi utilizzare per accedere è alice@example.com.

Gli account utente gestiti sono contenuti in un'unità organizzativa e possono essere membri di un numero qualsiasi di gruppi.

Gli account utente gestiti sono destinati all'utilizzo da parte di utenti umani anziché da utenti di macchine. Un account utente di macchina è un particolare tipo di account utilizzato da un di un'applicazione o di una macchina virtuale (VM), non di una persona. Per gli utenti di macchine, Google Cloud fornisce account di servizio. Gli account di servizio verranno discussi più in dettaglio più avanti in questo documento.

Gruppo

I gruppi consentono di raggruppare più utenti. Puoi utilizzare i gruppi per gestire una mailing list elenco o per applicare controllo dell'accesso o configurazioni comuni a più utenti.

Cloud Identity e Google Workspace identificano i gruppi tramite l'indirizzo email, ad esempio billing-admins@example.com. Come per l'indirizzo email principale di un utente, l'indirizzo email del gruppo deve utilizzare uno dei domini principali, secondari o degli alias dell'account Cloud Identity o Google Workspace. L'indirizzo email non deve corrispondere a una casella di posta, a meno che il gruppo non venga utilizzato come mailing list. L'autenticazione avviene comunque utilizzando l'email anziché l'email del gruppo, quindi un utente non può accedere utilizzando un indirizzo email di gruppo .

Un gruppo può avere le seguenti entità come membri:

  • Utenti (utenti gestiti o account consumer)
  • Altri gruppi
  • Account di servizio

A differenza di un'unità organizzativa, i gruppi non fungono da contenitore:

  • Un utente o un gruppo può essere membro di un numero qualsiasi di gruppi, non solo di uno.
  • L'eliminazione di un gruppo non comporta l'eliminazione degli utenti o dei gruppi membri.

I gruppi possono contenere membri di qualsiasi account Cloud Identity o Google Workspace, nonché account consumer. Puoi utilizzare lo non consentire i membri esterni alla tua organizzazione per limitare i membri ad account utente appartenenti alla stessa identità di Cloud Identity Google Workspace o Google Workspace.

Identità esterne

Se federate un account Cloud Identity o Google Workspace con un IdP esterno, potete consentire ai dipendenti di utilizzare le loro credenziali e la loro identità esistenti per accedere ai servizi Google.

A livello più elementare, la federazione comporta la configurazione del Single Sign-On utilizzando SAML, che collega le identità in Cloud Identity o Google Workspace alle identità gestite dal tuo IdP esterno. Per collegare un'identità, ad esempio alice@example.com e abilitarla per il Single Sign-On a Google, devi soddisfare due prerequisiti:

  • L'IdP esterno deve riconoscere l'identità alice@example.com e e ne consente l'uso per il Single Sign-On.
  • Il tuo account Cloud Identity o Google Workspace deve contengono un account utente che utilizza alice@example.com come identità. Questo un account utente deve esistere prima del primo tentativo di Single Sign-On.

Anziché creare e gestire manualmente gli account utente in Cloud Identity o Google Workspace, puoi automatizzare il processo combinando il servizio Single Sign-On basato su SAML con il provisioning automatico degli utenti. La il provisioning automatico degli utenti consiste nel sincronizzare tutto o un sottoinsieme dei utenti e gruppi da una fonte autorevole esterna a Cloud Identity o Google Workspace.

A seconda dell'IdP scelto, il Single Sign-On basato su SAML e il provisioning automatico degli utenti possono essere gestiti dallo stesso componente software o richiedere componenti separati. Il modello di dominio distingue quindi un Identity Provider SAML da una fonte autorevole esterna.

Provider di identità SAML esterno

L'IdP esterno è l'unico sistema di autenticazione e fornisce una singola di accesso per i tuoi dipendenti su più applicazioni. È esterno a Google e pertanto è definito provider di identità esterno.

Quando attivi il Single Sign-On, Cloud Identity o Google Workspace inoltra le decisioni di autenticazione all'IdP SAML. In termini SAML, Cloud Identity o Google Workspace agisce come provider di servizi che si affida all'IdP SAML per verificare l'identità di un utente per suo conto.

Ogni account Cloud Identity o Google Workspace può essere consultato all'indirizzo per la maggior parte di un IdP esterno. Più account Cloud Identity o Google Workspace possono fare riferimento a diversi provider di identità SAML, ma non è possibile che un singolo account Cloud Identity o Google Workspace utilizzi più provider di identità SAML.

I provider di identità esterni di uso comune includono Active Directory Federation Services (AD FS), Azure AD, Okta o Ping Identity.

Fonte autorevole esterna

L'origine attendibile per le identità è l'unico sistema che utilizzi per creare, gestire ed eliminare le identità dei tuoi dipendenti. È esterno a ed è pertanto indicata come fonte autorevole esterna.

Dall'origine attendibile esterna, è possibile eseguire il provisioning automatico di account utente e gruppi in Cloud Identity o Google Workspace. Il provisioning potrebbe essere gestito dalla stessa fonte attendibile o tramite middleware di provisioning.

Affinché il provisioning automatico degli utenti sia efficace, è necessario eseguire il provisioning degli utenti con un'identità riconosciuta dal tuo IdP SAML. Se esegui la mappatura tra identità (ad esempio, se mappi l'identità alice@example.com in Cloud Identity o Google Workspace a u12345@corp.example.com nel tuo IdP SAML), sia l'IdP SAML sia il middleware di provisioning devono eseguire la stessa mappatura.

Account utente esterno

Si presume che i provider di identità esterni utilizzino il concetto di account utente. che tiene traccia del nome, degli attributi e della configurazione.

L'origine attendibile (o il middleware di provisioning) deve eseguire il provisioning di tutti (o di un sottoinsieme) gli account utente esterni in Cloud Identity o Google Workspace per facilitare l'esperienza di accesso. In molti casi, è sufficiente propagare solo un sottoinsieme degli attributi dell'utente (come come indirizzo email, nome e cognome) a Cloud Identity oppure Google Workspace per limitare la ridondanza dei dati.

Gruppo esterno

Se il tuo provider di identità esterno supporta il concetto di gruppo, puoi eventualmente mappare questi gruppi ai gruppi in Cloud Identity o Google Workspace.

La mappatura e il provisioning automatico dei gruppi sono facoltativi e non necessari per l'accesso singolo, ma entrambi i passaggi possono essere utili se vuoi riutilizzare i gruppi esistenti per controllare l'accesso in Google Workspace o Google Cloud.

Google Cloud

Come altri servizi Google, Google Cloud si basa su Accedi con Google per autenticare gli utenti. Inoltre, Google Cloud si integra da vicino Google Workspace e Cloud Identity per consentirti di gestire risorse in modo efficiente.

Google Cloud introduce la nozione di nodi organizzazione, cartelle in modo programmatico a gestire i progetti. Queste entità vengono utilizzate principalmente per gestire l'accesso e la configurazione, pertanto sono pertinenti solo marginalmente nel contesto della gestione delle identità. Tuttavia, Google Cloud include anche un altro tipo di utente account: account di servizio. Gli account di servizio appartengono ai progetti e svolgono un ruolo fondamentale nella gestione delle identità.

Nodo organizzazione

Un'organizzazione è il nodo radice della gerarchia delle risorse Google Cloud e un contenitore per progetti e cartelle. Le organizzazioni ti permettono di strutturare risorse in modo gerarchico e sono fondamentali per la gestione centralizzata delle risorse in modo efficiente.

Ogni organizzazione appartiene a una singola Cloud Identity Account Google Workspace. Il nome dell'organizzazione è ricavato dal nome di dominio principale dell'account Cloud Identity o Google Workspace corrispondente.

Cartella

Le cartelle sono nodi nella gerarchia delle risorse di Google Cloud e possono contenere progetti, altre cartelle o una combinazione di entrambi. Raggruppare le cartelle le risorse che condividono Criteri IAM (Identity and Access Management) o criteri dell'organizzazione. Questi criteri vengono applicati automaticamente a tutti i progetti nella cartella e vengono anche ereditati dalle cartelle secondarie.

Le cartelle sono simili, ma non correlate, alle unità organizzative. Le unità organizzative ti aiutano a gestire gli utenti e ad applicare configurazioni o criteri comuni agli utenti, mentre le cartelle ti aiutano a gestire i progetti Google Cloud e ad applicare configurazioni o criteri comuni ai progetti.

Progetto

Un progetto è un container per le risorse. I progetti svolgono un ruolo fondamentale per la gestione delle API, della fatturazione e dell'accesso alle risorse.

Nel contesto della gestione delle identità, i progetti sono pertinenti perché sono i contenitori degli account di servizio.

Service account

Un account di servizio (o account di servizio Google Cloud) è un tipo speciale di account utente destinato a essere utilizzato da applicazioni e altri tipi di utenti di macchine.

Ogni account di servizio appartiene a un progetto Google Cloud. Come nel caso di account utente gestiti, gli amministratori possono controllare completamente il ciclo di vita e la configurazione di un servizio .

Anche gli account di servizio utilizzano un indirizzo email come identità, ma a differenza di account utente gestiti, l'indirizzo email utilizza sempre un dominio di proprietà di Google come come developer.gserviceaccount.com.

I service account non partecipano alla federazione e non dispongono di una password. Su Google Cloud, utilizzi IAM per controllare l'autorizzazione di un account di servizio per una risorsa di calcolo come una macchina virtuale (VM) o una funzione Cloud Run, eliminando la necessità di gestire le credenziali. Al di fuori di Google Cloud, puoi utilizzare chiavi dell'account di servizio per consentire a un'applicazione di eseguire l'autenticazione usando un account di servizio.

Service account Kubernetes

Gli account di servizio Kubernetes sono un concetto di Kubernetes e sono pertinenti quando utilizzi Google Kubernetes Engine (GKE). Analogamente agli account di servizio Google Cloud, destinato a essere usato dalle applicazioni, non dagli esseri umani.

Gli account di servizio Kubernetes possono essere utilizzati per l'autenticazione quando un'applicazione chiama l'API Kubernetes di un cluster Kubernetes, ma non possono essere utilizzati al di fuori del cluster. Non sono riconosciuti da nessuna API di Google e quindi non sostituiscono un account di servizio Google Cloud.

Quando esegui il deployment di un'applicazione come pod Kubernetes, puoi associarlo a un account di servizio. Questa associazione consente all'applicazione di utilizzare l'API Kubernetes senza dover configurare o gestire certificati o altre credenziali.

Utilizzando Identità carico di lavoro puoi collegare un account di servizio Kubernetes a un servizio Google Cloud . Questo link consente a un'applicazione anche di autenticarsi alle API di Google, senza dover gestire certificati o altre credenziali.

Passaggi successivi