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 che dell'applicazione è in grado di 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 localmente nell'applicazione.
In questo argomento viene spiegato come utilizzare la prima opzione, che offre la un'opzione di gestione delle chiavi semplice. Creiamo una chiave di crittografia Cloud KMS e implementare crittografia busta utilizzando Tink, il servizio crittografico open source di Google libreria.
Perché è necessaria la crittografia lato client?
Ti serve la crittografia lato client per proteggere i dati di Cloud SQL a livello di colonna 1. Immagina di avere una tabella di nomi e carte di credito numeri. 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 il lato client la crittografia. Se all'utente non viene concesso l'accesso alla chiave di crittografia in a Cloud KMS, non riescono a leggere i dati della carta di credito.
Crea chiavi utilizzando Cloud KMS
Cloud KMS consente di creare e gestire le chiavi nella Google Cloud Platform.
Cloud KMS supporta molti tipi di chiavi diversi. Per la crittografia lato client, devi creare una chiave simmetrica.
Per consentire alla tua applicazione di accedere alla chiave in Cloud KMS, devi
concedere l'account di servizio utilizzato dall'applicazione con
Ruolo cloudkms.cryptoKeyEncrypterDecrypter
. In gcloud, utilizzi il seguente codice
per eseguire questa operazione:
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 sia possibile utilizzare la chiave KMS per criptare i dati, in questo caso utilizziamo una soluzione più flessibile chiamata crittografia busta. In questo modo possiamo criptare i messaggi più lunghi di 64 kB, ovvero la dimensione massima dei messaggi che l'API Cloud Key Management Service può supportare.
Crittografia della busta di Cloud KMS
Nella crittografia envelope, la chiave KMS funge da chiave di crittografia della chiave (KEK). Vale a dire che viene utilizzato per crittografare le chiavi di crittografia dei dati (DEK), che a loro volta sono utilizzate per crittografare i dati effettivi.
Dopo aver creato una chiave 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 envelope da zero, in questo argomento utilizziamo Tink.
Tink
Tink è una libreria multipiattaforma e multilingue che offre le API crittografiche. Per criptare i dati con la crittografia envelope di Tink, devi fornire Tink con un URI della chiave che rimandi alla tua KEK in Cloud KMS e credenziali che consentono a Tink di usare la KEK. Tink genera la DEK, cripta i dati, esegue il wrapping della DEK e restituisce un singolo testo cifrato con i dati criptati e la DEK con wrapping.
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 che tu abbia un database con
campo user-id
e un campo encrypted-medical-history
. In questo caso, il campo
Probabilmente user-id
dovrebbe essere usato come dati associati per criptare i dati medici
storia. In questo modo si garantisce che un aggressore non possa trasferire la storia clinica di un utente
a un 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 di un database contenente le informazioni sugli elettori. che utilizza la crittografia lato client. Il codice di esempio mostra come:
- Crea 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 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 del nome 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.