Best practice per l'utilizzo dei CMEK

Questa pagina illustra le best practice per la configurazione della crittografia at-rest con le chiavi di crittografia gestite dal cliente (CMEK) nelle risorse Google Cloud. Questa guida è rivolta ad architetti cloud e team di sicurezza e illustra le best practice e le decisioni che devi prendere durante la progettazione dell'architettura CMEK.

Questa guida presuppone che tu abbia già dimestichezza con Cloud Key Management Service (Cloud KMS) e che tu abbia letto la guida approfondita su Cloud KMS.

Decisioni preliminari

I consigli riportati in questa pagina sono rivolti ai clienti che utilizzano le chiavi CMEK per criptare i propri dati. Se non sai se utilizzare CMEK creati manualmente o automaticamente nell'ambito della tua strategia di sicurezza, questa sezione fornisce indicazioni per queste decisioni preliminari.

Decidere se utilizzare CMEK

Ti consigliamo di utilizzare CMEK per criptare i dati at-rest nei servizi Google Cloud se hai bisogno di una delle seguenti funzionalità:

  • Possiedi le tue chiavi di crittografia.

  • Controlla e gestisci le tue chiavi di crittografia, inclusa la scelta della posizione, del livello di protezione, della creazione, controllo dell'accesso, della rotazione, dell'utilizzo e della distruzione.

  • Genera il materiale della chiave in Cloud KMS o importa il materiale della chiave gestito al di fuori di Google Cloud.

  • Imposta le norme relative a dove devono essere utilizzate le chiavi.

  • Eliminare in modo selettivo i dati protetti dalle tue chiavi in caso di offboarding o per risolvere gli eventi di sicurezza (crypto-shredding).

  • Crea e utilizza chiavi univoche per un cliente, stabilendo un confine criptato per i tuoi dati.

  • Registra l'accesso amministrativo e ai dati alle chiavi di crittografia.

  • Soddisfare le normative attuali o future che richiedono uno di questi obiettivi.

Se non hai bisogno di queste funzionalità, valuta se la crittografia predefinita a riposo con chiavi gestite da Google è appropriata per il tuo caso d'uso. Se scegli di utilizzare solo la crittografia predefinita, puoi interrompere la lettura di questa guida.

Scegli la creazione manuale o automatica delle chiavi

Questa guida illustra le best practice per le decisioni che devi prendere quando esegui autonomamente il provisioning dei CMEK. Cloud KMS Autokey prende alcune di queste decisioni per te e automatizza molti consigli di questa guida. L'utilizzo di Autokey è più semplice del provisioning delle chiavi e rappresenta la scelta consigliata se le chiavi create da Autokey soddisfano tutti i tuoi requisiti.

Autokey esegue il provisioning dei CMEK per te. I CMEK di cui è stato eseguito il provisioning tramite Autokey hanno le seguenti caratteristiche:

  • Livello di protezione: HSM.
  • Algoritmo:AES-256 GCM.

  • Periodo di rotazione: un anno.

    Dopo che una chiave è stata creata da Autokey, un amministratore Cloud KMS può modificare il periodo di rotazione rispetto al valore predefinito.

  • Separazione dei compiti:
    • All'account di servizio del servizio vengono concesse automaticamente le autorizzazioni di crittografia e decrittografia per la chiave.
    • Le autorizzazioni di amministratore Cloud KMS si applicano come di consueto alle chiavi create da Autokey. Gli amministratori di Cloud KMS possono visualizzare, aggiornare, attivare o disattivare e distruggere le chiavi create da Autokey. Agli amministratori di Cloud KMS non vengono assegnate autorizzazioni di crittografia e decrittografia.
    • Gli sviluppatori di Autokey possono richiedere solo la creazione e l'assegnazione delle chiavi. Non possono visualizzare o gestire le chiavi.
  • Specificità o granularità della chiave: le chiavi create da Autokey hanno una granularità che varia in base al tipo di risorsa. Per dettagli specifici del servizio sulla granularità delle chiavi, consulta Servizi compatibili.

  • Posizione:Autokey crea le chiavi nella stessa posizione della risorsa da proteggere.

    Se devi creare risorse protette da CMEK in località in cui Cloud HSM non è disponibile, devi creare il CMEK manualmente.

  • Stato della versione della chiave: le chiavi appena create richieste utilizzando Autokey vengono create come versione della chiave primaria nello stato abilitato.
  • Nomi dei keyring: tutte le chiavi create da Autokey vengono create in un keyring denominato autokey nel progetto Autokey nella località selezionata. I keyring nel progetto Autokey vengono creati quando un sviluppatore Autokey richiede la prima chiave in una determinata posizione.
  • Nomi delle chiavi: le chiavi create da Autokey seguono questa convenzione di denominazione: PROJECT_NUMBER-SERVICE_SHORT_NAME-RANDOM_HEX
  • Esportazione delle chiavi: come tutte le chiavi Cloud KMS, le chiavi create da Autokey non possono essere esportate.
  • Monitoraggio delle chiavi: come tutte le chiavi Cloud KMS utilizzate nei servizi integrati CMEK compatibili con il monitoraggio delle chiavi, le chiavi create da Autokey vengono monitorate nella dashboard di Cloud KMS.

