Questa sezione illustra come utilizzare Cloud Identity per gestire le identità che i tuoi dipendenti utilizzano per accedere a Google Cloud i servizi di machine learning.
Provider di identità esterno come fonte attendibile
Ti consigliamo di federare il tuo account Cloud Identity con il tuo o provider di identità. La federazione ti aiuta a garantire che l'account esistente i processi di gestione si applicano a Google Cloud e ad altri servizi Google.
Se non hai un provider di identità, puoi creare account utente. direttamente in Cloud Identity.
Il seguente diagramma mostra una vista generale della federazione delle identità e dei singoli l'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 alla provider di identità esterno per Single Sign-On con SAML, usando 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 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 vengono automatizzate tramite il codice Terraform in questo progetto. Consulta: Controlli amministrativi per Cloud Identity per le impostazioni di sicurezza consigliate che è necessario configurare in aggiunta il deployment del codice Terraform.
Gruppi per il controllo dell'accesso
Un'entità è un'identità a cui è possibile concedere l'accesso a una risorsa. Presidi includono Account Google per gli utenti, gruppi Google, account Google Workspace, Cloud Identity domini 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à principale possa interagire con i servizi Google Cloud, devi concedergli 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 progetto pipeline di base e di non concedere ruoli agli utenti ai gruppi 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 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 Cloud Billing. Questo privilegio non è consigliato per per gli utilizzi odierni. | 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 dell'audit della sicurezza logaritmi. | 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 gestione della rete configurazioni. | Visualizzatore di rete Compute | 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 credenziali e altri secret utilizzati dalle applicazioni. | Amministratore Secret Manager | progetti secrets |
grp-gcp-kms-admin@example.com |
Il team responsabile dell'applicazione della chiave di crittografia per soddisfare i requisiti di conformità. | Visualizzatore Cloud KMS | Progetti kms |
Man mano che crei i tuoi carichi di lavoro sulle basi, crei ulteriori gruppi e concedere ruoli IAM basati sui requisiti di accesso per ciascuno 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. Proprietario e Editor possono portare all'escalation dei privilegi e allo spostamento laterale, Il ruolo Visualizzatore include l'accesso per leggere tutti i dati. Per le best practice su IAM ruoli, consulta Utilizza 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 è per definizione, per cui il super amministratore può accederà comunque alla console di Cloud Identity nel caso di un SSO o in caso di interruzione del servizio. Ciò significa, però, che devi prendere in considerazione 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 maggiori informazioni le informazioni, vedi Best practice per la protezione degli account amministratore.
Problemi con gli account utente consumer
Se non utilizzavi Cloud Identity o Google Workspace prima di è stato eseguito l'onboarding in Google Cloud, è possibile che i dipendenti usano già account consumer associati alle proprie 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 Google Workspace per tutti gli account utente, ti consigliamo il blocco della 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 in modo forzato ogni di questi controlli di sicurezza basati sulle best practice nelle prime fasi del processo di creazione base.
| Controllo | Descrizione |
|---|---|
| Implementare la verifica in due passaggi | Gli account utente potrebbero essere compromessi tramite phishing, social media ingegneria informatica, password spraying o varie 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 con un meccanismo anti-phishing, come i token di sicurezza Titan o altri token basati sugli standard FIDO U2F (CTAP1) anti-phishing. |
| Imposta la durata della sessione per Servizi Google Cloud | Token OAuth permanenti sullo sviluppatore workstation può rappresentare un rischio per la sicurezza se esposte. È consigliabile imposti un criterio di riautenticazione per richiedere l'autenticazione ogni 16 ore con un token di sicurezza. |
| Impostare la durata della sessione per Google Servizi | (solo clienti Google Workspace)
Le sessioni web persistenti tra altri servizi Google possono essere rischio per la sicurezza se esposti. Ti consigliamo di applicare un limite massimo durata della sessione web e allinearla ai controlli della durata della sessione al tuo provider SSO. |
| Condividere i dati di Cloud Identity con i servizi Google Cloud | 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 nell'ambiente Google Cloud. Questi log contengono informazioni pertinente per il tuo ambiente Google Cloud, 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 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 al momento dell'accesso potrebbero essere visualizzate ulteriori verifiche dell'accesso basate sul rischio se Google ritiene che l'accesso di un utente sia sospetto. |
| Risolvere i problemi relativi agli utenti consumer account | Utenti con un indirizzo email valido nel tuo dominio, ma senza un Account Google possono registrarsi ad account consumer non gestiti. Questi account potrebbero contengono dati aziendali, ma non sono controllati dal tuo account. dei processi di gestione del ciclo di vita. Ti consigliamo di adottare le misure necessarie per assicurarti che tutti gli account utente siano account gestiti. |
| Disattiva il recupero dell'account per Super account 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 possano consentire a un malintenzionato di ottenere i privilegi di super amministratore del tuo ambiente. Pianificare una procedura interna per consentire a un super amministratore di contattare un altro super amministratore 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 assistito dall'assistenza. |
| Applicare e monitorare le password requisiti per gli utenti | Nella maggior parte dei casi, le password degli utenti vengono gestite tramite il provider di identità, 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 l'efficacia delle 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 utilizzando i 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 al super amministratore account amministratore o altri amministratori delegati con l'amministratore di Gruppi autorizzazioni aggiuntive. 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 rivedere i controlli in il provider di identità e il meccanismo di sincronizzazione per garantire I membri non di dominio non vengono aggiunti ai gruppi o a cui applichi limitazioni di gruppo. |
Passaggi successivi
- Scopri di più sulla struttura organizzativa (documento successivo di questa serie).