Questa sezione illustra come utilizzare Cloud Identity per gestire le identità utilizzate dai dipendenti per accedere ai servizi Google Cloud.
Provider di identità esterno come fonte attendibile
Ti consigliamo di federare l'account Cloud Identity con il tuo provider di identità esistente. La federazione aiuta a garantire che i processi di gestione degli account esistenti si applichino a Google Cloud e ad altri servizi Google.
Se non hai ancora un provider di identità, puoi creare account utente direttamente in Cloud Identity.
Il seguente diagramma mostra una visualizzazione ad alto livello della federazione delle identità e del servizio Single Sign-On (SSO). Utilizza Microsoft Active Directory, situato nell'ambiente on-premise, come provider di identità di esempio.
Questo diagramma descrive le seguenti best practice:
- Le identità degli utenti vengono gestite in un dominio Active Directory che si trova nell'ambiente on-premise e federato a Cloud Identity. Active Directory utilizza Google Cloud Directory Sync per eseguire il provisioning delle identità in Cloud Identity.
- Gli utenti che tentano di accedere ai servizi Google vengono reindirizzati al provider di identità esterno per il Single Sign-On con SAML, utilizzando le proprie credenziali esistenti per l'autenticazione. Nessuna password è sincronizzata con Cloud Identity.
La tabella seguente fornisce i link per configurare le indicazioni per i provider di identità.
| Provider di identità | Consulenza |
|---|---|
| Active Directory | |
| Microsoft Entra ID (in precedenza Azure AD) | |
| Altri provider di identità esterni (ad esempio Ping o Okta) |
Ti consigliamo vivamente di applicare l'autenticazione a più fattori al tuo provider di identità con un meccanismo resistente al phishing, ad esempio un token di sicurezza Titan.
Le impostazioni consigliate per Cloud Identity non sono automatizzate tramite il codice Terraform in questo progetto base. Consulta i controlli amministrativi per Cloud Identity per conoscere le impostazioni di sicurezza consigliate che devi configurare oltre al deployment del codice Terraform.
Gruppi per controllo dell'accesso
Un'entità è un'identità a cui può essere concesso l'accesso a una risorsa. Le entità includono gli Account Google per gli utenti, i gruppi Google, gli account Google Workspace, i domini Cloud Identity e gli account di servizio. Alcuni servizi ti consentono anche di concedere l'accesso a tutti gli utenti che eseguono l'autenticazione con un Account Google o a tutti gli utenti su internet. Affinché un'entità possa interagire con i servizi Google Cloud, devi concederle i ruoli in Identity and Access Management (IAM).
Per gestire i ruoli IAM su larga scala, ti consigliamo di assegnare gli utenti ai gruppi in base alle loro funzioni lavorative e ai requisiti di accesso, per poi concedere i ruoli IAM a questi gruppi. Devi aggiungere gli utenti ai gruppi utilizzando i processi nel tuo provider di identità esistente per la creazione e l'iscrizione ai gruppi.
Non è consigliabile concedere ruoli IAM ai singoli utenti perché le singole assegnazioni possono aumentare la complessità di gestione e controllo dei ruoli.
Il progetto configura gruppi e ruoli per l'accesso di sola visualizzazione alle risorse di base. Ti consigliamo di eseguire il deployment di tutte le risorse del progetto base tramite la pipeline di base e di non concedere ruoli agli utenti ai gruppi per modificare le risorse di base al di fuori della pipeline.
La tabella seguente mostra i gruppi configurati dal progetto base per la visualizzazione delle risorse di base.
| Nome | Descrizione | Ruoli | Ambito |
|---|---|---|---|
grp-gcp-org-admin@example.com |
Amministratori con privilegi elevati che possono concedere ruoli IAM a livello di organizzazione. Può accedere a qualsiasi altro ruolo. Questo privilegio non è consigliato per l'uso quotidiano. | Amministratore dell'organizzazione | organizzazione |
grp-gcp-billing-admin@example.com |
Amministratori con privilegi elevati che possono modificare l'account di fatturazione Cloud. Questo privilegio non è consigliato per l'uso giornaliero. | Amministratore account di fatturazione | organizzazione |
grp-gcp-billing-viewer@example.com |
Il team responsabile della visualizzazione e dell'analisi della spesa per tutti i progetti. | Visualizzatore account di fatturazione | organizzazione |
| Utente BigQuery | progetto di fatturazione | ||
grp-gcp-audit-viewer@example.com |
Il team responsabile della verifica dei log relativi alla sicurezza. | progetto di logging | |
grp-gcp-monitoring-users@example.com |
Il team responsabile del monitoraggio delle metriche sulle prestazioni delle applicazioni. | Visualizzatore Monitoring | progetto di monitoraggio |
grp-gcp-security-reviewer@example.com |
Il team responsabile della revisione della sicurezza del cloud. | Revisore della sicurezza | organizzazione |
grp-gcp-network-viewer@example.com |
Il team responsabile della visualizzazione e della gestione delle configurazioni di rete. | Visualizzatore rete Compute | organizzazione |
grp-gcp-scc-admin@example.com |
Il team responsabile della configurazione di Security Command Center. | Editor amministratore Centro sicurezza | organizzazione |
grp-gcp-secrets-admin@example.com |
Il team responsabile della gestione, dell'archiviazione e del controllo delle credenziali e di altri secret utilizzati dalle applicazioni. | Amministratore Secret Manager | progetti secret |
grp-gcp-kms-admin@example.com |
Il team responsabile dell'applicazione della gestione delle chiavi di crittografia per soddisfare i requisiti di conformità. | Visualizzatore Cloud KMS | progetti kms |
Man mano che costruisci i tuoi carichi di lavoro sulla base degli elementi di base, puoi creare gruppi aggiuntivi e concedere ruoli IAM basati sui requisiti di accesso per ciascun carico di lavoro.
Ti consigliamo vivamente di evitare i ruoli di base (come Proprietario, Editor o Visualizzatore) e di utilizzare invece i ruoli predefiniti. I ruoli di base sono eccessivamente permissivi e rappresentano un potenziale rischio per la sicurezza. I ruoli Proprietario ed Editor possono portare all'escalation dei privilegi e allo spostamento laterale e il ruolo Visualizzatore include l'accesso per leggere tutti i dati. Per le best practice sui ruoli IAM, consulta Utilizzare IAM in modo sicuro.
Account super amministratore
Gli utenti di Cloud Identity con l'account super amministratore ignorano le impostazioni SSO dell'organizzazione e si autenticano direttamente in Cloud Identity. Questa eccezione è stata pianificata, quindi il super amministratore può comunque accedere alla console Cloud Identity in caso di configurazione errata o interruzione del servizio SSO. Tuttavia, devi prendere in considerazione ulteriore protezione per gli account super amministratore.
Per proteggere i tuoi account super amministratore, ti consigliamo di applicare sempre la verifica in due passaggi con token di sicurezza in Cloud Identity. Per ulteriori informazioni, consulta Best practice per la protezione degli account amministratore.
Problemi con gli account utente consumer
Se non hai utilizzato Cloud Identity o Google Workspace prima di eseguire l'onboarding in Google Cloud, è possibile che i dipendenti della tua organizzazione utilizzino già account consumer associati alle loro identità email aziendali per accedere ad altri servizi Google come Google Marketing Platform o YouTube. Gli account consumer sono account completamente posseduti e gestiti dalle persone che li hanno creati. Poiché questi account non sono sotto il controllo della tua organizzazione e potrebbero includere dati personali e aziendali, devi decidere come consolidare questi account con altri account aziendali.
Ti consigliamo di consolidare gli account utente consumer esistenti nell'ambito dell'onboarding in Google Cloud. Se non utilizzi già Google Workspace per tutti i tuoi account utente, ti consigliamo di bloccare la creazione di nuovi account consumer.
Controlli amministrativi per Cloud Identity
Cloud Identity dispone di vari controlli amministrativi non automatizzati dal codice Terraform nel progetto. Ti consigliamo di applicare ognuno di questi controlli di sicurezza basati sulle best practice fin dalle prime fasi del processo di creazione delle basi.
| Controlli | Descrizione |
|---|---|
| Implementare la verifica in due passaggi | Gli account utente potrebbero essere compromessi da phishing, ingegneria sociale, password spraying o altre minacce. La verifica in due passaggi aiuta a mitigare queste minacce. Ti consigliamo di applicare la verifica in due passaggi a tutti gli account utente della tua organizzazione che utilizzano un meccanismo anti-phishing come token di sicurezza Titan o altri token basati sugli standard FIDO U2F (CTAP1) resistenti al phishing. |
| Impostare la durata della sessione per i servizi Google Cloud | I token OAuth permanenti sulle workstation per sviluppatori possono rappresentare un rischio per la sicurezza se esposti. Ti consigliamo di impostare un criterio di riautenticazione in modo che richieda l'autenticazione ogni 16 ore utilizzando un token di sicurezza. |
| Impostare la durata della sessione per Google Services | (solo per i clienti di Google Workspace)
Le sessioni web persistenti in altri servizi Google possono rappresentare un rischio per la sicurezza se esposte. Ti consigliamo di applicare una durata massima per le sessioni web e allinearla ai controlli per la durata delle sessioni del provider SSO. |
| Condividere dati da Cloud Identity con i servizi Google Cloud | Gli audit log delle attività di amministrazione di Google Workspace o Cloud Identity vengono normalmente gestiti e visualizzati nella Console di amministrazione, separatamente dai log nel tuo ambiente Google Cloud. Questi log contengono informazioni rilevanti per il tuo ambiente Google Cloud, ad esempio gli eventi di accesso utente. Ti consigliamo di condividere gli audit log di Cloud Identity con il tuo ambiente Google Cloud per gestire centralmente i log di tutte le origini. |
| Configurare la verifica post-SSO | Il progetto prevede che tu abbia configurato l'accesso SSO con il tuo provider di identità esterno. Ti consigliamo di abilitare un ulteriore livello di controllo basato sull'analisi del rischio associato all'accesso di Google. Dopo aver applicato questa impostazione, gli utenti potrebbero dover effettuare ulteriori verifiche dell'accesso basate sul rischio se Google ritiene che l'accesso di un utente sia sospetto. |
| Risolvere i problemi relativi agli account utente consumer | Gli utenti con un indirizzo email valido nel tuo dominio, ma nessun Account Google, possono registrarsi ad account consumer non gestiti. Questi account potrebbero contenere dati aziendali, ma non sono controllati dai processi di gestione del ciclo di vita dell'account. Ti consigliamo di verificare che tutti gli account utente siano account gestiti. |
| Disabilita il recupero dell'account per gli account super amministratore | Il recupero autonomo dell'account super amministratore è disattivato per impostazione predefinita per tutti i nuovi clienti (per i clienti esistenti potrebbe essere attiva questa impostazione). La disattivazione di questa impostazione aiuta a ridurre il rischio che un attacco telefonico, un'email compromessa o un attacco di ingegneria sociale possano consentire a un utente malintenzionato di ottenere privilegi di super amministratore sul tuo ambiente. Pianifica una procedura interna affinché un super amministratore possa contattare un altro super amministratore della tua organizzazione se ha perso l'accesso al proprio account e assicurati che tutti i super amministratori abbiano familiarità con la procedura per il recupero con assistenza. |
| Applicare e monitorare i requisiti delle password per gli utenti | Nella maggior parte dei casi, le password degli utenti vengono gestite tramite il provider di identità esterno, ma gli account super amministratore ignorano l'accesso SSO e devono utilizzare una password per accedere a Cloud Identity. Disattiva il riutilizzo delle password e monitora la sicurezza della password per tutti gli utenti che utilizzano una password per accedere a Cloud Identity, in particolare per gli account super amministratore. |
| Imposta criteri a livello di organizzazione per l'utilizzo dei gruppi | Per impostazione predefinita, gli account utente esterni possono essere aggiunti ai gruppi in Cloud Identity. Ti consigliamo di configurare le impostazioni di condivisione in modo che i proprietari dei gruppi non possano aggiungere membri esterni. Tieni presente che questa restrizione non si applica all'account super amministratore o ad altri utenti con delega di amministratore con autorizzazioni di amministratore di Gruppi. Poiché la federazione del tuo provider di identità viene eseguita con privilegi di amministratore, le impostazioni di condivisione dei gruppi non si applicano a questa sincronizzazione dei gruppi. Ti consigliamo di rivedere i controlli del provider di identità e del meccanismo di sincronizzazione per assicurarti che non vengano aggiunti membri non del dominio ai gruppi o di applicare limitazioni dei gruppi. |
Passaggi successivi
- Scopri di più sulla struttura organizzativa (documento successivo di questa serie).