Article initialement publie en 2017, mis a jour en juin 2026 : versions recentes, composants keyring de MySQL 8.x, rotation des cles, gestionnaires de cles externes (Vault / KMS) et limitations actualisees.

Pour chiffrer une base de donnees, il existe au moins 3 approches :

  1. Chiffrement du disque (LUKS, dm-crypt, chiffrement du volume cloud) ;
  2. Chiffrement par le moteur de base de donnees (TDE, Transparent Data Encryption) ;
  3. Chiffrement au niveau applicatif, avant insertion dans la base.

Dans l’exemple qui suit, nous utilisons la deuxieme solution (TDE) avec l’une des bases suivantes, dans une version encore maintenue :

Moteur Versions recommandees (2026) Remarques
MariaDB 10.11 LTS, 11.4 LTS, 11.8 LTS TDE depuis 10.1.3. La 11.8 LTS est celle de Debian 13. La 10.6 LTS s’arrete en juillet 2026.
MySQL 8.0, 8.4 LTS La 5.7 est en fin de vie depuis octobre 2023. Composants keyring obligatoires (les anciens plugins sont retires en 8.4).
Percona Server 8.0, 8.4 Compatible MySQL 8.x + keyring Vault/KMS.

MySQL et Percona Server chiffrent les tablespaces InnoDB, les journaux redo/undo et les binlogs. MariaDB chiffre en plus les tables temporaires sur disque et les tables Aria. L’implementation differe donc selon le moteur. Nous decrivons d’abord MariaDB, puis donnons l’equivalent MySQL / Percona 8.x.

1. MariaDB : chiffrement avec le plugin file_key_management

1.1. Creation de la cle de chiffrement

On genere une cle (et son vecteur d’initialisation) avec OpenSSL. On utilise SHA-256 plutot que l’ancien SHA-1 :

openssl enc -aes-256-cbc -P -md sha256
enter aes-256-cbc encryption password:
Verifying - enter aes-256-cbc encryption password:
salt=C86B3CDB07C10213
key=29EE4F5E80B9597A98819C46117D70EC7A2EA7A9E096A89F297A62005ACB112B
iv =80FFE0A5D8B2BF8DAE9EC200C0F7FDE4

On stocke le resultat dans un fichier (par exemple /etc/mysql/keys.txt) au format identifiant;iv;cle. On peut declarer plusieurs cles (une par ligne, identifiants differents), ce qui sera utile pour la rotation :

cat /etc/mysql/keys.txt
1;80FFE0A5D8B2BF8DAE9EC200C0F7FDE4;29EE4F5E80B9597A98819C46117D70EC7A2EA7A9E096A89F297A62005ACB112B

On verrouille ensuite les permissions : le fichier ne doit etre lisible que par l’utilisateur mysql :

chown mysql:mysql /etc/mysql/keys.txt
chmod 400 /etc/mysql/keys.txt

Bonne pratique : ne pas laisser la cle en clair sur le serveur. On peut chiffrer keys.txt lui-meme avec OpenSSL et fournir le mot de passe via file_key_management_filekey (valeur litterale ou FILE:/chemin) :

openssl enc -aes-256-cbc -md sha256 -salt -in keys.txt -out keys.enc

1.2. Configuration dans my.cnf

On charge le plugin et on active le chiffrement. Creez par exemple /etc/mysql/mariadb.conf.d/90-encryption.cnf. Notez que les noms de variables s’ecrivent aujourd’hui avec des underscores :

[mysqld]
# --- Chargement du plugin de gestion de cles ---
plugin_load_add               = file_key_management
file_key_management_filename  = /etc/mysql/keys.txt
# Si le fichier de cles est chiffre :
# file_key_management_filename = /etc/mysql/keys.enc
# file_key_management_filekey  = FILE:/etc/mysql/keyfile.key
file_key_management_encryption_algorithm = AES_CTR

# --- Chiffrement des donnees ---
innodb_encrypt_tables         = FORCE
innodb_encrypt_log            = ON
innodb_encryption_threads     = 4
innodb_encrypt_temporary_tables = ON

# --- Tables temporaires, fichiers temporaires et binlogs ---
encrypt_tmp_disk_tables       = ON
encrypt_tmp_files             = ON
encrypt_binlog                = ON
aria_encrypt_tables           = ON

# --- Rotation automatique de la cle (en secondes) ---
innodb_encryption_rotate_key_age = 1

# Requis si innodb_encrypt_tables = ON (au lieu de FORCE)
innodb_file_per_table         = ON

Avec la valeur FORCE pour innodb_encrypt_tables, le chiffrement est impose a toutes les tables, meme si un developpeur ecrit ENCRYPTED=NO a la creation. Si l’on souhaite laisser le choix table par table, on met ON : il devient alors imperatif d’avoir innodb_file_per_table = ON.

1.3. Verification du fonctionnement

On redemarre la base pour appliquer la configuration :

systemctl restart mariadb

On verifie que le plugin est bien charge :

