Looker utilizza la crittografia AES-256 Galois/Counter Mode (GCM) per criptare i dati sensibili archiviati internamente, tra cui:
- Backup del database interno di Looker
- Informazioni su database e connessioni di servizio
- Informazioni di autenticazione dell'utente
- Valori degli attributi utente
- Dati dei clienti memorizzati nella cache o pronti per la consegna
Per un elenco dettagliato dei dati criptati da Looker, contatta il tuo account manager o apri una richiesta di supporto nel Centro assistenza di Looker facendo clic su Contattaci.
I dati vengono criptati utilizzando una chiave di dati univoca e contengono una busta con crittografia firmata e con controllo delle versioni per garantire la verifica. Questa modalità richiede l'uso di una chiave master cliente (CMK) esterna. CMK viene utilizzata per ricavare, criptare e decriptare la chiave di crittografia della chiave (KEK), che a sua volta viene utilizzata per ricavare, criptare e decriptare le chiavi di dati.
La crittografia viene utilizzata solo per la cache e il database interni di Looker. I database dei clienti non sono in alcun modo interessati dalla crittografia di Looker. Inoltre, solo i dati statici (dati archiviati su disco) vengono criptati in questo modo.
Le installazioni ospitate dal cliente possono utilizzare i propri account AWS KMS o i propri sistemi di gestione delle chiavi personalizzati. Tutte le chiavi di dati e la KEK sono criptate e utilizzate internamente nell'installazione di Looker ospitata dal cliente. Se non utilizzi AWS KMS, il CMK esterno deve essere conservato in modo sicuro.
Le installazioni ospitate dai clienti esistenti che vogliono utilizzare la crittografia GCM devono eseguire la migrazione dalla crittografia precedente alla nuova crittografia GCM. Le nuove installazioni ospitate dal cliente richiedono una configurazione aggiuntiva per la crittografia GCM.
Segui le procedure descritte nelle sezioni seguenti.
Arresto di Looker e creazione di un backup completo
Se stai eseguendo la migrazione alla crittografia GCM da un'istanza Looker esistente, assicurati di creare un backup completo in caso di problemi con la migrazione della crittografia. Se stai installando una nuova istanza di Looker, salta questa sezione.
Se utilizzi il database interno di Looker:
cd looker
./looker stop
tar -zcvf /tmp/looker-pre-encrypt.tar.gz /home/lookerops/looker --exclude=.cache --exclude=log --exclude=.tmp --exclude=.snapshots --exclude=looker.jar --exclude=authorized_keys --exclude=dr-log --exclude=core
Se esegui un database MySQL esterno per archiviare i dati delle applicazioni di Looker, esegui il backup del database separatamente. Se il database è un'istanza MySQL, crea uno snapshot. Il database è relativamente piccolo, quindi dovrebbe richiedere solo pochi minuti. quindi arresta Looker.
Se Looker è in cluster, assicurati di arrestare tutti i nodi prima di procedere:
cd looker
./looker stop
Se alcuni nodi sono ancora in esecuzione quando in seguito eseguirai il comando di migrazione, il comando avrà esito negativo con il messaggio "Ci sono altri nodi attivi connessi a questo database Looker di backend. Se Looker è stato arrestato nell'ultimo minuto, riprova a breve, altrimenti verifica che tutti i nodi nel cluster siano arrestati."
Generazione di un CMK
Se utilizzi AWS KMS, crea un CMK utilizzando AWS Management Console o l'API.
Se non utilizzi AWS KMS, genera un CMK Base64 a 32 byte. Puoi archiviare la CMK in una variabile di ambiente o in un file.
Per generare la CMK e archiviarla in una variabile di ambiente, puoi utilizzare il comando seguente per generarla:
openssl rand -base64 32Dopo aver generato la CMK, copiala e utilizza il seguente comando per archiviare la CMK nella variabile di ambiente
LKR_MASTER_KEY_ENV(dove<CMK_value>è la CMK che hai generato con il comando precedente):export LKR_MASTER_KEY_ENV=<CMK_value>Se Looker è in cluster, esegui il comando precedente su ciascun nodo nel cluster.
Per generare e archiviare la CMK in un file, puoi utilizzare il comando seguente (dove
<path_to_CMK_file>è il percorso e il nome del file per archiviare la CMK):openssl rand -base64 32 > <path_to_key_file>
Dopo aver generato il file CMK, imposta le autorizzazioni del file della chiave sull'attuale utente in sola lettura:
chmod 0400 <path_to_key_file>
Dopo aver generato un CMK, assicurati di conservarlo in un luogo sicuro e permanente prima di continuare. La perdita della CMK dopo la crittografia del database interno può causare la perdita dell'istanza.
Creazione di un ruolo AWS IAM
Se non utilizzi AWS KMS, salta questa sezione.
Se utilizzi AWS KMS, Looker ti consiglia di creare un nuovo ruolo IAM univoco per la tua CMK e allegarlo con la tua istanza di Looker.
Di seguito è riportato un ruolo IAM di esempio che contiene le autorizzazioni minime richieste per la CMK:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "kms:GenerateRandom",
"Resource": "*"
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"kms:Decrypt",
"kms:Encrypt",
"kms:Generate*",
],
"Resource": "arn:aws:kms:*:*:key/*"
}
]
}
Imposta le variabili di ambiente
Se utilizzi AWS KMS, imposta la variabile di ambiente AWS_REGION sulla tua regione AWS e la variabile di ambiente LKR_AWS_CMK sull'alias della tua CMK:
export AWS_REGION=<AWS_region>
export LKR_AWS_CMK=alias/<CMK_alias>
Facoltativamente, puoi anche impostare la variabile di ambiente LKR_AWS_CMK_EC in modo da impostare un contesto di crittografia AWS personalizzato. Se non imposti questa variabile di ambiente, Looker utilizzerà il contesto di crittografia predefinito, la stringa Looker_Encryption_Context.
export LKR_AWS_CMK_EC=<My_Encryption_Context>
Se non utilizzi AWS KMS e stai archiviando la CMK in un file, imposta la variabile di ambiente LKR_MASTER_KEY_FILE sul percorso del file CMK:
export LKR_MASTER_KEY_FILE=<path_to_key_file>
Se non utilizzi AWS KMS e stai archiviando la CMK in una variabile di ambiente, imposta la variabile di ambiente LKR_MASTER_KEY_ENV sul valore di CMK:
export LKR_MASTER_KEY_ENV=<CMK_value>
Se Looker è in cluster, esegui il comando precedente su ciascun nodo nel cluster.
Crittografia del database interno
Se stai eseguendo la migrazione di un'istanza Looker esistente alla crittografia GCM, esegui la migrazione del database interno di Looker e avvia Looker:
java -jar looker.jar migrate_encryption
./looker start
Se l'istanza di Looker inizia con le opzioni di avvio
-d <db.yaml>e--internal-db-creds=<db.yaml>, che offrono un percorso a un file YAML con le credenziali del database, devi includere la stessa opzione con il comandojava -jar looker.jar migrate_encryption.Ad esempio,
java -jar looker.jar migrate_encryption -d /path/file.
Se installi una nuova istanza di Looker, il processo di crittografia inizierà all'avvio della nuova istanza.
Il processo di crittografia richiede solitamente meno di un minuto. Una volta avviato Looker, puoi verificare la nuova crittografia cercando GCM nel log Looker:
grep GCM log/looker.log
2018-10-29 22:42:20.279 +0000 [INFO|007d0|crypt] :: Starting migration from AES-128-CBC Legacy to AES-GCM-256
2018-10-29 22:42:20.468 +0000 [INFO|007d0|db:looker] :: (0.000152s) INSERT INTO "SETTING" ("KEY", "VALUE") VALUES
Risolvere i problemi
In questa sezione sono elencati alcuni errori comuni e le relative soluzioni:
Impossibile trovare l'attività "migrate_encryption": aggiorna la tua istanza di Looker a Looker 6.4.
Looker non può iniziare perché: archivio chiavi mancante. Looker non riesce a trovare la CMK. Verifica che il percorso CMK nella variabile di ambiente
LKR_MASTER_KEY_FILEsia corretto.Looker non può iniziare perché: le dimensioni della chiave master non sono valide; l'estensione deve essere 32 byte, ma è X: la chiave CMK deve essere lunga esattamente 32 byte.
Looker non può iniziare perché: l'autorizzazione per il file della chiave di backup
deve essere 0400, ma è XXX . Il file CMK deve essere di sola lettura con valorechmodpari a0400.