Questo documento illustra le best practice e le indicazioni che ti aiutano a configurare la federazione in modo coerente e sicuro. Le linee guida 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 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 federe Cloud Identity o Google Workspace con il tuo provider di identità esterno (IdP), ad esempio Active Directory o Azure Active Directory. La configurazione della federazione in genere comporta quanto segue:
- Provisioning automatico degli account utente pertinenti da una fonte ufficiale esterna a Cloud Identity o Google Workspace.
- Consentire agli utenti di utilizzare un IdP esterno per l'autenticazione ai servizi Google.
Mappatura delle 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 ai seguenti scopi:
- L'indirizzo email principale è il nome utente che un utente deve fornire quando esegue l'accesso. Anche se gli utenti possono aggiungere indirizzi email o alias alternativi al proprio account utente Google, questi indirizzi non sono considerati identità e non possono essere utilizzati per accedere.
- Quando un amministratore deve inviare notifiche agli utenti (ad esempio per annunciare un potenziale rischio per la sicurezza), le notifiche vengono inviate solo all'indirizzo email principale.
Per configurare il Single Sign-On e il provisioning automatico degli utenti tra Google e l'IdP esterno, devi mappare le identità nel tuo IdP esterno alle identità corrispondenti in Cloud Identity o Google Workspace. Le seguenti sezioni descrivono le best practice per la creazione di questa mappatura.
Utilizza la stessa identità in tutti i sistemi federati
Tutto ciò che serve per stabilire una mappatura è verificare che l'asserzione SAML fornita dall'IdP a Google contenga una rivendicazione NameID con un valore che corrisponda all'indirizzo email principale di un utente Cloud Identity o Google Workspace esistente. L'IdP è libero di utilizzare qualsiasi mappatura o logica applicabile per generare una rivendicazione NameID adatta per i suoi utenti esistenti.
Molti IdP si basano sugli indirizzi email (o, più in generale, nomi conformi a RFC 822) per identificare gli utenti. Ecco alcuni esempi:
- L'attributo
userPrincipalNamein Active Directory è un nome conforme alla specifica 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à dell'indirizzo email principale in Cloud Identity o Google Workspace. L'utilizzo della stessa identità utente nei sistemi federati presenta diversi vantaggi:
Quando gli utenti accedono a uno strumento Google come la console Google Cloud, viene loro richiesto di fornire l'indirizzo email principale dell'utente di Cloud Identity o Google Workspace prima di essere reindirizzati all'IdP esterno. A seconda dell'IdP, all'utente potrebbe essere visualizzata un'altra schermata di accesso che richiede l'inserimento di nome utente e 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 mappare tra le identità degli utenti, è più facile correlare gli audit log di Google Cloud con i log di sistemi on-premise.
Allo stesso modo, se le applicazioni di cui viene eseguito il deployment on-premise e su Google Cloud devono scambiare dati contenenti le identità degli utenti, eviterai la complessità aggiuntiva derivante dalla mappatura degli identificatori degli utenti.
Per maggiori dettagli sulla mappatura degli utenti di Active Directory o degli utenti di 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 recapitare le email di notifica. Ecco alcuni esempi di notifiche:
Avvisi relativi al budget: se hai configurato un avviso relativo al budget, Google Cloud invia una notifica agli amministratori 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 a progetti: se assegni il ruolo di Amministratore di 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 assegnato 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 record MX DNS necessari, 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, anche Google Cloud tenta di recapitare email di notifica, che però devono essere gestite dall'infrastruttura email esistente. Per assicurarti che gli utenti di Cloud Identity non perdano le notifiche, accertati che il tuo sistema email esistente accetti i messaggi inviati agli indirizzi email principali degli utenti di Cloud Identity e che inoltri questa email alle caselle di posta corrette. Segui questi passaggi:
Assicurati che tutti i domini aggiunti a Cloud Identity dispongano di record MX DNS che rimandano al 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 l'indirizzo email principale utilizzato da Cloud Identity e l'indirizzo email dell'utente non corrispondono, configura un alias nel tuo sistema email esistente in modo che le email inviate a ciascun 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 le licenze Google Workspace agli utenti chiave che si occupano della fatturazione o che interagiscono con l'assistenza e che hanno quindi 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 utilizzino account consumer 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 mostrare gli account consumer esistenti, consulta Valutazione degli Account Google esistenti.
Puoi gestire gli account consumer esistenti nei seguenti modi:
- Mantieni gli account consumer così come sono, accettando potenziali rischi.
- Esegui la migrazione degli account a Cloud Identity o Google Workspace avviando un trasferimento.
- Imponi ai proprietari degli account utente non gestiti di modificare il proprio indirizzo email in modo da utilizzare un dominio diverso.
Per maggiori dettagli su come consolidare gli account consumer esistenti, vedi Valutare le opzioni di consolidamento delle identità.
Il modo in cui decidi di gestire gli account consumer influenza come e in quale sequenza imposti la federazione. Valuta tutti gli account consumer esistenti utilizzati dagli utenti prima di iniziare a creare account utente o a configurare il servizio Single Sign-On in Cloud Identity o Google Workspace.
Mappatura degli insiemi di identità
Dopo aver definito il modo in cui le singole identità vengono mappate tra il tuo IdP esterno e Cloud Identity o Google Workspace, devi determinare l'insieme di identità per cui abilitare l'accesso ai servizi Google.
L'insieme effettivo di identità che possono autenticarsi per i servizi Google è l'intersezione di due insiemi:
- Identità esterne mappate a un'identità in Cloud Identity o Google Workspace.
Identità esterne consentite dall'IdP esterno 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 che utilizzi. Ad esempio, Azure AD si basa sulle assegnazioni, mentre AD FS utilizza i criteri di controllo dell'accesso.
Limita l'insieme di identità che possono eseguire l'autenticazione 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 loro sottoinsieme devono essere in grado di eseguire l'autenticazione per i servizi Google.
Se prevedi di concedere l'accesso ai servizi Google solo a un sottoinsieme dei dipendenti della tua organizzazione, ti consigliamo di limitare l'autenticazione a questo insieme di utenti. Limitando il numero di utenti che possono autenticarsi, puoi stabilire un ulteriore livello di difesa utile nel caso in cui tu abbia configurato accidentalmente una regola di controllo dell'accesso in modo che sia troppo permissiva.
Puoi limitare il gruppo 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 avrà esito negativo, 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 dalla tua presenza o meno di account consumer esistenti di cui devi eseguire la migrazione.
Limitare 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 intendi ancora eseguire la migrazione, devi fare attenzione a non creare account utente in conflitto per errore. 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 dispongono già di un account consumer.
- 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 hai creato degli 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 in che modo i diversi tipi di identità si sovrappongono e interrelano.
Nel diagramma, le identità con un account utente in Cloud Identity o Google Workspace sono indicate nell'ellisse più piccola (gialla). L'ellisse è contenuta nella seconda ellisse (blu), che contiene le identità in grado di eseguire l'autenticazione. La terza e più grande ellisse (rosa) contiene gli altri ed è costituita dalle identità che hanno un account utente nel tuo IdP. Per maggiori dettagli 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 che utilizzano lo stesso dominio. Questi nuovi account consumer appaiono come utenti non gestiti nel tuo account Cloud Identity o Google Workspace, ma non sono autorizzati a utilizzare il Single Sign-On o qualsiasi altra configurazione applicata nel tuo account Cloud Identity o Google Workspace.
Un modo per impedire 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 da parte di un dipendente di creare 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 sono più disponibili account consumer di cui eseguire la migrazione 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 servizio Single Sign-On a Cloud Identity o Google Workspace.
Esegui il provisioning degli utenti di 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 sospeso gli account utente non abilitati per il Single Sign-On.
Il seguente diagramma mostra questa configurazione.
Se stai ancora eseguendo la migrazione degli account consumer, puoi monitorare temporaneamente le registrazioni di nuovi account consumer acquisendo le email di verifica inviate durante il processo di registrazione. Per le email di verifica viene usato
l'indirizzo del mittente della busta corrispondente a *@idverification.bounces.google.com.
Imposta un filtro nel tuo sistema email che identifichi le email con questo indirizzo del mittente della busta e le blocchi per la revisione interna.
Imposta le identità di Cloud Identity o Google Workspace come 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 del tuo IdP esterno. Esistono due scenari tipici che possono portare a questi account utente:
- Creerai un nuovo account utente in Cloud Identity o Google Workspace e utilizzerai un indirizzo email principale che non corrisponda a nessun utente del tuo IdP esterno.
- Hai un account utente in Cloud Identity o Google Workspace che è mappato 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, a tutti gli utenti (ad eccezione dei super amministratori) viene richiesto di 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 di questo tipo è effettivamente disattivato, 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. Questo potrebbe consentire a un ex dipendente di 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 dipendente è stato eliminato, è possibile che assegni al nuovo dipendente il nome utente utilizzato dall'ex dipendente.
L'account utente del nuovo dipendente potrebbe avere un ID interno diverso da quello dell'ex dipendente. Tuttavia, dal punto di vista della federazione, i due account utente vengono considerati uguali se sono mappati entrambi 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 dall'obbligo di utilizzare il Single Sign-On, ma possono comunque utilizzare il Single Sign-On quando l'accesso viene avviato dall'IdP. La possibilità di utilizzare il Single Sign-On avviato dall'IdP rende gli utenti super amministratori sensibili allo squatting dei 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. Michela, che non conosce la password di Alice, trova un modo per creare un nuovo utente nell'IdP esterno mappato a alice-admin@example.com. Anche se 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 permette a Mallory di utilizzare il Single Sign-On avviato dall'IdP e di autenticarsi come alice-admin@example.com.
Per ridurre il rischio di squash dei nomi, assicurati che le identità di 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 implementato dal tuo IdP esterno al ciclo di vita dell'account utente in Cloud Identity o Google Workspace.
Utilizza 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 ridotto di attività richiede privilegi di super amministratore, quando possibile è meglio limitare il numero di amministratori con accesso di super amministratore e utilizzare account utente con meno privilegi per l'amministrazione giornaliera dell'account o dell'organizzazione Google Cloud.
Una volta individuati gli amministratori che richiedono l'accesso come 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 l'identità
alice-admin@example.come assegna i privilegi di super user. Per Alice è consigliabile utilizzare questo account solo nei casi 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 sia inoltrato aalice@example.com.
Assicurati che entrambe le identità siano riconosciute dall'IdP esterno in modo che l'insieme di identità in Cloud Identity o Google Workspace continui a essere un sottoinsieme di identità nel tuo IdP esterno.
Ti consigliamo di seguire uno schema di denominazione per questi account super amministratore dedicati, in modo che nei log di controllo tu possa monitorare dove e come vengono utilizzati. Ad esempio, aggiungi -admin al nome utente, come nell'esempio precedente.
Limitare il numero di utenti dei servizi in Google Workspace e Cloud Identity
L'IdP esterno potrebbe contenere non solo gli account utente per i dipendenti, ma anche gli account utente destinati a utenti di macchine, come applicazioni, strumenti o lavori in background.
Al contrario, in Google Cloud il modo migliore per abilitare un'applicazione all'autenticazione e all'accesso alle API di Google consiste nell'implementare uno dei seguenti approcci:
Un'applicazione web o uno strumento 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 ad accedere ai suoi dati e, una volta ricevuto il consenso, è in grado di eseguire l'accesso per conto dell'utente finale.
Se l'accesso alle API o ai servizi non deve avvenire per conto di un utente finale, ma per conto dell'applicazione stessa, è preferibile utilizzare gli account di servizio Google Cloud per l'autenticazione e poi concedere all'account di servizio l'accesso alle risorse utilizzando IAM.
Se agli account di servizio Google Cloud vengono concessi i ruoli appropriati in IAM, possono essere utilizzati per autenticare e utilizzare qualsiasi API Cloud. Se devi concedere a un account di servizio l'accesso alle API 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, puoi consentire a un account di servizio di agire per conto di un utente di Cloud Identity o Google Workspace. Poiché la delega è un privilegio importante, ti consigliamo di utilizzare la delega a livello di dominio di Google Workspace solo nei casi in cui l'approccio OAuth non è 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 nell'IdP esterno, quindi esegui il provisioning su 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 in Cloud Identity e Google Workspace utenti del servizio che non intendi utilizzare per la delega a livello di dominio di Google Workspace.
Mappatura dei cicli di vita degli account utente
Gli account utente del 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 temporaneamente sospeso e poi riattivato, ad esempio quando il dipendente va in assenza.
- Quando l'utente lascia l'azienda, l'account utente viene eliminato o mantenuto in stato di sospensione per un determinato periodo di conservazione di tempo prima di essere eliminato.
Il seguente diagramma illustra questo ciclo di vita.
In questa sezione sono elencate 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.
Specifica il tuo IdP esterno come fonte attendibile
Molti sistemi informativi HRIS (HRIS), IdP e adattatori supportano solo il provisioning unidirezionale degli utenti. Ciò significa che le modifiche apportate nell'HRIS o nell'IdP vengono propagate a Cloud Identity o Google Workspace, ma le modifiche apportate in Cloud Identity o Google Workspace non vengono propagate.
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 gli utenti e affidarti al provisioning automatico per la propagazione delle modifiche a Google Workspace e Cloud Identity. Se designa l'IdP esterno come fonte attendibile, limiti il rischio di incoerenze e che l'IdP sostituisca le modifiche manuali.
Automatizzare il provisioning degli utenti per Cloud Identity o Google Workspace
Per consentire a un dipendente di eseguire l'autenticazione 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:
- Grazie all'automazione del provisioning, puoi assicurarti che le identità di Cloud Identity o Google Workspace siano sempre un sottoinsieme delle identità nel tuo IdP esterno.
- Riduci al minimo il rischio di introdurre inavvertitamente una mancata corrispondenza tra un'identità in Cloud Identity o Google Workspace e l'identità corrispondente nel tuo IdP esterno. Mancata corrispondenza, come un errore ortografico accidentale dell'indirizzo email, può portare i dipendenti a riscontrare problemi di accesso.
- Riduce al minimo lo sforzo di amministrazione manuale.
Se utilizzi un HRIS per gestire il processo di onboarding, un modo per automatizzare il provisioning degli utenti consiste nel configurare l'HRIS in modo che esegua il provisioning degli account utente sia sull'IdP esterno sia su Cloud Identity o Google Workspace, come illustrato nel diagramma seguente.
Affinché questa configurazione funzioni correttamente, devi assicurarti che la tua HRIS esegua il provisioning degli account utente in modo che vengano mappati tra loro correttamente. 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 in modo indipendente da un HRIS è utilizzare l'IdP esterno come fonte ufficiale per il provisioning degli utenti in Cloud Identity o Google Workspace. In questa configurazione, la configurazione per la mappatura degli account utente e degli set di account utente viene gestita nell'IdP o tramite l'adattatore, come illustrato nel diagramma seguente.
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 a 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.
Propaga 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 del dipendente 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 i seguenti casi:
- Se l'utente di Cloud Identity o Google Workspace ha una sessione del browser attiva, la sessione continuerà a funzionare. Anche gli eventuali token OAuth già 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 avvisi sul budget.
- Se all'utente è stata assegnata una licenza Google Workspace, le email continueranno a essere recapitate nella sua casella di posta, l'utente continuerà a essere visualizzato nella sua rubrica e l'utente potrebbe essere ancora disponibile in Google Calendar.
- Se consenti agli utenti di utilizzare app meno sicure, l'utente potrebbe comunque essere in grado di accedere a Gmail, Google Calendar e ad altri dati utilizzando le 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, venga sospeso anche l'account utente corrispondente in Cloud Identity o Google Workspace. 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 allegate e i ruoli assegnati in Google Cloud rimangono invariati.
Propaga gli eventi di eliminazione a Cloud Identity o Google Workspace
Quando un dipendente lascia l'organizzazione definitivamente, puoi decidere non solo di 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 di Cloud Identity o Google Workspace corrispondente, l'insieme di utenti di Cloud Identity e Google Workspace non sarà più un sottoinsieme degli utenti del tuo IdP esterno. Questo può trasformarsi in 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, puoi riutilizzare il nome utente del vecchio dipendente, 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 ottenere l'accesso ai dati e alle impostazioni del vecchio dipendente.
Per evitare i rischi associati agli account utente Cloud Identity o Google Workspace orfani, puoi eliminare un utente di Cloud Identity o Google Workspace non appena viene eliminato l'account utente corrispondente nel tuo IdP.
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, che pertanto potrebbero non soddisfare i 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 degli account utente nel tuo IdP esterno mantenendo l'utente in stato di sospensione per un determinato periodo di conservazione. Elimina l'utente sia nell'IdP che in Cloud Identity/Google Workspace una volta trascorso il periodo di conservazione.
Quando elimini un account utente nel tuo IdP esterno, sospendi l'utente Cloud Identity o Google Workspace corrispondente e sostituisci l'indirizzo email principale con un nome che difficilmente possa causare 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 una volta trascorso il periodo di conservazione.
Per conservare i dati di Google Workspace degli 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 l'utente a accounts.google.com, dove l'utente vede la schermata di accesso di Google e gli viene richiesto di inserire l'indirizzo email. A seconda del dominio dell'indirizzo email fornito, l'account utente viene quindi cercato in Gmail, nella directory dell'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 questo processo di autenticazione.
Se configuri un account Cloud Identity o Google Workspace per l'utilizzo del Single Sign-On, gli utenti vengono reindirizzati a un IdP 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 dimostra che l'autenticazione è riuscita. L'asserzione contiene l'indirizzo email dell'utente ed è firmata dal certificato dell'IdP esterno in modo che Accedi con Google possa verificarne l'autenticità.
Questo processo è definito Single Sign-On avviato dal fornitore di servizi e si applica a tutti gli utenti, tranne ai super amministratori. I super amministratori non vengono mai reindirizzati a un IdP esterno e vengono invitati a inserire una password.
Alcuni IdP supportano anche il servizio Single Sign-On avviato dall'IdP. In questo modello, l'utente esegue l'autenticazione presso l'IdP esterno e segue un link che rimanda a un servizio Google come Google Cloud o Google Ads. Se il Single Sign-On è stato abilitato 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 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à, questa procedura 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/minuscole, è preferibile eseguire il provisioning automatico degli account utente.
Le asserzioni SAML possono contenere attributi aggiuntivi, ma non vengono considerate durante l'autenticazione. Gli attributi contenenti informazioni come nome, cognome o iscrizioni ai 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 da non includere attributi non richiesti da Accedi con Google.
Utilizza google.com come emittente
Le sessioni di Accedi con Google non sono limitate a un singolo strumento o dominio. Una volta stabilita, invece, una sessione è valida per tutti i servizi Google a cui l'utente è stato autorizzato ad accedere. Questo elenco di servizi potrebbe includere servizi come Google Cloud e Google Ads, nonché servizi come 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 (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 specifica per il dominio quando configuri il Single Sign-On in Cloud Identity o Google Workspace. Abilita l'opzione dell'emittente specifica per il 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 e quelli avviati da 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 l'IdP esterno per specificare google.com come pubblico nelle dichiarazioni SAML. A seconda dell'IdP, questa impostazione potrebbe anche essere indicata come emittente, identificatore di attendibilità del componente o ID entità.
Allinea la durata delle sessioni Google e delle sessioni IdP
Quando un utente ha completato il processo Single Sign-On e una sessione è stata stabilita, la sessione Accedi con Google rimane attiva per un determinato periodo di tempo. Al termine di questo periodo di tempo o se l'utente si disconnette, all'utente viene richiesto di eseguire nuovamente l'autenticazione ripetendo il processo 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 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, 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 IdP è superiore a quella della sessione Google, la riautenticazione potrebbe avvenire in modalità invisibile. Ciò significa che l'utente viene reindirizzato all'IdP, ma potrebbe non dover inserire di nuovo le credenziali. La riautenticazione silenziosa potrebbe compromettere l'intento di abbreviare 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.
Disabilita il Single Sign-On per gli utenti super amministratore
Per gli utenti con ruolo di super amministratore, l'accesso SSO è facoltativo: possono utilizzare il servizio SSO quando l'accesso viene avviato dall'IdP, ma possono anche accedere utilizzando nome utente e password.
Se non hai intenzione di utilizzare il Single Sign-On avviato dall'IdP per gli utenti super amministratori, puoi ridurre i rischi utilizzando la seguente procedura:
- Aggiungi un'unità organizzativa dedicata per i super amministratori.
- Assegna un profilo SSO all'unità organizzativa che disabilita 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 amministratori.
Autenticazione a più fattori
L'attivazione del Single Sign-On tra Cloud Identity o Google Workspace e l'IdP esterno migliora l'esperienza utente per i dipendenti. Gli utenti devono autenticarsi con meno frequenza e non devono memorizzare credenziali separate per accedere ai servizi Google.
Tuttavia, consentire agli utenti di eseguire l'autenticazione senza soluzione di continuità tra servizi e 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 utente malintenzionato potrebbe utilizzare queste credenziali per accedere alle risorse non solo nel tuo ambiente esistente, ma anche su uno o più servizi Google.
Per ridurre il rischio di furto di credenziali, conviene utilizzare l'autenticazione a più fattori per tutti gli account utente.
Applicare l'autenticazione a più fattori agli utenti
Una volta configurato il Single Sign-On per il tuo account Cloud Identity o Google Workspace, gli utenti senza privilegio 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 a Google.
Se il tuo IdP esterno non supporta l'autenticazione a più fattori, puoi abilitare la verifica post-SSO per consentire a Google di eseguire una verifica aggiuntiva dopo che l'utente torna dall'autenticazione presso 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.
Imponi l'autenticazione in due passaggi di Google per gli utenti con ruolo di super amministratore
Gli utenti super amministratori non vengono reindirizzati al tuo IdP esterno quando tentano di accedere alla console Google Cloud o ad altri siti Google. Agli utenti dei super amministratori viene invece richiesto di eseguire l'autenticazione usando nome utente e password.
Poiché gli utenti super amministratori possono eseguire l'autenticazione per nome utente e password, non sono soggetti ad alcun criterio di autenticazione a più fattori che potrebbe essere applicato dall'IdP. Per proteggere gli utenti con privilegi di super amministratore, applica l'autenticazione in due passaggi di Google a tutti gli utenti super amministratori.
Gli utenti super amministratori in genere rientrano in una delle due categorie seguenti:
Utenti super amministratori personalizzati: questi utenti sono personalizzati e destinati a essere utilizzati da un singolo amministratore. Ti consigliamo di applicare la verifica in due passaggi a tutti gli utenti super amministratori personalizzati.
Utenti super amministratori della macchina: sebbene sia meglio evitare questi account utente, a volte è necessario abilitare strumenti come Cloud Directory Sync o l'app della galleria Azure AD per gestire utenti e gruppi in Cloud Identity o Google Workspace.
Limita il numero di utenti super amministratori della macchina e prova ad abilitare la verifica in due passaggi, se possibile.
Per gli utenti che non utilizzano il Single Sign-On, puoi applicare l'autenticazione in due passaggi a livello globale, di unità organizzativa o di gruppo:
Se non esistono utenti super amministratori delle macchine che non possono utilizzare la verifica in due passaggi, ti consigliamo di attivare l'applicazione forzata per tutti gli utenti. Se applichi la verifica in due passaggi per tutti gli utenti, eviti il rischio di perdere accidentalmente degli utenti.
Se hai alcuni utenti super amministratori della 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 forzata per il gruppo e aggiungi tutti i super user pertinenti.
Per maggiori dettagli sull'utilizzo dell'autenticazione in due passaggi per proteggere gli utenti super amministratori, consulta le nostre best practice per la sicurezza degli account amministratore.
Forza la verifica post-SSO per gli utenti super amministratore
Anche se agli utenti super amministratori non è richiesto di utilizzare il Single Sign-On, è comunque consentito utilizzare questo tipo di accesso se vengono avviati dall'IdP. Per garantire che gli utenti super amministratori siano sempre soggetti alla verifica in due passaggi, anche se si autenticano mediante l'accesso avviato dall'IdP, attiva verifiche SSO aggiuntive e verifica in due passaggi per tutti gli utenti super amministratori.
Le verifiche SSO aggiuntive potrebbero sembrare ridondanti nei casi in cui l'IdP stia già applicando l'autenticazione a più fattori, ma l'impostazione può contribuire a proteggere gli utenti super amministratori in caso di compromissione dell'IdP.
Non limitare il Single Sign-On tramite maschera di rete
Quando configuri il Single Sign-On in Cloud Identity o Google Workspace, puoi facoltativamente specificare una maschera di rete. Se specifichi una maschera, solo gli utenti con indirizzi IP corrispondenti alla maschera sono soggetti al Single Sign-On, mentre agli altri utenti viene richiesta la password quando accedono.
Se utilizzi 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 si applica o meno. Se applichi l'autenticazione a più fattori all'IdP esterno, questa tattica potrebbe consentire a un utente o a un utente malintenzionato di eludere i criteri di autenticazione a più fattori configurati presso l'IdP esterno.
Per garantire che l'autenticazione a più fattori si applichi in modo coerente, indipendentemente dalla località o dall'indirizzo IP di un utente, evita di limitare il Single Sign-On tramite la maschera di rete.
Per limitare l'accesso alle risorse in base all'indirizzo IP, configura una lista consentita degli indirizzi IP appropriata presso il tuo provider di identità esterno oppure utilizza l'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.