SHOW PLUGINS;
...
| file_key_management | ACTIVE | ENCRYPTION | file_key_management.so | GPL |
...

Puis on controle que les tables sont effectivement chiffrees :

SELECT name FROM information_schema.INNODB_TABLESPACES_ENCRYPTION WHERE ENCRYPTION_SCHEME = 1;
+-------------------+
| name              |
+-------------------+
| test/mtt_user     |
| test/mtt_country  |
| test/mtt_phone    |
| test/mtt_email    |
+-------------------+

1.4. Rotation des cles

La rotation consiste a chiffrer les pages avec une nouvelle cle. Avec file_key_management, on ajoute une nouvelle cle (nouvel identifiant) dans le fichier, puis MariaDB re-chiffre progressivement en arriere-plan selon innodb_encryption_rotate_key_age :

cat /etc/mysql/keys.txt
1;80FFE0A5D8B2BF8DAE9EC200C0F7FDE4;29EE4F5E80B9597A98819C46117D70EC7A2EA7A9E096A89F297A62005ACB112B
2;1B7F2A...;AA13C9...

On peut suivre l’avancement de la rotation :

SELECT * FROM information_schema.INNODB_TABLESPACES_ENCRYPTION;

2. MySQL / Percona Server 8.x : composants keyring

Changement majeur depuis MySQL 8.0 : les anciens plugins keyring (keyring_file…) sont remplaces par des composants keyring, et les plugins sont definitivement retires en 8.4. La configuration ne passe plus par my.cnf mais par un fichier manifeste.

On declare le composant via un manifeste global /usr/sbin/mysqld.my (ou local au datadir) :

{
  "components": "file://component_keyring_file"
}

Et la configuration du composant dans /usr/lib/mysql/plugin/component_keyring_file.cnf :

{
  "path": "/var/lib/mysql-keyring/component_keyring_file",
  "read_only": false
}

On active ensuite le chiffrement par defaut dans my.cnf :

[mysqld]
default_table_encryption = ON
table_encryption_privilege_check = ON
binlog_encryption = ON
innodb_redo_log_encrypt = ON
innodb_undo_log_encrypt = ON

La rotation de la cle maitre se fait a chaud avec une simple commande SQL :

ALTER INSTANCE ROTATE INNODB MASTER KEY;

Et l’on verifie l’etat du keyring :

SELECT * FROM performance_schema.keyring_component_status;

3. Gestion des cles externalisee (production)

Garder la cle maitre sur le serveur de base reste un point faible. Pour un usage de production ou soumis a une exigence de conformite, on confie la cle a un gestionnaire de cles externe :

  • MariaDB : plugins AWS Key Management (AWS KMS) ou solutions tierces (Eperi, HashiCorp Vault via passerelle) a la place de file_key_management.
  • MySQL / Percona : composant/plugin keyring_vault (HashiCorp Vault), component_keyring_oci, ou keyring base sur AWS KMS.

L’interet : la cle maitre n’est jamais stockee en clair sur le serveur, elle est recuperee a la demande aupres du coffre-fort, avec audit et rotation centralises.

4. Limitations (mises a jour)

  • Sauvegardes physiques : contrairement a 2017, Percona XtraBackup 8.x et mariabackup savent desormais sauvegarder les tablespaces InnoDB chiffres (via le keyring). Attention : le fichier de cles / keyring n’est PAS copie dans la sauvegarde, il faut le sauvegarder separement et de maniere securisee.
  • mysqlbinlog : il ne peut pas lire directement sur disque des binlogs chiffres. On passe par le serveur avec l’option --read-from-remote-server (les evenements sont alors dechiffres par le serveur).
  • Dumps logiques : les exports mysqldump / mariadb-dump ne sont PAS chiffres : il faut chiffrer le fichier resultant (GPG, openssl…).
  • Donnees encore potentiellement exposees :
    • les relay logs sur les replicas s’ils ne sont pas eux-memes chiffres ;
    • le slow query log, le log d’erreur, le log general et le log d’audit (qui restent en clair).

5. Desactivation du chiffrement (MariaDB)

  1. Si innodb_encrypt_tables est sur FORCE, le repasser sur ON (redemarrage de MariaDB obligatoire) ;
  2. Convertir toutes les tables avec ALTER TABLE ... ENCRYPTED=NO; ;
  3. Retirer toute la configuration de chiffrement de my.cnf et redemarrer MariaDB.

Conclusion

Le chiffrement au repos (TDE) reste simple a mettre en oeuvre et transparent pour les applications. Les deux points d’attention en 2026 : utiliser une version encore maintenue (MariaDB 10.11/11.4/11.8 LTS, MySQL 8.0/8.4) et, surtout, externaliser la cle maitre vers un coffre-fort (Vault, KMS) plutot que de la laisser sur le serveur. Le TDE protege contre le vol de disque ou de sauvegarde ; il ne remplace pas le chiffrement applicatif ni le controle d’acces pour les donnees les plus sensibles.

📚 À lire aussi