Informazioni sulle chiavi di crittografia gestite dal cliente (CMEK)

Per impostazione predefinita, Cloud SQL per PostgreSQL cripta i contenuti dei clienti riposo. Cloud SQL per PostgreSQL gestisce la crittografia per conto tuo senza che tu debba fare altro. Questa opzione è denominata crittografia predefinita di Google.

Se vuoi controllare le tue chiavi di crittografia, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK) in Cloud KMS con i servizi integrati con CMEK, tra cui Cloud SQL per PostgreSQL. L'utilizzo delle chiavi Cloud KMS ti consente di controllare il loro livello di protezione, la posizione, la pianificazione della rotazione, le autorizzazioni di utilizzo e accesso e i confini di crittografia. L'utilizzo di Cloud KMS ti consente inoltre di monitorare l'utilizzo delle chiavi, visualizzare i log di controllo e controllare i cicli di vita delle chiavi. Invece di lasciare che sia Google a controllare e gestire la simmetria chiavi di crittografia delle chiavi (KEK) che proteggono i dati, sei tu a controllare e gestire queste chiavi in Cloud KMS.

Dopo aver configurato le risorse con le CMEK, l'esperienza di accesso Le risorse Cloud SQL per PostgreSQL sono simili all'utilizzo della crittografia predefinita di Google. Per ulteriori informazioni sulla crittografia vedi Chiavi di crittografia gestite dal cliente (CMEK).

CMEK con Autokey di Cloud KMS

Puoi creare CMEK manualmente per proteggere le risorse Cloud SQL per PostgreSQL o utilizzare Autokey di Cloud KMS. Con Autokey, i keyring e le chiavi vengono generati on demand come parte della creazione di risorse in Cloud SQL per PostgreSQL. Gli agenti di servizio che utilizzano le chiavi per le operazioni di crittografia e decrittografia vengono creati se non esistono già e vengono concessi i ruoli IAM (Identity and Access Management) richiesti. Per ulteriori informazioni, consulta la panoramica di Autokey.

Autokey non crea chiavi per le risorse Cloud SQL per PostgreSQL BackupRun. Quando crei un backup di un'istanza Cloud SQL per PostgreSQL, il backup è criptato con la chiave gestita dal cliente dell'istanza principale.

Cloud SQL per PostgreSQL è compatibile con Autokey di Cloud KMS solo quando si creano risorse utilizzando Terraform o l'API REST.

Per scoprire come utilizzare le chiavi CMEK create manualmente per proteggere le risorse Cloud SQL per PostgreSQL, consulta Utilizzare le chiavi di crittografia gestite dal cliente (CMEK).

Per utilizzare i CMEK creati da Cloud KMS Autokey per proteggere le risorse Cloud SQL per PostgreSQL, segui come esempio i passaggi forniti per Secret Manager in Utilizzare Autokey con le risorse Secret Manager.

Confronto tra crittografia gestita da Google e crittografia gestita dal cliente

I diagrammi riportati di seguito mostrano come funziona la crittografia dei dati at-rest all'interno di un'istanza Cloud SQL quando si utilizza la crittografia predefinita di Google rispetto alle chiavi di crittografia gestite dal cliente.

Senza CMEK

I dati vengono caricati su Google e poi suddivisi in blocchi e ogni blocco viene criptato con una propria chiave di crittografia dei dati. Il wrapping delle chiavi di crittografia dei dati viene eseguito utilizzando una chiave di crittografia della chiave. Con la funzionalità di crittografia predefinita di Google, la chiave di crittografia della chiave viene recuperata dall'archivio chiavi interno di Google. I blocchi criptati e le chiavi di crittografia con wrapping vengono distribuiti nell'infrastruttura di archiviazione di Google.

Con CMEK

I dati vengono caricati su Google, poi suddivisi in blocchi e ogni blocco viene criptato con una propria chiave di crittografia dei dati. Le chiavi di crittografia dei dati vengono sottoposte a wrapping utilizzando una chiave di crittografia della chiave. Se CMEK utilizza Cloud KMS, la chiave di crittografia della chiave viene recuperata da Cloud KMS. I blocchi criptati e le chiavi di crittografia con wrapping vengono distribuiti nell'infrastruttura di archiviazione di Google.

Quando decripta i dati con wrapping con chiavi di crittografia gestite dal cliente, Cloud SQL utilizza la KEK per decriptare la DEK e la DEK non criptata per decriptare i dati at-rest.

Blocco di dati criptato con DEK e archiviato con DEK con wrapping. Una richiesta di annullamento del wrapping della DEK viene inviata allo spazio di archiviazione KMS, che memorizza la KEK non esportabile. KMS Storage restituisce la DEK senza wrapping.

Quando Cloud SQL interagisce con le chiavi CMEK?

Operazione Note
Creazione dell'istanza Durante la creazione dell'istanza, la configuri in modo che utilizzi il prompt di crittografia gestite dal cliente.
Creazione del backup Durante i backup per un'istanza abilitata per CMEK, crittografia gestita dal cliente Le chiavi criptano i dati utente, ad esempio query e risposte degli utenti. Backup da un Eredita l'istanza abilitata per CMEK e la crittografia con la stessa chiave Cloud KMS dell'istanza di origine.
Ripristino dell'istanza Durante i ripristini di un'istanza abilitata per CMEK, Cloud SQL utilizza la chiave per accedere ai dati nell'istanza di backup in fase di ripristino. Quando ripristini un un'istanza diversa, l'istanza di destinazione può utilizzare una chiave diversa la crittografia.
Creazione di una replica Quando crei una replica di lettura di un'istanza Cloud SQL nello stesso eredita la CMEK dall'istanza padre. Se crei una replica di lettura in un'altra regione, devi selezionare un CMEK dall'altra regione. Ogni regione utilizza il proprio set di chiavi.
Clona creazione Le istanze clone di un'istanza con CMEK abilitato ereditano la crittografia CMEK con la stessa chiave Cloud KMS dell'istanza di origine.
Aggiornamento dell'istanza Durante gli aggiornamenti di un'istanza con CMEK abilitato, Cloud SQL controlla la chiave CMEK.

