Questo documento presenta best practice e indicazioni che ti aiutano a configurare la federazione in modo coerente e sicuro. Le indicazioni si basano sulle 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, si basano su 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. La configurazione della federazione solitamente comporta 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 un IdP esterno per autenticarsi ai 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 al momento dell'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 annunciare un potenziale rischio per la sicurezza), queste notifiche vengono inviate solo all'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
Per stabilire una mappatura è sufficiente verificare che l'affermazione SAML
fornita dall'IdP a Google contenga un
claim NameID
con un valore che corrisponda all'indirizzo email principale di un
utente Cloud Identity o Google Workspace esistente. L'SP è libera di utilizzare qualsiasi mappatura o logica applicabile per ricavare un reclamo NameID adatto per i suoi 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. L'utilizzo della stessa identità utente in più sistemi federati presenta diversi vantaggi:
Quando gli utenti accedono a uno strumento Google come la console Google Cloud, prima viene loro chiesto di 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 le applicazioni di cui è stato eseguito il deployment on-premise e su Google Cloud devono scambiare dati contenenti le identità utente, eviterai la complessità aggiuntiva di dover mappare gli identificatori utente.
Per ulteriori dettagli sulla mappatura degli utenti di Active Directory o Azure AD a Cloud Identity o Google Workspace, consulta la guida di Active Directory o Azure AD.
Assicurati che le identità utilizzino indirizzi email indirizzabili
Google Cloud utilizza l'indirizzo email principale di un utente per inviare email di notifica. Ecco alcuni esempi di queste notifiche:
Avvisi di budget: se hai configurato un avviso di budget, Google Cloud invia una notifica agli amministratori della fatturazione e agli utenti della fatturazione quando viene superata una soglia di 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 al progetto: se assegni il ruolo Amministratore progetto a un utente che fa parte di un account Cloud Identity o Google Workspace diverso da quello a cui è associata l'organizzazione del progetto, a quell'utente viene inviato un invito. Prima che il ruolo appena concesso possa essere applicato, l'utente deve accettare l'invito facendo clic su un link nel messaggio email.
Risposte alle richieste di assistenza e altre notifiche dell'assistenza.
Se utilizzi Google Workspace e hai configurato correttamente i necessari record MX DNS, tutte le email di notifica inviate all'indirizzo email principale vengono recapitate nella Posta in arrivo di 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. Per assicurarti che gli utenti di Cloud Identity non perdano le notifiche, verifica che il sistema email esistente accetti i messaggi inviati agli indirizzi email principali degli utenti di Cloud Identity e che indirizzi queste email alle caselle postali corrette. Segui questi passaggi:
Assicurati che tutti i domini aggiunti a Cloud Identity abbiano record MX DNS che rimandino al tuo sistema email esistente.
Assicurati che l'indirizzo email principale di un utente Cloud Identity corrisponda a una casella di posta esistente nel tuo sistema email. Se non c'è corrispondenza tra l'indirizzo email principale utilizzato da Cloud Identity e l'indirizzo email dell'utente, configura un alias nel sistema email esistente in modo che le email inviate a ciascun indirizzo email principale vengano inoltrate alla cassetta postale corretta.
Se queste soluzioni non sono pratiche, ti consigliamo di aggiungere Google Workspace al tuo account Cloud Identity esistente e di assegnare le licenze di Google Workspace agli utenti chiave che si occupano della fatturazione o dell'interazione con l'assistenza e che, di conseguenza, hanno maggiori probabilità di 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 mostrare gli account dei consumatori esistenti, consulta 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 cambiare il proprio indirizzo email per utilizzare un dominio diverso.
Per maggiori dettagli su come consolidare gli account consumer esistenti, consulta Valutare le opzioni di consolidamento dell'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 usati dagli utenti prima di iniziare a creare account utente o a configurare l'accesso singolo in Cloud Identity o Google Workspace.
Mappa insiemi di identità
Dopo aver definito la mappatura delle singole identità tra il tuo fornitore di identità esterno e Cloud Identity o Google Workspace, devi determinare l'insieme di identità per cui attivare l'accesso ai servizi Google.
L'insieme effettivo di identità che possono autenticarsi nei servizi Google è l'intersezione di due insiemi:
- Identità esterne che vengono associate a un'identità in Cloud Identity o Google Workspace.
Identità esterne consentite dal tuo IdP esterno per l'accesso singolo 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 su assegnazioni, mentre AD FS utilizza criteri di controllo degli accessi.
Limitare l'insieme di identità che possono autenticarsi nei servizi Google
A seconda di come prevedi di utilizzare Google Cloud, Google Workspace e altri strumenti Google, tutti i dipendenti della tua organizzazione o solo un sottoinsieme devono essere in grado di autenticarsi ai servizi Google.
Se prevedi di concedere l'accesso ai servizi Google solo a un sottoinsieme di dipendenti della tua organizzazione, è meglio limitare l'autenticazione a questo insieme di utenti. Limitando il numero di utenti che possono autenticarsi, crei un ulteriore livello di difesa che è utile nel caso in cui tu abbia configurato accidentalmente una regola di controllo dell'accesso 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 alcun account utente mappato, qualsiasi tentativo di autenticazione da parte di un utente non andrà a buon fine, anche se l'IdP consente all'utente di accedere a Cloud Identity o Google Workspace utilizzando il Single Sign-On.
- Configura il Single Sign-On nel tuo IdP per ridurre al minimo il numero di utenti autorizzati ad accedere a Cloud Identity o 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 dei consumatori
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 già account consumer 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.
- Evita di bloccare inavvertitamente gli account di cui è stata eseguita la migrazione consentendo l'accesso singolo non solo per gli utenti per i quali crei account utente in Cloud Identity o Google Workspace, ma anche per tutti gli account consumer di cui deve essere eseguita la migrazione.
Il seguente diagramma mostra come diversi tipi di identità si sovrappongono e si interrelazionano.
Nel diagramma, le identità con un account utente in Cloud Identity o Google Workspace sono nell'ellisse più piccola (gialla). Questa ellisse è contenuta nella seconda ellisse (blu), che contiene le identità in grado di autenticarsi. La terza e più grande ellisse (grigio) contiene le altre ed è 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 account 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 impiegato di registrarsi a un nuovo account consumer con la stessa identità non andranno a buon fine. Tuttavia, se non esiste ancora un utente corrispondente in Cloud Identity o
Google Workspace, la registrazione di un nuovo account consumer andrà a buon fine.
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 l'indirizzo email aziendale del dipendente come indirizzo email principale o alias, in modo che non sia 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 non hai ancora completato la migrazione degli account dei consumatori, puoi monitorare temporaneamente le registrazioni di nuovi account dei consumatori acquisendo le email di verifica inviate durante la procedura di registrazione. Le email di verifica utilizzano un
indirizzo del mittente della busta corrispondente a *@idverification.bounces.google.com.
Configura un filtro nel tuo sistema email che identifichi le email con questo indirizzo del mittente della busta e le trattenga 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:
- Creazione di un nuovo account utente in Cloud Identity o Google Workspace e utilizzo di un indirizzo email principale che non è mappato a nessun utente nell'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 attivi l'accesso singolo in Cloud Identity o Google Workspace, tutti gli utenti (ad eccezione dei super amministratori) sono obbligati a utilizzare l'accesso singolo. Per un account utente Cloud Identity o Google Workspace che non è mappato a un'identità nella tua IdP esterna, qualsiasi tentativo di utilizzare l'accesso singolo non andrà a buon fine. 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 l'accesso singolo viene disattivato temporaneamente o definitivamente, l'account utente può essere utilizzato di nuovo. 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 nel frattempo l'account utente del precedente impiegato è stato eliminato, è possibile che tu possa assegnare al nuovo impiegato il nome utente che utilizzava l'ex impiegato.
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 sono considerati uguali se entrambi mappano allo stesso 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 identità se non dispongono di una controparte nel tuo IdP esterno.
Prendi in considerazione il seguente esempio: Alice ha un utente super amministratorealice-admin@example.com in Cloud Identity o Google Workspace e non utilizza la verifica in due passaggi. Mallory, che non conosce la password di Alice, trova un modo per creare un nuovo utente nell'IDP esterno che viene mappato a 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 potente insieme di autorizzazioni che si applicano non solo all'account Cloud Identity o 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 assegna le autorizzazioni standard. Questo account deve essere utilizzato quotidianamente per le attività di routine. Crea un secondo account utente con l'identità
alice-admin@example.come assegnati i privilegi di superutente. È buona norma che Alice utilizzi questo account solo per le occasioni in cui sono richiesti i privilegi di super amministratore.Per assicurarti che le email di notifica inviate a questo indirizzo email vengano ricevute nella casella di posta dell'utente, configura Google Workspace o il tuo sistema email esistente in modo che l'indirizzo email
alice-admin@example.comsia un alias o venga inoltrato aalice@example.com.
Assicurati che entrambe le identità siano riconosciute dal tuo provider di identità esterno in modo che l'insieme di identità in Cloud Identity o Google Workspace continui a essere un sottoinsieme delle identità nel tuo provider di identità esterno.
Ti consigliamo di seguire uno schema di denominazione per questi account super amministratore dedicati
in modo da poter monitorare dove e come vengono utilizzati nei log di controllo. 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 agli 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 averlo ricevuto, può eseguire l'accesso per suo conto.
Se l'accesso ad API o servizi non deve essere eseguito per conto di un utente finale, ma per conto dell'applicazione stessa, è meglio utilizzare gli account di servizio Google Cloud per l'autenticazione e poi concedere l'accesso all'account di servizio 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 a livello di 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 l'azienda:
- Viene creato un nuovo account utente per un dipendente che si unisce all'organizzazione.
- L'account utente potrebbe essere sospeso temporaneamente e poi riattivato, ad esempio quando il dipendente va in ferie.
- Quando l'utente lascia l'azienda, il suo account viene eliminato o mantenuto in stato di sospensione per un determinato periodo di conservazione prima di essere eliminato definitivamente.
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.
Designare l'IdP esterno come fonte attendibile
Molti sistemi di informazione sulle risorse umane (HRIS), provider di identità e adattatori supportano solo il provisioning degli utenti in un'unica direzione. Ciò significa che le modifiche apportate nel sistema HR o nell'IDP vengono propagate a Cloud Identity o Google Workspace, ma le modifiche apportate in Cloud Identity o Google Workspace non vengono propagate nuovamente.
Per evitare incoerenze causate dal provisioning unidirezionale, designa la tua IDE esterna come fonte attendibile. Utilizza esclusivamente il tuo provider di identità (o sistema HR) esterno per creare, modificare o eliminare gli utenti e affidati al provisioning automatico per far sì che le modifiche vengano 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 la coerenza con il tuo IdP esterno, è meglio automatizzare il processo di provisioning di questi account utente in Cloud Identity o Google Workspace:
- Automatizzando il provisioning, puoi assicurarti che le identità Cloud Identity o Google Workspace siano sempre un sottoinsieme delle identità nel tuo provider di identità 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. In caso contrario, le mancate corrispondenze, come un errore ortografico accidentale dell'indirizzo email, possono causare problemi di accesso ai dipendenti.
- Riduci al minimo l'impegno di amministrazione manuale.
Se utilizzi un sistema HRIS per gestire la procedura di onboarding, un modo per automatizzare il provisioning degli utenti è configurare il sistema HRIS in modo che esegui il provisioning degli account utente sia per il tuo provider di identità esterno sia per Cloud Identity o Google Workspace, come nel seguente diagramma.
Affinché questa configurazione funzioni correttamente, devi assicurarti che il tuo sistema HRIS preveda account utente in modo che siano correttamente mappati tra loro. Inoltre, il sistema HR deve gestire la decisione su quali account utente eseguire il provisioning in 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, la configurazione per la mappatura degli account utente e dei set di account utente viene gestita nell'IdP o dall'adattatore, come mostrato nel seguente diagramma.
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 utilizzati 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 il suo accesso 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. Tuttavia, possono verificarsi i seguenti problemi:
- 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 hai configurato le maschere di rete, il dipendente potrebbe comunque essere 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 continueranno a essere recapitate nella sua cassetta postale, l'utente continuerà a essere visualizzato nella rubrica e potrebbe essere ancora indicato come disponibile in 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.
Analogamente, quando riattivi un account utente nell'IdP esterno, assicurati di riattivare anche l'account utente corrispondente in Cloud Identity o Google Workspace.
La 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, potresti decidere di non solo sospendere il suo account utente nell'IDP esterno, ma anche eliminarlo.
Se elimini un account utente nel tuo provider di identità esterno, ma non elimini l'utente Cloud Identity o Google Workspace corrispondente, l'insieme di utenti in Cloud Identity e Google Workspace non è più un sottoinsieme di utenti nel tuo provider di identità 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 di eliminarli definitivamente, 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. Elimina l'utente sia nell'IDP sia in Cloud Identity o Google Workspace al termine del periodo di conservazione.
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 questa procedura 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'affermazione contiene l'indirizzo email dell'utente e è firmata dal certificato del provider di identità 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 provider di identità supportano anche il Single Sign-On avviato dall'IdP. In questo modello, l'utente si autentica presso l'IdP esterno e poi segue un link che rimanda a un servizio Google 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 un utente ha eseguito l'autenticazione presso l'IdP esterno, Cloud Identity o
Google Workspace utilizza l'affermazione SAML trasmessa dall'IdP esterno
per stabilire una sessione. Oltre a convalidarne l'autenticità, questo processo include l'identificazione dell'account utente Cloud Identity o Google Workspace corrispondente al valore NameID nell'affermazione SAML.
Il valore NameID dovrebbe contenere l'indirizzo email principale dell'account dell'utente da autenticare. L'indirizzo email è sensibile alle maiuscole. Gli alias e gli 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 le dimensioni delle asserzioni SAML, configura l'IdP in modo che non includa attributi non richiesti da Accesso Google.
Utilizza google.com come emittente
Le sessioni di Accesso Google non sono limitate a un singolo strumento o dominio. Al contrario, una volta stabilita, la sessione è valida per tutti i servizi Google a cui l'utente è stato concesso l'accesso. 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 questo valore predefinito attivando l'opzione Utilizza un emittente specifico per il dominio quando configuri il Single Sign-On in Cloud Identity o 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.DOMAIN
In tutti gli altri casi, mantieni l'impostazione predefinita per utilizzare google.com come emittente
e configura l'IdP esterno in modo da specificare google.com come pubblico nelle assertigoogle.com di 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 ha completato la procedura di accesso singolo ed è stata stabilita una sessione, la sessione di accesso Google rimane attiva per un determinato periodo di 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, nonché 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. In altre parole, l'utente viene reindirizzato all'IdP, ma potrebbe non dover inserire di nuovo le credenziali. La re-autenticazione silenziosa potrebbe minare l'intento di abbreviare la durata delle sessioni di Google.
Per assicurarti che gli utenti debbano inserire di nuovo le proprie credenziali dopo la scadenza di una sessione Google, configura la durata della sessione Google e la durata della sessione IdP in modo che la durata della sessione 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: possono utilizzarlo quando l'accesso viene avviato dall'IdP, ma possono 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:
- Aggiungi un'unità organizzativa dedicata per i super amministratori.
- Assegna un profilo SSO all'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 meno di frequente e non devono 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.
Configura l'IdP in modo che richieda l'utilizzo di un secondo fattore (ad esempio un codice monouso o una chiave USB) per applicare l'autenticazione a più fattori ogni volta che viene utilizzato il Single Sign-On a Google.
Se il tuo provider di identità esterno non supporta l'autenticazione multifattoriale, ti consigliamo di attivare la verifica post-SSO per consentire a Google di eseguire un'ulteriore verifica dopo che l'utente è tornato dall'autenticazione con il tuo provider di identità 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.
Applicare 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 amministratore personalizzati.
Utenti super amministratori della macchina: anche se è meglio evitare questi account utente, a volte sono necessari per consentire a strumenti come Cloud Directory Sync o all'app Galleria di Azure AD di 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 hai utenti super amministratori della macchina che non possono utilizzare la verifica in due passaggi, è meglio 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, attiva l'applicazione per il gruppo e aggiungi tutti i super utenti pertinenti.
Per ulteriori dettagli sull'utilizzo dell'autenticazione in due passaggi per proteggere gli utenti super amministratore, consulta le nostre best practice per la sicurezza degli account amministratore.
Applicare 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 in base alla maschera di rete
Quando configuri l'accesso singolo in Cloud Identity o Google Workspace, puoi specificare facoltativamente una maschera di rete. Se specifichi una maschera, solo gli utenti con indirizzi IP corrispondenti alla maschera sono soggetti all'accesso singolo. Gli altri utenti vengono invitati a inserire una password al momento dell'accesso.
Se utilizzi maschere di rete, potresti minare l'autenticazione multifattoriale impostata dal tuo provider di identità esterno. Ad esempio, cambiando località o utilizzando una VPN, un utente potrebbe essere in grado di controllare se la maschera di rete viene applicata 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 dalla posizione o dall'indirizzo IP di un utente, evita di limitare il Single Sign-On in base alla 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 altre best practice:
- Confronta i pattern per la federazione di un IdP esterno con Google Cloud.