Notez que vous consultez actuellement la documentation de Looker. Pour accéder à la documentation sur Looker Studio, consultez la page https://support.google.com/looker-studio.

Migration vers le chiffrement AES-256 GCM

Looker utilise le chiffrement AES-256 Galois/Counter Mode (GCM) pour chiffrer les données sensibles stockées en interne, y compris:

Sauvegardes de la base de données interne de Looker
Informations sur la connexion au service et à la base de données
Informations d'authentification des utilisateurs
Valeurs des attributs utilisateur
Données client mises en cache ou prêtes à être envoyées

Pour obtenir une liste détaillée des données que Looker chiffre, ouvrez une demande d'assistance.

Les données sont chiffrées à l'aide d'une clé unique et contiennent une enveloppe de chiffrement signée avec versions gérées pour garantir la validation. Ce mode nécessite l'utilisation d'une clé principale client (CMK) externe. La clé CMK permet d'extraire, de chiffrer et de déchiffrer la clé de chiffrement de clé (KEK), qui à son tour sert à dériver, chiffrer et déchiffrer les clés de données.

Le chiffrement n'est utilisé que pour la base de données et le cache internes de Looker. Les bases de données des clients ne sont en aucun cas affectées par le chiffrement de Looker. En outre, seules les données statiques (données stockées sur le disque) sont chiffrées de cette manière.

Les installations hébergées par le client peuvent utiliser leurs propres comptes AWS KMS ou leurs propres systèmes de gestion de clés personnalisés. Toutes les clés de données et la KEK sont chiffrées et utilisées en interne lors de l'installation de Looker hébergée par le client. Si vous n'utilisez pas AWS KMS, la clé CMK externe doit être conservée de manière sécurisée.

Les installations existantes hébergées par le client qui souhaitent utiliser le chiffrement GCM doivent passer de l'ancien chiffrement au nouveau. Les nouvelles installations hébergées par un client nécessitent une configuration supplémentaire pour le chiffrement GCM.

Suivez dans l'ordre les procédures décrites dans les sections suivantes.

Arrêter Looker et créer une sauvegarde complète

Si vous passez au chiffrement GCM à partir d'une instance Looker existante, veillez à créer une sauvegarde complète au cas où il y aurait un problème lors de la migration du chiffrement. Si vous installez une nouvelle instance Looker, ignorez cette section.

Si vous utilisez la base de données interne de 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

Si vous exécutez une base de données MySQL externe pour stocker les données de l'application Looker, sauvegardez-la séparément. Si la base de données est une instance MySQL, prenez un instantané. La base de données étant relativement petite, cela ne devrait prendre que quelques minutes. Arrêtez ensuite Looker.

Si Looker est en cluster, assurez-vous d'arrêter tous les nœuds avant de continuer:

cd looker
./looker stop

Si des nœuds sont toujours en cours d'exécution lorsque vous exécutez ultérieurement la commande de migration, celle-ci échoue et affiche le message suivant : "D'autres nœuds actifs sont connectés à cette base de données Looker backend. Si Looker a été arrêté au cours de la dernière minute, réessayez dans quelques instants. Sinon, vérifiez que tous les nœuds du cluster sont arrêtés."

Générer une clé CMK

Si vous utilisez AWS KMS, créez une clé CMK à l'aide de la console de gestion AWS ou de l'API.

Si vous n'utilisez pas AWS KMS, générez une clé CMK en base64 de 32 octets. Vous pouvez stocker la clé CMK dans une variable d'environnement ou dans un fichier.

