Informazioni sulle chiavi di crittografia gestite dal cliente (CMEK)

Per impostazione predefinita, Cloud SQL per SQL Server cripta i contenuti dei clienti at-rest. Cloud SQL per SQL Server 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 i servizi integrati con CMEK, tra cui Cloud SQL per SQL Server. 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 le CMEK, l'esperienza di accesso Le risorse di Cloud SQL per SQL Server sono simili 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 Cloud KMS Autokey

Puoi creare manualmente CMEK per proteggere Cloud SQL per SQL Server o usare Cloud KMS Autokey. Con Autokey, i keyring e le chiavi vengono generati on demand come della creazione di risorse in Cloud SQL per SQL Server. 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 creare chiavi per le risorse Cloud SQL per SQL Server BackupRun. Quando crei un backup di un'istanza Cloud SQL per SQL Server, è criptato con la chiave gestita dal cliente dell'istanza principale.

Cloud SQL per SQL Server è 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 risorse Cloud SQL per SQL Server, consulta Utilizza le chiavi di crittografia gestite dal cliente (CMEK).

Per utilizzare le CMEK create da Cloud KMS Autokey per proteggere le risorse Cloud SQL per SQL Server, segui i passaggi forniti per Secret Manager in Using Autokey with Risorse di Secret Manager come esempio.

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 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 crittografia Google predefinita, la chiave di crittografia della chiave viene recuperata dal Keystore 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. Il wrapping delle chiavi di crittografia dei dati viene eseguito 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 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 il prompt 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 abilitata per CMEK, Cloud SQL utilizza la chiave per accedere ai dati nell'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 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.
Creazione del clone 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 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. L'account servizio è 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, 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 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 di Cloud SQL o di 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 accessibile di nuovo, Cloud SQL ripristina 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 di 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 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 richiesta. Per ulteriori informazioni, consulta Key Access Justifications Panoramica.

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 criptati con CMEK definitivamente inaccessibili?

Potresti voler eliminare 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 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 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 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 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