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 te senza alcuna azione aggiuntiva sul tuo parte. 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 servizi integrati con CMEK, tra cui Cloud SQL per MySQL. L'utilizzo delle chiavi Cloud KMS consente di controllare la protezione livello, posizione, pianificazione della rotazione, autorizzazioni di utilizzo e accesso e confini crittografici. L'utilizzo di Cloud KMS consente inoltre puoi monitorare l'utilizzo delle chiavi, visualizzare i log di controllo e e controllare i cicli di vita chiave. 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 ulteriori informazioni sulla crittografia vedi Chiavi di crittografia gestite dal cliente (CMEK).

CMEK con Cloud KMS Autokey

Puoi creare manualmente CMEK per proteggere Cloud SQL per MySQL o usare Cloud KMS Autokey. Con Autokey, i keyring e le chiavi vengono generati on demand come parte della creazione di risorse in Cloud SQL per MySQL. Gli agenti di servizio che utilizzano le chiavi per le operazioni di crittografia e decriptazione vengono creati se non utilizzano queste chiavi esistono già e dispongono dei ruoli Identity and Access Management (IAM) richiesti. Per maggiori informazioni 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 solo con Cloud KMS Autokey quando si creano risorse con Terraform o l'API REST.

Per scoprire come utilizzare CMEK create manualmente per proteggere le tue risorse Cloud SQL per MySQL, consulta Utilizza 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 la crittografia dei dati at-rest funziona all'interno di un'istanza Cloud SQL quando si utilizza la crittografia predefinita di Google rispetto a quelle 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 funzionalità di crittografia predefinita di Google, la chiave di crittografia della chiave viene recuperata dall'archivio chiavi interno di Google. I blocchi crittografati e le chiavi di crittografia con wrapping sono distribuiti nell'infrastruttura di archiviazione di Google.

Con 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. 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 si decriptano i dati sottoposti a wrapping con chiavi di crittografia gestite dal cliente, Cloud SQL utilizza la KEK per decriptare la DEK e la DEK non criptata decriptare i dati at-rest.

Blocco di dati criptato con DEK e archiviato con DEK con wrapping. Una richiesta di unwrapping della DEK viene inviata allo spazio di archiviazione KMS, in cui è archiviata 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 le chiavi 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 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 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 per creare una replica di lettura o di failover in una regione diversa, devi selezionare 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

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 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, selezioni questa chiave per criptare l'istanza.

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 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 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 principale. 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 le chiavi esterne con Cloud KMS, consulta Cloud External Key Manager (Cloud EKM).

Key Access Justifications

Puoi utilizzare le giustificazioni di accesso alle chiavi nell'ambito di Cloud EKM. Key Access Justifications che ti consentiranno di visualizzare il motivo di ogni richiesta di Cloud EKM. Inoltre, in base alla giustificazione fornita, puoi approvare o rifiutare automaticamente 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 distruggere il mazzo di chiavi o la chiave, ma puoi distruggere le versioni della 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 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 si utilizzano 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 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, 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.

Passaggi successivi