Best practice per l'utilizzo dei CMEK

Questa pagina descrive le best practice per la configurazione della crittografia at-rest con chiavi di crittografia gestite dal cliente (CMEK) sulle tue risorse Google Cloud . Questa guida è destinata agli architetti cloud e ai team di sicurezza e delinea le best practice e le decisioni che devi prendere durante la progettazione dell'architettura CMEK.

Questa guida presuppone che tu abbia già familiarità con Cloud Key Management Service (Cloud KMS) e con le chiavi di crittografia gestite dal cliente e che tu abbia letto l'approfondimento su Cloud KMS.

Decisioni preliminari

I consigli in questa pagina sono destinati ai clienti che utilizzano le chiavi CMEK per criptare i propri dati. Se non sai se utilizzare le chiavi CMEK create 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 Cloudse hai bisogno di una delle seguenti funzionalità:

  • Possedere le chiavi di crittografia.

  • Controlla e gestisci le chiavi di crittografia, inclusi scelta della posizione, livello di protezione, creazione, controllo dell'accesso, rotazione, utilizzo e 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.

  • Elimina selettivamente i dati protetti dalle tue chiavi in caso di offboarding o per correggere eventi di sicurezza (distruzione crittografica).

  • Crea e utilizza chiavi univoche per un cliente, stabilendo un confine crittografico intorno ai tuoi dati.

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

  • Rispetto delle normative attuali o future che richiedono uno di questi obiettivi.

Se non hai bisogno di queste funzionalità, valuta se la crittografia at-rest predefinita con Google-owned and managed keys è adatta al 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 il provisioning delle chiavi CMEK autonomamente. Cloud KMS Autokey prende alcune di queste decisioni per te e automatizza molti consigli di questa guida. L'utilizzo di Autokey è più semplice rispetto al provisioning manuale delle chiavi ed è la scelta consigliata se le chiavi create da Autokey soddisfano tutti i tuoi requisiti.

Autokey esegue il provisioning delle chiavi CMEK per te. Le chiavi CMEK di cui è stato eseguito il provisioning automatico hanno le seguenti caratteristiche:

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

  • Periodo di rotazione:un anno.

    Una volta creata una chiave da Autokey, un amministratore Cloud KMS può modificare il periodo di rotazione rispetto a quello predefinito.

  • Separazione dei compiti:
    • All'account di servizio per il servizio vengono concesse automaticamente le autorizzazioni di crittografia e decrittografia sulla chiave.
    • Le autorizzazioni di amministratore Cloud KMS si applicano come di consueto alle chiavi create da Autokey. Gli amministratori Cloud KMS possono visualizzare, aggiornare, attivare o disattivare ed eliminare le chiavi create da Autokey. Gli amministratori Cloud KMS non ricevono autorizzazioni di crittografia e decrittografia.
    • Gli sviluppatori di Autokey possono richiedere solo la creazione e l'assegnazione di 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 informazioni specifiche del servizio sulla granularità delle chiavi, vedi 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 la CMEK manualmente.

  • Stato della versione della chiave:le chiavi appena create richieste utilizzando Autokey vengono create come versione della chiave primaria nello stato abilitato.
  • Denominazione del keyring: tutte le chiavi create da Autokey vengono create in un keyring chiamato autokey. I keyring nel progetto Autokey vengono creati quando uno sviluppatore Autokey richiede la prima chiave in una determinata località. Il portachiavi autokey viene creato nel progetto di gestione delle chiavi designato se utilizzi l'archiviazione delle chiavi in un progetto dedicato o nel progetto risorsa se utilizzi l'archiviazione delle chiavi nello stesso progetto.
  • Denominazione delle chiavi:le chiavi create da Autokey seguono questa convenzione di denominazione: PROJECT_NUMBER-SERVICE_SHORT_NAME-RESOURCE_TYPE_DESCRIPTOR_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 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 la loro gestione. Queste decisioni influiscono su costi, overhead operativo e facilità di implementazione di funzionalità come la distruzione crittografica.

Le sezioni seguenti descrivono i consigli per ogni scelta di progettazione.

Utilizza un progetto chiave CMEK centralizzato per ogni ambiente

Ti consigliamo di utilizzare un progetto chiave 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 ambienti e a consentire la separazione dei compiti.

Il seguente diagramma illustra questi concetti nella progettazione consigliata:

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

Struttura consigliata di cartelle e progetti Cloud KMS

Se utilizzi Cloud KMS Autokey, ogni cartella per cui Autokey è abilitato deve avere un progetto di chiavi Cloud KMS dedicato.

Crea chiavi automatizzate Cloud KMS per ogni località

