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 Cloud SQL in modo che solo la tua applicazione possa decriptarli.
Per abilitare la crittografia lato client, hai le seguenti opzioni:
- Utilizzare una chiave di crittografia archiviata in Cloud Key Management Service (Cloud KMS).
- Utilizzare una chiave di crittografia archiviata localmente nella tua applicazione.
In questo documento, descriviamo come utilizzare la prima opzione, che fornisce l'opzione di gestione delle chiavi più semplice. Creiamo una chiave di crittografia in Cloud KMS e implementiamo la crittografia envelope utilizzando la libreria di crittografia open source di Tink, Google.
Perché è necessaria la crittografia lato client?
È necessaria la crittografia lato client se vuoi proteggere i dati Cloud SQL a livello di colonna. Supponiamo 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 delle carte di credito. Puoi criptare i numeri utilizzando la crittografia lato client. A condizione che all'utente non venga concesso l'accesso alla chiave di crittografia in Cloud KMS, non potrà leggere i dati della carta di credito.
Puoi anche limitare l'accesso a livello di istanza o database.
Creare chiavi utilizzando Cloud KMS
Cloud KMS consente di creare e gestire le chiavi su Google Cloud.
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 all'account di servizio utilizzato dall'applicazione il ruolo cloudkms.cryptoKeyEncrypterDecrypter. In gcloud CLI, utilizza il seguente
comando:
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
Sebbene tu possa utilizzare la chiave KMS per criptare direttamente i dati, qui utilizziamo una soluzione più flessibile chiamata crittografia envelope. In questo modo possiamo criptare messaggi più lunghi di 64 KB, ovvero la dimensione massima dei messaggi che l'API Cloud Key Management Service può supportare.
Crittografia envelope Cloud KMS
Nella crittografia envelope, la chiave KMS funge da chiave di crittografia delle chiavi (KEK). Ovvero, viene utilizzata 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:
- Generare una chiave di crittografia dei dati (DEK) localmente.
- Utilizzare questa DEK localmente per criptare il messaggio.
- Chiama Cloud KMS per criptare (eseguire il wrapping) della DEK con la KEK.
- Archiviare i dati criptati e la DEK con wrapping.
Invece di implementare la crittografia envelope da zero, in questo documento utilizziamo Tink.
Tink
Tink è una libreria multilingue e multipiattaforma che fornisce API di crittografia di alto livello. Per criptare i dati con la crittografia envelope di Tink, fornisci a Tink un URI della chiave che rimanda alla tua KEK in Cloud KMS e le credenziali che consentono a Tink di utilizzare la KEK. Tink genera la DEK, cripta i dati, esegue il wrapping della DEK e restituisce un singolo testo criptato 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 all'argomento normale messaggio/testo criptato, i metodi di crittografia e decrittografia supportano i dati associati facoltativi. Questo argomento può essere utilizzato per collegare il testo criptato a un insieme di dati. Ad esempio, supponiamo di avere un database con un campo user-id e un campo encrypted-medical-history. In questo caso, il campo user-id deve probabilmente essere utilizzato come dati associati durante la crittografia della storia clinica. In questo modo, un utente malintenzionato non può spostare la storia clinica da un utente all'altro. Viene inoltre utilizzato per verificare di avere la riga di dati 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:
- Creare una tabella di database e un pool di connessioni
- Configurare Tink per la crittografia envelope
- Criptare e decriptare i dati utilizzando la crittografia envelope di Tink con una KEK in Cloud KMS
Prima di iniziare
Crea un'istanza Cloud SQL seguendo queste istruzioni. Prendi nota della stringa di connessione, dell'utente del database e della password del database che hai creato.
Crea un database per la tua applicazione seguendo queste istruzioni. Prendi nota del nome del database.
Crea una chiave KMS per la tua applicazione seguendo queste istruzioni. Copia il nome della risorsa della chiave creata.
Crea un account di servizio con le autorizzazioni "Client Cloud SQL" seguendo queste istruzioni.
Aggiungi l'autorizzazione "Autore crittografia/decrittografia CryptoKey Cloud KMS" per la chiave al tuo account di servizio seguendo queste istruzioni.