Se hai requisiti che non possono essere soddisfatti con le chiavi create da Autokey, ad esempio un livello di protezione diverso da HSM o servizi che non sono compatibili con Autokey, ti consigliamo di utilizzare le chiavi CMEK create manualmente anziché Autokey.

Progetta l'architettura CMEK

Quando progetti un'architettura CMEK, devi considerare la configurazione delle chiavi che utilizzerai e il modo in cui vengono gestite. Queste decisioni influiscono sul costo, sul sovraccarico operativo e sulla facilità di implementazione di funzionalità come la crittografia distruttiva.

Le sezioni seguenti illustrano i consigli per ogni scelta di design.

Utilizza un progetto di chiavi CMEK centralizzato per ogni ambiente

Ti consigliamo di utilizzare un progetto di chiavi CMEK centralizzato per ogni cartella dell'ambiente. Non creare risorse criptate con CMEK nello stesso progetto in cui gestisci le chiavi Cloud KMS. Questo approccio aiuta a impedire la condivisione delle chiavi di crittografia tra gli ambienti e a consentire la separazione delle responsabilità.

Il seguente diagramma illustra questi concetti nel design consigliato:

  • Ogni cartella dell'ambiente ha un progetto di chiavi Cloud KMS gestito distintamente dai progetti di applicazione.
  • I keyring e le chiavi Cloud KMS vengono configurati nel progetto chiavi Cloud KMS e queste chiavi vengono utilizzate per criptare le risorse nei progetti di applicazione.
  • I criteri Identity and Access Management (IAM) vengono applicati a progetti o cartelle per consentire la separazione dei compiti. Il principale che gestisce le chiavi Cloud KMS nel progetto chiavi Cloud KMS non è lo stesso che utilizza le chiavi di crittografia nei progetti di applicazione.

Struttura di progetto e cartella Cloud KMS consigliata

Se utilizzi Cloud KMS Autokey, ogni cartella per la quale è attivato Autokey deve avere un progetto di chiavi Cloud KMS dedicato.

Crea keyring Cloud KMS per ogni località

Devi creare keyring Cloud KMS nelle località in cui esegui il deployment delle risorse Google Cloud criptate con CMEK.

  • Le risorse a livello di regione e di zona devono utilizzare un keyring e un CMEK nella stessa regione della risorsa o nella località global. Le risorse a livello di regione e di zona non possono utilizzare un keyring multi-regione diverso da global.
  • Le risorse multiregione (ad esempio un set di dati BigQuery nella regione us multiregione) devono utilizzare un portachiavi e un CMEK nella stessa regione multiregione o duale. Le risorse multiregione non possono utilizzare un keyring regionale.
  • Le risorse globali devono utilizzare un keyring e CMEK nella località global.

L'applicazione delle chiavi regionali è un aspetto di una strategia di regionalizzazione dei dati. Se fornisci l'utilizzo di keyring e chiavi in una regione definita, fornisci anche l'utilizzo di risorse che devono corrispondere alla regione del keyring. Per indicazioni sulla residenza dei dati, consulta Implementare i requisiti di residenza e sovranità dei dati.

Per i carichi di lavoro che richiedono funzionalità di alta disponibilità o di ripristino di emergenza in più località, è tua responsabilità valutare se il tuo carico di lavoro è resiliente nel caso in cui Cloud KMS non sia disponibile in una determinata regione. Ad esempio, un disco permanente Compute Engine criptato con una chiave Cloud KMS di us-central1 non può essere ricreato in us-central2 in uno scenario di ripristino di emergenza in cui us-central1 non è disponibile. Per ridurre il rischio di questo scenario, puoi pianificare la crittografia di una risorsa con chiavi global.

