Pratiche consigliate per l'utilizzo delle chiavi CMEK

Questa pagina descrive le pratiche consigliate per configurare la 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 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 e che tu abbia letto l'approfondimento su Cloud KMS.

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 create manualmente o quelle create da Autokey 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 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.

  • 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 Google Cloud 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 Google Cloud. 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 Google Cloud?

  • 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.
Google consiglia una governance centralizzata delle chiavi per le organizzazioni con requisiti normativi rigorosi o che devono fare affidamento su sistemi di chiavi esterni per gestire il ciclo di vita delle chiavi.

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 Google Cloud 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.

Google consiglia la governance delle chiavi distribuite quando la tua priorità è la velocità, l'agilità e la responsabilità chiara degli sviluppatori.

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 automatizzato dei progetti, a volte chiamato "Project Factory", per automatizzare la creazione delle chiavi e l'assegnazione delle autorizzazioni oppure utilizzare Cloud KMS Autokey per abilitare il provisioning on demand che supporta la separazione dei compiti, anche per le pipeline di Infrastructure as Code (IaC).

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. Se utilizzi Cloud KMS Autokey, questo progetto chiave dedicato è il luogo in cui Autokey eseguirà il provisioning delle chiavi.
  • 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 in un progetto dedicato

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.
  • Se utilizzi Cloud KMS Autokey, Autokey esegue il provisioning delle chiavi nel progetto della risorsa.
  • I guardrail a livello di organizzazione e cartella, come i vincoli dei criteri dell'organizzazione e i criteri IAM, impongono la separazione dei compiti e altre pratiche, ma se non utilizzi Autokey, l'applicazione della separazione dei compiti potrebbe richiedere una configurazione più attenta.
  • Se non utilizzi Autokey, gli sviluppatori hanno bisogno di privilegi Cloud KMS elevati nel progetto di risorse. Se utilizzi Autokey, gli utenti hanno bisogno solo dei ruoli specifici del servizio per le risorse che vogliono creare, ad esempio il ruolo Utente BigQuery o Amministratore Compute.

Archiviazione delle chiavi nello stesso progetto

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)
  • Crea, ruota, attiva, disattiva ed elimina chiavi e risorse correlate.
  • Gestisci i criteri IAM.

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:

  • Utente BigQuery (roles/bigquery.user)
  • Compute Admin (roles/compute.admin)
 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.

Quando utilizzi Autokey, questo ruolo viene concesso automaticamente all'agente di servizio.

 Autore crittografia/decriptazione CryptoKey Cloud KMS (roles/cloudkms.cryptoKeyEncrypterDecrypter) Cripta e decripta i dati utilizzando la chiave.
Le chiavi create utilizzando Autokey rispettano automaticamente questi principi.

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 risorsa KeyHandle.
  • 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.

Scegli se utilizzare Autokey

Dopo aver scelto l'architettura di archiviazione delle chiavi, devi decidere come vengono eseguito il provisioning delle chiavi. Ti consigliamo di automatizzare la creazione delle chiavi utilizzando Cloud KMS Autokey, se possibile, per ridurre il lavoro manuale e gli errori di configurazione. Autokey supporta entrambi i modelli di archiviazione:

  • Autokey con archiviazione delle chiavi nello stesso progetto: gli sviluppatori generano senza problemi le chiavi all'interno dei propri progetti on demand, rispettando al contempo le misure di protezione centrali. Puoi abilitare Autokey con l'archiviazione delle chiavi nello stesso progetto per progetto o per tutti i progetti in una cartella.
  • Autokey con archiviazione delle chiavi in un progetto dedicato: gli sviluppatori generano chiavi senza problemi all'interno di un progetto di gestione centralizzata delle chiavi per conto delle risorse in altri progetti. Puoi abilitare Autokey con l'archiviazione delle chiavi in un progetto dedicato a livello di cartella.

Le seguenti pratiche consigliate vengono automatizzate quando utilizzi Autokey:

  • Crea le chiavi nella stessa posizione della risorsa che proteggeranno
  • Mantenere la separazione dei compiti tra gli amministratori delle chiavi e i proprietari delle risorse
  • Concedi concessioni di ruoli IAM sulle nuove chiavi
  • Utilizza il livello di protezione HSM.
  • Seguire le strategie di granularità consigliate
  • Pianifica la rotazione automatica delle chiavi ogni 365 giorni

Poiché Cloud KMS Autokey gestisce il provisioning e l'assegnazione delle chiavi in corso, l'utilizzo di Autokey riduce gran parte dell'overhead di creazione di policy, strumenti e procedure operative personalizzati. Sebbene semplifichi l'impegno iniziale e continuo, devi comunque impostare sistemi di protezione operativi e configurare controlli di rilevamento e monitoraggio per garantire una governance coerente in tutta l'organizzazione.

Conformità e Autokey

Molti regimi di conformità richiedono di mantenere il controllo sulle chiavi di crittografia, indipendentemente dal provider di servizi cloud.

La delega delle attività di routine di provisioning delle chiavi a Cloud KMS Autokey non viola questo standard. Autokey funge esclusivamente da motore di automazione che esegue i criteri predefiniti. Mantieni la proprietà, l'autorità e il controllo crittografico finali tramite tre meccanismi principali:

  • Il responsabile della crittografia mantiene il controllo esclusivo sulle chiavi. Solo gli amministratori possono disattivare, ruotare o eliminare le versioni delle chiavi. Il servizio Autokey non può eseguire queste azioni del ciclo di vita.
  • Gli amministratori determinano esattamente dove è abilitata Autokey e quali entità possono richiedere le chiavi. Puoi disattivare Autokey o revocare le autorizzazioni a qualsiasi livello della gerarchia delle risorse in qualsiasi momento, interrompendo immediatamente l'automazione.
  • Ogni chiave generata, autorizzazione assegnata e criterio modificato da Autokey viene registrato in Cloud Logging. In questo modo, i revisori dispongono di una traccia di audit continua e automatizzata per verificare la conformità.

