Questa pagina descrive come implementare la crittografia lato client su Cloud SQL.
Panoramica
La crittografia lato client è l'atto di criptare i dati prima di scriverli in Cloud SQL. Puoi criptare i dati di Cloud SQL in modo tale che solo la tua applicazione possa decriptare.
Per attivare la crittografia lato client, hai a disposizione le seguenti opzioni:
- Utilizzo di una chiave di crittografia archiviata in Cloud Key Management Service (Cloud KMS).
- Utilizzo di una chiave di crittografia archiviata in locale nella tua applicazione.
In questo argomento descriviamo come utilizzare la prima opzione, che offre l'opzione di gestione delle chiavi più fluida. Creiamo una chiave di crittografia in Cloud KMS e implementiamo la crittografia envelope utilizzando Tink, la libreria crittografica open source di Google.
Perché è necessaria la crittografia lato client?
Devi avere la crittografia lato client se vuoi proteggere i dati di Cloud SQL a livello di colonna.1 Immagina di avere una tabella di nomi e numeri di carte di credito. Vuoi concedere a un utente l'accesso a questa tabella, ma non vuoi che visualizzi i numeri di carta di credito. Puoi criptare i numeri usando la crittografia lato client. Finché all'utente non è concesso l'accesso alla chiave di crittografia in Cloud KMS, all'utente non sarà possibile leggere i dati della carta di credito.
Creare chiavi utilizzando Cloud KMS
Cloud KMS consente di creare e gestire le chiavi sulla Google Cloud Platform.
Cloud KMS supporta molti tipi di chiavi diversi. Per la crittografia lato client, devi creare una chiave simmetrica.
Per concedere alla tua applicazione l'accesso alla chiave in Cloud KMS, devi concedere l'account di servizio utilizzato dall'applicazione con il ruolo cloudkms.cryptoKeyEncrypterDecrypter
. In gcloud, usa questo comando
per farlo:
gcloud kms keys add-iam-policy-binding key \ --keyring=key-ring \ --location=location \ --member=serviceAccount:service-account-name@example.domain.com \ --role=roles/cloudkms.cryptoKeyEncrypterDecrypter
Anche se puoi utilizzare la chiave KMS per criptare direttamente i dati, in questo caso utilizziamo una soluzione più flessibile chiamata crittografia envelope. In questo modo possiamo criptare i messaggi più lunghi di 64 kB, ovvero la dimensione massima dei messaggi supportata dall'API Cloud Key Management Service.
Crittografia envelope di Cloud KMS
Nella crittografia envelope, la chiave KMS agisce come chiave di crittografia della chiave (KEK). Vale a dire che vengono utilizzate per criptare le chiavi di crittografia dei dati (DEK) che a loro volta vengono utilizzate per criptare i dati effettivi.
Dopo aver creato una KEK in Cloud KMS, per criptare ogni messaggio devi:
- Genera una chiave di crittografia dei dati (DEK) localmente.
- Utilizza questa DEK in locale per criptare il messaggio.
- Chiama Cloud KMS per criptare (wrapping) la DEK con la KEK.
- Archivia i dati criptati e la DEK con wrapping.
Anziché implementare la crittografia envelope da zero, in questo argomento usiamo Tink.
Tink
Tink è una libreria multilingue e multipiattaforma che fornisce API crittografiche di alto livello. Per criptare i dati con la crittografia envelope di Tink, devi fornire a Tink un URI della chiave che punta alla tua KEK in Cloud KMS e le credenziali che permettono a Tink di utilizzare la KEK. Tink genera la DEK, cripta i dati, esegue il wrapping della DEK e restituisce un singolo testo crittografato con i dati criptati e la DEK con wrapping.
Tink supporta la crittografia envelope in C++, Java, Go e Python utilizzando l'API AEAD:
public interface Aead{
byte[] encrypt(final byte[] plaintext, final byte[] associatedData)
throws…
byte[] decrypt(final byte[] ciphertext, final byte[] associatedData)
throws…
}
Oltre al normale argomento messaggio/testo crittografato, i metodi di crittografia e decriptazione supportano dati associati facoltativi. Questo argomento può essere usato per collegare
il testo crittografato a un dato. Ad esempio, supponi di avere un database con un campo user-id
e un campo encrypted-medical-history
. In questo caso, probabilmente il campo user-id
dovrebbe essere utilizzato come dati associati durante la crittografia della cronologia medica. Ciò garantisce che un utente malintenzionato non possa trasferire l'anamnesi medica da un utente all'altro. Viene utilizzato anche per verificare che la riga di dati sia corretta quando esegui una query.
Esempi
In questa sezione, esamineremo il codice campione per un database di informazioni sugli elettori che utilizza la crittografia lato client. Il codice campione mostra come:
- Crea una tabella di database e un pool di connessioni
- Configura Tink per la crittografia busta
- Cripta e decripta i dati utilizzando la crittografia envelope di Tink con una KEK in Cloud KMS
Prima di iniziare
Crea un'istanza Cloud SQL seguendo queste instructions. Prendi nota della stringa di connessione, dell'utente e della password del database che crei.
Crea un database per la tua applicazione seguendo queste instructions. Prendi nota del nome del database.
Crea una chiave KMS per la tua applicazione seguendo queste instructions. Copia il nome della risorsa della chiave creata.
Crea un account di servizio con le autorizzazioni "Client Cloud SQL" seguendo queste instructions.
Aggiungi l'autorizzazione "Autore crittografia/decriptazione CryptoKey Cloud KMS" per la chiave al tuo account di servizio seguendo queste instructions.