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

Pour obtenir la liste détaillée des données que Looker chiffre, envoyez 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 versionnée pour garantir la validation. Ce mode nécessite l'utilisation d'une clé maître client (CMK) externe. La CMK permet de dériver, de chiffrer et de déchiffrer la clé de chiffrement de clé (KEK), qui permet à son tour de dériver, de chiffrer et de 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 client. 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 KEK sont chiffrées et utilisées en interne sur l'installation 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 les procédures décrites dans les sections suivantes dans l'ordre.

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 configuré 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, 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 une CMK

Si vous utilisez AWS KMS, créez une CMK à l'aide de la console de gestion AWS 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 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 de clé CMEK, définissez les autorisations du fichier de clé sur "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 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.

Vous trouverez ci-dessous 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 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 d'accès du fichier de 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 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 le keystore de sauvegarde est manquant : Looker ne trouve pas la CMK. Vérifiez que le chemin d'accès à la 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.