Questa pagina descrive come implementare la crittografia lato client su Cloud SQL.
Panoramica
La crittografia lato client consiste nel criptare i dati prima di scriverli in Cloud SQL. Puoi criptare i dati di Cloud SQL in modo che solo la tua applicazione possa decriptarli.
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 localmente nell'applicazione.
In questo argomento viene descritto come utilizzare la prima opzione, che offre la gestione delle chiavi più semplice. Creiamo una chiave di crittografia in Cloud KMS e implementiamo la crittografia dell'involucro utilizzando Tink, la libreria crittografica open source di Google.
Perché hai bisogno della crittografia lato client?
La crittografia lato client è necessaria 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 possa visualizzare i numeri di carta di credito. Puoi criptare i numeri utilizzando la crittografia lato client. Finché all'utente non viene concesso l'accesso alla chiave di crittografia in Cloud KMS, non può leggere i dati della carta di credito.
Creare chiavi utilizzando Cloud KMS
Cloud KMS ti 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 all'applicazione l'accesso alla chiave in Cloud KMS, devi assegnare all'account di servizio utilizzato dall'applicazione il ruolo cloudkms.cryptoKeyEncrypterDecrypter
. In gcloud, 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 dell'involucro. In questo modo, possiamo criptare i messaggi più lunghi di 64 KB, che è la dimensione massima supportata dall'API Cloud Key Management Service.
Crittografia envelope Cloud KMS
Nella crittografia envelope, la chiave KMS funge da chiave di crittografia della chiave (KEK). In altre parole, 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:
- Genera una chiave di crittografia dei dati (DEK) localmente.
- Utilizza questa DEK localmente per criptare il messaggio.
- Chiama Cloud KMS per criptare (avvolgere) la DEK con la KEK.
- Memorizza i dati criptati e la chiave DEK con wrapping.
Anziché implementare la crittografia dell'involucro da zero, in questo argomento utilizziamo Tink.
Tink
Tink è una libreria multipiattaforma e multilingue che fornisce API di crittografia di alto livello. Per criptare i dati con la crittografia dell'envelope di Tink, fornisci a Tink un URI chiave che rimandi alla tua KEK in Cloud KMS e le credenziali che consentono a Tink di utilizzare la KEK. Tink genera la DEK, cripta i dati, cripta la DEK e restituisce un singolo testo cifrato con i dati criptati e la DEK criptata.
Tink supporta la crittografia dell'involucro 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 messaggio/crittogramma, i metodi di crittografia e decrittografia supportano i dati associati facoltativi. Questo argomento può essere utilizzato per associare il testo cifrato a un dato. 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
dovrebbe probabilmente essere utilizzato come dati associati durante la crittografia della
storia clinica. In questo modo, un malintenzionato non può spostare la storia clinica da un utente all'altro. Viene utilizzato anche per verificare di avere la riga di dati corretta quando
esegui una query.
Esempi
In questa sezione esamineremo il codice campione di 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
- Configurare Tink per la crittografia envelope
- Crittografa e decripta i dati utilizzando la crittografia dell'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 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.