Per ulteriori informazioni, consulta Scegliere il tipo di località migliore.

Se utilizzi Cloud KMS Autokey, i keyring vengono creati nella stessa posizione delle risorse che proteggi.

Scegli una strategia di granularità delle chiavi

La granularità si riferisce alla scala e all'ambito dell'utilizzo previsto di ogni chiave. Ad esempio, una chiave che protegge più risorse è meno granulare di una chiave che protegge una sola risorsa.

Le chiavi Cloud KMS di cui è stato eseguito il provisioning manuale per CMEK devono essere provisionate in advance prima di creare una risorsa che verrà criptata con la chiave, ad esempio un disco permanente Compute Engine. Puoi scegliere di creare chiavi molto granulari per le singole risorse o chiavi meno granulari per il riutilizzo tra le risorse in modo più generale.

Sebbene non esista uno schema universalmente corretto, valuta i seguenti compromessi dei diversi schemi:

Chiavi ad alta granularità, ad esempio una chiave per ogni singola risorsa

  • Maggiore controllo per disattivare in sicurezza le versioni delle chiavi: la disattivazione o l'eliminazione di una versione della chiave utilizzata per un ambito ristretto comporta un rischio inferiore di influire su altre risorse rispetto alla disattivazione o all'eliminazione di una chiave condivisa. Ciò significa anche che l'utilizzo di chiavi altamente granulari contribuisce a ridurre l'impatto potenziale della compromissione di una chiave rispetto all'utilizzo di chiavi a bassa granularità.
  • Costo: l'utilizzo di chiavi granulari richiede la gestione di più versioni attive rispetto a una strategia che utilizza chiavi con una granularità inferiore. Poiché i prezzi di Cloud KMS si basano sul numero di versioni della chiave attive, la scelta di una granularità della chiave più elevata comporta costi più elevati.
  • Overhead operativo: l'utilizzo di chiavi altamente granulari potrebbe richiedere un impegno amministrativo o strumenti aggiuntivi per l'automazione per il provisioning di un gran numero di risorse Cloud KMS e per gestire i controlli di accesso per gli agenti di servizio in modo che possano utilizzare solo le chiavi appropriate. Se hai bisogno di chiavi con elevata granularità, Autokey potrebbe essere una buona scelta per automatizzare il provisioning. Per ulteriori informazioni sulla granularità della chiave di Autokey per ciascun servizio, consulta Servizi compatibili.

Chiavi a bassa granularità, ad esempio una chiave per ogni applicazione, per ogni regione e per ogni ambiente

  • È necessario prestare attenzione per disattivare in sicurezza le versioni delle chiavi: la disattivazione o l'eliminazione di una versione della chiave utilizzata per un ambito ampio richiede più attenzione rispetto alla disattivazione o all'eliminazione di una chiave altamente granulare. Prima di disattivare la vecchia versione della chiave, devi assicurarti che tutte le risorse criptate da quella versione vengano criptate di nuovo in modo sicuro con una nuova versione. Per molti tipi di risorse, puoi visualizzare l'utilizzo delle chiavi per identificare dove è stata utilizzata una chiave. Ciò significa anche che l'utilizzo di chiavi a bassa granularità può aumentare l'impatto potenziale della compromissione di una chiave rispetto all'utilizzo di chiavi ad alta granularità.
  • Costo: l'utilizzo di chiavi meno granulari richiede la creazione di meno versioni della chiave e i prezzi di Cloud KMS si basano sul numero di versioni della chiave attive.
  • Overhead operativo: puoi definire e preconfigurare un numero noto di chiavi con meno impegno per garantire controlli di accesso appropriati.

Scegliere il livello di protezione per le chiavi

Quando crei una chiave, è tua responsabilità selezionare il livello di protezione appropriato per ogni chiave in base ai tuoi requisiti per i dati e i carichi di lavoro criptati con CMEK. Le seguenti domande possono aiutarti nella valutazione:

  1. Hai bisogno di una delle funzionalità CMEK? Puoi esaminare le funzionalità elencate in Decidere se utilizzare CMEK in questa pagina.

  2. È necessario che il materiale della chiave rimanga all'interno del confine fisico di un modulo di sicurezza hardware (HSM)?

    • In questo caso, vai alla domanda successiva.
    • In caso contrario, ti consigliamo di utilizzare CMEK con chiavi basate su software.

  3. È necessario che il materiale della chiave venga archiviato al di fuori di Google Cloud?