Devi creare i keyring Cloud KMS nelle località in cui implementi le risorseGoogle Cloud crittografate con CMEK.

  • Le risorse regionali e di zona devono utilizzare un keyring e una CMEK nella stessa regione della risorsa o nella località global. Le risorse di una singola regione e di una singola zona non possono utilizzare un portachiavi multiregionale diverso da global.
  • Le risorse multiregionali (ad esempio un set di dati BigQuery nella multi-regione us) devono utilizzare un portachiavi e CMEK nella stessa multi-regione o nella stessa doppia regione. Le risorse multiregionali non possono utilizzare un portachiavi regionale.
  • Le risorse globali devono utilizzare un keyring e CMEK nella località global.

L'applicazione delle chiavi regionali è un elemento di una strategia di regionalizzazione dei dati. Se applichi l'utilizzo di keyring e chiavi in una regione definita, applichi anche che le risorse devono corrispondere alla regione del keyring. Per indicazioni sulla residenza dei dati, consulta Controllare la residenza dei dati.

Per i carichi di lavoro che richiedono funzionalità di alta affidabilità 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 della regione A non può essere ricreato nella regione B in uno scenario di ripristino di emergenza in cui la regione A non è disponibile. Per mitigare il rischio di questo scenario, puoi pianificare la crittografia di una risorsa con chiavi global.

Per saperne di più, vedi Scegliere il tipo di località migliore.

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

Scegliere una strategia di granularità delle chiavi

Granularità si riferisce alla scala e all'ambito dell'utilizzo previsto di ogni chiave. Ad esempio, una chiave che protegge diverse risorse è considerata meno granulare rispetto a una chiave che protegge una sola risorsa.

Le chiavi Cloud KMS di cui è stato eseguito il provisioning manuale per CMEK devono essere sottoposte a provisioning in anticipo 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 da riutilizzare in modo più ampio tra le risorse.

In generale, consigliamo la seguente strategia di granularità:

  • Ogni chiave protegge le risorse in una singola località, ad esempio us-central1.
  • Ogni chiave protegge le risorse in un singolo servizio o prodotto, ad esempio BigQuery.
  • Ogni chiave protegge le risorse in un singolo progetto Google Cloud .

Questo suggerimento potrebbe non essere la strategia di granularità ideale per la tua organizzazione. Per la maggior parte delle organizzazioni, questa strategia offre un buon equilibrio tra l'overhead della gestione di molte chiavi altamente granulari e i potenziali rischi dell'utilizzo di chiavi meno granulari condivise tra molti progetti, servizi o risorse.

Le chiavi create con Cloud KMS Autokey seguono questo consiglio.

Se vuoi seguire una strategia di granularità diversa, valuta i seguenti compromessi tra i diversi pattern:

Chiavi a granularità elevata: ad esempio, una chiave per ogni singola risorsa

  • Maggiore controllo per disattivare in modo sicuro 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 molto granulari contribuisce a ridurre il potenziale impatto 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 delle chiavi rispetto a una strategia che utilizza chiavi con 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 maggiori.
  • Overhead operativo:l'utilizzo di chiavi molto granulari potrebbe richiedere uno sforzo amministrativo o strumenti aggiuntivi per l'automazione per eseguire il provisioning di un gran numero di risorse Cloud KMS e per gestire i controlli dell'accesso per gli agenti di servizio in modo che possano utilizzare solo le chiavi appropriate. Se hai bisogno di chiavi con granularità elevata, Autokey potrebbe essere una buona scelta per automatizzare il provisioning. Per saperne di più sulla granularità delle chiavi Autokey per ogni servizio, consulta Servizi compatibili.

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

  • Richiede attenzione per disattivare in sicurezza le versioni della chiave: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 molto granulare. Prima di disattivare la vecchia versione della chiave, devi assicurarti che tutte le risorse criptate da questa versione della chiave vengano criptate nuovamente in modo sicuro con una nuova versione della chiave. 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 un numero inferiore di versioni della chiave e i prezzi di Cloud KMS si basano sul numero di versioni della chiave attive.
  • Overhead operativo:puoi definire e pre-provisionare un numero noto di chiavi, con meno sforzi necessari per garantire controlli dell'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. Richiedi che il materiale della chiave rimanga all'interno del confine fisico di un modulo di sicurezza hardware (HSM)?

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

  4. Hai bisogno del controllo amministrativo del tuo cluster HSM e dell'isolamento crittografico da altri Google Cloud clienti?

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

