Questa pagina descrive le best practice per la configurazione 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 (eliminazione crittografica).
Crea e utilizza chiavi univoche per un cliente, stabilendo un confine crittografico intorno ai tuoi dati.
Registra l'accesso amministrativo e ai dati alle chiavi di crittografia.
Rispetto delle normative attuali o future che richiedono uno di questi obiettivi.
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 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 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.
Dopo la creazione di una chiave da parte di 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 di Cloud KMS possono visualizzare, aggiornare, abilitare o disabilitare ed eliminare le chiavi create da Autokey. Gli amministratori Cloud KMS non dispongono delle 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 dettagli specifici del servizio sulla granularità delle chiavi, vedi Servizi compatibili.
Località:Autokey crea chiavi nella stessa località della risorsa da proteggere.
Se devi creare risorse protette da CMEK in località in cui Cloud HSM non è disponibile, devi creare manualmente la chiave CMEK.
- 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
autokeynel progetto Autokey nella località selezionata. I keyring nel progetto Autokey vengono creati quando uno sviluppatore Autokey richiede la prima chiave in una determinata località. - Denominazione 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 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 non compatibili con Autokey, ti consigliamo di utilizzare le 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, spese operative 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 gli ambienti e a consentire la separazione dei compiti.
Il seguente diagramma illustra questi concetti nella progettazione consigliata:
- Ogni cartella di ambiente ha un progetto chiave Cloud KMS amministrato separatamente dai progetti 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 di chiavi Cloud KMS non è lo stesso principal che utilizza le chiavi di crittografia nei progetti di applicazioni.
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 a livello di singola regione e di zona non possono utilizzare un portachiavi multiregionale diverso daglobal. - Le risorse multiregionali (ad esempio un set di dati BigQuery nella multiregione
us) devono utilizzare un portachiavi e CMEK nella stessa multiregione 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, vedi Controllare la residenza 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 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 ridurre 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 per te nella stessa località delle risorse che proteggi.
Scegli 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 manualmente 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 Autokey di Cloud KMS seguono questo consiglio.
Se vuoi seguire una strategia di granularità diversa, valuta i seguenti compromessi tra 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 con granularità elevata contribuisce a ridurre il potenziale impatto della compromissione di una chiave rispetto all'utilizzo di chiavi con granularità bassa.
- 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 maggiore 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 ricriptate 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 il potenziale impatto 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-provisioning 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:
Hai bisogno di una delle funzionalità di CMEK? Puoi esaminare le funzionalità elencate in Decidere se utilizzare CMEK in questa pagina.
- In caso affermativo, continua con la domanda successiva.
- In caso contrario, ti consigliamo di utilizzare la Google crittografia predefinita.
Richiedi che il materiale della chiave rimanga all'interno del confine fisico di un modulo di sicurezza hardware (HSM)?
- In caso affermativo, continua con la domanda successiva.
- In caso contrario, ti consigliamo di utilizzare CMEK con chiavi supportate da software.
Richiedi che il materiale della chiave venga archiviato al di fuori di Google Cloud?
- In questo caso, ti consigliamo CMEK con Cloud External Key Manager.
- In caso contrario, consigliamo CMEK con Cloud HSM (chiavi supportate da hardware).
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 delle chiavi? 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 carichi di lavoro 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 quando pianifichi i controlli dell'accesso. Le sezioni seguenti introducono questi consigli.
Applica il principio del privilegio minimo
Quando assegni l'autorizzazione per la gestione delle CMEK, considera 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 crittografia at-rest 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 del controllo |
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 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ò 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 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 del criterio dell'organizzazione constraints/cloudkms.minimumDestroyScheduledDuration con una durata minima 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 nel tuo 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.
Configurare i controlli di rilevamento 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 audit log dell'attività di amministrazione di Cloud KMS (insieme agli audit log dell'attività di amministrazione 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à correlate alla creazione o alla modifica delle risorse Cloud KMS. Per indicazioni sulla configurazione dei sink di log aggregati, vedi Aggrega e archivia i log della tua organizzazione.
Se vuoi, puoi abilitare 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, puoi 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 in che modo aumenteranno i costi di logging.
Monitorare l'utilizzo delle chiavi
Puoi visualizzare l'utilizzo delle chiavi con l'API Cloud KMS Inventory 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 che tu possa intraprendere azioni come l'eliminazione dei dati inaccessibili o la riattivazione della chiave. Puoi 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 la causa dell'operazione e attivare un processo downstream facoltativo per ripristinare la chiave, se necessario.Ti consigliamo di stabilire un piano operativo per rilevare automaticamente gli eventi che ritieni importanti e di rivedere periodicamente la dashboard di utilizzo delle chiavi.
Abilitare Security Command Center per i risultati delle vulnerabilità di Cloud KMS
Security Command Center genera risultati di vulnerabilità che
mettono in evidenza gli errori di configurazione associati a Cloud KMS e ad altre
risorse. Ti consigliamo di attivare Security Command Center e 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 delinea i principi e gli obiettivi di alto livello della gestione delle chiavi di crittografia, ma non è prescrittivo in merito al prodotto o alla configurazione particolari che consentono di ottenere 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 soddisfarli.
Per indicazioni su come i servizi Google Cloud possono contribuire a soddisfare i requisiti di diversi framework di conformità, consulta le seguenti risorse:- Protezione dei dati sanitari su Google Cloud
- Risorse per normative e conformità Cloud
- Google Cloud Guida all'implementazione FedRAMP
- Conformità allo standard PCI DSS (Payment Card Industry Data Security Standard)
Riepilogo delle best practice
La tabella seguente riepiloga le best practice consigliate in questo documento:
| Argomento | Attività |
|---|---|
| Decidere se utilizzare CMEK | Utilizza CMEK se richiedi una delle funzionalità attivate da CMEK. |
| Scegli la creazione manuale o automatica delle chiavi | Utilizza Autokey di Cloud KMS se le caratteristiche delle chiavi create da Autokey soddisfano le tue esigenze. |
| Progetti chiave Cloud KMS | Utilizza un progetto chiave centralizzato per ogni ambiente. Non creare risorse Cloud KMS nello stesso progetto delle risorse Google Cloud che le chiavi proteggono. |
| Keyring Cloud KMS | Crea keyring Cloud KMS per ogni località in cui vuoi proteggere Google Cloud le risorse. |
| Granularità della chiave | Scegli un pattern di granularità delle chiavi che soddisfi le 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 delle chiavi deve essere archiviato al di fuori di Google Cloud. Scegli Cloud HSM se il materiale della chiave può essere ospitato su moduli di sicurezza hardware (HSM) di Google Cloud. Scegli le chiavi software se le tue esigenze non richiedono Cloud HSM o Cloud EKM. Consulta le indicazioni per la selezione di un livello di protezione. |
| Materiale chiave | Per il materiale della chiave ospitato su Google Cloud, utilizza il materiale della chiave generato da Google Cloud, se possibile. Se utilizzi materiale della chiave importato, implementa l'automazione e le 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 le chiavi vengano ruotate in base a una pianificazione. Scegli e applica un periodo di rotazione che soddisfi le tue esigenze, idealmente non inferiore a una volta all'anno. Utilizza una rotazione della chiave più frequente per i carichi di lavoro sensibili. |
| Privilegio minimo | Concedi i ruoli predefiniti più limitati che consentono alle entità di completare le attività. Non utilizzare i ruoli di base. |
| Separazione dei compiti | Mantieni autorizzazioni separate per gli amministratori delle chiavi e i principal che utilizzano le chiavi. |
| Privilegi sul progetto | Utilizza i blocchi del progetto per evitare l'eliminazione accidentale dei progetti chiave. |
| Richiedi CMEK | Utilizza il vincolo constraints/gcp.restrictNonCmekServices. |
| Richiedere una durata minima di pianificazione dell'eliminazione | Utilizza il vincolo
constraints/cloudkms.minimumDestroyScheduledDuration. |
| Applica i livelli di protezione consentiti per le chiavi CMEK | Utilizza il vincolo constraints/cloudkms.allowedProtectionLevels. |
| Abilitare e aggregare l'audit logging | Aggrega gli audit log delle attività amministrative per tutte le risorse della tua organizzazione. Valuta se vuoi attivare la registrazione delle operazioni che utilizzano le chiavi. |
| Monitorare l'utilizzo delle chiavi | Utilizza l'API Cloud KMS Inventory o la console Google Cloud per comprendere l'utilizzo delle chiavi. (Facoltativo) Utilizza Cloud Monitoring per impostare avvisi per operazioni sensibili come la pianificazione della distruzione di una chiave. |
| Abilita Security Command Center per Cloud KMS | Esamina i risultati delle vulnerabilità e integra la revisione dei risultati delle vulnerabilità nelle tue operazioni di sicurezza. |
| Valutare i requisiti di conformità | Esamina l'architettura di Cloud KMS e confrontala con eventuali requisiti di conformità che devi rispettare. |
Passaggi successivi
- Scopri di più su come Cloud KMS Autokey riduce lo sforzo necessario per utilizzare CMEK in modo coerente.