Autokey supporta solo il livello di protezione HSM. Se hai bisogno di altri livelli di protezione, devi eseguire il provisioning delle chiavi autonomamente.

Se possibile, utilizza il materiale della chiave generato da Google

Questa sezione non si applica alle chiavi Cloud EKM.

Quando crei una chiave, devi consentire a Cloud KMS di generare il materiale della chiave per te o importare manualmente il materiale della chiave generato al di fuori di Google Cloud. Se possibile, ti consigliamo di scegliere l'opzione generata. Questa opzione non espone il materiale della chiave non elaborato al di fuori di Cloud KMS e crea automaticamente nuove versioni della chiave in base al periodo di rotazione della chiave scelto. Se hai bisogno dell'opzione per importare il tuo materiale per le chiavi, ti consigliamo di valutare le seguenti considerazioni operative e i rischi dell'utilizzo dell'approccio BYOK (Bring Your Own Key):

  • Puoi implementare l'automazione per importare in modo coerente le nuove versioni delle chiavi? Sono incluse sia le impostazioni Cloud KMS per limitare le versioni delle chiavi all'importazione sia l'automazione al di fuori di Cloud KMS per generare e importare in modo coerente il materiale della chiave. Qual è l'impatto se l'automazione non riesce a creare una nuova versione della chiave al momento previsto?
  • Come intendi archiviare o mettere in custodia in modo sicuro il materiale della chiave originale?
  • Come puoi ridurre il rischio che il processo di importazione delle chiavi lasci trapelare il materiale della chiave non elaborato?
  • Quali sarebbero le conseguenze della reimportazione di una chiave eliminata in precedenza perché il materiale della chiave non elaborato è stato conservato al di fuori di Google Cloud?
  • Il vantaggio dell'importazione autonoma del materiale chiave giustifica l'aumento del costo operativo e del rischio?

Scegli lo scopo e l'algoritmo della chiave più adatti alle tue esigenze

Quando crei una chiave, devi selezionare lo scopo e l'algoritmo sottostante per la chiave. Per i casi d'uso CMEK, è possibile utilizzare solo chiavi con lo scopo ENCRYPT_DECRYPT simmetrico. Questo scopo della chiave utilizza sempre l'algoritmoGOOGLE_SYMMETRIC_ENCRYPTION, che utilizza chiavi Advanced Encryption Standard (AES-256) a 256 bit in modalità Galois Counter (GCM), con padding di metadati interni di Cloud KMS. Quando utilizzi Autokey, queste impostazioni vengono applicate automaticamente.

Per altri casi d'uso, come la crittografia lato client, esamina gli scopi e gli algoritmi delle chiavi disponibili per scegliere l'opzione più adatta al tuo caso d'uso.

Scegli un periodo di rotazione

Ti consigliamo di valutare il periodo di rotazione delle chiavi appropriato per le tue esigenze. La frequenza di rotazione della chiave dipende dai requisiti dei carichi di lavoro in base alla sensibilità o alla conformità. Ad esempio, rotazione della chiave potrebbe essere obbligatoria almeno una volta all'anno per soddisfare determinati standard di conformità oppure potresti scegliere un periodo di rotazione più frequente per i carichi di lavoro altamente sensibili.

Dopo aver ruotato una chiave simmetrica, la nuova versione viene contrassegnata come versione della chiave primaria e viene utilizzata per tutte le nuove richieste per proteggere le informazioni. Le vecchie versioni delle chiavi rimangono disponibili per la decriptazione dei dati criptati in precedenza protetti con quella versione. Quando ruoti una chiave, i dati criptati con le versioni precedenti della chiave non vengono criptati di nuovo automaticamente.

La rotazione frequente delle chiavi consente di limitare il numero di messaggi criptati con la stessa versione della chiave, il che contribuisce a ridurre il rischio e le conseguenze della compromissione di una chiave.

Se utilizzi Autokey, le chiavi vengono create utilizzando un periodo di rotazione della chiave predefinito di un anno. Puoi modificare il periodo di rotazione delle chiavi dopo averle create.

Applica controlli di accesso appropriati

Ti consigliamo di prendere in considerazione i principi del privilegio minimo e della separazione dei compiti quando pianifichi i controlli di accesso. Le sezioni seguenti illustrano questi consigli.