Anziché indebolire la governance, la delega del provisioning ad Autokey rafforza la conformità. Sostituisce i passaggi di configurazione manuali e soggetti a errori con l'applicazione programmatica della separazione dei compiti e della sicurezza della pipeline, soddisfacendo i rigorosi requisiti di controllo degli schemi di conformità come NIST SP 800-152 e PCI DSS.

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 implementare queste pratiche utilizzando l'approccio automatizzato con Autokey di Cloud KMS o configurandole manualmente. 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

Quando utilizzi CMEK manuale, devi creare i portachiavi Cloud KMS nelle località in cui prevedi di eseguire il deployment delle risorse Google Cloud 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 a livello di singola regione e di zona non possono utilizzare un portachiavi multiregionale diverso da global.
  • Le risorse multiregionali (come un set di dati BigQuery nella multi-regione us) devono utilizzare un portachiavi e una chiave nella stessa multi-regione. Le risorse multiregionali non possono utilizzare una chiave regionale.
  • Le risorse globali devono utilizzare un keyring e una chiave nella località global.

Nella maggior parte dei casi, queste limitazioni vengono applicate dal servizio Google Cloud.

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. Per indicazioni sulla residenza dei dati, vedi Controllare la residenza dei dati. Per saperne di più, consulta Scegliere una posizione appropriata.

Se utilizzi Cloud KMS Autokey, i keyring vengono creati automaticamente 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 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 Google Cloud 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.

Le chiavi create con Cloud KMS Autokey seguono questo consiglio.

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. Le seguenti domande possono aiutarti nella tua valutazione:

  1. Hai requisiti normativi, di isolamento o di residenza specializzati? Valuta se il tuo workload richiede una delle seguenti caratteristiche di alta sicurezza:

    • Archiviazione esterna: utilizza CMEK manuale con Cloud EKM. Consigliamo il livello di protezione EXTERNAL_VPC per una migliore disponibilità.
    • Hardware dedicato: utilizza CMEK manuale con Cloud HSM single-tenant.

    Altrimenti, continua con la domanda successiva.

  2. Vuoi il provisioning e la gestione del ciclo di vita delle chiavi automatizzati?

    • In questo caso, utilizza Cloud KMS Autokey. Autokey crea automaticamente le chiavi utilizzando il livello di protezione Cloud HSM multitenant. Anche se le chiavi basate su software sono accettabili, ti consigliamo di accettare la baseline di sicurezza più elevata di Cloud HSM per usufruire dell' automazione fornita da Autokey.

    • In caso contrario, continua con la domanda successiva.

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

    • In questo caso, utilizza Cloud HSM multitenant.
    • In caso contrario, utilizza le chiavi supportate dal 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.

Richiedi Cloud KMS Autokey

L'utilizzo di Cloud KMS Autokey per creare tutte le CMEK garantisce che le chiavi vengano create in modo coerente. Se vuoi applicare questa coerenza, puoi configurare una cartella in modo che richieda le CMEK create da Autokey e impedire l'utilizzo di chiavi create manualmente per CMEK. Per scoprire come configurare queste limitazioni, consulta Imponi l'utilizzo di Autokey.

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.

Se hai imposto l'utilizzo di Autokey, tutte le chiavi saranno supportate dall'hardware.

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 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.

Abilitare Security Command Center per i risultati delle vulnerabilità di Cloud KMS

Security Command Center genera risultati relativi alle 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.

Monitoraggio e correzione

Ti consigliamo di fare del controllo dell'utilizzo delle chiavi e dell'allineamento con le best practice consigliate un componente fondamentale della tua strategia di monitoraggio, perché funge da controllo investigativo cruciale per identificare rischi e configurazioni errate nella configurazione di CMEK. Tieni traccia di questi risultati, esegui il triage in base alle tue procedure di sicurezza e risolvili tempestivamente. I seguenti strumenti ti aiutano a identificare i problemi che puoi risolvere per migliorare la tua postura di sicurezza:

  • Dashboard Metriche di crittografia: puoi visualizzare le metriche di crittografia per vedere quali risorse sono protette con una CMEK e in che misura queste CMEK sono allineate alle pratiche consigliate. Puoi identificare i problemi da risolvere visualizzando gli elenchi delle risorse non protette da una CMEK e gli elenchi delle chiavi che non sono completamente in linea con le best practice.

  • Dashboard Utilizzo delle chiavi: puoi visualizzare l'utilizzo delle chiavi per identificare Google Cloud le risorse 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 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. Le informazioni nella dashboard Utilizzo delle chiavi sono disponibili anche utilizzando l'API Cloud KMS Inventory.

Ti consigliamo di stabilire un piano operativo per rilevare automaticamente gli eventi che consideri importanti e di rivedere periodicamente la dashboard di utilizzo delle chiavi.

Riepilogo delle best practice

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

Argomento Attività
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 chiave Cloud KMS Utilizza un progetto chiave centralizzato per ogni ambiente. Non creare risorse Cloud KMS nello stesso progetto delle risorse Google Cloudprotette dalle chiavi.
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 single-tenant se il materiale della chiave deve essere ospitato su partizioni dedicate su moduli di sicurezza hardware (HSM) di proprietà di Google Cloud. Scegli Cloud HSM multitenant se il materiale della chiave può essere ospitato su cluster di moduli di sicurezza hardware (HSM) di proprietà di Google Cloudcondivisi con altri clienti 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 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.
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.