Chiffrement dans MySQL : utilisation de la clé principale

À l'approche du lancement d'un nouveau cycle pour le cours «Bases de données» Nous continuons à publier une série d'articles sur le chiffrement dans MySQL.

Dans l'article précédent de cette série (Chiffrement dans MySQL : stockage des clés) nous avons parlé des magasins de clés. Dans cet article, nous examinerons comment la clé maîtresse (master key) est utilisée, ainsi que les avantages et les inconvénients du chiffrement par enveloppes (envelope encryption). 

L'idée du chiffrement par enveloppes est que les clés utilisées pour le chiffrement (clés d'espace de table) sont chiffrées par une autre clé (la clé maîtresse, master key). Ce sont en fait les clés d'espace de table qui sont utilisées pour chiffrer les données. Graphiquement, cela peut être représenté comme suit :

La clé maîtresse (master key) est stockée dans un magasin de clés (keyring), tandis que les clés d'espace de table se trouvent dans les en-têtes des espaces de table chiffrés (sur la page 0 de l'espace de table). 

Sur l'illustration ci-dessus :

• La table A est chiffrée avec la clé 1 (Key 1). La clé 1 est chiffrée avec la clé maîtresse (master key) et est stockée de manière chiffrée dans l'en-tête de la table A.

• La table B est chiffrée avec la clé 2 (Key 2). La clé 2 est chiffrée avec la clé maîtresse (master key) et est stockée de manière chiffrée dans l'en-tête de la table B.

• Et ainsi de suite.

Lorsque le serveur doit déchiffrer la table A, il récupère la clé maîtresse du magasin, lit la clé 1 chiffrée dans l'en-tête de la table A et déchiffre la clé 1. La clé 1 déchiffrée est mise en cache en mémoire sur le serveur et utilisée pour déchiffrer la table A.

InnoDB

Dans InnoDB, le chiffrement et le déchiffrement réels sont effectués au niveau d'E/S. Cela signifie que la page est chiffrée juste avant d'être écrite sur le disque et déchiffrée immédiatement après avoir été lue depuis le disque.

Dans InnoDB, le chiffrement fonctionne uniquement au niveau des espaces de table. Par défaut, toutes les tables sont créées dans des espaces de table séparés (file-per-table tablespace). En d'autres termes, un espace de table contenant uniquement une table est créé. Bien que vous puissiez également créer des tables dans l'espace de table principal (general tablespace). Mais dans tous les cas, la table se trouve toujours dans un espace de table. Et puisque le chiffrement est effectué au niveau de l'espace de table, il est soit complètement chiffré, soit pas du tout. Cela signifie qu'il n'est pas possible de chiffrer seulement certaines tables dans l'espace de table principal. 

Si, pour une raison quelconque, vous avez désactivé file-per-table, alors toutes les tables sont créées dans l'espace de table système (system tablespace). Dans Percona Server for MySQL il est possible de chiffrer l'espace de table système à l'aide de la variable innodbsystablespaceencrypt ou en utilisant des fils de chiffrement (encryption threads), mais cela reste une fonctionnalité expérimentale. Cela n'existe pas dans MySQL.

Avant de continuer, nous devons examiner la structure de l'identifiant de la clé principale (master key ID). Il est composé d'un UUID, d'un ID de clé (KEYID) et du préfixe « INNODBKey ». Cela se présente comme suit : INNODBKey-UUID-KEYID.

UUID est l'UUID du serveur avec un espace de table chiffré. L'ID de clé (KEYID) est simplement une valeur qui augmente continuellement. Lors de la création initiale de la clé principale, l'ID de clé KEYID est égal à 1. Lors de la rotation de la clé, lorsque une nouvelle clé principale est créée, l'ID de clé KEYID = 2 et ainsi de suite. Nous parlerons plus en détail de la rotation des clés principales dans les prochains articles de cette série.

Maintenant que nous savons à quoi ressemble l'identifiant de la clé principale, examinons l'en-tête de l'espace de table chiffré. Lorsque l'espace de table est chiffré, les informations de chiffrement sont ajoutées à l'en-tête. Cela se présente comme suit :

