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, inclusi Google Cloud, Google Marketing Platform e Google Ads, si basano su Google Sign-In 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 in genere comporta quanto segue:
- Eseguire automaticamente il provisioning degli account utente pertinenti da un'origine autorevole esterna a Cloud Identity o Google Workspace.
- Consentire agli utenti di utilizzare un IdP esterno per l'autenticazione ai servizi Google.
Mappa identità
L'identità di un account utente gestito da Cloud Identity o Google Workspace è definita dal suo indirizzo email principale. L'indirizzo email principale è indicato come 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 a questi scopi:
- L'indirizzo email principale è il nome utente che un utente deve fornire quando accede. Sebbene gli utenti possano aggiungere indirizzi email alternativi o alias 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 IdP esterno, devi mappare le identità nel tuo IdP esterno alle identità corrispondenti in Cloud Identity o Google Workspace. Le sezioni seguenti descrivono le best practice per stabilire questo mapping.
Utilizzare la stessa identità in tutti i sistemi federati
Per stabilire una mappatura è sufficiente verificare che l'asserzione SAML
fornita dall'IdP a Google contenga un
rivendicazione NameID
con un valore che corrisponda all'indirizzo email principale di un utente
Cloud Identity o Google Workspace esistente. Il provider di identità è libero di utilizzare
qualsiasi mappatura o logica applicabile per derivare un'attestazione NameID adatta per
i suoi utenti esistenti.
Molti IdP si basano su indirizzi email (o più in generale, su nomi conformi a RFC 822) per identificare gli utenti. Alcuni esempi sono:
- L'attributo
userPrincipalNamein Active Directory è un nome conforme a RFC 822 che identifica in modo univoco un utente e che può essere utilizzato per accedere 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 dal tuo IdP esterno si basano già su un indirizzo email come identità, puoi utilizzare la stessa identità come indirizzo email principale in Cloud Identity o Google Workspace. L'utilizzo della stessa identità utente in tutti i sistemi federati presenta diversi vantaggi:
Quando gli utenti accedono a uno strumento Google come la consoleGoogle Cloud , viene chiesto loro di fornire l'indirizzo email principale del proprio utente Cloud Identity o Google Workspace prima di essere reindirizzati al tuo IdP esterno. A seconda dell'IdP, all'utente potrebbe essere presentata un'altra schermata di accesso che richiede il nome utente e la password.
Se gli indirizzi email sono diversi per questi passaggi, la sequenza di schermate di accesso può confondere facilmente 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 correlare i log di controllo 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 identità utente, eviti la complessità aggiuntiva di dover mappare gli identificatori utente.
Per maggiori dettagli sul mapping degli utenti di Active Directory o Azure AD a Cloud Identity o Google Workspace, consulta la guida Active Directory o Azure AD.
Assicurati che le identità utilizzino indirizzi email instradabili
Google Cloud utilizza l'indirizzo email principale di un utente per inviare email di notifica. Ecco alcuni esempi di queste notifiche:
Avvisi relativi al budget: se hai configurato un avviso relativo al budget, Google Cloud invia una notifica agli amministratori della fatturazione e agli utenti della fatturazione quando viene superata una soglia del budget.
Notifiche di pagamento: tutte le notifiche o gli 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, viene inviato un invito all'utente. Prima che il ruolo appena concesso possa entrare in vigore, 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 record MX DNS necessari, tutte le email di notifica inviate all'indirizzo email principale vengono recapitate alla 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 Cloud Identity non perdano le notifiche, verifica che il tuo sistema di posta esistente accetti i messaggi inviati agli indirizzi email principali degli utenti Cloud Identity e che li indirizzi alle caselle postali corrette. Segui questi passaggi:
Assicurati che tutti i domini aggiunti a Cloud Identity abbiano record MX DNS che puntano al tuo sistema di posta esistente.
Assicurati che l'indirizzo email principale di un utente Cloud Identity corrisponda a una casella di posta esistente nel tuo sistema email. Se esiste una mancata corrispondenza tra l'indirizzo email principale utilizzato da Cloud Identity e l'indirizzo email dell'utente, configura un alias nel tuo sistema di posta esistente in modo che le email inviate a ogni indirizzo email principale vengano indirizzate alla casella di posta corretta.
Se queste soluzioni non sono pratiche, valuta la possibilità di aggiungere Google Workspace al tuo account Cloud Identity esistente e assegnare licenze Google Workspace agli utenti chiave responsabili della fatturazione o dell'interazione con l'assistenza e che, pertanto, 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 i tuoi dipendenti abbiano utilizzato account privati per accedere a questi servizi.
Consentire ai dipendenti di utilizzare account consumer per scopi aziendali può essere rischioso. Per ulteriori dettagli su quali sono questi rischi e su come puoi visualizzare gli account consumatore esistenti, consulta Valutazione degli Account Google esistenti.
Puoi gestire gli account consumer esistenti nei seguenti modi:
- Mantieni gli account consumer così come sono, accettando i potenziali rischi.
- Migra gli account a Cloud Identity o Google Workspace avviando un trasferimento.
- Forza 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, vedi Valutazione delle opzioni di consolidamento dell'identità.
Il modo in cui decidi di gestire gli account consumer influisce su come e in quale sequenza configuri la federazione. Valuta gli account consumer esistenti utilizzati dai tuoi utenti prima di iniziare a creare account utente o configurare il Single Sign-On in Cloud Identity o Google Workspace.
Mappare i set di identità
Dopo aver definito la mappatura delle singole identità tra il tuo IdP 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 ai servizi Google è l'intersezione di due insiemi:
- Identità esterne che corrispondono a un'identità in Cloud Identity o Google Workspace.
Identità esterne che il tuo IdP esterno consente per il single sign-on a Cloud Identity o Google Workspace.
La procedura per controllare chi è autorizzato a utilizzare il Single Sign-On varia a seconda dell'IdP utilizzato. Ad esempio, Azure AD si basa sulle assegnazioni, mentre AD FS utilizza i criteri di controllo dell'accesso.
Limitare l'insieme di identità che possono autenticarsi ai 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 di questi devono essere in grado di autenticarsi ai servizi Google.
Se prevedi di concedere l'accesso ai servizi Google solo a un sottoinsieme dei dipendenti della tua organizzazione, è consigliabile limitare l'autenticazione a questo insieme di utenti. Limitando il numero di utenti che possono autenticarsi, stabilisci un ulteriore livello di difesa che ti aiuta nel caso in cui tu abbia configurato accidentalmente una regola di controllo dell'accesso troppo blanda.
Puoi limitare l'insieme di utenti che possono autenticarsi su Google nei seguenti modi:
- Ridurre al minimo il numero di account utente in Cloud Identity o Google Workspace. Se non esiste un account utente mappato, qualsiasi tentativo di autenticazione da parte di un utente non andrà a buon fine, anche se il provider di identità 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 che possono accedere a Cloud Identity o Google Workspace.
L'approccio migliore per la tua situazione dipende dal fatto che tu abbia account consumer esistenti 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 prevedi ancora di 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 che non hanno un account consumer esistente.
- Evita 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 account utente in Cloud Identity o Google Workspace, ma anche per tutti gli account consumer di cui non è ancora stata eseguita la migrazione.
Il seguente diagramma mostra come si sovrappongono e si interrelazionano i diversi tipi di identità.
Nel diagramma, le identità con un account utente in Cloud Identity o Google Workspace si trovano nell'ellisse più piccola (gialla). Questa ellisse è contenuta nella seconda ellisse (blu), che contiene le identità in grado di autenticarsi. La terza ellisse, la più grande (grigia), 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 separata alle best practice.
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 per 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 il Single Sign-On 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, qualsiasi tentativo di
un dipendente di registrarsi a un nuovo account consumer con la stessa identità
non andrà 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 da migrare a Cloud Identity, impedisci la registrazione di nuovi account consumer applicando la seguente configurazione:
Limita l'autenticazione consentendo solo agli utenti pertinenti di utilizzare il Single Sign-On per Cloud Identity o Google Workspace.
Esegui il provisioning di 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 gli account utente per cui non è attivato il Single Sign-On in uno stato sospeso.
Il seguente diagramma mostra questa configurazione.
Se stai ancora eseguendo la migrazione degli account consumer, puoi monitorare temporaneamente le nuove registrazioni di account consumer acquisendo le email di verifica inviate durante la procedura di registrazione. Le email di verifica utilizzano un
indirizzo del mittente della busta che corrisponde a *@idverification.bounces.google.com.
Configura un filtro nel tuo sistema di posta elettronica che identifichi le email con questo indirizzo
mittente della busta e le metta in attesa per la 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 corrispondono a nessun utente nel tuo IdP esterno. Esistono due scenari tipici che possono portare alla creazione di questi account utente:
- Crea un nuovo account utente in Cloud Identity o Google Workspace e utilizza un indirizzo email principale che non corrisponde a nessun utente nel tuo IdP esterno.
- Hai un account utente in Cloud Identity o Google Workspace che esegue il mapping 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 o Google Workspace, tutti gli utenti (ad eccezione dei super amministratori) sono obbligati a utilizzare il Single Sign-On. Per un account utente Cloud Identity o Google Workspace che non è mappato a un'identità nel tuo IdP esterno, qualsiasi tentativo di utilizzare il Single Sign-On non andrà a buon fine. Un account utente senza una controparte è effettivamente 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 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 di un altro dipendente che ha lasciato l'azienda mesi o anni prima. Se l'account utente del precedente dipendente è stato nel frattempo eliminato, è possibile che tu possa assegnare al nuovo dipendente il nome utente che il precedente dipendente utilizzava in precedenza.
L'account utente del nuovo dipendente potrebbe avere un ID interno diverso da quello del dipendente precedente. Tuttavia, dal punto di vista della federazione, i due account utente sono considerati uguali se entrambi vengono mappati allo stesso indirizzo email principale in Cloud Identity o Google Workspace. Di conseguenza, quando il nuovo dipendente accede a Google, potrebbe "ereditare" dati, impostazioni e autorizzazioni esistenti del precedente dipendente.
Gli utenti super amministratore di Cloud Identity e Google Workspace sono esenti dall'obbligo di utilizzare il Single Sign-On, ma possono comunque utilizzarlo quando l'accesso viene avviato dall'IdP. La possibilità di utilizzare il servizio Single Sign-On avviato dall'IdP rende gli utenti super amministratori sensibili allo squatting di nomi se non hanno una controparte nell'IdP esterno.
Considera il seguente esempio: 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 la password di Alice, trova un modo per creare un nuovo utente nell'IdP esterno che esegue il mapping a alice-admin@example.com. Sebbene questo account utente appena creato non
abbia privilegi speciali e non abbia 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 il Single Sign-On avviato da IdP e di autenticarsi come
alice-admin@example.com.
Per ridurre questo rischio di squatting del nome, assicurati che le tue identità Cloud Identity o Google Workspace siano un sottoinsieme delle identità nel tuo IdP esterno. Il modo migliore per farlo è mappare l'intero ciclo di vita dell'account utente come implementato dal tuo IdP esterno al ciclo di vita dell'account utente in Cloud Identity o Google Workspace.
Utilizzare utenti super amministratore 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, quando possibile è meglio limitare il numero di amministratori con accesso super amministratore e utilizzare account utente con meno privilegi per l'amministrazione quotidiana del tuo account o della tua organizzazione. Google Cloud
Dopo aver identificato gli amministratori che richiedono l'accesso super amministratore, crea account utente super amministratore dedicati, ad esempio:
- Crea un account utente con l'identità
alice@example.come assegna autorizzazioni regolari. Questo account deve essere utilizzato quotidianamente per le attività di routine. Crea un secondo account utente con identità
alice-admin@example.come assegnagli privilegi di superutente. È una best practice per Alice utilizzare questo account solo per le occasioni in cui sono necessari 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 IdP esterno in modo che l'insieme di identità in Cloud Identity o Google Workspace continui a essere un sottoinsieme delle identità nel tuo IdP 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
Il tuo IdP esterno potrebbe contenere non solo account utente per i dipendenti, ma anche account utente destinati a utenti macchina 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 di Google è implementare uno dei seguenti approcci:
Un'applicazione o uno strumento web che deve accedere 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 il consenso dell'utente finale per accedere ai suoi dati e, una volta ricevuto il consenso, è in grado di eseguire l'accesso per suo conto.
Se l'accesso ad API o servizi non deve avvenire per conto di un utente finale, ma per conto dell'applicazione stessa, è consigliabile utilizzare Google Cloud service account per l'autenticazione e poi concedere l'accesso al service account alle risorse utilizzando IAM.
Se ai service account Google Cloud vengono concessi i ruoli appropriati in IAM, possono essere utilizzati per autenticare e utilizzare qualsiasi API Cloud. Se devi concedere a unaccount di serviziot l'accesso ad API esterne aGoogle 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 Google Workspace solo nei casi in cui l'approccio OAuth non è pratico.
Utilizza un utente Cloud Identity o Google Workspace dedicato per ogni Google Cloud service account abilitato per la delega a livello di dominio di Google Workspace. Crea questo utente nel tuo IdP esterno e poi eseguine 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 degli 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.
Mappare i cicli di vita degli account utente
Gli account utente nel tuo IdP 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 entra a far parte dell'organizzazione.
- L'account utente potrebbe essere sospeso temporaneamente e riattivato in un secondo momento, ad esempio quando il dipendente va in congedo.
- 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 IdP esterno.
Designa il tuo IdP esterno come fonte attendibile
Molti sistemi informativi HR (HRIS), IdP e adattatori supportano solo il provisioning utenti unidirezionale. Ciò significa che le modifiche apportate nel sistema HRIS o nel provider di identità vengono propagate a Cloud Identity o Google Workspace, ma le modifiche apportate in Cloud Identity o Google Workspace non vengono propagate di nuovo.
Per evitare incoerenze causate dal provisioning unidirezionale, designa il tuo IdP esterno come fonte attendibile. Utilizza esclusivamente il tuo IdP (o HRIS) esterno per creare, modificare o eliminare utenti e affidati al provisioning automatico per fare in modo che le modifiche vengano propagate a Google Workspace e Cloud Identity. Se designi l'IdP esterno come fonte attendibile, limiti il rischio di incoerenze e che le modifiche manuali vengano 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, è consigliabile 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 IdP esterno.
- Ridurre 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 IdP esterno. Errori di corrispondenza come un errore ortografico accidentale dell'indirizzo email possono altrimenti causare problemi di accesso ai dipendenti.
- Ridurre al minimo l'impegno amministrativo manuale.
Se utilizzi un sistema HRIS per gestire la procedura di onboarding, un modo per automatizzare il provisioning degli utenti è configurare il sistema HRIS per eseguire il provisioning degli account utente sia nel tuo IdP esterno sia in Cloud Identity o Google Workspace, come illustrato nel seguente diagramma.
Affinché questa configurazione funzioni correttamente, devi assicurarti che il tuo HRIS fornisca account utente in modo che si mappino correttamente tra loro. Inoltre, l'HRIS deve gestire la decisione di 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 HRIS è utilizzare il tuo IdP esterno come origine autorevole per il provisioning degli utenti in Cloud Identity o Google Workspace. In questa configurazione, la configurazione per la mappatura degli account utente e i set di account utente vengono gestiti nell'IdP o dall'adattatore, come mostrato nel seguente diagramma.
Se utilizzi Active Directory come IdP, puoi duplicare questa configurazione utilizzando Google Cloud Directory Sync. Altri IdP 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, in modo temporaneo o permanente, ti consigliamo di revocare l'accesso ai servizi Google. Se sospendi l'account utente del dipendente nel tuo IdP esterno, revochi la sua capacità di utilizzare il Single Sign-On per l'autenticazione su Google, ma ciò potrebbe non revocare completamente l'accesso a tutti i servizi Google. Possono comunque verificarsi le seguenti situazioni:
- Se l'utente Cloud Identity o Google Workspace ha una sessione del browser attiva, questa continuerà a funzionare. Anche i token OAuth già ottenuti continuano 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 avvisi relativi al budget.
- Se all'utente è assegnata una licenza Google Workspace, le email continueranno a essere recapitate alla sua casella di posta, l'utente continuerà a essere visualizzato nella rubrica e potrebbe essere ancora elencato come disponibile in Google Calendar.
- Se consenti agli utenti di utilizzare app meno sicure, l'utente potrebbe comunque 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 nel tuo 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 tutti gli altri accessi.
Allo stesso modo, quando riattivi un account utente nel tuo 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 dati dell'utente vengono conservati, le licenze Google Workspace rimangono associate 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 nel tuo IdP esterno, ma anche di eliminarlo.
Se elimini un account utente nel tuo IdP 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 degli utenti nel tuo IdP esterno. Questo può diventare un problema in futuro se un nuovo dipendente entra a far parte della tua organizzazione e ha lo stesso nome del dipendente che ha lasciato l'azienda. Se crei un account utente nel tuo IdP per il nuovo dipendente, potresti riutilizzare il nome utente del vecchio dipendente, facendo in modo che il nuovo account utente venga mappato al vecchio account utente in Cloud Identity o Google Workspace. Di conseguenza, il nuovo dipendente potrebbe accedere 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 nel tuo IdP viene eliminato.
L'eliminazione di un utente 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 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 nel tuo IdP esterno mantenendo l'utente in stato sospeso per un determinato periodo di conservazione. Elimina l'utente sia nel tuo IdP sia in Cloud Identity o Google Workspace dopo che è trascorso il periodo di conservazione.
Quando elimini un account utente nel tuo IdP 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 di eliminazione nel tuo IdP esterno. Mantieni l'account utente rinominato in uno stato sospeso per un periodo di conservazione ed eliminalo al termine del periodo di conservazione.
Per conservare i dati di Google Workspace degli utenti sospesi, mantieni la licenza Google Workspace assegnata all'utente o passala 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
Google Sign-In
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 quindi cercato in Gmail, nella
directory degli account consumer o, se il dominio corrisponde al
dominio principale, secondario o 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 utilizzare il Single Sign-On, gli utenti vengono reindirizzati a un IdP esterno per l'autenticazione. Quando l'IdP esterno ha completato l'autenticazione, il risultato viene ritrasmesso ad Accedi con Google tramite un'asserzione SAML. Questa asserzione SAML funge da prova di un'autenticazione riuscita. L'asserzione contiene l'indirizzo email dell'utente ed è firmata dal certificato del provider di identità esterno, in modo che Accedi con Google possa verificarne l'autenticità.
Questo processo è denominato single sign-on avviato dal service provider 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 chiesto loro di inserire una password.
Alcuni IdP supportano anche il Single Sign-On avviato da IdP. In questo modello, l'utente esegue l'autenticazione presso l'IdP esterno e poi segue un link che punta a un servizio Google come Google Cloud o Google Ads. Se il servizio Single Sign-On è stato attivato per un account Cloud Identity o Google Workspace, tutti gli utenti di questo account possono utilizzare il servizio Single Sign-On avviato da IdP, inclusi i super amministratori.
Riduci al minimo l'insieme di attributi trasmessi nelle asserzioni SAML
Dopo che un utente si è autenticato presso l'IdP esterno, Cloud Identity o
Google Workspace utilizzano l'asserzione 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 che corrisponde al valore NameID nell'asserzione SAML.
Il valore NameID deve contenere l'indirizzo email principale dell'account utente da autenticare. L'indirizzo email è sensibile alle maiuscole. Gli alias e
gli indirizzi email alternativi non vengono presi in considerazione.
Per evitare errori di ortografia o di maiuscole e minuscole accidentali, è consigliabile eseguire il provisioning automatico degli account utente.
Le asserzioni SAML possono contenere attributi aggiuntivi, ma non vengono presi in considerazione durante l'autenticazione. Gli attributi contenenti informazioni come il nome, il cognome o le appartenenze 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 il tuo IdP in modo che non includa attributi che non sono richiesti dall'accesso con Google.
Utilizzare google.com come emittente
Le sessioni di accesso con Google non sono limitate a un singolo strumento o dominio. Al contrario, una volta stabilita una sessione, questa è valida per tutti i servizi Google a cui l'utente ha ottenuto 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 di protocollo SAML: per impostazione predefinita, Google utilizza google.com come emittente (l'elemento Issuer nella richiesta 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 o
Google Workspace. Attiva l'opzione dell'emittente specifica del dominio solo se
hai più di un account Cloud Identity o Google Workspace (e
quindi più domini) e il tuo IdP deve essere in grado di distinguere tra
gli accessi avviati da un account Cloud Identity o Google Workspace
rispetto a un altro account. Quando abiliti l'opzione, le richieste SAML utilizzano
google.com/a/DOMAIN come emittente e prevedono
google.com/a/DOMAIN come pubblico, dove
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 per specificare google.com come pubblico nelle asserzioni SAML. A seconda del tuo IdP, questa impostazione potrebbe essere chiamata anche
emittente, identificatore di attendibilità relying party o ID entità.
Allineare la durata delle sessioni Google e IdP
Una volta completata la procedura di Single Sign-On e stabilita una sessione, la sessione di accesso con 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 di nuovo l'autenticazione ripetendo la procedura 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 impostandola su 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 sessioneGoogle Cloud in tutti i tipi di account Cloud Identity e Google Workspace.
La maggior parte degli IdP esterni mantiene anche una sessione per gli utenti autenticati. Se la durata della sessione IdP è superiore a quella della sessione Google, allora la riautenticazione potrebbe avvenire in modo invisibile. ovvero l'utente viene reindirizzato all'IdP, ma potrebbe non dover inserire nuovamente le credenziali. La riautenticazione silenziosa potrebbe compromettere l'intento di ridurre la durata delle sessioni Google.
Per assicurarti che gli utenti debbano inserire nuovamente 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 il Single Sign-On per gli utenti super amministratori
Per gli utenti superamministratori, SSO è facoltativo: possono utilizzare SSO quando l'accesso viene avviato dall'IdP, ma possono anche accedere utilizzando nome utente e password.
Se non prevedi di utilizzare Single Sign-On avviato dall'IdP per gli utenti super amministratori, puoi ridurre il rischio utilizzando la seguente procedura:
- 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 IdP esterno migliora l'esperienza utente per i dipendenti. Gli utenti devono autenticarsi meno spesso e non devono memorizzare credenziali separate per accedere ai servizi Google.
Tuttavia, consentire agli utenti di autenticarsi senza problemi in servizi e ambienti diversi 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, ma anche in uno o più servizi Google.
Per ridurre il rischio di furto delle credenziali, è consigliabile utilizzare l'autenticazione a più fattori 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 privilegi di super amministratore devono utilizzare l'IdP esterno per l'autenticazione.
Configura il tuo 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 per Google.
Se il tuo IdP esterno non supporta l'autenticazione a più fattori, valuta la possibilità di attivare la verifica post-SSO per fare in modo che Google esegua una verifica aggiuntiva dopo che l'utente torna dall'autenticazione con il tuo IdP esterno.
Evita di utilizzare maschere di rete, perché potrebbero essere utilizzate in modo illecito 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 amministratore non vengono reindirizzati al tuo IdP esterno quando tentano di accedere alla console Google Cloud o ad altri siti Google. Agli utenti superamministratori viene invece chiesto di autenticarsi tramite nome utente e password.
Poiché gli utenti super amministratore possono autenticarsi tramite nome utente e password, non sono soggetti a criteri di autenticazione a più fattori che il tuo IdP potrebbe applicare. Per proteggere gli utenti super amministratore, applica l'autenticazione in due passaggi di Google per tutti gli utenti super amministratore.
Gli utenti superamministratori in genere rientrano in una delle due categorie seguenti:
Utenti super amministratore 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 amministratore macchina:anche se è meglio evitare questi account utente, a volte sono necessari per attivare 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 amministratore della macchina e prova ad attivare la verifica in due passaggi ogni volta che è possibile.
Per gli utenti che non utilizzano il Single Sign-On, puoi applicare l'autenticazione a due fattori su entrambi gli account a livello globale, per unità organizzativa o per gruppo:
Se non hai utenti super amministratore macchina che non possono utilizzare la verifica in due passaggi, è consigliabile attivare l'applicazione forzata per tutti gli utenti. Se applichi la verifica in due passaggi a tutti gli utenti, eviti il rischio di dimenticarti accidentalmente di alcuni utenti.
Se hai alcuni utenti super amministratori macchina che non possono utilizzare la verifica in due passaggi, utilizza un gruppo dedicato per controllare la verifica in due passaggi. Crea un nuovo gruppo, attiva l'applicazione per il gruppo e aggiungi tutti i superamministratori pertinenti.
Per maggiori dettagli sull'utilizzo dell'autenticazione a due fattori 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 amministratore
Sebbene gli utenti super amministratori non siano tenuti a utilizzare il servizio Single Sign-On, possono comunque utilizzarlo quando viene avviato dall'IdP. Per assicurarti che gli utenti superamministratori siano sempre soggetti alla verifica in due passaggi, anche se eseguono l'autenticazione tramite l'accesso avviato da IdP, attiva verifiche SSO aggiuntive e verifica in due passaggi per tutti gli utenti superamministratori.
Le verifiche SSO aggiuntive potrebbero sembrare ridondanti nei casi in cui il tuo IdP applica già l'autenticazione a più fattori, ma l'impostazione può contribuire a proteggere gli utenti superamministratori se il tuo IdP viene compromesso.
Non limitare il Single Sign-On in base alla maschera di rete
Quando configuri il Single Sign-On 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 al Single Sign-On; agli altri utenti viene richiesta una password quando accedono.
Se utilizzi le maschere di rete, potresti compromettere l'autenticazione a più fattori applicata dal tuo IdP esterno. Ad esempio, modificando le 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 le norme di autenticazione a più fattori configurate 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 un'opportuna lista consentita di indirizzi IP nel tuo IdP esterno o utilizza Accesso sensibile 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.