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 il tuo account Cloud Identity con il tuo provider di identità esistente. La federazione ti consente di assicurarti che le procedure di gestione dell'account esistenti si applichino a Google Cloud e ad altri servizi Google.
Se non hai un provider di identità esistente, puoi creare account utente direttamente in Cloud Identity.
Il seguente diagramma mostra una visione di alto livello della federazione delle identità e del singolo accesso (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à utente vengono gestite in un dominio Active Directory situato 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 viene sincronizzata con Cloud Identity.
La tabella seguente fornisce i link alle indicazioni per la configurazione dei 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 fornitore di servizi di identità con un meccanismo resistente al phishing, come un token di sicurezza Titan.
Le impostazioni consigliate per Cloud Identity non sono automatizzate tramite il codice Terraform in questo blueprint. Consulta i controlli amministrativi per Cloud Identity per le impostazioni di sicurezza consigliate da configurare oltre al deployment del codice Terraform.
Gruppi per controllo dell'accesso
Un'entità è un'identità a cui è possibile concedere l'accesso a una risorsa. I principali includono Account Google per gli utenti, gruppi Google, account Google Workspace, domini Cloud Identity e account di servizio. Alcuni servizi ti consentono anche di concedere l'accesso a tutti gli utenti che si autenticano 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, quindi di concedere i ruoli IAM a questi gruppi. Devi aggiungere gli utenti ai gruppi utilizzando le procedure del tuo provider di identità esistente per la creazione e l'appartenenza ai gruppi.
Sconsigliamo di concedere ruoli IAM ai singoli utenti perché le singole assegnazioni possono aumentare la complessità della gestione e del controllo dei ruoli.
Il blueprint configura gruppi e ruoli per l'accesso di sola visualizzazione alle risorse di base. Ti consigliamo di eseguire il deployment di tutte le risorse nel blueprint tramite la pipeline di base e di non concedere ruoli agli utenti dei gruppi per modificare le risorse di base al di fuori della pipeline.
La tabella seguente mostra i gruppi configurati dal blueprint per visualizzare le risorse della Fondazione.
Nome | Descrizione | Ruoli | Ambito |
---|---|---|---|
grp-gcp-org-admin@example.com |
Amministratori con privilegi elevati che possono concedere ruoli IAM a livello di organizzazione. Possono 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 quotidiano. | Amministratore account di fatturazione | organizzazione |
grp-gcp-billing-viewer@example.com |
Il team responsabile della visualizzazione e dell'analisi della spesa in tutti i progetti. | Visualizzatore account di fatturazione | organizzazione |
Utente BigQuery | progetto di fatturazione | ||
grp-gcp-audit-viewer@example.com |
Il team responsabile del controllo dei log correlati alla sicurezza. | progetto di logging | |
grp-gcp-security-reviewer@example.com |
Il team responsabile della revisione della sicurezza nel cloud. | Security Reviewer | organizzazione |
grp-gcp-network-viewer@example.com |
Il team responsabile della visualizzazione e della manutenzione delle configurazioni di rete. | Compute Network Viewer | organizzazione |
grp-gcp-scc-admin@example.com |
Il team responsabile della configurazione di Security Command Center. | Security Center Admin Editor | 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 di Secret Manager | progetti secrets |
grp-gcp-kms-admin@example.com |
Il team responsabile dell'applicazione della gestione delle chiavi di crittografia per soddisfare i requisiti di conformità. | Cloud KMS Viewer | Progetti kms |
Quando crei i tuoi carichi di lavoro sulla base, crei gruppi aggiuntivi e concedi ruoli IAM in base ai requisiti di accesso per ogni 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 e Editor possono comportare l'aumento dei privilegi e il movimento laterale, mentre il ruolo Visualizzatore include l'accesso in lettura a 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 aggirano le impostazioni SSO dell'organizzazione e si autenticano direttamente in Cloud Identity. Questa eccezione è prevista per impostazione predefinita, in modo che il super amministratore possa ancora accedere alla console Cloud Identity in caso di mancata configurazione o interruzione del servizio SSO. Tuttavia, significa che devi prendere in considerazione una protezione aggiuntiva per gli account super amministratore.
Per proteggere i tuoi account super amministratore, ti consigliamo di applicare sempre la verifica in due passaggi con i token di sicurezza in Cloud Identity. Per ulteriori informazioni, consulta le best practice per la sicurezza degli account amministratore.
Problemi con gli account utente consumer
Se non utilizzavi Cloud Identity o Google Workspace prima di eseguire l'onboarding in Google Cloud, è possibile che i dipendenti della tua organizzazione stiano già utilizzando 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 interamente di proprietà 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 consolidarli 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 che non sono automatizzati dal codice Terraform nel blueprint. Ti consigliamo di applicare ciascuno di questi controlli di sicurezza delle best practice all'inizio del processo di creazione della tua base.
Controllo | Descrizione |
---|---|
Implementare la verifica in due passaggi | Gli account utente potrebbero essere compromessi tramite phishing, social engineering, password spraying o varie altre minacce. La verifica in due passaggi contribuisce a mitigare queste minacce. Ti consigliamo di applicare la verifica in due passaggi a tutti gli account utente della tua organizzazione con un meccanismo anti-phishing, come i token di sicurezza Titan o altri token basati sugli standard FIDO U2F (CTAP1) anti-phishing. |
Impostare la durata della sessione per i Google Cloud servizi | I token OAuth permanenti sulle postazioni di lavoro degli sviluppatori possono rappresentare un rischio per la sicurezza se esposti. Ti consigliamo di impostare un criterio di riautenticazione per richiedere l'autenticazione ogni 16 ore utilizzando un token di sicurezza. |
Impostare la durata della sessione per i servizi Google | (solo clienti Google Workspace)
Le sessioni web permanenti su altri servizi Google possono rappresentare un rischio per la sicurezza se esposte. Ti consigliamo di applicare una durata massima della sessione web e di allinearla ai controlli della durata della sessione nel tuo provider SSO. |
Condividere i dati di Cloud Identity con Google Cloud servizi | I log di controllo delle attività amministrative di Google Workspace o Cloud Identity vengono in genere gestiti e visualizzati nella Console di amministrazione, separatamente dai log nel tuo Google Cloud ambiente. Questi log contengono informazioni pertinenti per il tuo Google Cloud ambiente, ad esempio gli eventi di accesso degli utenti. Ti consigliamo di condividere gli audit log di Cloud Identity con il tuo Google Cloud ambiente per gestire centralmente i log di tutte le fonti. |
Configurare la verifica post-SSO | Il blueprint presuppone che tu abbia configurato l'accessoSSO con il tuo provider di identità esterno. Ti consigliamo di attivare un ulteriore livello di controllo in base all'analisi dei rischi di accesso di Google. Dopo aver applicato questa impostazione, gli utenti potrebbero dover sostenere ulteriori verifiche dell'accesso basate sul rischio al momento dell'accesso se Google ritiene che l'accesso di un utente sia sospetto. |
Risolvere i problemi relativi agli account degli utenti consumer | Gli utenti con un indirizzo email valido nel tuo dominio, ma senza Account Google, possono registrarsi per gli account consumer non gestiti. Questi account potrebbero contenere dati aziendali, ma non sono controllati dalle procedure di gestione del ciclo di vita dell'account. Ti consigliamo di adottare le misure necessarie per assicurarti che tutti gli account utente siano account gestiti. |
Disattivare 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 (i clienti esistenti potrebbero avere questa impostazione attivata). La disattivazione di questa impostazione contribuisce a ridurre il rischio che un attacco di ingegneria sociale o un telefono o un'email compromessi consentano a un malintenzionato di ottenere privilegi di super amministratore nel tuo ambiente. Pianifica una procedura interna che consenta a un super amministratore di contattare un altro super amministratore della tua organizzazione se ha perso l'accesso al proprio account e assicurati che tutti i super amministratori conoscano la procedura per il recupero con l'assistenza dell'Assistenza Google. |
Applicare e monitorare i requisiti per le password degli utenti | Nella maggior parte dei casi, le password utente vengono gestite tramite il tuo provider di identità esterno, ma gli account super amministratore aggirano il SSO e devono utilizzare una password per accedere a Cloud Identity. Disattiva il riutilizzo delle password e monitora l'efficacia delle password per tutti gli utenti che utilizzano una password per accedere a Cloud Identity, in particolare per gli account super amministratore. |
Impostare 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 limitazione non si applica all'account super amministratore o ad altri amministratori delegati con autorizzazioni di amministratore di Gruppi. Poiché la federazione dal tuo provider di identità viene eseguita con i privilegi di amministratore, le impostazioni di condivisione dei gruppi non si applicano a questa sincronizzazione dei gruppi. Ti consigliamo di esaminare i controlli nel fornitore di identità e nel meccanismo di sincronizzazione per assicurarti che i membri non del dominio non vengano aggiunti ai gruppi o di applicare le limitazioni dei gruppi. |
Passaggi successivi
- Leggi l'articolo sulla struttura organizzativa (documento successivo di questa serie).