Utilizza il materiale della chiave generato da Google Cloud, se possibile

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 della chiave, ti consigliamo di valutare i seguenti aspetti operativi e rischi dell'utilizzo dell'approccio Bring Your Own Key (BYOK):

  • Puoi implementare l'automazione per importare in modo coerente le nuove versioni della chiave? Ciò include sia le impostazioni di Cloud KMS per limitare le versioni delle chiavi alla sola 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 all'ora prevista?
  • Come intendi archiviare o depositare in modo sicuro il materiale delle chiavi originale?
  • Come puoi mitigare il rischio che la procedura di importazione delle chiavi divulghi il materiale delle chiavi non elaborate?
  • Quale sarebbe l'impatto del reimporto di una chiave eliminata in precedenza perché il materiale della chiave non elaborato è stato conservato al di fuori di Google Cloud?
  • Il vantaggio di importare personalmente il materiale delle chiavi giustifica l'aumento del sovraccarico operativo e del rischio?

Scegli lo scopo e l'algoritmo della chiave giusti per le tue esigenze

Quando crei una chiave, devi selezionare lo scopo e l'algoritmo sottostante per la chiave. Per i casi d'uso di CMEK, possono essere utilizzate solo chiavi con lo scopo simmetrico ENCRYPT_DECRYPT. Questo scopo della chiave utilizza sempre l'algoritmo GOOGLE_SYMMETRIC_ENCRYPTION, che utilizza chiavi Advanced Encryption Standard (AES-256) a 256 bit in Galois Counter Mode (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.

Scegliere un periodo di rotazione

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

Dopo la rotazione di una chiave simmetrica, la nuova versione viene contrassegnata come versione della chiave primaria e viene utilizzata per tutte le nuove richieste di protezione delle informazioni. Le versioni precedenti della chiave rimangono disponibili per decriptare i dati criptati in precedenza protetti con quella versione. Quando ruoti una chiave, i dati criptati con le versioni precedenti della chiave non vengono criptati nuovamente in modo automatico.

La rotazione frequente delle chiavi contribuisce a 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 la loro creazione.

Applica controlli dell'accesso appropriati

Ti consigliamo di prendere in considerazione i principi del privilegio minimo e della separazione dei compiti durante la pianificazione dei controlli dell'accesso. Le sezioni seguenti introducono questi consigli.

Applica il principio del privilegio minimo

Quando assegni l'autorizzazione per la gestione delle chiavi 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 mitigare i rischi di incidenti di sicurezza correlati all'accesso con privilegi eccessivi.

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

Pianificare la separazione dei compiti

Mantieni identità e autorizzazioni separate per chi amministra le chiavi di crittografia e per chi le utilizza. NIST SP 800-152 definisce una separazione dei compiti tra il 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 CMEK per gestire la crittografia at-rest con i servizi Google Cloud , il ruolo IAM per utilizzare le 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 ha bisogno solo del ruolo IAM roles/storage.objectCreator e il service agent Cloud Storage nello stesso progetto (ad esempio service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com) ha bisogno del ruolo IAM roles/cloudkms.cryptoKeyEncrypterDecrypter.

La tabella seguente elenca i ruoli IAM in genere associati a ciascuna mansione:

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. Cryptographic officer
roles/cloudkms.cryptoKeyEncrypterDecrypter Fornisce 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 dei controlli
Le violazioni di questo principio e i problemi correlati possono essere rilevati automaticamente dai risultati delle vulnerabilità di Security Command per Cloud KMS.

Applicare CMEK in modo coerente

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

Applica i blocchi di progetto

Ti consigliamo di proteggere i progetti con blocchi (anteprima) per evitare l'eliminazione accidentale. Quando viene applicato un vincolo del progetto, l'eliminazione del progetto della chiave Cloud KMS viene bloccata finché il vincolo non viene rimosso.

Richiedi chiavi CMEK

Ti consigliamo di applicare l'utilizzo di CMEK nel tuo ambiente utilizzando i vincoli dei criteri 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 di pianificazione dell'eliminazione

Ti consigliamo di impostare una durata minima pianificata per l'eliminazione. L'eliminazione della chiave è un'operazione irreversibile che può causare 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 eliminato in modo definitivo. In questo modo hai un po' di tempo per ripristinare una chiave in caso di eliminazione accidentale. Tuttavia, è possibile che un utente con il ruolo Amministratore Cloud KMS crei una chiave con una durata pianificata per l'eliminazione di sole 24 ore, il che potrebbe non essere sufficiente per rilevare un problema e ripristinare la chiave. La durata pianificata per l'eliminazione può essere impostata solo durante la creazione della chiave.

Mentre una chiave è pianificata 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 ripristinarla prima della fine del periodo pianificato per la distruzione.

Per garantire 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 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 le chiavi CMEK

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

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

Configura i controlli investigativi per le chiavi CMEK

Google Cloud fornisce vari controlli di rilevamento per le CMEK. Le sezioni seguenti introducono come attivare e utilizzare questi controlli pertinenti per Cloud KMS.

Abilitare e aggregare l'audit logging

Ti consigliamo di aggregare gli