Questa pagina descrive le pratiche consigliate per configurare la crittografia at-rest con chiavi di crittografia gestite dal cliente (CMEK) sulle tue risorse Cloud de Confiance . Questa guida è destinata agli architetti cloud e ai team di sicurezza e delinea le pratiche e le decisioni consigliate 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.Scegliere dove utilizzare CMEK
Google consiglia di utilizzare le chiavi di crittografia gestite dal cliente quando vuoi un confine crittografico intorno ai tuoi dati o a quelli dei tuoi clienti nel cloud. Per maggiori informazioni, vedi Chiavi di crittografia gestite dal cliente (CMEK).
Puoi utilizzare le chiavi CMEK nei servizi compatibili per raggiungere i seguenti obiettivi: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 Cloud de Confiance.
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.
Rispetta le normative attuali o future che richiedono uno di questi obiettivi.
Google consiglia inoltre di prendere in considerazione i framework di conformità applicabili alle esigenze della tua attività. 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 aiutarti a soddisfarli.
Per indicazioni su come Cloud de Confiance i servizi possono contribuire a soddisfare i requisiti di diversi framework di conformità, consulta le seguenti risorse:
Scegliere l'origine del materiale della chiave
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 Cloud de Confiance. Se possibile, ti consigliamo di scegliere di generare il materiale della chiave in Cloud KMS. Questa opzione non rischia di esporre 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 devi importare il tuo materiale delle chiavi, ti consigliamo di valutare i seguenti rischi e considerazioni operative 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 il processo 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 Cloud de Confiance?
Il vantaggio di importare personalmente il materiale delle chiavi giustifica l'aumento del sovraccarico operativo e del rischio?
Scegliere i modelli di gestione e archiviazione delle chiavi
Quando progetti l'architettura CMEK, devi decidere dove e come verranno gestite le chiavi. Idealmente, dovresti scegliere un modello di governance delle chiavi e un modello di archiviazione delle chiavi allineati. Il modello di governance e il modello di archiviazione che scegli influenzano configurazioni critiche come l'applicazione della separazione dei compiti.
Governance delle chiavi
La governance delle chiavi descrive chi in un'organizzazione è responsabile della gestione del ciclo di vita delle risorse Cloud KMS e del mantenimento delle misure di protezione per controllare l'utilizzo di Cloud KMS. Esistono approcci chiave alla governance in uno spettro che va dalla governance centralizzata alla governance delegata:
- Governance centralizzata: un team dedicato alla sicurezza o alla piattaforma è responsabile della gestione del ciclo di vita di tutte le chiavi crittografiche nell'organizzazione. Questo modello viene spesso scelto da aziende altamente regolamentate con requisiti di conformità rigorosi.
- Governance delegata: un team di sicurezza centrale utilizza i guardrail per imporre standard di crittografia, ma delega la responsabilità delle operazioni del ciclo di vita delle chiavi ai proprietari delle applicazioni all'interno dei loro progetti. Queste misure di salvaguardia possono includere policy dell'organizzazione che utilizzano vincoli gestiti e personalizzati, nonché concessioni e policy di negazione IAM. In questo modo si eliminano i colli di bottiglia operativi centrali.
Archiviazione delle chiavi
L'archiviazione delle chiavi descrive dove vengono create le risorse Cloud KMS all'interno di un'organizzazione. Esistono due approcci principali all'archiviazione delle chiavi: l'archiviazione delle chiavi in un progetto dedicato e l'archiviazione delle chiavi nello stesso progetto.
Archiviazione delle chiavi in un progetto dedicato: un progetto di gestione delle chiavi dedicato contiene le chiavi utilizzate per più applicazioni. In genere, ogni cartella dell'ambiente ha il proprio progetto chiave. Puoi utilizzare Autokey con l'archiviazione delle chiavi in un progetto dedicato. Per saperne di più sul modello di archiviazione delle chiavi in un progetto dedicato, consulta Archiviazione delle chiavi in un progetto dedicato.
Archiviazione delle chiavi nello stesso progetto: le chiavi vengono archiviate nello stesso progetto Cloud de Confiance delle risorse che proteggono. A volte questa operazione viene descritta come "la chiave segue i dati". Puoi utilizzare Autokey con l'archiviazione delle chiavi nello stesso progetto. Per saperne di più sul modello di archiviazione delle chiavi nello stesso progetto, consulta Archiviazione delle chiavi nello stesso progetto.
Allineare governance e spazio di archiviazione
La seguente matrice fornisce esempi di come questi modelli di governance e archiviazione possono essere combinati per soddisfare le diverse esigenze dell'organizzazione:
| Modello di governance | Archiviazione delle chiavi in un progetto dedicato | Archiviazione delle chiavi nello stesso progetto |
|---|---|---|
| Governance centralizzata | Approccio completamente centralizzato Utilizzo consigliato: organizzazioni con requisiti normativi rigorosi che impongono l'isolamento dei limiti del progetto. Impatto operativo: elevata complessità di configurazione. Richiede un'automazione robusta (ad esempio una "fabbrica di progetti") per evitare ritardi operativi per i team di sviluppo. |
Proprietà regolata Utilizzo consigliato: organizzazioni che richiedono una supervisione centralizzata della sicurezza, ma vogliono massimizzare la velocità degli sviluppatori. Impatto operativo: bassa complessità di configurazione. La sicurezza centralizzata applica i criteri utilizzando le barriere di protezione, mentre le chiavi si trovano insieme alle risorse che proteggono per facilitarne la gestione. |
| Governance delegata | Non consigliato L'introduzione della complessità di IAM tra progetti vanifica lo scopo della delega della gestione delle chiavi ai team delle applicazioni. |
Autonomous DevOps Utilizzo consigliato: organizzazioni decentralizzate ad alta velocità con una forte cultura DevOps. Impatto operativo: complessità di configurazione minima. I team delle applicazioni hanno piena autonomia su risorse e chiavi all'interno dei confini del progetto. |
Utilizza un'architettura coerente in tutti gli ambienti
Ti consigliamo di utilizzare lo stesso pattern di archiviazione delle chiavi per qualsiasi applicazione negli ambienti di sviluppo, test e produzione. Questa coerenza architetturale contribuisce a garantire che le tue autorizzazioni IAM, le pipeline di deployment e i controlli di sicurezza vengano testati a fondo negli ambienti inferiori prima di essere implementati in produzione. Se scegli architetture diverse per i tuoi ambienti, introduci il rischio di configurazione che può causare errori di deployment.
Archiviazione delle chiavi in un progetto dedicato
In un modello di archiviazione delle chiavi in un progetto dedicato, tutte le chiavi per una cartella dell'ambiente specifica (ad es. Produzione) vengono archiviate in un progetto di gestione centralizzata delle chiavi condiviso. Le autorizzazioni di gestione delle chiavi vengono concesse a un team di sicurezza condiviso, che in genere gestisce anche le operazioni e le misure di protezione del ciclo di vita delle chiavi, come i criteri dell'organizzazione CMEK e le concessioni di ruoli e policy IAM.
Caso d'uso
Ti consigliamo di utilizzare il modello di archiviazione delle chiavi in un progetto dedicato se la tua organizzazione dà la priorità a un controllo rigoroso e centralizzato delle chiavi di crittografia, spesso guidato da requisiti normativi o quando le chiavi sono ospitate su un HSM esterno.
Se la tua organizzazione è soggetta a un framework di conformità che richiede un Cryptographic Officer o un Key Custodian, come PCI DSS o BSI C5, questo modello è una buona scelta. Isolando tutte le chiavi per un'applicazione in un unico progetto di chiavi dedicato, puoi concedere il ruolo Amministratore Cloud KMS solo a un piccolo gruppo di amministratori della sicurezza sottoposto a revisione. In questo modo, è possibile semplificare i controlli di conformità limitando il numero di progetti in cui devono essere esaminate le policy di accesso per l'amministrazione delle chiavi.
Considerazioni
Questo approccio può introdurre complessità IAM tra progetti e potenziali colli di bottiglia per i team di sviluppo. Per contribuire a mitigare questo problema, puoi implementare il provisioning automatico dei progetti, a volte chiamato "Project Factory", per automatizzare la creazione delle chiavi e l'assegnazione delle autorizzazioni.
Esempio
Il seguente diagramma mostra una gerarchia di risorse di esempio per un ambiente di produzione che utilizza il modello di archiviazione delle chiavi dedicato al progetto:
- La cartella Prod contiene singole cartelle e progetti per diverse applicazioni, oltre a una cartella condivisa.
- I progetti applicativi contengono una serie di risorse diverse, come istanze di Compute Engine e bucket Cloud Storage, ma non contengono chiavi Cloud KMS.
- La cartella Condivisa contiene risorse condivise tra le diverse applicazioni.
- All'interno della cartella condivisa, esiste un progetto chiave dedicato in cui è abilitata l'API Cloud KMS. Questo progetto contiene tutte le chiavi utilizzate per proteggere le risorse all'interno della cartella Prod.
- I guardrail a livello di organizzazione e cartella, come i vincoli dei criteri dell'organizzazione e i criteri IAM, applicano la separazione dei compiti e altre pratiche.
- Gli sviluppatori possono disporre di privilegi elevati, ad esempio il ruolo di Proprietario progetto, all'interno di una singola cartella o progetto dell'applicazione senza concedere loro privilegi sul progetto chiave.
Archiviazione delle chiavi nello stesso progetto
In questo modello, le chiavi vengono archiviate nello stesso progetto delle risorse che proteggono. Le misure di protezione per la gestione delle chiavi vengono solitamente implementate da un team di sicurezza di base, anche se gli sviluppatori gestiscono il ciclo di vita delle chiavi per le proprie applicazioni.
Caso d'uso
Ti consigliamo di utilizzare lo stesso modello di archiviazione delle chiavi del progetto se la tua priorità è la velocità, l'agilità e la responsabilità chiara degli sviluppatori. La collocazione delle chiavi con le risorse che proteggono allinea la proprietà delle chiavi alla proprietà dei dati: la chiave segue i dati. Questo modello facilita la delega delle responsabilità di gestione delle chiavi ai proprietari dei workload, che possono assumersi la responsabilità di allinearsi alle norme dell'organizzazione CMEK e gestire le operazioni del ciclo di vita delle chiavi all'interno dei loro progetti.
Considerazioni
Sebbene questo modello consenta ai team delle applicazioni di operare in autonomia, richiede un controllo diligente dei ruoli IAM all'interno di ogni progetto per applicare il principio del privilegio minimo. Questo modello potrebbe aumentare la complessità operativa per le organizzazioni che implementano Bring Your Own Key (BYOK) o utilizzano chiavi Cloud EKM a causa del sovraccarico di coordinamento tra i sistemi.
Esempio
Il seguente diagramma mostra una gerarchia di risorse di esempio per un ambiente di produzione che utilizza il modello di archiviazione delle chiavi nello stesso progetto:
- La cartella Prod contiene cartelle e progetti individuali per diverse applicazioni.
- I progetti applicativi contengono una serie di risorse diverse, come istanze Compute Engine e bucket Cloud Storage, incluse le chiavi Cloud KMS che proteggono queste risorse.
- I guardrail a livello di organizzazione e cartella, come i vincoli dei criteri dell'organizzazione e i criteri IAM, applicano la separazione dei compiti e altre pratiche, ma l'applicazione della separazione dei compiti potrebbe richiedere una configurazione più attenta.
- Gli sviluppatori hanno bisogno di privilegi Cloud KMS elevati sul progetto risorsa per poter creare e gestire le chiavi.
Forzare la separazione dei compiti
Indipendentemente dal modello di archiviazione, devi mantenere principal e autorizzazioni separati per gli amministratori delle chiavi di crittografia e per gli utenti che le utilizzano. Per applicare il principio del privilegio minimo e la rigorosa separazione dei compiti, assegna i ruoli IAM in base a responsabilità operative specifiche.
La tabella seguente riepiloga la separazione dei ruoli consigliata per Cloud KMS:
| Responsabilità | Ruolo consigliato | Riepilogo delle autorizzazioni |
|---|---|---|
Amministrazione delle chiavi, ad es. cicli di vita e governance delle chiavi Ciò può includere amministratori umani e principal IaC che richiedono privilegi elevati. |
Amministratore Cloud KMS (roles/cloudkms.admin) |
|
Provisioning delle risorse, ad esempio la creazione di risorse protette da CMEK Possono essere inclusi sviluppatori umani e principal IaC senza privilegi elevati. |
Ruoli di amministratore o editor specifici del servizio, ad esempio:
|
Seleziona le chiavi durante la creazione delle risorse. |
Utilizzo delle chiavi, ad esempio crittografia e decrittazione Concedi questo ruolo solo ai service agent. Per le chiavi utilizzate nelle integrazioni CMEK, i principal umani non hanno bisogno di queste autorizzazioni. |
Autore crittografia/decriptazione CryptoKey Cloud KMS
(roles/cloudkms.cryptoKeyEncrypterDecrypter) |
Cripta e decripta i dati utilizzando la chiave. |
Applica l'escalation privilegio minimo per le pipeline IaC
Molte organizzazioni automatizzano il provisioning delle risorse utilizzando pipeline Infrastructure as Code (IaC) come Terraform Runner. La modalità di archiviazione delle chiavi influisce direttamente sulla security posture di queste pipeline.
Per automatizzare il provisioning delle chiavi Cloud KMS, alle pipeline IaC devono essere concessi ruoli amministrativi con privilegi elevati per generare chiavi e modificare le policy IAM. Se un malintenzionato compromette la pipeline IaC, potrebbe ottenere il controllo amministrativo completo del tuo piano di gestione delle chiavi.
- Se utilizzi l'archiviazione delle chiavi in un progetto dedicato, la pipeline richiede l'accesso amministrativo al progetto Cloud KMS centrale. Una compromissione della pipeline ha il potenziale di esporre il piano di gestione delle chiavi per l'intera organizzazione.
- Se utilizzi l'archiviazione delle chiavi nello stesso progetto, la pipeline richiede solo l'accesso amministrativo al progetto di risorse. In questo modo si limita l'ambito del potenziale rischio all'applicazione specifica, ma è comunque necessario gestire i privilegi elevati all'interno del progetto.
Cloud KMS Autokey risolve questo rischio delegando il provisioning delle chiavi a un service agent sicuro e gestito da Google, in modo da poter implementare una pipeline con privilegi minimi per il provisioning continuo delle chiavi:
- Pipeline con privilegi minimi: la pipeline IaC richiede solo il ruolo Utente Autokey di Cloud KMS con privilegi minimi (
roles/cloudkms.autokeyUser) per richiedere una chiave creando una risorsaKeyHandle. - Provisioning automatizzato: la creazione effettiva delle chiavi e gli aggiornamenti delle policy IAM vengono gestiti dietro le quinte dall'agente di servizio Cloud KMS gestito da Google.
- Ambito di rischio limitato: riducendo al minimo le autorizzazioni concesse alla tua pipeline, questo design evita di concedere alle pipeline di deployment privilegi elevati di creazione delle chiavi o di amministratore della sicurezza o la possibilità di assegnare ruoli helper, il che riduce significativamente il rischio di compromissione della pipeline.
Una pipeline IaC che attiva Autokey richiede un ruolo più permissivo
come Cloud KMS Autokey Admin (roles/cloudkms.autokeyAdmin), quindi se utilizzi
pipeline IaC per gestire l'attivazione di Autokey, devi applicare
la separazione dei compiti anche ai singoli principal IaC.
Allinearsi alle pratiche consigliate per la gestione delle chiavi
Google consiglia pratiche per la posizione, il livello di protezione, la pianificazione della rotazione, la granularità e le autorizzazioni delle chiavi. Puoi vedere in che misura le tue chiavi sono allineate a queste pratiche utilizzando la dashboard delle metriche di crittografia. Puoi rilevare le violazioni della separazione dei compiti utilizzando i risultati di vulnerabilità di Security Command Center.
Località chiave
Devi creare i keyring Cloud KMS nelle località in cui prevedi di implementare Cloud de Confiance le risorse criptate con CMEK. Devi eseguire questa operazione prima di poter creare le chiavi.- Le risorse regionali e di zona devono utilizzare un keyring e una chiave nella stessa regione
della risorsa o nella località
global. - Le risorse globali devono utilizzare un keyring e una chiave nella località
global.
Nella maggior parte dei casi, queste limitazioni vengono applicate dal servizio Cloud de Confiance.
L'applicazione dell'utilizzo delle chiavi regionali è un elemento di una strategia di regionalizzazione dei dati efficace. Se applichi l'utilizzo di keyring e chiavi in una regione definita, applichi anche l'obbligo che le risorse corrispondano alla regione del keyring.
Scegli una strategia di granularità delle chiavi
Granularità si riferisce alla scala e all'ambito dell'utilizzo previsto di ciascuna chiave. Ad esempio, una chiave che protegge diverse risorse è considerata meno granulare di una chiave che protegge una sola risorsa. La scelta di una strategia di granularità della chiave adatta ti aiuta ad allinearti al consiglio del NIST secondo cui ogni chiave ha uno scopo specifico.
In generale, ti consigliamo di utilizzare ogni chiave nel seguente modo:
- Utilizzato per un singolo Cloud de Confiance progetto.
- Utilizzato in una sola posizione, ad esempio
us-central1. - Utilizzato in un singolo servizio o prodotto, ad esempio BigQuery.
- Ove possibile, utilizzato per una singola risorsa, ad esempio un singolo bucket Cloud Storage.
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.
Seguire queste linee guida sulla granularità semplifica la disattivazione o l'eliminazione sicura delle versioni delle chiavi e limita i rischi di eliminazione accidentale o dannosa delle chiavi.
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.
* Se richiedi che il materiale delle chiavi venga archiviato al di fuori di
Cloud de Confiance, utilizza le chiavi Cloud EKM. Consigliamo il livello di protezione EXTERNAL_VPC per una migliore disponibilità.
* Se non devi archiviare il materiale della chiave al di fuori di
Cloud de Confiance, ti consigliamo di utilizzare chiavi supportate da software.
Scegliere un periodo di rotazione
Cloud KMS supporta la rotazione automatica delle chiavi delle chiavi simmetriche supportate da software e hardware, come quelle utilizzate per CMEK. Per le chiavi supportate dal software, ti consigliamo di utilizzare il periodo di rotazione standard del settore di 90 giorni. Per le chiavi Cloud HSM, consigliamo il periodo di rotazione standard del settore di 365 giorni. Le chiavi esterne devono essere ruotate manualmente in base alla pianificazione scelta.
Ti consigliamo di valutare il periodo di rotazione della chiave appropriato per le 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.
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.
Applica il principio del privilegio minimo
Quando concedi i ruoli IAM, segui il principio del privilegio minimo.
Ti consigliamo vivamente di evitare di utilizzare i ruoli di base come
Proprietario, Editor e Visualizzatore. Concedi invece ruoli Cloud KMS predefiniti per mitigare i rischi di incidenti di sicurezza correlati all'accesso con privilegi eccessivi. Ad esempio, se un principal deve solo importare materiale
delle chiavi, concedi il ruolo Cloud KMS Importer (roles/cloudkms.importer) anziché
il ruolo Cloud KMS Admin (roles/cloudkms.admin), che è più permissivo.
Impostare barriere di sicurezza operative
Le sezioni seguenti descrivono i controlli che puoi implementare per contribuire a mitigare 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 privilegi (anteprima) per evitare l'eliminazione accidentale dei tuoi progetti Cloud KMS e delle chiavi che contengono. Mentre un blocco del progetto è attivo, il progetto non può essere eliminato finché il blocco non viene rimosso. Per i progetti che contengono chiavi Cloud KMS, ciò impedisce una possibile causa di eliminazione accidentale delle chiavi.
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 permanente 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 definitivo. In questo modo hai un po' di tempo per ripristinare una chiave in caso di eliminazione accidentale. Tuttavia, è possibile che una persona 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 un tempo 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 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 nel tuo 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 utilizzino i livelli di protezione
che consenti.
Configura i controlli investigativi per le chiavi CMEK
Cloud de Confiance fornisce vari controlli di rilevamento per le CMEK. Le sezioni seguenti introducono come attivare e utilizzare i controlli pertinenti per Cloud KMS.
Abilitare e aggregare l'audit logging
Ti consigliamo di aggregare i log di controllo dell'attività di amministrazione di Cloud KMS 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 si utilizzano le chiavi CMEK, è possibile generare un volume di log sostanziale 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 valutare in che modo aumenteranno i costi di logging.
Riepilogo delle best practice
La seguente tabella riassume le best practice consigliate in questo documento:
| Argomento | Attività |
|---|---|
| Progetti chiave Cloud KMS | Utilizza un progetto chiave centralizzato per ogni ambiente. Non creare risorse Cloud KMS nello stesso progetto delle risorse Cloud de Confianceprotette dalle chiavi. |
| Keyring Cloud KMS | Crea keyring Cloud KMS per ogni località in cui vuoi proteggere Cloud de Confiance le risorse. |
| Granularità della chiave | Scegli un pattern di granularità delle chiavi che soddisfi le tue esigenze in termini di tolleranza al rischio, costi e overhead operativo. |
| Livello di protezione | Scegli Cloud EKM se il materiale delle chiavi deve essere archiviato al di fuori di Cloud de Confiance o se hai bisogno di una certificazione FIPS 140-2 di livello 2 o 3. In caso contrario, scegli le chiavi software. Consulta le indicazioni per la selezione di un livello di protezione. |
| Materiale chiave | Per il materiale della chiave ospitato su Cloud de Confiance, utilizza il materiale della chiave generato da Cloud de Confiance, 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 alla 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. |
| Valutare i requisiti di conformità | Esamina l'architettura di Cloud KMS e confrontala con eventuali requisiti di conformità che devi rispettare. |