Quali località supportano le istanze Cloud SQL abilitate per CMEK?

CMEK è disponibile in tutte le località delle istanze di Cloud SQL.

Informazioni sugli account di servizio

Se per le tue istanze Cloud SQL è abilitata la chiave CMEK, devi utilizzare un account di servizio richiedere l'accesso alla chiave a Cloud KMS.

Per utilizzare una chiave di crittografia gestita dal cliente in un progetto, devi disporre di un e devi concedere alla chiave di crittografia gestita dal cliente l'accesso l'account di servizio. L'account di servizio deve esistere all'interno del progetto. La è visibile in tutte le regioni.

Se utilizzi la console per creare un'istanza, Cloud SQL esegue automaticamente crea l'account di servizio quando scegli per la prima volta la chiave gestita dal cliente (se non esiste già un account di servizio). Non è necessario disporre di autorizzazioni speciali sul tuo account utente quando Cloud SQL crea automaticamente l'account di servizio.

Informazioni sulle chiavi

In Cloud KMS, devi creare un keyring con una chiave di crittografia impostata con una posizione. Quando crei una nuova istanza Cloud SQL, selezioni questa chiave per criptare l'istanza.

Devi conoscere l'ID chiave e la regione della chiave quando crei un nuovo Cloud SQL di Compute Engine che utilizzano chiavi di crittografia gestite dal cliente. Devi posizionare le nuove istanze Cloud SQL nella stessa regione della chiave di crittografia gestita dal cliente associata all'istanza. Puoi creare un progetto sia per le chiavi sia per le istanze Cloud SQL oppure progetti diversi per ciascuno.

Le chiavi di crittografia gestite dal cliente utilizzano il seguente formato:

projects/[KMS_PROJECT_ID]/locations/[LOCATION]/keyRings/[KEY_RING]/cryptoKeys/[KEY_NAME]

Se Cloud SQL non è in grado di accedere alla chiave (ad esempio se disattivi la versione della chiave), sospende l'istanza. Una volta che la chiave diventa nuovamente accessibile, Cloud SQL riprende automaticamente l'istanza.

Quando ruoti le chiavi, le istanze criptate con quella chiave non vengono automaticamente viene ricriptata con la nuova versione della chiave primaria. Puoi ricriptare qualsiasi tipo di dati Istanza o replica principale CMEK con la nuova versione della chiave primaria. Per ulteriori informazioni su come eseguire nuovamente la crittografia di un'istanza o di una replica Cloud SQL dopo una rotazione delle chiavi, consulta Eseguire nuovamente la crittografia di un'istanza o di una replica abilitata per CMEK esistente.

Gestori delle chiavi esterni

Puoi usare chiavi memorizzate in gestori di chiavi esterni, ad esempio Fortanix, Futurex o Thales, come chiavi di crittografia gestite dal cliente. Per scoprire come utilizzare indirizzi con Cloud KMS, vedi Cloud External Key Manager (Cloud EKM).

Key Access Justifications

Puoi utilizzare Key Access Justifications come parte di Cloud EKM. Key Access Justifications consente di visualizzare il motivo di ogni richiesta Cloud EKM. Inoltre, in base alla giustificazione fornita, puoi approvare o rifiutare automaticamente una richiesta. Per ulteriori informazioni, consulta Key Access Justifications Panoramica.

Di conseguenza, Key Access Justifications offre un maggiore controllo sui tuoi dati fornendo una e una giustificazione per ogni tentativo di decriptare i dati.

Per informazioni correlate sull'utilizzo delle chiavi con le istanze Cloud SQL, consulta Creazione di un'istanza Cloud SQL con CMEK.

Come faccio a rendere i dati criptati con CMEK definitivamente inaccessibili?

Potresti trovarti in situazioni in cui vuoi distruggere definitivamente i dati criptati con CMEK. Per farlo, devi eliminare la versione della chiave di crittografia gestita dal cliente. Non puoi eliminare il keyring o la chiave, ma puoi eliminare le versioni della chiave chiave.

Come posso esportare e importare i dati da e in un'istanza abilitata per CMEK?

Se vuoi che i tuoi dati rimangano criptati con una chiave gestita dal cliente durante per esportare o importare, devi impostare una chiave di crittografia gestita dal cliente nel bucket Cloud Storage prima di esportare i dati al suo interno. Non esistono offerte speciali o restrizioni all'importazione dei dati in una nuova istanza quando è stato precedentemente archiviato su un'istanza abilitata con una crittografia gestita dal cliente chiave.

Limitazioni

Quando utilizzi le chiavi di crittografia gestite dal cliente, si applicano le seguenti limitazioni:

  • Non puoi abilitare le chiavi di crittografia gestite dal cliente su un'istanza esistente.
  • Non puoi assegnare una chiave diversa a una replica nella stessa regione del dell'istanza principale. Per le repliche tra regioni, devi creare una nuova chiave regione.
  • Non puoi assegnare una chiave diversa a un clone.
  • Non puoi utilizzare le chiavi di crittografia gestite dal cliente per criptare:
    • Server esterni (istanze principali esterne e repliche esterne)
    • Metadati dell'istanza, come l'ID istanza, la versione del database e la macchina tipo, flag, pianificazione del backup e così via
  • Non puoi utilizzare le chiavi di crittografia gestite dal cliente per criptare i dati utente in transito, ad esempio query e risposte degli utenti.

Passaggi successivi