Questo documento presenta best practice e indicazioni che ti aiutano a configurare la federazione in modo coerente e sicuro. La guida si basa best practice per l'utilizzo di Cloud Identity o Google Workspace con Google Cloud.
Tutti i servizi Google, tra cui Google Cloud, Google Marketing Platform, e Google Ads, affidati Accedi con Google per autenticare gli utenti. Anziché creare e gestire manualmente gli account utente in Cloud Identity o Google Workspace per ogni dipendente, puoi federare Cloud Identity o Google Workspace con il tuo provider di identità (IdP) esterno, ad esempio Active Directory o Azure Active Directory. Configurazione della federazione prevede in genere quanto segue:
- Esegui il provisioning automatico degli account utente pertinenti da un'origine autorevole esterna a Cloud Identity o Google Workspace.
- Consentire agli utenti di utilizzare una IdP esterno per l'autenticazione nei servizi Google.
Mappa identità
L'identità di un account utente gestito da Cloud Identity o Google Workspace è definita dal relativo indirizzo email principale. L'indirizzo email principale è indicato come Indirizzo email dell'Account Google nella pagina dell'Account Google. Per essere considerato valido, l'indirizzo email principale deve utilizzare uno dei domini che hai aggiunto al tuo account Cloud Identity o Google Workspace.
L'indirizzo email principale serve anche per:
- L'indirizzo email principale è il nome utente che un utente deve fornire quando eseguendo l'accesso. Sebbene gli utenti possano aggiungere indirizzi email o alias alternativi al proprio account utente Google, questi indirizzi non sono considerati identità e non possono essere utilizzati per accedere.
- Quando un amministratore deve inviare notifiche agli utenti (ad esempio, per comunicare un potenziale rischio per la sicurezza), le notifiche vengono inviate al solo l'indirizzo email principale.
Per configurare il Single Sign-On e il provisioning automatico degli utenti tra Google e il tuo provider di identità esterno, devi mappare le identità nel tuo provider di identità esterno alle identità corrispondenti in Cloud Identity o Google Workspace. Le sezioni seguenti descrivono le best practice per stabilire questa mappatura.
Utilizza la stessa identità in tutti i sistemi federati
Tutto ciò che serve per stabilire una mappatura è verificare che l'asserzione SAML
che l'IdP fornisce a Google contiene
Rivendicazione di NameID
con un valore che corrisponde all'indirizzo email principale di un indirizzo email esistente
come utente di Cloud Identity o Google Workspace. L'IdP è gratuito
qualsiasi mappatura o logica sia applicabile per ottenere una richiesta NameID adatta per
per gli utenti esistenti.
Molte IdP si basano sugli indirizzi email (o più in generale su nomi conformi allo standard RFC 822) per identificare gli utenti. Ecco alcuni esempi:
- L'attributo
userPrincipalNamein Active Directory è un nome conforme allo standard RFC 822 che identifica in modo univoco un utente e può essere utilizzato per accedere a Windows o Active Directory Federation Services (AD FS). - Azure Active Directory utilizza l'attributo
UserPrincipalNameper identificare gli utenti e consentire loro di accedere.
Se gli utenti gestiti dal tuo IdP esterno si basano già su un indirizzo email come identità, puoi utilizzare la stessa identità dell'indirizzo email principale in Cloud Identity o Google Workspace. Utilizzare la stessa identità utente sistemi federati offre diversi vantaggi:
Quando gli utenti accedono a uno strumento Google come la console Google Cloud, devono prima fornire l'indirizzo email principale del proprio utente Cloud Identity o Google Workspace prima di essere reindirizzati al tuo provider di identità esterno. A seconda dell'IdP, all'utente potrebbe essere presentata un'altra schermata di accesso in cui inserire il nome utente e la password.
Se gli indirizzi email sono diversi per questi passaggi, la sequenza di schermate di accesso può facilmente confondere gli utenti finali. Al contrario, se gli utenti possono utilizzare un'identità comune in tutti i passaggi, non sono esposti alle differenze tecniche tra gli IdP, il che riduce al minimo la potenziale confusione.
Se non devi eseguire la mappatura tra le identità utente, è più facile correlati gli audit log di Google Cloud con i log dei sistemi on-premise.
Analogamente, se il deployment delle applicazioni viene eseguito on-premise Google Cloud deve scambiare dati contenenti identità degli utenti, evitare la complessità aggiuntiva di dover mappare gli identificatori degli utenti.
Per maggiori dettagli sulla mappatura degli utenti di Active Directory o di Azure AD a Cloud Identity o Google Workspace, consulta le Active Directory o Azure AD guida.
Assicurati che le identità utilizzino indirizzi email instradabili
Google Cloud utilizza l'indirizzo email principale di un utente per la consegna email di notifica. Ecco alcuni esempi di queste notifiche:
Avvisi relativi al budget: se hai configurato avviso relativo al budget Google Cloud invia una notifica agli amministratori della fatturazione e agli utenti della fatturazione quando viene superata la soglia del budget.
Notifiche relative ai pagamenti: eventuali notifiche o avvisi relativi ai pagamenti vengono inviati agli indirizzi email degli utenti pagamenti configurati per l'account di fatturazione interessato.
Inviti a progetti: se assegni il ruolo di Amministratore progetto a un utente che fa parte di un'altra Cloud Identity o Google Workspace diverso da quello associato all'organizzazione del progetto, viene inviato un invito all'utente. Prima che il ruolo appena concesso possa l'utente deve accettare l'invito facendo clic su un link nell'email per creare un nuovo messaggio email.
Risposte alle richieste di assistenza e altre notifiche dell'assistenza.
Se utilizzi Google Workspace e hai configurato correttamente i necessari Sistema DNS Record MX, vengono recapitate tutte le email di notifica inviate all'indirizzo email principale nella casella di posta Gmail dell'utente corrispondente.
Per gli utenti di Cloud Identity, Google Cloud tenta anche di inviare email di notifica, ma l'email deve essere gestita dall'infrastruttura email esistente. Assicurati che i tuoi utenti di Cloud Identity non perdano notifiche, assicurati che il tuo sistema email esistente accetti i messaggi che vengono inviati agli indirizzi email principali degli utenti di Cloud Identity in modo che le email vengano indirizzate alle caselle di posta corrette. Segui questi passaggi:
Assicurati che tutti i domini aggiunto a Cloud Identity avere record MX DNS che puntano al sistema email esistente.
Assicurati che l'indirizzo email principale di un utente di Cloud Identity corrisponda a una casella postale esistente nel tuo sistema di posta elettronica. In caso di mancata corrispondenza tra l'indirizzo email principale utilizzato da Cloud Identity e l'indirizzo email dell'utente, configura un alias nel sistema di posta esistente in modo che l'email inviata a ciascun indirizzo email principale viene indirizzata al casella di posta.
Se queste soluzioni non sono pratiche, considera aggiungendo Google Workspace a un account Cloud Identity esistente e assegnando le licenze Google Workspace agli utenti chiave che si trovano fatturazione o di interazione con l'assistenza e chi è quindi più probabile per ricevere notifiche.
Valutare le opzioni di migrazione per gli account consumer esistenti
Se i tuoi dipendenti utilizzavano servizi Google come Google Ad Manager, Google AdSense o Google Analytics prima che la tua organizzazione si registrasse a Cloud Identity o Google Workspace, è possibile che abbiano utilizzato account consumer per accedere a questi servizi.
Consentire ai dipendenti di utilizzare account consumer per scopi commerciali può essere rischioso. Per maggiori dettagli su quali sono questi rischi e su come puoi far emergere consumatori esistenti gli account, vedi Valutare gli Account Google esistenti.
Puoi gestire gli account consumer esistenti nei seguenti modi:
- Mantieni gli account dei consumatori invariati, accettando i potenziali rischi.
- Esegui la migrazione degli account a Cloud Identity o Google Workspace avviando un trasferimento.
- Forzare i proprietari degli account utente non gestiti a modificare il proprio indirizzo email per utilizzare un altro dominio.
Per ulteriori dettagli su come consolidare gli account consumer esistenti, consulta Valutazione delle opzioni di consolidamento delle identità.
Il modo in cui decidi di gestire gli account dei consumatori influisce su come e in quale sequenza configuri la federazione. Valuta gli account consumer esistenti utilizzati dagli utenti Prima di iniziare a creare account utente o a configurare l'accesso Single Sign-On Cloud Identity o Google Workspace.
Mappa i set di identità
Quando definisci in che modo le singole identità vengono mappate tra i tuoi indirizzi e Cloud Identity o Google Workspace, devi stabilire l'insieme di identità per cui abilitare l'accesso ai servizi Google.
L'insieme effettivo di identità che possono eseguire l'autenticazione nei servizi Google è intersezione di due insiemi:
- Identità esterne che vengono associate a un'identità in Cloud Identity o Google Workspace.
Identità esterne consentite dall'IdP esterno accedi a Cloud Identity o Google Workspace.
La procedura per controllare chi è autorizzato a utilizzare il Single Sign-On varia in base all'IdP utilizzato. Ad esempio, Azure AD si basa compiti, mentre AD FS usa criteri di controllo dell'accesso.
Limita l'insieme di identità che possono eseguire l'autenticazione nei servizi Google
A seconda di come prevedi di utilizzare Google Cloud, e altri strumenti Google, per tutti i dipendenti dell'organizzazione o solo per devono essere in grado di autenticarsi sui servizi Google.
Se prevedi di concedere l'accesso a un solo sottoinsieme dei dipendenti della tua organizzazione servizi Google, è meglio limitare l'autenticazione a questo insieme di utenti. Se limiti il numero di utenti che possono eseguire l'autenticazione, puoi stabilire un'ulteriore che aiuta in caso di configurazione accidentale di accessi regola di controllo troppo permissiva.
Puoi limitare l'insieme di utenti che possono autenticarsi su Google nei seguenti modi:
- Riduci al minimo il numero di account utente in Cloud Identity o Google Workspace. Se non è presente un account utente mappato, qualsiasi tentativo l'autenticazione di un utente avrà esito negativo, anche se l'IdP lo consente a Cloud Identity o Google Workspace mediante Single Sign-On.
- Configurare il Single Sign-On nel tuo IdP per ridurre al minimo il numero di utenti a cui è consentito accedere a Cloud Identity Google Workspace.
L'approccio migliore per la tua situazione dipende dal fatto che tu abbia già account consumer di cui devi eseguire la migrazione.
Limita l'insieme di identità di cui esegui il provisioning se devi ancora eseguire la migrazione degli account consumer
Puoi eseguire la migrazione di un account consumer a Cloud Identity o Google Workspace solo se non hai creato un account utente con la stessa identità in Cloud Identity o Google Workspace.
Se hai account consumer esistenti di cui vuoi eseguire la migrazione, devi fare attenzione a non creare accidentalmente account utente in conflitto. Segui queste linee guida:
- Limita l'autenticazione creando nuovi account utente Cloud Identity o Google Workspace solo per gli utenti che ne hanno bisogno e di cui è noto che non hanno un account consumer esistente.
- Evitare di bloccare inavvertitamente gli account di cui è stata eseguita la migrazione consentendo il Single Sign-On non solo per gli utenti per i quali crei utenti in Cloud Identity o Google Workspace, ma anche per tutti gli account consumer di cui deve ancora essere eseguita la migrazione.
Il seguente diagramma mostra come diversi tipi di identità si sovrappongono sono correlate tra loro.
Nel diagramma, le identità con un account utente in Cloud Identity Google Workspace è l'ellisse più piccola (giallo). L'ellisse è contenuta nella seconda ellisse (blu), che contiene le identità per l'autenticazione. La terza ellisse (in grigio) è la più grande e contiene le altre. È costituita dalle identità che hanno un account utente nel tuo IdP. Per informazioni dettagliate su come configurare Active Directory, Azure AD o Okta, consulta la nostra guida alle best practice distinta.
Impedire la registrazione di nuovi account consumer
L'aggiunta di un dominio come example.com al tuo account Cloud Identity o Google Workspace non impedisce ai dipendenti di registrarsi a nuovi account consumer utilizzando lo stesso dominio. Questi nuovi account consumer vengono visualizzati come utenti non gestiti nel tuo account Cloud Identity o Google Workspace, ma non possono utilizzare l'accesso singolo o qualsiasi altra configurazione applicata nel tuo account Cloud Identity o Google Workspace.
Un modo per bloccare la creazione di un nuovo account consumer è creare un utente
in Cloud Identity o Google Workspace con lo stesso indirizzo email
. Ad esempio, se hai creato un utente alice@example.com nel tuo account Cloud Identity o Google Workspace, tutti i tentativi di un dipendente di registrarsi a un nuovo account consumer con la stessa identità non andranno a buon fine. Tuttavia, se non esiste nessun utente corrispondente in Cloud Identity o
Google Workspace, la registrazione di un nuovo account consumer
riuscire.
Quando non ci sono più account consumer di cui eseguire la migrazione a Cloud Identity, prendi provvedimenti per impedire la registrazione di nuovi account consumer applicando la seguente configurazione:
Limita l'autenticazione consentendo solo agli utenti pertinenti di utilizzare l'accesso singolo a Cloud Identity o Google Workspace.
Esegui il provisioning degli utenti Cloud Identity o Google Workspace per tutti i dipendenti. Assicurati che gli account utente utilizzino aziendale come indirizzo email principale o alias, in modo che è possibile creare nuovi account consumer utilizzando lo stesso indirizzo email. Se possibile, mantieni in stato di sospensione gli account utente per i quali non è attivato il Single Sign-On.
Il seguente diagramma mostra questa configurazione.
Se è ancora in corso la migrazione degli account consumer, puoi
monitorare temporaneamente le registrazioni dei nuovi account consumer acquisendo la verifica
email inviate durante il processo di registrazione. Le email di verifica utilizzano un
indirizzo del mittente della busta corrispondente a *@idverification.bounces.google.com.
Imposta un filtro nel tuo sistema email per identificare le email con questa busta
dell'indirizzo del mittente e verranno conservati per la revisione interna.
Rendi le identità Cloud Identity o Google Workspace un sottoinsieme delle identità nel tuo provider di identità esterno
Il tuo account Cloud Identity o Google Workspace potrebbe contenere account utente con identità che non corrispondono a nessun utente nell'IDP esterno. Esistono due scenari tipici che possono generare questi account utente:
- Crei un nuovo account utente in Cloud Identity oppure Google Workspace e utilizzare un indirizzo email principale che non corrisponde a qualsiasi utente del tuo IdP esterno.
- Hai un account utente in Cloud Identity o Google Workspace che mappa a un'identità nel tuo IdP esterno, ma poi elimini l'identità nell'IdP esterno. Ad esempio, potresti eliminare l'identità se il dipendente lascia l'azienda.
Quando abiliti il Single Sign-On in Cloud Identity oppure Google Workspace, tutti gli utenti (ad eccezione dei super amministratori) forzato a utilizzare il Single Sign-On. Per Cloud Identity o Account utente Google Workspace che non corrisponde a un'identità nel tuo IdP esterno, qualsiasi tentativo di utilizzare il Single Sign-On avrà esito negativo. Un account utente senza una controparte di questo tipo è praticamente inattivo, ma potrebbe comunque rappresentare un rischio, come nelle seguenti situazioni:
Se a un certo punto il Single Sign-On viene disattivato temporaneamente o definitivamente, l'account utente può essere riutilizzato. In questo modo, un ex dipendente potrebbe accedere alle risorse aziendali.
Il nome dell'account utente eliminato potrebbe essere riutilizzato. Ad esempio, un dipendente che entra a far parte dell'azienda potrebbe condividere lo stesso nome con un altro dipendente che ha lasciato l'azienda mesi o anni prima. Se l'impostazione precedente di un dipendente è stato eliminato, è possibile che tu potrebbe assegnare al nuovo dipendente il nome utente che aveva per gli utilizzi odierni.
L'account utente del nuovo dipendente potrebbe avere un ID interno diverso da quello dell'ex dipendente. Tuttavia, dal punto di vista della federazione, i due account utente vengono considerati uguali se mappano entrambi l'indirizzo email principale in Cloud Identity o Google Workspace. Di conseguenza, quando il nuovo dipendente accede a Google, potrebbe "ereditare" i dati, le impostazioni e le autorizzazioni esistenti dell'ex dipendente.
Gli utenti super amministratori di Cloud Identity e Google Workspace sono esenti dal requisito di utilizzo del Single Sign-On, ma possono comunque utilizzarlo quando l'accesso viene avviato dall'IdP. La possibilità di utilizzare il Single Sign-On avviato dall'IdP rende gli utenti super amministratori sensibili al furto di nome se non dispongono di una controparte nel tuo IdP esterno.
Considera l'esempio seguente: Alice ha un utente super amministratore
alice-admin@example.com in Cloud Identity o Google Workspace
e non utilizza la verifica in due passaggi. Mallory, che non conosce Alice
password, trova un modo per creare un nuovo utente nell'IdP esterno mappato
alice-admin@example.com. Sebbene questo account utente appena creato potrebbe non avere privilegi speciali e non avere alcuna relazione con l'account utente di Alice, il fatto che condivida un'identità comune con l'account super amministratore di Alice ora consente a Mallory di utilizzare l'accesso singolo avviato dall'IDP e di autenticarsi come alice-admin@example.com.
Per ridurre questo rischio di squatting dei nomi, assicurati che le tue identità Cloud Identity o Google Workspace siano un sottoinsieme delle identità nel tuo provider di identità esterno. Il modo migliore per farlo è mappare l'intero ciclo di vita dell'account utente come implementato dal tuo provider di identità esterno al ciclo di vita dell'account utente in Cloud Identity o Google Workspace.
Utilizzare utenti super amministratori dedicati
Gli account super amministratore di Google Workspace e Cloud Identity dispongono di un un insieme di autorizzazioni che non si applicano solo a Cloud Identity Google Workspace, ma anche a un'organizzazione Google Cloud associata. Poiché solo un numero limitato di attività richiede privilegi di super amministratore, se possibile è meglio limitare il numero di amministratori con accesso di super amministratore e utilizzare account utente con privilegi inferiori per la gestione quotidiana del tuo account o della tua organizzazione Google Cloud.
Dopo aver identificato gli amministratori che richiedono l'accesso come super amministratori, crea account utente super amministratore dedicati, ad esempio:
- Crea un account utente con l'identità
alice@example.come assegnale autorizzazioni standard. Questo account dovrebbe essere utilizzato quotidianamente per attività di routine. Crea un secondo account utente con l'identità
alice-admin@example.come assegnati i privilegi di superutente. È una best practice che Alice utilizzi l'account di servizio solo nelle occasioni in cui sono necessari i privilegi di super amministratore.Per garantire che le email di notifica inviate a questo indirizzo vengono ricevute nella casella di posta dell'utente, configura Google Workspace o sistema di posta elettronica in modo che l'indirizzo email
alice-admin@example.comsia un alias o inoltrato aalice@example.com.
Assicurati che entrambe le identità siano riconosciute dal tuo IdP esterno in modo che il set di identità in Cloud Identity o Google Workspace continua sii un sottoinsieme di identità nel tuo IdP esterno.
Ti consigliamo di seguire uno schema di denominazione per questi account super amministratore dedicati
in modo che negli audit log sia possibile
tracciare dove e come vengono utilizzati. Ad esempio, aggiungi -admin al nome utente, come nell'esempio precedente.
Limitare il numero di utenti del servizio in Google Workspace e Cloud Identity
L'IdP esterno potrebbe contenere non solo account utente per i dipendenti, ma anche account utente destinati a utenti di macchine come applicazioni, strumenti o job in background.
Al contrario, il modo preferito su Google Cloud per consentire a un'applicazione di autenticarsi e accedere alle API Google è implementare uno dei seguenti approcci:
Uno strumento o un'applicazione web che deve accedere alle API o ai servizi Google per conto di un utente finale deve utilizzare OAuth 2.0 o OpenID Connect. Se utilizza uno di questi protocolli, l'applicazione chiede innanzitutto all'utente finale il consenso per accedere ai suoi dati e, dopo aver ricevuto il consenso, può eseguire l'accesso per conto dell'utente finale.
Se l'accesso alle API o ai servizi non deve essere eseguito per conto di un utente finale, per conto dell'applicazione stessa, è preferibile utilizzare Account di servizio Google Cloud per l'autenticazione e quindi concedi all'account di servizio l'accesso alle risorse utilizzando IAM.
Se agli account di servizio Google Cloud vengono assegnati i ruoli appropriati in IAM, possono essere utilizzati per autenticare e utilizzare qualsiasi API Cloud. Se devi concedere a un account di servizio l'accesso ad API esterne a Google Cloud, ad esempio all'API Directory o all'API Drive, puoi utilizzare la delega a livello di dominio di Google Workspace.
Con la delega a livello di dominio di Google Workspace, consenti a un account di servizio di agire per conto di un utente Cloud Identity o Google Workspace. Poiché la delega è un privilegio potente, ti consigliamo di utilizzare la delega a livello di dominio di Google Workspace solo nei casi in cui l'approccio OAuth non sia pratico.
Utilizza un utente Cloud Identity o Google Workspace dedicato per ogni account di servizio Google Cloud abilitato per la delega a livello di dominio di Google Workspace. Crea questo utente nel tuo IdP esterno e poi esegui il provisioning in Cloud Identity o Google Workspace in modo che l'insieme di utenti in Cloud Identity o Google Workspace continui a essere un sottoinsieme di utenti nel tuo IdP esterno.
Evita di creare utenti di servizio in Cloud Identity e Google Workspace che non intendi utilizzare per la delega su tutto il dominio di Google Workspace.
Mappa i cicli di vita degli account utente
Gli account utente nel tuo provider di identità esterno seguono un determinato ciclo di vita. In genere, Questo ciclo di vita riflette il rapporto di lavoro tra il dipendente e azienda:
- Viene creato un nuovo account utente per un dipendente che si unisce all'organizzazione.
- L'account utente potrebbe essere temporaneamente sospeso e successivamente riattivati, ad esempio quando il dipendente va in congedo.
- Quando l'utente lascia l'azienda, il suo account viene eliminato oppure lo stato di sospensione per un determinato periodo di conservazione prima di essere in fase di eliminazione.
Il seguente diagramma illustra questo ciclo di vita.
Questa sezione elenca le best practice per garantire che il ciclo di vita degli account utente in Cloud Identity o Google Workspace segua il ciclo di vita degli account utente corrispondenti nel tuo provider di identità esterno.
Specifica l'IdP esterno come fonte attendibile
Molti sistemi informativi HR (HRIS), IdP e adattatori supportano solo la modalità monodirezionale e il provisioning degli utenti. Ciò significa che le modifiche apportate nell'HRIS o nell'IdP propagata a Cloud Identity o Google Workspace, ma cambia eseguite in Cloud Identity o Google Workspace non vengono propagate indietro.
Per evitare incoerenze causate dal provisioning unidirezionale, imposta il tuo un IdP esterno come fonte attendibile. Utilizza esclusivamente il tuo IdP esterno (o HRIS) creare, modificare o eliminare gli utenti e affidarsi al provisioning automatico le modifiche verranno propagate a Google Workspace e Cloud Identity. Se designi il tuo IdP esterno come origine attendibile, limiti il rischio di incoerenze e di avere modifiche manuali sostituite dall'IdP.
Automatizzare il provisioning degli utenti in Cloud Identity o Google Workspace
Per consentire a un dipendente di autenticarsi su Google utilizzando il Single Sign-On: devi prima creare un account utente per il dipendente in Cloud Identity o Google Workspace. Per garantire coerenza con l'IdP esterno, per automatizzare il processo di provisioning di questi account Cloud Identity o Google Workspace:
- Automatizzando il provisioning, puoi assicurarti che Cloud Identity o identità Google Workspace sono sempre un sottoinsieme delle identità nel tuo IdP esterno.
- Riduci al minimo il rischio di introdurre inavvertitamente una mancata corrispondenza tra un'identità in Cloud Identity o Google Workspace e l'identità corrispondente nel tuo provider di identità esterno. Mancata corrispondenza, ad esempio l'errore ortografico accidentale dell'indirizzo email può altrimenti portare i dipendenti problemi di accesso.
- Riduce al minimo il lavoro di amministrazione manuale.
Se utilizzi un HRIS per gestire il processo di onboarding, un modo per automatizzare il provisioning degli utenti consiste nel configurare HRIS in modo che esegua il provisioning degli account utente all'IdP esterno e a Cloud Identity o Google Workspace, ad esempio nel diagramma seguente.
Affinché questa configurazione funzioni correttamente, devi assicurarti che HRIS esegua il provisioning di fatturazione in modo che vengano vengono mappati tra loro. Inoltre, l'HRIS deve gestire la decisione di quali account utente eseguire il provisioning a Cloud Identity o Google Workspace.
Un altro modo per automatizzare il provisioning degli utenti che funziona indipendentemente da un sistema HRIS è utilizzare il tuo IdP esterno come origine attendibile per il provisioning degli utenti in Cloud Identity o Google Workspace. In questa configurazione, per la configurazione mappare gli account utente e set di account utente è gestito nell'IdP o dall'adattatore, come mostra il diagramma seguente.
Se utilizzi Active Directory come tuo provider di identità, puoi duplicare questa configurazione utilizzando Google Cloud Directory Sync. Altri provider di identità come Azure AD o Okta dispongono di adattatori integrati per il provisioning degli utenti in Google Workspace. Poiché Google Workspace e Cloud Identity si basano sulla stessa piattaforma e utilizzano le stesse API, questi adattatori possono essere usati anche per Cloud Identity.
Propagare gli eventi di sospensione a Cloud Identity o Google Workspace
Quando un dipendente lascia l'organizzazione, temporaneamente o definitivamente, ti consigliamo di revocare l'accesso del dipendente ai servizi Google. Se monti l'account utente del dipendente nel tuo provider di identità esterno, revochi la sua capacità di utilizzare il Single Sign-On per autenticarsi su Google, ma l'accesso a tutti i servizi Google potrebbe non essere revocato completamente. Può verificarsi quanto segue:
- Se l'utente di Cloud Identity o Google Workspace ha una sessione del browser attiva, la sessione continuerà a funzionare. Anche i token OAuth che sono già stati ottenuti continueranno a essere validi.
- Se l'utente dispone dei privilegi di super amministratore o se disponi maschere di rete configurate, il dipendente potrebbe essere ancora in grado di accedere utilizzando una password.
- L'account utente potrebbe comunque ricevere notifiche da Google Cloud, inclusi gli avvisi relativi al budget.
- Se all'utente è stata assegnata una licenza Google Workspace, le email continuano a essere recapitati nella casella di posta dell'utente, quest'ultimo continua a essere visualizzato la rubrica e l'utente potrebbe essere ancora indicato come disponibile su Google Google Calendar.
- Se consenti agli utenti di utilizzare app meno sicure, l'utente potrebbe comunque riuscire ad accedere a Gmail, Google Calendar e ad altri dati utilizzando password per le app.
Per revocare completamente l'accesso ai servizi Google, propaga gli eventi di sospensione a Cloud Identity o Google Workspace nei seguenti modi:
Assicurati che ogni volta che un account utente viene sospeso nell'IDP esterno, anche l'account utente corrispondente in Cloud Identity o Google Workspace venga sospeso. La sospensione di un utente in Cloud Identity o Google Workspace termina le sessioni del browser attive, invalida i token e revoca tutto l'altro accesso.
Allo stesso modo, quando riattivi un account utente nel tuo IdP esterno, riattivare anche l'account utente corrispondente Cloud Identity o Google Workspace.
Sospensione di un account utente in Cloud Identity o Google Workspace è un'operazione non distruttiva. Mentre l'account utente è sospeso, i suoi dati vengono conservati, le licenze Google Workspace rimangono collegate e i ruoli assegnati in Google Cloud rimangono invariati.
Propagare gli eventi di eliminazione a Cloud Identity o Google Workspace
Quando un dipendente lascia definitivamente l'organizzazione, puoi decidere di non solo sospendere l'account utente del dipendente nell'IdP esterno, ma anche eliminare li annotino.
Se elimini un account utente nell'IdP esterno, ma non elimini utente di Cloud Identity o Google Workspace corrispondente, di utenti in Cloud Identity e Google Workspace non è più un sottoinsieme degli utenti del tuo IdP esterno. Questo può diventare un problema in futuro se un nuovo dipendente entra nella tua organizzazione e ha lo stesso nome del dipendente che ha lasciato l'azienda. Se crei un account utente nel tuo provider di identità per il nuovo dipendente, potresti riutilizzare il nome utente del vecchio dipendente, con il risultato che il nuovo account utente verrà mappato al vecchio account utente in Cloud Identity o Google Workspace. Di conseguenza, il nuovo dipendente potrebbe ottenere l'accesso ai dati e alle impostazioni del vecchio dipendente.
Puoi evitare i rischi associati agli account utente Cloud Identity o Google Workspace orfani eliminando un utente Cloud Identity o Google Workspace non appena l'account utente corrispondente nella tua IdP viene eliminato.
L'eliminazione di un utente di Cloud Identity o Google Workspace è un'operazione distruttiva che può essere annullata solo entro un determinato periodo di tempo. A seconda dei servizi Google utilizzati dall'utente, l'eliminazione dell'utente potrebbe causare l'eliminazione definitiva dei dati associati e potrebbe quindi non soddisfare i tuoi requisiti di conformità.
Per conservare le impostazioni e i dati dell'utente per un determinato periodo di conservazione prima in modo definitivo, implementa uno dei seguenti approcci:
Ritarda l'eliminazione dell'account utente nell'IdP esterno mantenendolo in stato di sospensione per un determinato periodo di conservazione. Eliminare l'utente sia nell'IdP sia in Cloud Identity o Google Workspace il periodo di conservazione è trascorso.
Quando elimini un account utente nel tuo provider di identità esterno, sospendi l'utente Cloud Identity o Google Workspace corrispondente e modifica il suo indirizzo email principale con un nome che difficilmente causerà un conflitto. Ad esempio, rinomina
alice@example.cominobsolete-yyyymmdd-alice@example.com, doveyyyymmddriflette la data dell'eliminazione nell'IDP esterno. Mantieni l'account utente rinominato in stato di sospensione per un periodo di conservazione ed eliminalo al termine di questo periodo.
Per conservare i dati di Google Workspace per gli utenti sospesi, mantieni la licenza Google Workspace assegnata all'utente o passa a una licenza Utente archiviato per assicurarti che le regole di conservazione di Google Workspace Vault continuino a essere applicate e che i dati dell'utente vengano conservati.
Single Sign-On
Tutti i prodotti Google, inclusi servizi come Google Cloud, Google Ads e YouTube, utilizzano Accedi con Google per autenticare gli utenti. Un servizio avvia il processo di autenticazione reindirizzando un utente a accounts.google.com, dove l'utente vede la schermata di accesso di Google e gli viene chiesto il suo indirizzo email. A seconda del dominio
dell'indirizzo email fornito, l'account utente viene cercato in Gmail, nella directory degli account consumer o, se il dominio corrisponde al suo
dominio principale, secondario o dell'alias,
in un account Cloud Identity o Google Workspace.
Il seguente diagramma illustra questo processo di autenticazione.
Se configuri un account Cloud Identity o Google Workspace per l'utilizzo del Single Sign-On, gli utenti vengono reindirizzati a un provider di identità esterno per l'autenticazione. Quando l'IdP esterno ha completato l'autenticazione, il risultato viene inoltrato nuovamente ad Accedi con Google tramite un'asserzione SAML. Questa asserzione SAML serve come prova di un'autenticazione riuscita. L'asserzione contiene l'indirizzo email dell'utente, e viene firmato dal certificato dell'IdP esterno, in modo che Accedi con Google possa verificarne l'autenticità.
Questa procedura è indicata come accesso singolo avviato dal fornitore di servizi e si applica a tutti gli utenti, ad eccezione dei super amministratori. I super amministratori non vengono mai reindirizzati a un IdP esterno e viene loro chiesta una password.
Alcuni IdP supportano anche il Single Sign-On avviato dall'IdP. In questo modello, l'utente esegue l'autenticazione presso l'IdP esterno e segue un link che rimanda a una come Google Cloud o Google Ads. Se il Single Sign-On è stato attivato per un account Cloud Identity o Google Workspace, tutti gli utenti di quell'account possono utilizzare il Single Sign-On avviato dall'IDP, inclusi i super amministratori.
Riduci al minimo l'insieme di attributi passati nelle asserzioni SAML
Dopo che l'utente si è autenticato presso l'IdP esterno, Cloud Identity o
Google Workspace utilizza l'asserzione SAML passata dall'IdP esterno
per stabilire una sessione. Oltre a convalidarne l'autenticità, questo processo
include l'identificazione dell'utente di Cloud Identity o Google Workspace
corrispondente al valore NameID nell'asserzione SAML.
Il valore NameID dovrebbe contenere l'indirizzo email principale dell'account dell'utente da autenticare. L'indirizzo email è sensibile alle maiuscole. Alias e
indirizzi email alternativi non vengono presi in considerazione.
Per evitare mancate corrispondenze accidentali di ortografia o maiuscole, è meglio eseguire il provisioning automatico degli account utente.
Le asserzioni SAML possono contenere attributi aggiuntivi, ma non vengono considerati durante l'autenticazione. Gli attributi contenenti informazioni quali nome, cognome o appartenenza a gruppi di un utente vengono ignorati perché l'account dell'utente in Cloud Identity o Google Workspace è considerato l'unica fonte di queste informazioni.
Per ridurre al minimo la dimensione delle asserzioni SAML, configura l'IdP in modo che non includa che non sono richiesto da Accedi con Google.
Utilizza google.com come emittente
Le sessioni di Accesso Google non sono limitate a un singolo strumento o dominio. Invece, una volta stabilita una sessione, questa è valida su tutti i servizi Google i servizi che l'utente è stato concesso l'accesso a. Questo elenco di servizi potrebbe includere servizi come Google Cloud e Google Ads, nonché servizi come la Ricerca Google e YouTube.
La natura globale di una sessione si riflette nello scambio del protocollo SAML: per impostazione predefinita, Google utilizza google.com come emittente (elemento Issuer nella richiesta SAML) nelle richieste SAML e si aspetta che le asserzioni SAML specifichino google.com come pubblico (elemento Audience nella risposta SAML).
Puoi modificare questa impostazione predefinita attivando l'opzione Utilizza un emittente specifico per il dominio.
quando configuri il Single Sign-On in Cloud Identity
Google Workspace. Attiva l'opzione Emittente specifico per dominio solo se hai più di un account Cloud Identity o Google Workspace (e quindi più domini) e la tua IdP deve essere in grado di distinguere tra gli accessi avviati da un account Cloud Identity o Google Workspace e da un altro. Quando attivi l'opzione, le richieste SAML utilizzano
google.com/a/DOMAIN come emittente e si aspettano
google.com/a/DOMAIN come pubblico, dove
google.com/a/DOMAIN è il dominio principale dell'account Cloud Identity o Google Workspace.
In tutti gli altri casi, mantieni l'impostazione predefinita per utilizzare google.com come emittente e configura il tuo IdP esterno in modo da specificare google.com come pubblico nelle assertazioni SAML. A seconda del tuo provider di identità, questa impostazione potrebbe essere indicata anche come emittente, identificatore attendibile della terza parte o ID entità.
Allinea la durata delle sessioni Google e delle sessioni dell'IDP
Quando un utente completa la procedura di Single Sign-On ed è stata avviata una sessione stabilito, la sessione Accedi con Google rimane attiva per un determinato periodo nel tempo. Al termine di questo periodo di tempo o se l'utente si disconnette, gli viene chiesto di eseguire nuovamente l'autenticazione ripetendo la procedura di Single Sign-On.
Per impostazione predefinita, la durata della sessione per servizi Google è di 14 giorni. Per gli utenti con una licenza Cloud Identity Premium o Google Workspace Business, puoi modificare la durata predefinita della sessione in un periodo diverso, ad esempio 8 ore.
Puoi controllare la durata della sessione utilizzata da Google Cloud. La sessione Google Cloud si applica alla console Google Cloud e a Google Cloud CLI e ad altri client API. Puoi impostare la durata della sessione Google Cloud in tutti i tipi di account Cloud Identity e Google Workspace.
La maggior parte degli IdP esterni gestisce anche una sessione per gli utenti autenticati. Se la durata della sessione dell'IdP è superiore a quella della sessione di Google, la nuova autenticazione potrebbe avvenire in modo silenzioso. Ciò significa che l'utente viene reindirizzato ma potrebbe non dover inserire di nuovo le credenziali. Riautenticazione silenziosa potrebbero minare l'intenzione di ridurre la durata delle sessioni su Google.
Per garantire che gli utenti debbano inserire di nuovo le credenziali dopo un sessione è scaduta, configura la durata della sessione Google e la sessione dell'IdP in modo che la durata della sessione dell'IdP sia inferiore a quella della sessione Google.
Disattivare l'accesso singolo per gli utenti super amministratori
Per gli utenti super amministratori, l'accesso SSO è facoltativo, quindi possono utilizzare l'accesso SSO quando l'accesso viene avviato dall'IdP, ma può anche accedere utilizzando nome utente e password.
Se non prevedi di utilizzare l'accesso singolo avviato dall'IDP per gli utenti super amministratori, puoi ridurre il rischio seguendo la procedura riportata di seguito:
- Aggiungere un'unità organizzativa dedicata per i super amministratori.
- Assegna un profilo SSO al unità organizzativa che disattiva il Single Sign-On.
In caso contrario, se prevedi di utilizzare il Single Sign-On avviato dall'IdP, assicurati di applicare la verifica post-SSO per gli utenti super amministratore.
Autenticazione a più fattori
L'attivazione del Single Sign-On tra Cloud Identity o Google Workspace e il tuo provider di identità esterno migliora l'esperienza utente per i dipendenti. Gli utenti devono autenticarsi con meno frequenza e non è necessario memorizzare credenziali separate per accedere ai servizi Google.
Tuttavia, consentire agli utenti di autenticarsi senza problemi in servizi ed ambienti significa anche che aumenta il potenziale impatto delle credenziali utente compromesse. Se il nome utente e la password di un utente vengono smarriti o rubati, un malintenzionato potrebbe utilizzare queste credenziali per accedere alle risorse non solo nel tuo ambiente esistente, ma anche in uno o più servizi Google.
Per ridurre il rischio di furto delle credenziali, è meglio utilizzare l'autenticazione multifattoriale per tutti gli account utente.
Applicare l'autenticazione a più fattori per gli utenti
Dopo aver configurato il Single Sign-On per il tuo account Cloud Identity o Google Workspace, gli utenti senza privilegio di super amministratore devono utilizzare il tuo provider di identità esterno per l'autenticazione.
Configurare l'IdP in modo che richieda l'utilizzo di un secondo fattore (ad esempio un server o una chiave USB) per forzare l'applicazione dell'autenticazione a più fattori. ogni volta che viene utilizzato il Single Sign-On a Google.
Se il tuo IdP esterno non supporta l'autenticazione a più fattori, prendi in considerazione abilitare la verifica post-SSO richiedere a Google di eseguire un'ulteriore verifica dopo il ritorno dell'utente mediante l'autenticazione basata sull'IdP esterno.
Evita di utilizzare le maschere di rete, poiché potrebbero essere utilizzate in modo improprio per aggirare l'autenticazione a più fattori per gli utenti.
Imponi l'autenticazione in due passaggi di Google per gli utenti super amministratori
Gli utenti super amministratori non vengono reindirizzati al tuo IdP esterno quando tentano di accedere alla console Google Cloud o ad altri siti Google. Gli utenti super-amministratori, invece, devono autenticarsi tramite nome utente e password.
Poiché gli utenti super amministratori possono autenticarsi tramite nome utente e password, non sono soggetti ai criteri di autenticazione multifattoriale che il tuo provider di identità potrebbe applicare. Per proteggere gli utenti super amministratori, applica l'autenticazione in due passaggi di Google per tutti gli utenti super amministratori.
Gli utenti super-amministratori rientrano in genere in una delle due categorie seguenti:
Utenti super amministratori personalizzati: questi utenti sono personalizzati e destinati all'utilizzo da parte di un singolo amministratore. Ti consigliamo di applicare la verifica in due passaggi a tutti gli utenti super amministratori personalizzati.
Utenti super amministratori di macchine: sebbene sia meglio evitare che questi utenti account, a volte sono necessari per abilitare strumenti come Cloud Directory Sync o l'app Galleria Azure AD per gestire utenti e gruppi in Cloud Identity o Google Workspace.
Limita il numero di utenti super amministratori del computer e prova ad attivare la verifica in due passaggi, se possibile.
Per gli utenti che non utilizzano l'accesso singolo, puoi applicare l'autenticazione in due passaggi su entrambi gli account a livello globale, per unità organizzativa o per gruppo:
Se non esistono utenti super amministratori per la macchina che non possono utilizzare la verifica in due passaggi verifica, è meglio eseguire attivare l'applicazione forzata per tutti gli utenti. Se imposti la verifica in due passaggi per tutti gli utenti, eviti il rischio di perdere utenti per sbaglio.
Se alcuni utenti super-amministratori della macchina non possono utilizzare la verifica in due passaggi, utilizza un gruppo dedicato per controllarla. Crea un nuovo gruppo, attivare l'applicazione forzata per il gruppo e aggiungere tutti i super user pertinenti.
Per maggiori dettagli sull'uso dell'autenticazione in due passaggi per proteggere gli utenti super amministratori, consulta le nostre best practice per la protezione degli account amministratore.
Applica la verifica post-SSO per gli utenti super amministratori
Sebbene agli utenti super amministratori non sia richiesto di utilizzare il Single Sign-On, possono comunque farlo se avviato dall'IdP. Per assicurarti che gli utenti super-amministratori siano sempre soggetti alla verifica in due passaggi, anche se si autenticano tramite l'accesso avviato dall'IDP, attiva le verifiche SSO aggiuntive e la verifica in due passaggi per tutti gli utenti super-amministratori.
Le verifiche SSO aggiuntive potrebbero sembrare ridondanti nei casi in cui il tuo IdP applichi già l'autenticazione a più fattori, ma l'impostazione può contribuire a proteggere gli utenti super-amministratori se il tuo IdP viene compromesso.
Non limitare il Single Sign-On per maschera di rete
Quando configuri il Single Sign-On in Cloud Identity Google Workspace, puoi specificare facoltativamente maschera di rete. Se specifichi una maschera, solo gli utenti con indirizzi IP corrispondenti alla maschera verranno soggetto a Single Sign-On. ad altri utenti viene richiesta la password quando accedi.
Se utilizzi maschere di rete, potresti minare l'autenticazione multifattoriale impostata dal tuo provider di identità esterno. Ad esempio, modificando da posizioni o utilizzando una VPN, un utente potrebbe essere in grado di controllare se la rete o meno. Se applichi l'autenticazione a più fattori all'IdP esterno, questa tattica potrebbe consentire a un utente o a un malintenzionato di aggirare i criteri di autenticazione a più fattori configurati nell'IdP esterno.
Per garantire che l'autenticazione a più fattori venga applicata in modo coerente indipendentemente da la località o l'indirizzo IP dell'utente, evita di limitare il Single Sign-On tramite la maschera di rete.
Per limitare l'accesso alle risorse in base all'indirizzo IP, configura una lista consentita di IP appropriata nel tuo IdP esterno o utilizza l'accesso in base al contesto per Google Cloud e Google Workspace.
Passaggi successivi
- Scopri di più sulle best practice aggiuntive:
- Confronta i pattern per la federazione di un IdP esterno con Google Cloud.