Chiffrement dans MySQL : stockage des clés

À l'approche du lancement d'un nouveau cycle pour le cours «Bases de données» nous avons préparé pour vous la traduction d'un article utile.

Le chiffrement transparent des données (Transparent Data Encryption, TDE) est apparu dans Percona Server for MySQL et MySQL il y a relativement longtemps. Mais vous êtes-vous déjà demandé comment cela fonctionne en coulisses et quel impact TDE peut avoir sur votre serveur ? Dans cette série d'articles, nous examinerons comment TDE fonctionne en interne. Commençons par le stockage des clés, car cela est nécessaire pour tout chiffrement. Ensuite, nous analyserons en détail comment le chiffrement fonctionne dans Percona Server for MySQL/MySQL et quelles fonctionnalités supplémentaires sont disponibles dans Percona Server for MySQL.

MySQL Keyring

Le Keyring est un plugin qui permet au serveur de demander, de créer et de supprimer des clés dans un fichier local (keyring_file) ou sur un serveur distant (par exemple, dans HashiCorp Vault). Les clés sont toujours mises en cache localement pour accélérer leur récupération.

Les plugins peuvent être classés en deux catégories :

• Stockage local. Par exemple, un fichier local (nous appelons cela un stockage de clés basé sur des fichiers, file-based keyring).
• Stockage distant. Par exemple, le serveur Vault (nous appelons cela un stockage de clés basé sur un serveur, server-based keyring).

Cette distinction est importante car les différents types de stockage se comportent légèrement différemment non seulement lors du stockage et de la récupération des clés, mais aussi au moment du démarrage.

En utilisant un stockage basé sur des fichiers, tout le contenu du stockage est chargé en cache au démarrage : l'identifiant de la clé, l'utilisateur de la clé, le type de clé et la clé elle-même.

Dans le cas d'un stockage basé sur un serveur (par exemple, le serveur Vault), seul l'identifiant de la clé et l'utilisateur de la clé sont chargés au démarrage, donc la récupération de toutes les clés ne ralentit pas le démarrage. Les clés sont chargées paresseusement. Autrement dit, la clé elle-même est chargée depuis Vault uniquement lorsqu'elle est réellement nécessaire. Une fois chargée, la clé est mise en cache en mémoire afin qu'il ne soit pas nécessaire de la récupérer à nouveau via des connexions TLS au serveur Vault. Ensuite, examinons les informations présentes dans le stockage des clés.

Les informations de la clé contiennent les éléments suivants :

• identifiant de clé — l'identifiant de la clé, par exemple :
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• type de clé — le type de clé, basé sur l'algorithme de chiffrement utilisé, valeurs possibles : «AES», «RSA» ou «DSA».
• longueur de clé — la longueur de la clé en octets, AES : 16, 24 ou 32, RSA 128, 256, 512 et DSA 128, 256 ou 384.
• user — propriétaire de la clé. Si la clé est système, par exemple, Master Key, ce champ est vide. Si la clé est créée à l'aide de keyring_udf, ce champ désigne le propriétaire de la clé.
• la clé elle-même

La clé est identifiée de manière unique par une paire : key_id, user.

Il existe également des différences dans le stockage et la suppression des clés.

Le stockage de fichiers fonctionne plus rapidement. On pourrait supposer que le stockage de clés consiste simplement à écrire une clé une seule fois dans un fichier, mais ce n'est pas le cas — il y a plus d'opérations ici. Lors de toute modification du stockage de fichiers, une sauvegarde de tout le contenu est d'abord créée. Supposons que le fichier s'appelle my_biggest_secrets, dans ce cas, la sauvegarde sera my_biggest_secrets.backup. Ensuite, le cache est modifié (des clés sont ajoutées ou supprimées) et, si tout se passe bien, le cache est vidé dans le fichier. Dans de rares cas, comme une panne du serveur, vous pouvez voir ce fichier de sauvegarde. Ce fichier de sauvegarde est supprimé lors du prochain chargement des clés (généralement après le redémarrage du serveur).

Lors de la sauvegarde ou de la suppression d'une clé dans le stockage serveur, le stockage doit se connecter au serveur MySQL avec les commandes « envoyer la clé » / « demander la suppression de la clé » (« send the key » / « request key deletion »).

Revenons à la vitesse de démarrage du serveur. En plus du fait que la vitesse de démarrage est affectée par le stockage lui-même, il y a aussi la question du nombre de clés à récupérer dans le stockage lors du démarrage. Bien sûr, c'est particulièrement important pour les stockages de serveur. Lors du démarrage, le serveur vérifie quelle clé est nécessaire pour les tables/bases de données cryptées et demande la clé au stockage. Sur un serveur « propre » avec un Master Key — le chiffrement doit avoir une seule Master Key, qui doit être extraite du stockage. Cependant, un plus grand nombre de clés peut être nécessaire, par exemple, lorsqu'une sauvegarde est restaurée d'un serveur principal à un serveur de secours. Dans de tels cas, il convient de prévoir une rotation des Master Key. Cela sera abordé plus en détail dans de futurs articles, bien que je souhaite ici noter qu'un serveur utilisant plusieurs Master Key peut démarrer un peu plus lentement, en particulier lors de l'utilisation d'un stockage de clés serveur.