Pour générer la clé CMK et la stocker dans une variable d'environnement, vous pouvez utiliser la commande suivante:
```
openssl rand -base64 32
```
Après avoir généré la clé CMK, copiez-la et exécutez la commande suivante pour la stocker dans la variable d'environnement LKR_MASTER_KEY_ENV (où <CMK_value> correspond à la clé CMK générée avec la commande précédente):
```
export LKR_MASTER_KEY_ENV=<CMK_value>
```
Si Looker est en cluster, exécutez la commande précédente sur chaque nœud du cluster.
Pour générer et stocker la clé CMK dans un fichier, vous pouvez utiliser la commande suivante (où <path_to_CMK_file> correspond au chemin d'accès et au nom de fichier de la clé CMK):
```
openssl rand -base64 32 > <path_to_key_file>
```

Après avoir généré le fichier CMK, définissez les autorisations du fichier de clé sur l'utilisateur actuel en lecture seule:

chmod 0400 <path_to_key_file>

Après avoir généré une clé CMK, veillez à la stocker dans un emplacement sûr et permanent avant de continuer. La perte de la clé CMK après le chiffrement de la base de données interne peut entraîner la perte de votre instance.

Créer un rôle AWS IAM

Si vous n'utilisez pas AWS KMS, ignorez cette section.

Si vous utilisez AWS KMS, Looker vous recommande de créer un rôle IAM unique pour votre clé CMK et de l'associer à votre instance Looker.

Voici un exemple de rôle IAM contenant les autorisations minimales requises pour votre clé 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/*"
        }
    ]
}

Définir des variables d'environnement

Si vous utilisez AWS KMS, définissez la variable d'environnement AWS_REGION sur votre région AWS et la variable d'environnement LKR_AWS_CMK sur l'alias de votre clé CMK:

export AWS_REGION=<AWS_region>
export LKR_AWS_CMK=alias/<CMK_alias>

Vous pouvez également définir la variable d'environnement LKR_AWS_CMK_EC pour définir un contexte de chiffrement AWS personnalisé. Si vous ne définissez pas cette variable d'environnement, Looker utilise le contexte de chiffrement par défaut, à savoir la chaîne Looker_Encryption_Context.

export LKR_AWS_CMK_EC=<My_Encryption_Context>

Si vous n'utilisez pas AWS KMS et que vous stockez votre clé CMK dans un fichier, définissez la variable d'environnement LKR_MASTER_KEY_FILE sur le chemin d'accès du fichier CMK:

export LKR_MASTER_KEY_FILE=<path_to_key_file>

Si vous n'utilisez pas AWS KMS et que vous stockez votre clé CMK dans une variable d'environnement, définissez la variable d'environnement LKR_MASTER_KEY_ENV sur la clé CMK:

export LKR_MASTER_KEY_ENV=<CMK_value>

Si Looker est en cluster, exécutez la commande précédente sur chaque nœud du cluster.

Chiffrer la base de données interne

Si vous migrez une instance Looker existante vers le chiffrement GCM, migrez la base de données interne de Looker et démarrez Looker:

java -jar looker.jar migrate_encryption
./looker  start

Si votre instance Looker commence par les options de démarrage -d <db.yaml> ou --internal-db-creds=<db.yaml>, qui fournissent un chemin d'accès à un fichier YAML contenant les identifiants de votre base de données, vous devez inclure cette même option dans la commande java -jar looker.jar migrate_encryption.

Par exemple, java -jar looker.jar migrate_encryption -d /path/file.

Si vous installez une nouvelle instance Looker, le processus de chiffrement commence lorsque vous démarrez la nouvelle instance.

Le chiffrement prend généralement moins d'une minute. Une fois que Looker a démarré, vous pouvez vérifier le nouveau chiffrement en recherchant GCM dans le journal 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

Dépannage

Cette section répertorie certaines erreurs courantes et leurs solutions:

Impossible de trouver la tâche "migrate_encryption": mettez à jour votre instance Looker vers Looker 6.4.
Looker ne peut pas démarrer, car le keystore de sauvegarde est manquant : Looker ne peut pas trouver la clé CMK. Vérifiez que le chemin d'accès CMK dans la variable d'environnement LKR_MASTER_KEY_FILE est correct.
Looker ne peut pas démarrer, car la taille de la clé principale n'est pas valide, elle doit être de 32 octets, mais la taille de X : la clé CMK doit avoir exactement 32 octets.
Looker ne peut pas démarrer, car l'autorisation pour le fichier de clé de sauvegarde doit être 0400, mais est XXX : le fichier CMK doit être en lecture seule avec une valeur chmod de 0400.