robots: noindex
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 sulla connessione a database e servizi
- Informazioni di autenticazione dell'utente
- Valori attributi utente
- Dati dei clienti memorizzati nella cache o pronti per la consegna
Per un elenco dettagliato dei dati criptati da Looker, apri una richiesta di assistenza.
I dati vengono criptati utilizzando una chiave dati univoca e contengono una busta con crittografia firmata e sottoposta a controllo delle versioni a garanzia della verifica. Questa modalità richiede l'utilizzo di una Customer Master Key (CMK) esterna. La chiave CMK viene utilizzata per ricavare, criptare e decriptare la chiave di crittografia delle chiavi (KEK), che a sua volta viene utilizzata per ricavare, criptare e decriptare le chiavi di dati.
La crittografia viene utilizzata solo per il database interno e la cache di Looker. I database dei clienti non sono in alcun modo interessati dalla crittografia di Looker. Inoltre, vengono criptati in questo modo solo i dati statici (dati archiviati su disco).
Le installazioni ospitate dal cliente possono utilizzare i propri account AWS KMS o i propri sistemi di gestione delle chiavi personalizzati. Tutte le chiavi dei 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 dal cliente 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 indicate nelle sezioni seguenti in ordine.
Arresto di Looker e creazione di un backup completo
Se stai eseguendo la migrazione alla crittografia GCM da un'istanza di Looker esistente, assicurati di creare un backup completo nel caso in cui si verifichi un problema 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 Looker, esegui il backup del database separatamente. Se il database è un'istanza MySQL, acquisisci uno snapshot. Il database è relativamente piccolo, quindi dovrebbe richiedere solo qualche minuto. quindi arresta Looker.
Se Looker è in cluster, assicurati di arrestare ogni nodo prima di procedere:
cd looker
./looker stop
Se dopo aver emesso il comando di migrazione sono ancora in esecuzione alcuni nodi, il comando non riuscirà e viene visualizzato 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 usi 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 CMK in una variabile di ambiente o in un file.
Per generare il CMK e archiviarlo in una variabile di ambiente, puoi utilizzare il seguente comando per generare:
openssl rand -base64 32
Dopo aver generato il CMK, copialo e utilizza il comando seguente per archiviare il CMK nella variabile di ambiente
LKR_MASTER_KEY_ENV
(dove<CMK_value>
è il CMK generato con il comando precedente):export LKR_MASTER_KEY_ENV=<CMK_value>
Se Looker è in cluster, esegui il comando precedente su ogni nodo nel cluster.
Per generare e archiviare il CMK in un file, puoi utilizzare il comando seguente (dove
<path_to_CMK_file>
è il percorso e il nome del file per archiviare il 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 con autorizzazione di 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 del CMK dopo la crittografia del database interno può causare la perdita dell'istanza.
Creazione di un ruolo AWS IAM
Se non stai utilizzando AWS KMS, salta questa sezione.
Se utilizzi AWS KMS, Looker ti consiglia di creare un nuovo ruolo IAM univoco per la tua CMK e di collegarlo alla tua istanza di Looker.
Di seguito è riportato un esempio di ruolo IAM che contiene le autorizzazioni minime richieste per 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 usi 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>
In via facoltativa, 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 memorizzi il tuo 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 memorizzi il tuo 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 ogni nodo nel cluster.
Crittografia del database interno
Se esegui 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>
o--internal-db-creds=<db.yaml>
, che forniscono un percorso a un file YAML con le tue credenziali di database, dovrai 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 di Looker.
Il processo di crittografia richiede in genere meno di un minuto. Una volta avviata, puoi verificare la nuova crittografia cercando GCM
nel log di 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 degli errori più comuni e le relative risoluzioni:
Impossibile trovare l'attività "migrate_encryption": aggiorna la tua istanza di Looker a Looker 6.4.
Looker non può avviarsi perché: archivio chiavi mancante: Looker non riesce a trovare CMK. Verifica che il percorso CMK nella variabile di ambiente
LKR_MASTER_KEY_FILE
sia corretto.Looker non può avviarsi perché: le dimensioni della chiave master non sono valide; devono essere 32 byte, ma è X: il CMK deve avere una lunghezza esatta di 32 byte.
Looker non può avviarsi perché: l'autorizzazione per il file della chiave di supporto
deve essere 0400, ma è XXX . Il file CMK deve essere di sola lettura con valorechmod
pari a0400
.