Questa sezione introduce l'utilizzo di Cloud Identity per gestire le identità utilizzate dai tuoi 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 aiuta a garantire che le tue procedure di gestione degli 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 panoramica della federazione delle identità e del single sign-on (SSO). Utilizza Microsoft Active Directory, che si trova 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 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 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 nel tuo provider di identità con un meccanismo resistente al phishing, ad esempio un token di sicurezza Titan.
Le impostazioni consigliate per Cloud Identity non vengono automatizzate tramite il codice Terraform in questo blueprint. Consulta Controlli amministrativi per Cloud Identity per le impostazioni di sicurezza consigliate che devi configurare oltre a implementare il codice Terraform.
Gruppi per controllo dell'accesso
Un'entità è un'identità a cui può essere concesso l'accesso a una risorsa. Le entità includono Account Google per gli utenti, gruppi Google, account Google Workspace, domini Cloud Identity e service account. 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 ruoli in Identity and Access Management (IAM).
Per gestire i ruoli IAM su larga scala, ti consigliamo di assegnare gli utenti a gruppi in base alle loro funzioni lavorative e ai requisiti di accesso, quindi concedere i ruoli IAM a questi gruppi. Devi aggiungere utenti ai gruppi utilizzando le procedure del tuo provider di identità esistente per la creazione e l'appartenenza ai gruppi.
Non consigliamo di concedere ruoli IAM ai singoli utenti perché le assegnazioni individuali 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 a utenti e gruppi per modificare le risorse di base al di fuori della pipeline.
La tabella seguente mostra i gruppi configurati dal blueprint 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 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 relativi alla sicurezza. | progetto di logging | |
grp-gcp-security-reviewer@example.com |
Il team responsabile della revisione della sicurezza del 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. | 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 | secrets projects |
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 | kms projects |
Man mano che crei i tuoi carichi di lavoro sulla base, crei gruppi aggiuntivi e concedi ruoli IAM basati sui 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 i ruoli predefiniti in alternativa. 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 al movimento laterale, mentre il ruolo Visualizzatore include l'accesso alla lettura di tutti i dati. Per le best practice sui ruoli IAM, consulta Utilizzare IAM in modo sicuro.
Account super amministratore
Gli utenti Cloud Identity con l'account super amministratore ignorano le impostazioni SSO dell'organizzazione e si autenticano direttamente su Cloud Identity. Questa eccezione è intenzionale, in modo che il super amministratore possa accedere comunque alla console Cloud Identity in caso di errata configurazione o interruzione dell'SSO. Tuttavia, 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, vedi 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 a 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 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 a Google Cloud. Se non utilizzi già Google Workspace per tutti i tuoi account utente, ti consigliamo di bloccare l'accesso agli 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 delle fondamenta.
| Controllo | Descrizione |
|---|---|
| Implementare la verifica in due passaggi | Gli account utente potrebbero essere compromessi tramite phishing, ingegneria sociale, 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 resistente al phishing, ad esempio i token di sicurezza Titan o altri token basati sugli standard FIDO U2F (CTAP1) resistenti al phishing. |
| Impostare la durata della sessione per Google Cloud servizi | I token OAuth persistenti sulle workstation 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 persistenti in 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 i servizi Google Cloud | I log di controllo dell'attività amministrativa 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 pertinenti per il tuo Google Cloud ambiente, ad esempio eventi di accesso degli utenti. Ti consigliamo di condividere gli audit log di Cloud Identity con il tuo ambienteGoogle Cloud per gestire centralmente i log di tutte le origini. |
| Configurare la verifica post-SSO | Il progetto presuppone che tu abbia configurato SSO con il tuo provider di identità esterno. Ti consigliamo di attivare un ulteriore livello di controllo basato sull'analisi del rischio di accesso di Google. Dopo aver applicato questa impostazione, gli utenti potrebbero visualizzare ulteriori verifiche dell'accesso basate sul rischio al momento dell'accesso se Google ritiene che l'accesso di un utente sia sospetto. |
| Risolvi i problemi relativi agli account utente consumer | Gli utenti con un indirizzo email valido nel tuo dominio, ma senza un Account Google, possono registrarsi per account consumer non gestiti. Questi account potrebbero contenere dati aziendali, ma non sono controllati dai processi di gestione del ciclo di vita del tuo account. Ti consigliamo di adottare misure 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 attiva). La disattivazione di questa impostazione contribuisce a ridurre il rischio che uno smartphone compromesso, un'email compromessa o un attacco di ingegneria sociale possano consentire a un malintenzionato di ottenere privilegi di super amministratore sul tuo ambiente. Pianifica una procedura interna per consentire 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. |
| Applicare e monitorare requisiti per le password degli 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'SSO e devono utilizzare una password per accedere a Cloud Identity. Disattiva il riutilizzo delle password e monitora la loro efficacia 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 privilegi amministrativi, le impostazioni di condivisione del gruppo non si applicano a questa sincronizzazione del gruppo. Ti consigliamo di esaminare i controlli nel provider di identità e nel meccanismo di sincronizzazione per assicurarti che i membri non di dominio non vengano aggiunti ai gruppi o di applicare limitazioni ai gruppi. |
Passaggi successivi
- Scopri di più sulla struttura organizzativa (il prossimo documento di questa serie).