Effectuer une migration vers le chiffrement GCM AES-256

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 les connexions aux bases de données et aux services
  • Informations d'authentification des utilisateurs
  • Valeurs des attributs utilisateur
  • Données client mises en cache ou préparées pour la livraison

Pour obtenir la liste détaillée des données chiffrées par Looker, ouvrez une demande d'assistance.

Les données sont chiffrées à l'aide d'une clé de données unique et contiennent une enveloppe de chiffrement signée et avec gestion des versions pour garantir la vérification. Ce mode nécessite l'utilisation d'une clé maître client (CMK) externe. La clé CMK sert à extraire, chiffrer et déchiffrer la clé de chiffrement de clé (KEK, Key Encryption Key), qui permet à son tour de dériver, de chiffrer et de déchiffrer des 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. De plus, seules les données statiques (données stockées sur 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 des clés personnalisés. Toutes les clés de données et la clé KEK sont chiffrées et utilisées en interne sur l'installation de Looker hébergée par le client. Si vous n'utilisez pas AWS KMS, la CMK externe doit être conservée de manière sécurisée.

Les installations hébergées par le client existantes qui souhaitent utiliser le chiffrement GCM doivent migrer de l'ancien chiffrement vers le nouveau chiffrement GCM. Les nouvelles installations hébergées par le 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ù la migration du chiffrement poserait problème. 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 base de données séparément. Si la base de données est une instance MySQL, prenez un instantané. La base de données étant relativement petite, l'opération ne devrait prendre que quelques minutes. Arrêtez ensuite Looker.

Si Looker est en cluster, veillez à arrêter chaque nœud avant de continuer:

cd looker
./looker stop

Si des nœuds sont toujours en cours d'exécution lorsque vous exécutez la commande de migration ultérieurement, la commande échoue et le message suivant s'affiche : "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 rapidement. Sinon, vérifiez que tous les nœuds du cluster sont arrêtés."

Générer une CMK

Si vous utilisez AWS KMS, créez une clé CMK à l'aide d'AWS Management Console ou de l'API.

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

  • Pour générer la 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 CMK, copiez-la et utilisez la commande suivante pour la stocker dans la variable d'environnement LKR_MASTER_KEY_ENV (où <CMK_value> est la CMK que vous avez générée avec la commande précédente) :

    export LKR_MASTER_KEY_ENV=<CMK_value>
    

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

  • Pour générer et stocker la 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 pour stocker la CMK) :

    openssl rand -base64 32 > <path_to_key_file>
    

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

chmod 0400 <path_to_key_file>

Une fois que vous avez généré une 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 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 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 utilisera le contexte de chiffrement par défaut, 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 CMK dans un fichier, définissez la variable d'environnement LKR_MASTER_KEY_FILE sur le chemin 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 valeur de la clé CMK:

export LKR_MASTER_KEY_ENV=<CMK_value>

Si Looker est configuré 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 démarre avec les options de démarrage -d <db.yaml> ou --internal-db-creds=<db.yaml>, qui fournissent un chemin d'accès à un fichier YAML avec vos identifiants de base de données, vous devez inclure la même option avec 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 Looker.

Le processus de chiffrement prend généralement moins d'une minute. Une fois Looker 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 les solutions à ces erreurs :

  • Tâche "migrate_encryption" introuvable : mettez à jour votre instance Looker vers Looker 6.4.

  • Looker ne peut pas démarrer, car: keystore de sauvegarde manquant: Looker ne trouve pas 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 est de X : la clé principale doit mesurer exactement 32 octets.

  • Looker ne peut pas démarrer, car l'autorisation du 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.