Chiffrement dans MySQL : rotation 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, nous avons discuté de comment fonctionne le chiffrement avec la clé principale (Master Key). Aujourd'hui, en nous basant sur les connaissances acquises précédemment, nous allons examiner la rotation des clés principales.

La rotation des clés principales consiste à générer une nouvelle clé principale et à réutiliser cette nouvelle clé pour chiffrer à nouveau les clés des espaces de table (qui sont stockées dans les en-têtes des espaces de table).

Rappelons à quoi ressemble l'en-tête d'un espace de table chiffré :

D'après l'article précédent, nous savons que le serveur lit les en-têtes de tous les espaces de table chiffrés au démarrage et mémorise l'ID de clé le plus élevé. Par exemple, si nous avons trois tables avec un KEYID = 3 et une table avec un KEYID = 4, l'identifiant de clé maximum sera de 4. Appelons cet ID de clé — MAX KEY ID.

Comment fonctionne la rotation de la clé principale

1. L'utilisateur exécute ALTER INNODB MASTER KEY.

2. Le serveur demande au magasin de clés (keyring) de générer une nouvelle clé principale avec l'UUID du serveur et un KEYID, égal à MAXKEYID augmenté de un. Ainsi, nous obtenons un identifiant de clé principale, égal à INNODBKEY-UUID- (MAXKEYID + 1). Lors de la génération réussie de la clé principale, MAX KEY ID est augmenté de 1 (c'est-à-dire MAXKEYID = MAXKEYID + 1).

3. Le serveur parcourt tous les espaces de table chiffrés avec la clé principale et pour chaque espace de table :

• chiffre la clé de l'espace de table avec la nouvelle clé principale ;

• met à jour l'identifiant de clé à nouveau MAXKEYID ;

• si l'UUID est différent de l'UUID du serveur, met à jour l'UUID du serveur.

Comme nous le savons, l'identifiant de la clé principale (Master Key ID), utilisé pour déchiffrer la table, se compose de l'UUID et du KEY ID, lus depuis l'en-tête de l'espace de table. Ce que nous faisons maintenant, c'est mettre à jour ces informations dans l'en-tête de chiffrement de l'espace de table, afin que le serveur obtienne la clé principale correcte.

Lorsque nous avons des espaces de tables provenant de différents endroits, par exemple, de différentes sauvegardes, ils peuvent utiliser des clés maîtresses différentes. Toutes ces clés maîtresses devront être récupérées depuis le stockage au démarrage du serveur. Cela peut ralentir le démarrage du serveur, surtout si un stockage de clés est utilisé. Grâce à la rotation de la clé maîtresse, nous réencryptons les clés des espaces de tables avec une clé maîtresse unique, identique pour tous les espaces de tables. Désormais, lors du démarrage, le serveur doit récupérer une seule clé maîtresse.

C'est, bien sûr, juste un effet secondaire agréable. L'objectif principal de la rotation des clés maîtresses est de rendre notre serveur plus sécurisé. En cas de vol de la clé maîtresse depuis le stockage (par exemple, depuis le Vault Server), il est possible de générer une nouvelle clé maîtresse et de réencrypter les clés des espaces de tables, rendant ainsi la clé volée invalide. Nous sommes en sécurité... presque.

Dans l'article précédent, j'ai mentionné que, après le vol de la clé d'espace de table, une tierce partie peut l'utiliser pour déchiffrer les données. À condition d'avoir accès à notre disque. En cas de vol de la clé maîtresse et d'accès aux données chiffrées, la clé maîtresse volée peut être utilisée pour déchiffrer la clé d'espace de table et ainsi obtenir les données déchiffrées. Comme nous pouvons le voir, la rotation de la clé maîtresse n'aide pas dans ce cas. Nous réencryptons la clé d'espace de table avec une nouvelle clé maîtresse, mais la clé réelle utilisée pour chiffrer/déchiffrer les données reste la même. Par conséquent, le « hacker » peut continuer à l'utiliser pour déchiffrer les données. J'ai déjà insinué que Percona Server for MySQL il peut effectuer un véritable réencryption des espaces de tables, et pas seulement un simple réencryption de la clé d'espace de table. Cette fonctionnalité s'appelle les fils de chiffrement (encryption threads). Cependant, à l'heure actuelle, cette fonctionnalité est encore expérimentale.

La rotation de la clé maîtresse est utile lorsque la clé maîtresse a été volée, mais que l'attaquant n'a pas la possibilité de l'utiliser et de déchiffrer les clés des espaces de tables.

Inscrivez-vous pour un cours démo gratuit.

Lire aussi :

• Chiffrement dans MySQL : stockage des clés

• Chiffrement dans MySQL : utilisation de la clé principale

Source : habr.com