Applica il principio del privilegio minimo

Quando assegni l'autorizzazione per la gestione dei CMEK, tieni presente il principio del privilegio minimo e concedi le autorizzazioni minime necessarie per eseguire un'attività. Ti consigliamo vivamente di evitare di utilizzare i ruoli di base. Assegna invece ruoli Cloud KMS predefiniti per ridurre i rischi di incidenti di sicurezza relativi all'accesso con privilegi in eccesso.

Le violazioni di questo principio e i problemi correlati possono essere rilevati automaticamente dai risultati sulle vulnerabilità di Security Command Center per IAM.

Pianifica la separazione dei compiti

Mantieni identità e autorizzazioni separate per chi amministra le chiavi di crittografia e per chi le utilizza. Lo standard NIST SP 800-152 definisce una separazione dei compiti tra l'ufficiale responsabile della crittografia che attiva e gestisce i servizi di un sistema di gestione delle chiavi di crittografia e un utente che utilizza queste chiavi per criptare o decriptare le risorse.

Quando utilizzi le chiavi CMEK per gestire la crittografia at-rest con i servizi Google Cloud, il ruolo IAM per l'utilizzo delle chiavi di crittografia viene assegnato all'agente di servizio del servizio Google Cloud, non al singolo utente. Ad esempio, per creare oggetti in un bucket Cloud Storage criptato, un utente deve disporre solo del ruolo IAM roles/storage.objectCreator, mentre l'agente di servizio Cloud Storage nello stesso progetto (ad esempio service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) deve disporre del ruolo IAM roles/cloudkms.cryptoKeyEncrypterDecrypter.

La tabella seguente elenca i ruoli IAM tipicamente associati a ciascuna funzione lavorativa:

Ruolo IAM Descrizione Designazione NIST SP 800-152
roles/cloudkms.admin Fornisce l'accesso alle risorse Cloud KMS, ad eccezione dell'accesso a tipi di risorse e operazioni crittografiche con limitazioni. Funzionariato per la crittografia
roles/cloudkms.cryptoKeyEncrypterDecrypter Offre la possibilità di utilizzare le risorse Cloud KMS solo per le operazioni encrypt e decrypt. Utente del sistema di gestione delle chiavi di crittografia
roles/cloudkms.viewer Abilita le operazioni get e list. Amministratore di controllo

Le violazioni di questo principio e i problemi correlati possono essere rilevati automaticamente tramite i risultati relativi alle vulnerabilità di Security Command per Cloud KMS.

Applicare CMEK in modo coerente

Le sezioni seguenti descrivono controlli aggiuntivi per contribuire ad attenuare i rischi, come l'utilizzo incoerente delle chiavi o l'eliminazione o la distruzione accidentale.

Applicare i pignoramenti del progetto

Ti consigliamo di proteggere i progetti con blocchi per evitare l'eliminazione accidentale. Quando viene applicato un blocco del progetto, l'eliminazione del progetto della chiave Cloud KMS viene bloccata fino alla rimozione del blocco.

Richiedere chiavi CMEK

Ti consigliamo di applicare l'utilizzo di CMEK nell'ambiente utilizzando i vincoli delle norme dell'organizzazione.

Utilizza constraints/gcp.restrictNonCmekServices per bloccare le richieste di creazione di determinati tipi di risorse senza specificare una chiave CMEK.

Richiedere una durata minima per l'eliminazione pianificata

Ti consigliamo di impostare una durata minima per Pianificata per l'eliminazione. La distruzione delle chiavi è un'operazione irreversibile che può comportare la perdita di dati. Per impostazione predefinita, Cloud KMS utilizza una durata pianificata per l'eliminazione (a volte chiamata periodo di eliminazione temporanea) di 30 giorni prima che il materiale della chiave venga distrutto in modo irreversibile. In questo modo hai un po' di tempo per recuperare una chiave in caso di distruzione accidentale. Tuttavia, è possibile per un utente con il ruolo di amministratore Cloud KMS creare una chiave con una durata pianificata per l'eliminazione minima di 24 ore, che potrebbe non essere sufficiente per rilevare un problema e ripristinare la chiave. La durata Prevista per l'eliminazione può essere impostata solo durante la creazione della chiave.

Mentre una chiave è prevista per l'eliminazione, non può essere utilizzata per operazioni di crittografia e tutte le richieste di utilizzo della chiave non vanno a buon fine. Durante questo periodo, monitora i log di controllo per verificare che la chiave non sia in uso. Se vuoi utilizzare di nuovo la chiave, devi restore prima del termine del periodo prevista per la distruzione.

