Questo documento presenta best practice e indicazioni utili per configurare della 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. Invece di creare e mantenere manualmente account utente nel Cloud Identity o Google Workspace per ciascun dipendente, puoi federare Cloud Identity o Google Workspace con il tuo provider di identità (IdP) esterno come Active Directory o Azure Active Directory. Configurazione della federazione prevede in genere quanto segue:
- Il provisioning automatico degli account utente pertinenti fonte autorevole esterna Cloud Identity o Google Workspace.
- Consentire agli utenti di utilizzare un IdP esterno per l'autenticazione nei servizi Google.
Mappatura delle identità
L'identità di un account utente gestito da Cloud Identity. Google Workspace sia definito dal suo indirizzo email principale. L'indirizzo email principale è indicato come indirizzo email dell'Account Google nella Pagina Account Google. Per essere considerato valido, l'indirizzo email principale deve utilizzare uno dei domini che hai aggiunto a Cloud Identity o Google Workspace .
Inoltre, l'indirizzo email principale ha i seguenti scopi:
- L'indirizzo email principale è il nome utente che un utente deve fornire quando eseguendo l'accesso. Anche se gli utenti possono aggiungere indirizzi email o alias alternativi al proprio account utente Google, questi indirizzi non sono considerati identità e non può essere utilizzato per eseguire l'accesso.
- Quando un amministratore deve inviare notifiche agli utenti (ad esempio, per segnalare un potenziale rischio per la sicurezza), le notifiche vengono inviate al solo l'indirizzo email principale.
Per configurare il servizio Single Sign-On e il provisioning automatico degli utenti tra Google e devi mappare le identità al tuo IdP esterno di identità in Cloud Identity o Google Workspace. Le seguenti le sezioni 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.
Molti IdP si affidano agli indirizzi email Conforme a RFC 822 per identificare gli utenti. Ecco alcuni esempi:
- L'attributo
userPrincipalNamein Active Directory è un indirizzo RFC nome conforme alla versione 822 che identifica in modo univoco un utente e che può essere utilizzato per: accedi a Windows o ad 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 dall'IdP esterno si affidano già a un indirizzo email la loro identità, puoi utilizzare la stessa identità dell'indirizzo email principale Cloud Identity o Google Workspace. Utilizzare la stessa identità utente sistemi federati offre diversi vantaggi:
Quando gli utenti accedono a uno strumento Google come Console Google Cloud, viene prima chiesto di fornire l'indirizzo email principale di Cloud Identity o Google Workspace prima che viene reindirizzato all'IdP esterno. A seconda dell'IdP, l'utente potrebbe verrà visualizzata un'altra schermata di accesso che richiede il nome utente e password.
Se gli indirizzi email sono diversi per questi passaggi, la sequenza di accesso le schermate possono facilmente confondere gli utenti finali. Al contrario, se gli utenti possono utilizzare una un'identità comune in tutti i passaggi, non sono esposti ai requisiti tecnici le differenze tra gli IdP, che riducono al minimo la potenziale confusione.
Se non devi mappare tra le identità utente, è più facile correlare gli audit log di Google Cloud con quelli di 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 di budget.
Notifiche di pagamento: eventuali notifiche o avvisi relativi ai pagamenti vengono inviati agli indirizzi email di utenti pagamenti configurate 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 .
Risposte alle richieste di assistenza e altre notifiche dell'assistenza.
Se utilizzi Google Workspace e hai configurato correttamente i necessari 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 inoltre di email di notifica, ma quest'ultima deve essere gestita dal tuo indirizzo email esistente. dell'infrastruttura. 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 registri a Cloud Identity Google Workspace, è possibile che i tuoi dipendenti abbiano utilizzato per accedere a questi servizi.
Consentire ai dipendenti di utilizzare gli 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 consumatore così come sono, accettando 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 le influenze degli account consumatore 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.
Mappatura di 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 mappare 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 Single Sign-On varia a seconda dell'IdP che usi. 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 eseguire l'autenticazione su Google nei seguenti casi: 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 consente all'utente di accedere 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 dall'eventuale presenza di account consumer di cui occorre 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 oppure Google Workspace solo se non hai creato un account utente con lo stesso in Cloud Identity o Google Workspace.
Se hai account consumer esistenti di cui prevedi ancora di eseguire la migrazione, di fare attenzione a non creare accidentalmente account utente in conflitto. Segui queste linee guida:
- Limita l'autenticazione creando una nuova identità Cloud Identity oppure Google Workspace solo per gli utenti che ne hanno bisogno e sono è noto per non disporre di un account consumatore.
- 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 e più grande ellisse (grigio) contiene le altre e è costituito dalle identità che dispongono di un account utente nel tuo IdP. Per maggiori dettagli su su come configurare Active Directory, Azure AD o Okta, consulta il nostro guida separata alle best practice.
Previeni la creazione di nuovi account consumer
Aggiungi un dominio, ad esempio example.com, a Cloud Identity
L'account Google Workspace non impedisce ai dipendenti di registrarsi a nuovi
e account consumer che usano lo stesso dominio. Questi nuovi account consumer
vengono visualizzati come utenti non gestiti in Cloud Identity
Google Workspace, ma non sono autorizzati a usare Single Sign-On o
qualsiasi altra configurazione applicata a Cloud Identity
Account 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 l'utente alice@example.com nel tuo
Cloud Identity o Google Workspace, ogni tentativo
che un dipendente crei un nuovo account consumer con la stessa identità
non riuscito. 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 altri account consumer di cui eseguire la migrazione a Cloud Identity, impedire la creazione di nuovi account consumer applicando la seguente configurazione:
Limita l'autenticazione consentendo solo agli utenti pertinenti di usare un singolo accedi a Cloud Identity o Google Workspace.
Eseguire il provisioning di 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 gli account utente non abilitati per il Single Sign-On in un sospeso.
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 una revisione interna.
Rendi le identità Cloud Identity o Google Workspace un sottoinsieme delle identità nel tuo IdP esterno
Il tuo account Cloud Identity o Google Workspace potrebbe contenere account utente con identità che non sono mappate ad alcun utente nel tuo IdP esterno. Esistono due scenari tipici che possono comportare la creazione di 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 oppure Google Workspace mappato su un'identità nel tuo IdP esterno, e poi elimini l'identità nell'IdP esterno. Ad esempio, potresti elimina 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 è effettivamente inutilizzabile, ma potrebbe comunque rappresentare un rischio, nelle seguenti situazioni:
Se a un certo punto il Single Sign-On viene disattivato temporaneamente o definitivamente, l'account utente può essere riutilizzato. Ciò potrebbe consentire a un ex dipendente di accedere e accedere alle risorse aziendali.
Il nome dell'account utente eliminato potrebbe essere riutilizzato. Ad esempio, un di un dipendente che si unisce all'azienda potrebbe condividere lo stesso nome con un un dipendente che ha lasciato l'azienda mesi o anni prima. Se l'esperienza utente 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 quella 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 utilizzare il Single Sign-On, ma possono comunque utilizzare il Single Sign-On, quando viene avviato dall'IdP. Possibilità di utilizzare Il Single Sign-On avviato dall'IdP rende gli utenti super amministratori sensibili allo squatting dei nomi se non dispongono di una controparte nell'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. Questo account utente appena creato potrebbe
avere privilegi speciali e non avere alcuna attinenza con l'account utente di Alice,
che ora condivide un'identità comune con l'account super amministratore di Alice
consente a Mallory di utilizzare il servizio Single Sign-On avviato dall'IdP e di autenticarsi
alice-admin@example.com.
Per ridurre il rischio di "name-squatting", assicurati che il tuo Le identità di Cloud Identity o Google Workspace sono un sottoinsieme nel tuo IdP esterno. Il modo migliore per raggiungere questo obiettivo è mappare l'intero ciclo di vita dell'account utente implementato dall'IdP esterno al ciclo di vita dell'account utente 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, quando possibile è meglio limitare il numero di amministratori con come super amministratore e per utilizzare account utente con meno privilegi per l'amministrazione giornaliera dell'account o dell'organizzazione Google Cloud.
Una volta identificati gli amministratori che richiedono l'accesso come super amministratore, Creare account utente per 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 identità
alice-admin@example.come e assegnargli i privilegi di super user. È 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. Per
Ad esempio, aggiungi -admin al nome utente, come nell'esempio precedente.
Limitare il numero di utenti dei servizi 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 migliore su Google Cloud per abilitare un'applicazione eseguire l'autenticazione e accedere alle API di Google è implementare uno dei seguenti approcci:
Un'applicazione o uno strumento web che richiede l'accesso alle API o ai servizi Google per conto di un utente finale deve utilizzare OAuth 2.0 o OpenID Connect. Utilizzando uno di questi protocolli, l'applicazione richiede innanzitutto la fine il consenso dell'utente ad accedere ai suoi dati e, quando riceve il consenso, in grado di 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 concessi 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 alle API al di fuori di Google Cloud, ad esempio API Directory o l'API Drive, puoi utilizzare Delega a livello di dominio Google Workspace.
Con la delega a livello di dominio di Google Workspace, attivi un servizio per agire per conto di Cloud Identity o Google Workspace utente. Poiché la delega è un privilegio importante, ti consigliamo di usare Delega a livello di dominio Google Workspace solo nei casi in cui OAuth non è pratico.
Usa un utente di Cloud Identity o Google Workspace dedicato per ogni Account di servizio Google Cloud abilitato per Google Workspace delega a livello di dominio. Crea questo utente nel tuo IdP esterno ed esegui il provisioning a Cloud Identity o Google Workspace per far sì che l'insieme di utenti in Cloud Identity o Google Workspace continua a essere sottoinsieme di utenti del tuo IdP esterno.
Evita di creare utenti del servizio in Cloud Identity e Google Workspace che non intendi utilizzare per Google Workspace delega a livello di dominio.
Mappare i cicli di vita degli account utente
Gli account utente nell'IdP 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 dell'utente in Cloud Identity o Google Workspace segue ciclo di vita degli account utente corrispondenti nell'IdP 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. Di designando l'IdP esterno come fonte attendibile, si limita il rischio incoerenze e la necessità di far ignorare le modifiche manuali da parte dell'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.
- Ridurre al minimo il rischio di introdurre inavvertitamente una mancata corrispondenza tra in Cloud Identity o Google Workspace e e l'identità corrispondente nel tuo IdP esterno. Mancata corrispondenza, ad esempio un errore di ortografia 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 in modo indipendente da un HRIS è utilizzare l'IdP esterno come fonte autorevole 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 IdP, puoi duplicare questa configurazione utilizzando Google Cloud Directory Sync. Altri IdP, ad esempio 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. Di sospendere l'account utente del dipendente nell'IdP esterno, revochi di utilizzare il Single Sign-On per l'autenticazione su Google, ma questo potrebbe non revocare completamente l'accesso a tutti i servizi Google. Può verificarsi quanto segue:
- Se l'utente di Cloud Identity o Google Workspace ha un sessione del browser attiva, la sessione continuerà a funzionare. Qualsiasi token OAuth già ottenute continueranno a essere valide.
- 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, tra cui 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 consentire agli utenti di utilizzare app meno sicure, l'utente potrebbe essere ancora in grado di accedere a Gmail, e 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, l'account utente corrispondente in Cloud Identity Anche Google Workspace è stato sospeso. Sospensione di un utente in Cloud Identity o Google Workspace termina il browser attivo sessioni, invalida i token e revoca tutti gli altri accessi.
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, vengono conservati, le licenze Google Workspace rimangono allegate e assegnate i ruoli 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. Ciò può trasformarsi in un problema in futuro se un nuovo dipendente si unisce al tuo che ha lo stesso nome del dipendente che ha lasciato dell'azienda. Se crei un account utente nell'IdP per il nuovo dipendente, potrebbe riutilizzare il nome utente del precedente dipendente, con conseguente mappatura del nuovo account utente all'account utente precedente in Cloud Identity o Google Workspace. Come il nuovo dipendente potrebbe accedere ai dati dell'ex dipendente e impostazioni.
Puoi evitare i rischi associati a Cloud Identity orfano o di account utente Google Workspace eliminando un'identità Cloud Identity all'utente di Google Workspace non appena l'account utente corrispondente nella tua IdP eliminato.
L'eliminazione di un utente di Cloud Identity o Google Workspace è operazione distruttiva che può essere annullata solo all'interno di un determinato periodo di tempo. A seconda dei servizi Google utilizzati dall'utente, l'eliminazione dell'utente potrebbe causano l'eliminazione definitiva dei dati associati e potrebbero quindi non soddisfare per soddisfare i 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 mantenendo il utente in stato di sospensione per un determinato periodo di conservazione. Eliminare l'utente sia nell'IdP sia in Cloud Identity/Google Workspace il periodo di conservazione è trascorso.
Quando elimini un account utente dall'IdP esterno, sospendi utente di Cloud Identity o Google Workspace corrispondente cambiare il suo indirizzo email principale con un nome che probabilmente causi in conflitto. Ad esempio, rinomina
alice@example.cominobsolete-yyyymmdd-alice@example.comdoveyyyymmddriflette la data di per eseguire l'eliminazione nel tuo IdP esterno. Mantieni l'account utente rinominato in un stato sospeso per un periodo di conservazione ed eliminarlo dopo il periodo di conservazione del periodo di tempo trascorso.
Per conservare i dati di Google Workspace per gli utenti sospesi, mantieni il una licenza Google Workspace assegnata all'utente oppure passare a una licenza Utente archiviato per garantire che Regole di conservazione di Google Workspace Vault continuano ad applicare e che i dati dell'utente vengono 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
Reindirizzamento di un utente a accounts.google.com, dove l'utente vede l'account Google
schermata di accesso e viene richiesto l'indirizzo e-mail. In base al dominio
dell'indirizzo email fornito, l'account utente viene quindi cercato in Gmail,
della directory dell'account consumer o se il dominio corrisponde
dominio principale, secondario o alias,
in un account Cloud Identity o Google Workspace.
Il seguente diagramma illustra questo processo di autenticazione.
Se configurare un account Cloud Identity o Google Workspace per utilizzare il Single Sign-On, gli utenti vengono reindirizzati a un IdP esterno per l'autenticazione. Quando l'interfaccia utente L'IdP ha completato l'autenticazione, il risultato viene inoltrato nuovamente a Google Accedere tramite un'asserzione SAML. Questa asserzione SAML serve come prova una corretta autenticazione. 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 è definita service-provider-managed single-avvied dal fornitore di servizi e si applica a tutti gli utenti tranne ai super amministratori. I super amministratori sono non vengono mai reindirizzati a un IdP esterno e viene richiesta 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 abilitati per un account Cloud Identity o Google Workspace, agli utenti di tale account è consentito utilizzare il servizio Single Sign-On avviato dall'IdP, inclusi 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 deve contenere l'indirizzo email principale dell'utente
dell'account da autenticare. L'indirizzo email è sensibile alle maiuscole. Alias e
indirizzi email alternativi non vengono presi in considerazione.
Per evitare errori di ortografia o maiuscole/minuscole accidentali, è consigliabile eseguire automaticamente il provisioning degli account utente.
Le asserzioni SAML possono contenere attributi aggiuntivi, ma non considerati durante l'autenticazione. Attributi contenenti informazioni come nome, cognome o iscrizione a gruppi dell'utente vengono ignorati perché le sue in Cloud Identity o Google Workspace è considerato l'unica fonte per queste informazioni utente.
Per ridurre al minimo la dimensione delle asserzioni SAML, configura l'IdP in modo che non includa alcuna che non sono richiesto da Accedi con Google.
Utilizza google.com come emittente
Le sessioni Accedi con 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 di protocollo SAML:
per impostazione predefinita, Google utilizza google.com come emittente (l'elemento Issuer nella
SAML) nelle richieste SAML e si aspetta che le asserzioni SAML specifichino
google.com come pubblico (l'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 specifica per il dominio solo se
avere più di un account Cloud Identity o Google Workspace (e
pertanto più domini) e l'IdP deve poter distinguere tra
accessi avviati da un'identità Cloud Identity o Google Workspace
tra un altro account e un altro. Quando attivi l'opzione, le richieste SAML utilizzano
google.com/a/DOMAIN come emittente e prevede
google.com/a/DOMAIN come pubblico, dove
DOMAIN è il dominio principale di
un account Cloud Identity o Google Workspace.
In tutti gli altri casi, mantieni l'impostazione predefinita per utilizzare google.com come emittente
e configurare l'IdP esterno per specificare google.com come pubblico in SAML
le asserzioni. A seconda dell'IdP, questa impostazione potrebbe essere chiamata anche
emittente, identificatore di attendibilità della parte coinvolta o ID entità.
Allinea la lunghezza 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. Allo scadere di questo periodo di tempo o se l'utente si disconnette, l'utente di eseguire nuovamente l'autenticazione ripetendo il processo Single Sign-On.
Per impostazione predefinita, la durata della sessione per servizi Google è di 14 giorni. Per gli utenti con un la licenza di Cloud Identity Premium o Google Workspace Business, lattina modificare la durata predefinita della sessione in un periodo diverso, ad esempio 8 ore.
Puoi per 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 delle sessioni di Google Cloud in tutte le istanze di Cloud Identity Tipi di account Google Workspace.
La maggior parte degli IdP esterni gestisce anche una sessione per gli utenti autenticati. Se della sessione dell'IdP è superiore a quella della sessione Google, la riautenticazione potrebbe essere eseguita automaticamente. 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.
Disabilita il Single Sign-On 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 il servizio Single Sign-On avviato dall'IdP per gli utenti con privilegi di super amministratore, puoi ridurre i rischi con la seguente procedura:
- 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 servizio Single Sign-On avviato dall'IdP, assicurati di applicare la verifica post-SSO per gli utenti super amministratori.
Autenticazione a più fattori
Abilitare il Single Sign-On tra Cloud Identity Google Workspace e l'IdP esterno migliorano l'esperienza utente dipendenti. Gli utenti devono autenticarsi con meno frequenza e non è necessario memorizzare credenziali separate per accedere ai servizi Google.
Consentendo agli utenti di eseguire l'autenticazione senza interruzioni tra servizi e ambienti significa anche che il potenziale impatto delle credenziali utente compromesse aumenta. 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, anche in uno o più servizi Google.
Per ridurre il rischio di furto di credenziali, è preferibile usare l'autenticazione multi-fattore l'autenticazione automatica per tutti gli account utente.
Applicare l'autenticazione a più fattori per gli utenti
Dopo aver configurato il Single Sign-On per Cloud Identity o Account Google Workspace, gli utenti senza privilegio di super amministratore devono utilizzare dell'IdP esterno per eseguire 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 ulteriori verifiche dopo il ritorno dell'utente mediante l'autenticazione basata sull'IdP esterno.
Evita di utilizzare maschere di rete, perché potrebbero essere utilizzate in modo illecito come modo per aggirare l'autenticazione multi-fattore. 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. Agli utenti super amministratori viene invece chiesto di autenticarsi con nome utente e password.
Poiché gli utenti super amministratori possono autenticarsi con nome utente e password, non sono soggetti ai criteri di autenticazione a più fattori che l'IdP 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 in genere rientrano in una di queste due categorie:
Utenti super amministratori personalizzati: sono utenti personalizzati e utilizzabili da 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 della macchina e prova ad abilitare la verifica in due passaggi la verifica, se possibile.
Per gli utenti che non utilizzano il Single Sign-On, puoi applicare l'autenticazione in due passaggi in un 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 applichi la verifica in due passaggi a tutti gli utenti, eviterai il rischio di perdere accidentalmente degli utenti.
Se hai degli utenti super amministratori della macchina che non possono utilizzare la verifica in due passaggi verifica in due passaggi, utilizza un gruppo dedicato per controllare la verifica in due passaggi. 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
Nonostante gli utenti super amministratori non siano tenuti a utilizzare il Single Sign-On, possono comunque autorizzati a utilizzare il servizio Single Sign-On quando viene avviato dall'IdP. A assicurare che gli utenti super amministratori siano sempre soggetti alla verifica in due passaggi, anche se eseguire l'autenticazione tramite accesso avviato dall'IdP, attivare verifica SSO aggiuntive e verifica in due passaggi per tutti gli utenti super amministratori.
Le verifiche SSO aggiuntive potrebbero sembrare ridondanti nei casi in cui l'IdP applica già l'autenticazione a più fattori, ma l'impostazione può essere utile 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 oppure 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 le maschere di rete, potresti indebolire l'architettura dell'autenticazione applicata dall'IdP 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 a livello esterno IdP, questa tattica potrebbe consentire a un utente o a un utente 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 un'istanza alla lista consentita di IP dell'IdP esterno accesso sensibile al contesto per Google Cloud e Google Workspace.
Passaggi successivi
- Scopri altre best practice:
- Confronta per federare un IdP esterno con Google Cloud.