Migrer vers le chiffrement GCM AES-256

robots: noindex

Looker utilise le chiffrement GCM (AES-256 Galois/Counter Mode) 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 base de données et les connexions aux services
  • Informations d'authentification des utilisateurs
  • Valeurs des attributs utilisateur
  • Données client mises en cache ou prêtes à être diffusées

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 multiversion afin de garantir la validation. Ce mode nécessite l'utilisation d'une clé principale client (CMK) externe. La clé CMK sert à dériver, chiffrer et déchiffrer la clé de chiffrement de clé (KEK), qui à son tour est utilisée pour générer, 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. Le chiffrement de Looker n'a aucune incidence sur les bases de données des clients. De plus, seules les données statiques (stockées sur un 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 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 existantes hébergées par le client qui souhaitent utiliser le chiffrement GCM doivent passer de l'ancien chiffrement au nouveau chiffrement GCM. Les nouvelles installations hébergées par le client nécessitent une configuration supplémentaire pour le chiffrement GCM.

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

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

Si vous passez au chiffrement GCM depuis une instance Looker existante, veillez à créer une sauvegarde complète en cas de problème de 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 cette 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, cette opération ne devrait prendre que quelques minutes. Ensuite, arrêtez Looker.

Si Looker est en cluster, veillez à 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 la commande de migration, celle-ci é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 un CMK

Si vous utilisez AWS KMS, créez un 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 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é le code CMK, copiez-le et utilisez la commande suivante pour le stocker dans la variable d'environnement LKR_MASTER_KEY_ENV (où <CMK_value> correspond au code généré à l'aide de 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 le code CMK dans un fichier, vous pouvez utiliser la commande suivante, où <path_to_CMK_file> correspond au chemin d'accès et au nom du fichier 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>

Une fois que vous avez généré un CMK, veillez à le stocker dans un endroit 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 IAM AWS

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 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 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 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 CMK dans une variable d'environnement, définissez la variable d'environnement LKR_MASTER_KEY_ENV sur la valeur de la 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 avec vos identifiants de base de données, vous devrez 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 démarre lorsque vous démarrez la nouvelle instance Looker.

Le processus de 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 permet de les résoudre:

  • Impossible de trouver la tâche "migrate_encryption": mettez à jour votre instance Looker vers Looker 6.4.

  • Looker ne peut pas démarrer, car il manque un keystore de sauvegarde : Looker ne trouve pas le CMK. Vérifiez que le chemin CMK de 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 de X. La CMK doit comporter exactement 32 octets.

  • Looker ne peut pas démarrer, car l'autorisation pour le fichier de clé de sauvegarde doit être 0400, mais il est XXX : le fichier CMK doit être en lecture seule avec la valeur chmod de 0400.