Transférer un tablespace MySQL chiffré au repos sur un autre serveur

12-08-2022

Temps de lecture estimé : 3 minutes

Si vous avez lu le billet évoquant le chiffrement at rest, une question a dû vous traverser l’esprit : si une table chiffrée ne permet pas sa recomposition, comment la migrer légitimement sur un autre serveur ?

Afin de garantir l’intérêt du chiffrement au repos et se prémunir d’un accès au disque, un accès logique au serveur MySQL est nécessaire à tout transfert. La commande MySQL qui permet cet export est :

FLUSH TABLE utilisateurs FOR EXPORT

Grâce à elle, nous allons pouvoir répéter le processus du billet précédent (structure -> discard -> import), à la différence que nous avons désormais des informations clés pour poursuivre.

En effet, en plus de commiter les changements en cours sur le système de fichier et de poser un verrou, cette commande a pour particularité de générer 2 fichiers supplémentaires pour une table chiffrée :

  • un fichier de méta-données utilisateurs.cfg facilitant la reconstruction sur le serveur destination (il n’est pas nécessaire en soit),
  • un fichier de transfert utilisateurs.cfp permettant la migration.

Ces fichiers ont pour durée de vie la session du verrou. Pour le faire sauter, il faut exécuter UNLOCK TABLES ou simplement quitter la session MySQL, en conséquence la façon la plus simple pour copier les fichiers est d’exécuter nos commandes shell directement dans le CLI MySQL :

mysql> \! rsync /var/lib/mysql/madatabase/utilisateurs.* destination:[path_copie]

Récupérons la structure de notre table :

mysql> show create table utilisateurs;
CREATE TABLE `utilisateurs` (
  `id` int NOT NULL AUTO_INCREMENT,
  `nom` varchar(50) NOT NULL,
  `prenom` varchar(50) NOT NULL,
  `maj_at` varchar(50) NOT NULL,
  `creation_at` datetime DEFAULT NULL,
  `creditLimit` decimal(10,2) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=13 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ENCRYPTION='Y'

Nous pouvons quitter le serveur source, le reste se fera sur le serveur de destination.

Sur ce dernier, procédons comme nous l’avions fait précédemment :

mysql> CREATE TABLE `utilisateurs` (
  `id` int NOT NULL AUTO_INCREMENT,
  `nom` varchar(50) NOT NULL,
  `prenom` varchar(50) NOT NULL,
  `maj_at` varchar(50) NOT NULL,
  `creation_at` datetime DEFAULT NULL,
  `creditLimit` decimal(10,2) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=13 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci ENCRYPTION='Y';
mysql> alter table utilisateurs discard tablespace;
$ cp [path_copie]/utilisateurs.* /var/lib/mysql/madatabase/
$ chown mysql: /var/lib/mysql/madatabase/utilisateurs.*
mysql> alter table utilisateurs import tablespace;
Query OK, 0 rows affected (0.10 sec)

Cool, ça marche !

Alors, pourquoi ça marche ? Le fichier responsable de ce succès est le fameux utilisateurs.cfp. Pour comprendre comment ce fichier .cfp fonctionne, rappelez-vous comment le chiffrement au repos opère :

  1. une clé unique est associée à chaque tablespace,
  2. une clé maîtresse chiffre les clés de tablespace.

Le fichier .cfp fonctionne comme une combinaison de ces deux clés. La première partie est une clé de transfert qui sert à chiffrer la deuxième section, la clé de tablespace. L’astuce dans le cas de l’import de tablespace consiste alors à bypasser le déchiffrement de la clé de tablespace par la master key, et le tour est joué.

Comme d’habitude, vous pouvez retrouver le code pour essayer par vous-même sur le dépôt d’exemple.

Source :

    Ce billet vous a plu ? Partagez-le sur les réseaux…


    … Ou inscrivez-vous à la newsletter pour ne manquer aucun article (Si vous ne voyez pas le formulaire, désactivez temporairement uBlock).

    Voir aussi