Chiffrement MySQL: keystore

A la veille du début d'un nouvel ensemble pour le cours "Bases de données", nous avons préparé une traduction d'un article utile pour vous.

---

Le chiffrement transparent des données (TDE) existe depuis longtemps dans Percona Server pour MySQL et MySQL. Mais vous êtes-vous déjà demandé comment cela fonctionne sous le capot et quel impact TDE peut avoir sur votre serveur? Dans cette série d'articles, nous examinerons le fonctionnement de TDE en interne. Commençons par le stockage des clés, car cela est nécessaire pour que tout cryptage fonctionne. Ensuite, nous examinerons de plus près le fonctionnement du chiffrement dans Percona Server pour MySQL / MySQL et quelles fonctionnalités supplémentaires sont disponibles dans Percona Server pour MySQL.

Porte-clés MySQL

Les keyring sont des plugins qui permettent au serveur d'interroger, de créer et de supprimer des clés dans un fichier local (keyring_file) ou sur un serveur distant (comme dans HashiCorp Vault). Les clés sont toujours mises en cache localement pour accélérer la récupération.



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

• Stockage local. Par exemple, un fichier local (nous appelons cela un trousseau de clés basé sur un fichier).
• Stockage à distance. Par exemple Vault Server (nous appelons ce trousseau de clés basé sur le serveur).

Cette séparation 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 également lors du démarrage.



Lors de l'utilisation d'un stockage de fichiers, au démarrage, tout le contenu du stockage est chargé dans le cache: ID de clé, utilisateur de clé, type de clé et la clé elle-même.



Dans le cas d'un coffre-fort principal (tel qu'un serveur Vault), seuls l'ID de clé et l'utilisateur clé sont chargés au démarrage, donc l'obtention 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 à partir de Vault uniquement lorsqu'elle est réellement nécessaire. Une fois chargée, la clé est mise en cache dans la mémoire afin qu'à l'avenir, il ne soit plus nécessaire d'y accéder via des connexions TLS au serveur Vault. Ensuite, regardons quelles informations sont présentes dans le magasin de clés.



Les informations clés contiennent les éléments suivants:

• key id — , :
  
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• key type — , , : «AES», «RSA» «DSA».
• key length — , AES: 16, 24 32, RSA 128, 256, 512 DSA 128, 256 384.
• user — . , , Master Key, . keyring_udf, .

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



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



Le stockage des fichiers est plus rapide. On pourrait supposer qu'un stockage de clés est une simple écriture unique d'une clé dans un fichier, mais non - il y a plus d'opérations en cours ici. Toute modification du stockage de fichiers créera d'abord une sauvegarde de tout le contenu. Supposons que le fichier s'appelle my_biggest_secrets, alors la sauvegarde sera my_biggest_secrets.backup. Ensuite, le cache est modifié (les clés sont ajoutées ou supprimées), et si tout réussit, le cache est vidé dans un fichier. Dans de rares cas, comme une panne de serveur, vous pouvez voir ce fichier de sauvegarde. Le fichier de sauvegarde est supprimé la prochaine fois que les clés sont chargées (généralement après un redémarrage du serveur).



Lors de la sauvegarde ou de la suppression d'une clé dans le référentiel du serveur, le référentiel doit se connecter au serveur MySQL avec les commandes "envoyer la clé" / "demander la suppression de la clé".



Revenons à la vitesse de démarrage du serveur. Outre le fait que le stockage lui-même affecte la vitesse de lancement, il y a également la question du nombre de clés du stockage dont vous avez besoin au démarrage. Bien sûr, cela est particulièrement important pour le stockage back-end. Au démarrage, le serveur vérifie quelle clé est requise pour les tables / tablespaces chiffrés et demande la clé au stockage. Sur un serveur «propre» avec chiffrement par clé principale, il doit y avoir une clé principale, qui doit être récupérée du stockage. Cependant, plus de clés peuvent être nécessaires, par exemple, lors de la restauration d'une sauvegarde du serveur principal vers un serveur de sauvegarde. Dans de tels cas, une rotation de clé principale doit être fournie. Cela sera discuté plus en détail dans les prochains articles, bien que j'aimerais souligner ici que le serveur,l'utilisation de plusieurs clés principales peut prendre un peu plus de temps à démarrer, en particulier lors de l'utilisation d'un magasin de clés côté serveur.



Parlons maintenant un peu plus de keyring_file. Lorsque je développais keyring_file, je me demandais également comment vérifier les changements de keyring_file pendant que le serveur fonctionnait. Dans la version 5.7, la vérification était effectuée sur la base des statistiques de fichiers, ce qui n'était pas une solution idéale, et dans la version 8.0, elle était remplacée par une somme de contrôle SHA256.