Per assicurarti che tutte le chiavi create rispettino una durata minima pianificata per l'eliminazione, ti consigliamo di configurare il vincolo dei criteri dell'organizzazione constraints/cloudkms.minimumDestroyScheduledDuration con un minimo di 30 giorni o con la durata che preferisci. Questo criterio dell'organizzazione impedisce agli utenti di creare chiavi con una durata pianificata per l'eliminazione inferiore al valore specificato nel criterio.

Applica i livelli di protezione consentiti per i CMEK

Ti consigliamo di applicare i requisiti per i livelli di protezione delle chiavi in modo coerente nell'ambiente utilizzando i vincoli dei criteri dell'organizzazione.

Utilizza constraints/cloudkms.allowedProtectionLevels per imporre che le nuove chiavi, le versioni delle chiavi e i job di importazione debbano utilizzare i livelli di protezione che consenti.

Configura i controlli di rilevamento per i CMEK

Google Cloud offre vari controlli di rilevamento per i CMEK. Le sezioni che seguono illustrano come attivare e utilizzare questi controlli pertinenti per Cloud KMS.

Attivare e aggregare la registrazione degli audit

Ti consigliamo di aggregare gli audit log delle attività amministrative di Cloud KMS (insieme agli audit log delle attività amministrative per tutti i servizi) in una posizione centralizzata per tutte le risorse della tua organizzazione. In questo modo, un team di sicurezza o un revisore può esaminare contemporaneamente tutte le attività relative alla creazione o alla modifica delle risorse Cloud KMS. Per guidance sulla configurazione dei sink dei log aggregati, consulta Aggregare e archiviare i log dell'organizzazione.

Se vuoi, puoi attivare i log di accesso ai dati per registrare le operazioni che utilizzano le chiavi, incluse le operazioni di crittografia e decrittografia. Quando utilizzi le chiavi CMEK, questo può generare un volume di log considerevole e influire sui costi perché ogni operazione di ogni servizio che utilizza le chiavi CMEK creerà log di accesso ai dati. Prima di attivare i log di accesso ai dati, ti consigliamo di definire un caso d'uso chiaro per i log aggiuntivi e di valutare l'aumento dei costi di registrazione.

Monitorare l'utilizzo delle chiavi

Puoi visualizzare l'utilizzo delle chiavi con l'API di inventario Cloud KMS per identificare le risorse Google Cloud della tua organizzazione che dipendono dalle chiavi Cloud KMS e sono protette da queste. Questa dashboard può essere utilizzata per monitorare lo stato, l'utilizzo e la disponibilità delle versioni delle chiavi e delle risorse corrispondenti che proteggono. La dashboard identifica anche i dati inaccessibili a causa di una chiave disattivata o eliminata, in modo da poter intraprendere azioni come la pulizia dei dati inaccessibili o la riattivazione della chiave.

Puoi anche utilizzare Cloud Monitoring con Cloud KMS per impostare avvisi per eventi critici come la pianificazione dell'eliminazione di una chiave. Cloud Monitoring ti offre la possibilità di valutare il motivo per cui è stata eseguita un'operazione di questo tipo e di attivare un processo a valle facoltativo per ripristinare la chiave, se necessario.

Ti consigliamo di stabilire un piano operativo per rilevare automaticamente gli eventi che ritieni importanti e di esaminare periodicamente la dashboard di utilizzo principale.

Attivare Security Command Center per i risultati relativi alle vulnerabilità di Cloud KMS

Security Command Center genera risultati relativi a vulnerabilità che evidenziano gli errori di configurazione associati a Cloud KMS e ad altre risorse. Ti consigliamo di attivare Security Command Center e di integrare questi risultati nelle tue operazioni di sicurezza esistenti. Questi risultati includono problemi come chiavi Cloud KMS accessibili pubblicamente, progetti Cloud KMS con il ruolo owner eccessivamente permissivo o ruoli IAM che violano la separazione dei compiti.

Valuta i tuoi requisiti di conformità

I diversi framework di conformità hanno requisiti diversi per la crittografia e la gestione delle chiavi. Un framework di conformità in genere definisce i principi e gli scopi di alto livello della gestione delle chiavi di crittografia, ma non è prescrittivo in merito al prodotto o alla configurazione specifici che garantiscono la conformità. È tua responsabilità comprendere i requisiti del tuo framework di conformità e in che modo i tuoi controlli, inclusa la gestione delle chiavi, possono soddisfare questi requisiti.