Maintenant, parlons un peu davantage de keyring_file. Lorsque j'ai développé keyring_file, je m'inquiétais également de savoir comment vérifier les modifications apportées à keyring_file pendant que le serveur est en cours d'exécution. Dans la version 5.7, la vérification se faisait sur la base des statistiques du fichier, ce qui n'était pas une solution idéale, et dans la version 8.0, elle a été remplacée par un contrôle de somme de contrôle SHA256.

Lors du premier lancement, keyring_file calcule les statistiques du fichier et la somme de contrôle, qui sont mémorisées par le serveur, et les modifications ne sont appliquées que si elles correspondent. Lorsque le fichier est modifié, la somme de contrôle est mise à jour.

Nous avons déjà abordé de nombreuses questions concernant les magasins de clés. Cependant, il y a un autre sujet important qui est souvent oublié ou mal compris : la séparation des clés entre les serveurs.

Que veux-je dire par là ? Chaque serveur (par exemple, Percona Server) dans le cluster doit avoir un espace distinct sur le serveur Vault, où Percona Server doit stocker ses clés. Dans chaque Master Key stocké, il y a un GUID du serveur Percona Server dans son identifiant. Pourquoi cela est-il important ? Imaginez que vous n'avez qu'un seul serveur Vault et que tous les Percona Server dans le cluster utilisent ce seul serveur Vault. Le problème semble évident. Si tous les Percona Server utilisaient le Master Key sans identifiants uniques, par exemple, id = 1, id = 2, etc., tous les serveurs du cluster utiliseraient la même clé maître. Ce que garantit le GUID — la délimitation entre les serveurs. Pourquoi alors parler de séparation des clés entre les serveurs, s'il existe déjà un GUID unique ? Il y a un autre plugin — keyring_udf. Avec ce plugin, l'utilisateur de votre serveur peut stocker ses clés sur le serveur Vault. Le problème se pose lorsque l'utilisateur crée une clé, par exemple, sur le serveur server1, puis essaie de créer une clé avec le même identifiant sur server2, par exemple :

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 signifie que l'opération est réussie
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

Attendez. Les deux serveurs utilisent le même serveur Vault, la fonction keyring_key_store ne devrait-elle pas échouer sur le serveur server2 ? Étonnamment, si vous essayez de faire la même chose sur un même serveur, vous obtiendrez une erreur :

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

Correct, ROB_1 existe déjà.

Discutons d'abord du deuxième exemple. Comme mentionné précédemment, keyring_vault ou tout autre plugin de stockage (keyring) met en cache tous les identifiants de clé en mémoire. Ainsi, après la création d'une nouvelle clé, ROB_1 est ajouté à server1, et en plus d'envoyer cette clé au Vault, la clé est également ajoutée au cache. Maintenant, lorsque nous tentons d'ajouter cette même clé une deuxième fois, keyring_vault vérifie si cette clé existe dans le cache et renvoie une erreur.

Dans le premier cas, la situation est différente. Les serveurs server1 et server2 ont des caches distincts. Après avoir ajouté ROB_1 au cache des clés sur le serveur server1 et au serveur Vault, le cache des clés sur server2 n'est pas synchronisé. Il n'y a pas de clé ROB_1 dans le cache sur server2. Ainsi, la clé ROB_1 est enregistrée dans keyring_key_store et sur le serveur Vault, ce qui écrase en fait (!) la valeur précédente. Maintenant, la clé ROB_1 sur le serveur Vault est égale à 543210987654321. Il est intéressant de noter que le serveur Vault ne bloque pas de telles actions et écrase facilement l'ancienne valeur.

Nous voyons maintenant pourquoi la séparation par serveurs sur Vault peut être importante — lorsque vous utilisez keyring_udf et souhaitez stocker des clés dans Vault. Comment assurer une telle séparation sur le serveur Vault ?

Il existe deux manières de séparer sur Vault. Vous pouvez créer différents points de montage pour chaque serveur ou utiliser différents chemins au sein d'un même point de montage. La meilleure façon de le montrer est par des exemples. Commençons donc par des points de montage distincts :

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = server2_mount
token = (...)
vault_ca = (...)

Ici, on peut voir que server1 et server2 utilisent différents points de montage. Lors de la séparation des chemins, la configuration ressemblera à ceci :

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server2
token = (...)
vault_ca = (...)

Dans ce cas, les deux serveurs utilisent le même point de montage «mount_point», mais des chemins différents. Lors de la création du premier secret sur le serveur server1 à ce chemin, le serveur Vault crée automatiquement le répertoire «server1». Pour server2, c'est la même chose. Quand vous supprimez le dernier secret dans mount_point/server1 ou mount_point/server2, le serveur Vault supprime également ces répertoires. Si vous utilisez la séparation des chemins, vous devez créer un seul point de montage et modifier les fichiers de configuration pour que les serveurs utilisent des chemins distincts. Le point de montage peut être créé à l'aide d'une requête HTTP. Avec CURL, cela peut se faire comme suit :

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

Tous les champs (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) correspondent aux paramètres du fichier de configuration. Bien sûr, vous pouvez utiliser les utilitaires Vault pour faire la même chose. Mais il est plus simple d'automatiser la création du point de montage. J'espère que ces informations vous seront utiles et que nous nous reverrons dans les prochains articles de cette série.

Lire aussi :

• Sysbench et distribution des variables aléatoires

Source : habr.com