L'ID de clé est l'ID de clé (KEYID) de l'identifiant de la clé principale dont nous avons déjà parlé. UUID est l'UUID du serveur, qui est également utilisé dans l'identifiant de la clé principale. L'ESPACE DE TABLE KEY est une clé d'espace de table, composée de 256 bits générés aléatoirement par le serveur. Le vecteur d'initialisation (IV, initialization vector) consiste également en 256 bits générés aléatoirement (bien qu'il devrait en fait être de 128 bits). L'IV est utilisé pour initialiser le chiffrement et le déchiffrement AES (sur les 256 bits, seuls 128 sont utilisés). À la fin, il y a une somme de contrôle CRC32 pour l'ESPACE DE TABLE KEY et l'IV.

Jusqu'à présent, j'ai un peu simplifié en disant que l'en-tête contient une clé d'espace de table chiffrée. En réalité, la clé d'espace de table et le vecteur d'initialisation sont stockés et chiffrés ensemble à l'aide de la clé principale. Rappelez-vous qu'avant de chiffrer la clé d'espace de table et le vecteur d'initialisation, un CRC32 est calculé pour eux.

À quoi sert CRC32 ?

En résumé, il s'agit de s'assurer de la validité de la clé principale. Après le déchiffrement de la clé de l'espace de table et du vecteur d'initialisation, une somme de contrôle est calculée et comparée au CRC32 stocké dans l'en-tête. Si les sommes de contrôle correspondent, nous avons la bonne clé principale et la clé de l'espace de table. Sinon, l'espace de table est marqué comme manquant (nous ne pourrons de toute façon pas le déchiffrer).

Vous pouvez vous demander : à quel moment les clés sont-elles vérifiées ? La réponse est : au démarrage du serveur. Un serveur avec des tables chiffrées / des espaces de tables lit le UUID, la KEY.L'ID de l'en-tête et génère un identifiant de clé principale. Il obtient ensuite la clé principale nécessaire à partir du stockage (keyring), déchiffre la clé de l'espace de table et vérifie la somme de contrôle. Encore une fois, si la somme de contrôle correspond, tout est en ordre, sinon l'espace de table est marqué comme manquant.

Si vous avez lu l'article précédent de cette série (Chiffrement dans MySQL : stockage des clés), vous vous souvenez peut-être qu'en utilisant le stockage de clés côté serveur, le serveur obtient uniquement la liste des identifiants de clés, plus précisément, l'id de la clé et l'id utilisateur, car cette paire identifie de manière unique la clé. Et maintenant, je dis que le serveur, au démarrage, obtient toutes les clés nécessaires pour vérifier la possibilité de déchiffrer les clés des espaces de tables. Pourquoi, alors, lors de l'initialisation, dans le cas d'un stockage de clés côté serveur, seul le key id et le user id sont chargés, et non toutes les clés ?id et userid, et non toutes les clés ? Parce que vous n'avez peut-être pas besoin de toutes les clés. C'est principalement lié à la rotation de la clé principale. Lors de la rotation de la clé principale, une nouvelle clé principale est créée dans le stockage, mais les anciennes clés ne sont pas supprimées. Ainsi, dans le stockage de clés côté serveur, vous pouvez avoir de nombreuses clés qui ne sont pas nécessaires au serveur et, par conséquent, ne sont pas extraites lors du démarrage du serveur.

Il est temps de parler des avantages et des inconvénients du chiffrement utilisant une clé maître. Le plus grand avantage est qu'il vous faut seulement une clé de chiffrement (la clé maître), qui sera stockée séparément de vos données chiffrées. Cela rend le démarrage du serveur rapide et le stockage réduit, ce qui facilite la gestion. De plus, il est facile de régénérer la clé maître unique.

Cependant, le chiffrement avec une clé maître présente un grand inconvénient : une fois que l'espace de table est chiffré avec keys, il reste toujours chiffré avec la même clé. La rotation de la clé maître n'est pas utile ici. Pourquoi est-ce un inconvénient ? Nous savons que MySQL a des bugs qui peuvent entraîner un plantage soudain et la création d'un fichier core. Puisque le fichier core contient un dump de la mémoire du serveur, il se peut que la clé chiffrée pour l'espace de table soit présente dans ce dump. Pire encore, les clés déchiffrées de l'espace de table sont conservées en mémoire, qui peut être échangée sur le disque. On pourrait dire que ce n'est pas un inconvénient, puisqu'il vous faut les droits root pour accéder à ces fichiers et à la partition d'échange. Oui. Mais l'accès root n'est nécessaire que pendant un certain temps. Une fois que quelqu'un a accès à la clé déchiffrée de l'espace de table, il ou elle peut continuer à l'utiliser pour déchiffrer des données même sans les droits root. De plus, le disque peut être volé, et la partition d'échange ou les fichiers core peuvent être lus avec des outils tiers. L'objectif du TDE est de rendre cela illisible, même si le disque est volé. Percona Server for MySQL Il y a une possibilité de re-chiffrement de l'espace de table avec de nouvelles clés générées. Cette fonction s'appelle les flux de chiffrement (encryption threads) et, au moment de la rédaction de cet article, elle est encore expérimentale.

En savoir plus sur le cours

Lire aussi :

• Chiffrement dans MySQL : stockage des clés

Source : habr.com