Per indicazioni su come i servizi Google Cloud possono aiutarti a soddisfare i requisiti di diversi framework di conformità, consulta le seguenti risorse:

Riepilogo delle best practice

La tabella seguente riassume le best practice consigliate in questo documento:

Argomento Attività
Decidere se utilizzare CMEK Utilizza CMEK se hai bisogno di una delle funzionalità attivate da CMEK.
Scegli la creazione manuale o automatica delle chiavi Utilizza Cloud KMS Autokey se le caratteristiche delle chiavi create da Autokey soddisfano le tue esigenze.
Progetti di chiavi Cloud KMS Utilizza un progetto di chiavi centralizzato per ogni ambiente. Non creare risorse Cloud KMS nello stesso progetto delle risorse Google Cloud protette dalle chiavi.
Raccolte di chiavi Cloud KMS Crea keyring Cloud KMS per ogni località in cui vuoi proteggere le risorse Google Cloud.
Granularità delle chiavi Scegli un pattern di granularità delle chiavi che sia adatto alle tue esigenze oppure utilizza Autokey per eseguire il provisioning automatico delle chiavi con la granularità consigliata per ogni servizio.
Livello di protezione Scegli Cloud EKM se il materiale della chiave deve essere archiviato al di fuori di Google Cloud. Scegli Cloud HSM se il materiale delle chiavi può essere ospitato su moduli di sicurezza hardware (HSM) di proprietà di Google. Scegli le chiavi software se le tue esigenze non richiedono Cloud HSM o Cloud EKM. Consulta le linee guida per la selezione di un livello di protezione.
Materiale chiave Per il materiale della chiave ospitato su Google Cloud, utilizza se possibile il materiale della chiave generato da Google. Se utilizzi materiale chiave importato, implementa automazioni e procedure per mitigare i rischi.
Scopo e algoritmo della chiave Tutte le chiavi CMEK devono utilizzare lo scopo della chiave simmetrica ENCRYPT_DECRYPT e l'algoritmo GOOGLE_SYMMETRIC_ENCRYPTION.
Periodo di rotazione Utilizza la rotazione automatica delle chiavi per assicurarti che vengano ruotate in base alla programmazione. Scegli e applica un periodo di rotazione che soddisfi le tue esigenze, idealmente non meno di una volta all'anno. Utilizza una rotazione della chiave più frequente per i carichi di lavoro sensibili.
Principio del privilegio minimo Concedi i ruoli predefiniti più limitati che consentono ai tuoi principali di completare le loro attività. Non utilizzare i ruoli di base.
Separazione dei compiti Mantieni autorizzazioni separate per gli amministratori delle chiavi e per i principali che utilizzano le chiavi.
Ippigazioni del progetto Utilizza i blocchi dei progetti per evitare l'eliminazione accidentale dei progetti delle chiavi.
Richiedere CMEK Utilizza il vincolo constraints/gcp.restrictNonCmekServices.
Richiedere una durata minima per l'eliminazione pianificata Utilizza il vincolo constraints/cloudkms.minimumDestroyScheduledDuration.
Applica i livelli di protezione consentiti per i CMEK Utilizza il vincolo constraints/cloudkms.allowedProtectionLevels.
Attivare e aggregare la registrazione degli audit Audit log aggregati delle attività amministrative per tutte le risorse della tua organizzazione. Valuta se attivare la registrazione delle operazioni che utilizzano le chiavi.
Monitorare l'utilizzo delle chiavi Utilizza l'API di inventario Cloud KMS o la console Google Cloud per comprendere l'utilizzo delle chiavi. Se vuoi, utilizza Cloud Monitoring per impostare avvisi per operazioni sensibili come la pianificazione della distruzione di una chiave.
Attivare Security Command Center per Cloud KMS Esamina i risultati relativi alle vulnerabilità e integra la revisione dei risultati relativi alle vulnerabilità nelle tue operazioni di sicurezza.
Valutare i requisiti di conformità Esamina l'architettura Cloud KMS e confrontala con eventuali requisiti di conformità a cui devi attenerti.

Passaggi successivi

  • Scopri di più su come Autokey di Cloud KMS riduce il tuo impegno per utilizzare CMEK in modo coerente.