La première fois que vous exécutez keyring_file, les statistiques du fichier et la somme de contrôle sont calculées et mémorisées par le serveur, et les modifications ne sont appliquées que si elles correspondent. La somme de contrôle est mise à jour lorsque le fichier est modifié.



Nous avons déjà couvert de nombreuses questions sur les keystores. Cependant, il existe un autre sujet important souvent oublié ou mal compris: le partage des clés entre les serveurs.



Ce que je veux dire? Chaque serveur (par exemple, le serveur Percona) du cluster doit avoir un emplacement distinct sur le serveur Vault où le serveur Percona doit stocker ses clés. Chaque clé principale stockée dans le référentiel contient le GUID du serveur Percona dans son identifiant. Pourquoi c'est important? Imaginez que vous n'ayez qu'un seul serveur Vault et que tous les serveurs Percona du cluster utilisent ce serveur Vault unique. Le problème semble évident. Si tous les serveurs Percona utilisaient la clé principale sans identificateurs uniques, tels que id = 1, id = 2, etc., alors tous les serveurs du cluster utiliseraient la même clé principale. C'est ce que fournit le GUID - la distinction entre les serveurs. Pourquoi alors parler de partage de clés entre serveurs alors qu'un GUID unique existe déjà? 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 produit lorsqu'un utilisateur crée une clé, par exemple, sur serveur1, puis essaie de créer une clé avec le même ID sur serveur2, par exemple:

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

Attendre. Les deux serveurs utilisent le même serveur Vault, la fonction keyring_key_store ne devrait-elle pas échouer sur server2? Fait intéressant, si vous essayez de faire la même chose sur le même serveur, vous obtenez une erreur:

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

C'est vrai, ROB_1 existe déjà.



Discutons d'abord du deuxième exemple. Comme nous l'avons dit précédemment, keyring_vault ou tout autre plugin de trousseau de clés mettra en cache tous les ID de clé en mémoire. Ainsi, après avoir créé une nouvelle clé, ROB_1 est ajouté au serveur1, et en plus d'envoyer cette clé à Vault, la clé est également ajoutée au cache. Maintenant, lorsque nous essayons d'ajouter la 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. Server1 et server2 ont des caches séparés. Après avoir ajouté ROB_1 aux caches de clés sur server1 et Vault, les caches de clés sur server2 ne sont pas synchronisés. Il n'y a pas de clé ROB_1 dans le cache sur server2. Ainsi, la clé ROB_1 est écrite dans le keyring_key_store et sur le serveur Vault, qui écrase (!) La valeur précédente. Désormais, la clé ROB_1 sur le serveur Vault est 543210987654321. Fait intéressant, le serveur Vault ne bloque pas de telles actions et écrase facilement l'ancienne valeur.



Nous pouvons maintenant voir pourquoi la division entre les serveurs d'un coffre-fort peut être importante - lorsque vous utilisez keyring_udf et que vous souhaitez stocker des clés dans un coffre-fort. Comment fournissez-vous cette séparation sur le serveur Vault?



Il existe deux façons de se diviser en Vault. Vous pouvez créer différents points de montage pour chaque serveur ou utiliser des chemins différents dans le même point de montage. Ceci est mieux illustré par des exemples. Jetons donc un coup d'œil aux points de montage individuels en premier:

--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 = sever2_mount
token = (...)
vault_ca = (...)

Ici, vous pouvez voir que serveur1 et serveur2 utilisent des points de montage différents. Lors du fractionnement 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/sever2
token = (...)
vault_ca = (...)

Dans ce cas, les deux serveurs utilisent le même point de montage, mais des chemins différents. Lorsque le premier secret est créé sur le serveur1 le long de ce chemin, le coffre-fort crée automatiquement le répertoire «serveur1». Pour server2, tout est pareil. Lorsque vous supprimez le dernier secret dans mount_point / server1 ou mount_point / server2, le serveur Vault supprime également ces répertoires. Dans le cas où vous utilisez la division de chemin, vous n'avez qu'à créer un point de montage et modifier les fichiers de configuration afin que les serveurs utilisent des chemins séparés. Un point de montage peut être créé à l'aide d'une requête HTTP. Avec CURL, cela peut être fait comme ceci:

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. Vous pouvez bien sûr utiliser les utilitaires Vault pour faire de même. Mais cela facilite l'automatisation de la création du point de montage. J'espère que vous trouverez ces informations utiles et nous vous verrons dans les prochains articles de cette série.

Lire la suite:

• Sysbench et distribution des variables aléatoires