Informazioni sulle chiavi di crittografia gestite dal cliente (CMEK)

Per impostazione predefinita, Cloud SQL per MySQL cripta i contenuti dei clienti at-rest. Cloud SQL per MySQL 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 MySQL. 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 di 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 che essere di proprietà e gestite da Google, le chiavi di crittografia della chiave (KEK) simmetriche che proteggono i tuoi dati sono sotto il tuo controllo e vengono gestite in Cloud KMS.

Dopo aver configurato le risorse con i CMEK, l'esperienza di accesso alle risorse Cloud SQL per MySQL è simile all'utilizzo della crittografia predefinita di Google. Per saperne di più sulle opzioni di crittografia, consulta Chiavi di crittografia gestite dal cliente (CMEK).

CMEK con Autokey di Cloud KMS

Puoi creare CMEK manualmente per proteggere le risorse Cloud SQL per MySQL oppure utilizzare Autokey di Cloud KMS. Con Autokey, le chiavi e i keyring vengono generati on demand nell'ambito della creazione delle risorse in Cloud SQL per MySQL. 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 BackupRun Cloud SQL per MySQL. Quando crei un backup di un'istanza Cloud SQL per MySQL, il backup viene criptato con la chiave gestita dal cliente dell'istanza principale.

Cloud SQL per MySQL è compatibile con Cloud KMS Autokey 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 MySQL, 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 MySQL, 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, 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. Con la crittografia Google predefinita, la chiave di crittografia della chiave viene recuperata dal Keystore 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. Con le chiavi CMEK che utilizzano 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 decriptata.

Quando Cloud SQL interagisce con le chiavi CMEK?

Operazione Note
Creazione dell'istanza Durante la creazione dell'istanza, la configuri in modo che utilizzi le chiavi di crittografia gestite dal cliente.
Creazione del backup Durante i backup di un'istanza abilitata per CMEK, le chiavi di crittografia gestite dal cliente criptano i dati utente, ad esempio query e risposte degli utenti. I backup di un'istanza con CMEK abilitato ereditano la crittografia con la stessa chiave Cloud KMS dell'istanza di origine.
Ripristino dell'istanza Durante i ripristini di un'istanza con CMEK abilitato, Cloud SQL utilizza la chiave per accedere ai dati dell'istanza di backup in fase di ripristino. Quando esegui il ripristino in un'istanza diversa, l'istanza di destinazione può utilizzare una chiave diversa per la crittografia.
Creazione di una replica Quando crei una replica di lettura o di failover di un'istanza Cloud SQL nella stessa regione, questa eredita la chiave CMEK dall'istanza principale. Se crei una replica di lettura o di failover in un'altra regione, devi selezionare una chiave CMEK dall'altra regione. Ogni regione utilizza il proprio set di chiavi.
Creazione del clone Le istanze clonate da 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 Cloud SQL.

Informazioni sugli account di servizio

Quando le istanze Cloud SQL hanno CMEK abilitato, devi utilizzare un account di servizio per richiedere l'accesso alle chiavi da Cloud KMS.

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

Se utilizzi la console per creare un'istanza, Cloud SQL crea automaticamente l'account di servizio quando scegli per la prima volta l'opzione 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, seleziona questa chiave per criptarla.

Devi conoscere l'ID chiave e la regione della chiave quando crei nuove istanze Cloud SQL che utilizzano le chiavi di crittografia gestite dal cliente. Devi inserire 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. Quando la chiave diventa nuovamente accessibile, Cloud SQL riprende automaticamente l'istanza.

Quando ruoti le chiavi, le istanze criptate con quella chiave non vengono criptate nuovamente automaticamente con la nuova versione della chiave primaria. Puoi criptare nuovamente qualsiasi istanza o replica principale CMEK esistente 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 della chiave, consulta Eseguire nuovamente la crittografia di un'istanza o di una replica abilitata per CMEK esistente.

Gestori delle chiavi esterni

Puoi utilizzare le chiavi archiviate in gestori di chiavi esterni, come Fortanix, Futurex o Thales, come chiavi di crittografia gestite dal cliente. Per scoprire come utilizzare le chiavi esterne con Cloud KMS, consulta Cloud External Key Manager (Cloud EKM).

Key Access Justifications

Puoi utilizzare Key Access Justifications nell'ambito 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 scoprire di più, consulta la Panoramica delle giustificazioni per l'accesso alle chiavi.

Pertanto, Key Access Justifications offre un maggiore controllo sui tuoi dati fornendo una giustificazione per ogni tentativo di decriptazione dei 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 con crittografia CMEK definitivamente inaccessibili?

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

Come faccio a esportare e importare dati da e verso un'istanza con CMEK abilitato?

Se vuoi che i tuoi dati rimangano criptati con una chiave gestita dal cliente durante un'esportazione o un'importazione, devi impostare una chiave di crittografia gestita dal cliente nel bucket Cloud Storage prima di esportarvi i dati. Non esistono requisiti o limitazioni speciali per l'importazione dei dati in una nuova istanza se i dati sono stati precedentemente archiviati in un'istanza abilitata con una chiave di crittografia gestita dal cliente.

Limitazioni

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

  • Non puoi attivare le chiavi di crittografia gestite dal cliente in un'istanza esistente.
  • Non puoi assegnare una chiave diversa a una replica nella stessa regione dell'istanza principale. Per le repliche tra regioni, devi creare una nuova chiave per la regione della replica.
  • 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, ad esempio ID istanza, versione del database, tipo di macchina, 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.
  • Dopo aver creato un'istanza Cloud SQL, non puoi modificare il tipo di chiave di crittografia. Non puoi passare da una chiave di crittografia gestita da Google a una chiave Cloud Key Management Service (KMS) e viceversa.

Passaggi successivi