Cryptage MariaDB (TDE) à l’aide du plug-in de cryptage de gestion des clés de fichiers de MariaDB

Le chiffrement transparent des données (TDE) est l’une des exigences les plus courantes des clients. MariaDB prend en charge TDE et fournit une variété d’options pour l’implémenter. Ce blog traite de la mise en œuvre de TDE au niveau de la couche de base de données à l’aide du plug-in de chiffrement de gestion des clés de fichier de MariaDB. Ce blog est le premier d’une série concernant le chiffrement des données au repos.

Dans ce blog, je réponds aux questions suivantes :

• Qu’est-ce que le TDE et comment protège-t-il les données ?
• Comment MariaDB prend-il en charge TDE ?
• Comment pouvez-vous implémenter TDE avec le plug-in de chiffrement de gestion des clés de fichiers de MariaDB ?

Le TDE n’est qu’une partie du paysage de la sécurité et il doit être mis en œuvre dans le contexte plus large de la sécurité. Pour déployer le chiffrement pour les charges de travail de production, en particulier celles soumises à des exigences réglementaires, une planification et une mise en œuvre supplémentaires sont nécessaires. Le chiffrement des données au repos et le chiffrement des données en transit sont tous deux pris en charge par MariaDB Enterprise Server. Ce blog décrit une manière dont le chiffrement des données au repos peut être déployé avec MariaDB Enterprise Server, mais ce n’est pas la seule manière possible. Il convient également de noter que le chiffrement des données au repos est automatique lorsque vous utilisez la base de données cloud de MariaDB, MariaDB SkySQL.

Transparence – Aucune clé utilisateur requise

Avant de discuter de la mise en œuvre du chiffrement de base de données transparent, j’aimerais clarifier le sens de « transparent ». Il existe une idée fausse commune au sujet du cryptage de la base de données selon laquelle toute personne n’ayant pas accès à la clé de sécurité obtiendra des données indésirables ou cryptées et ne pourra pas les lire. Ce n’est pas vrai.

Avec TDE, le cryptage est transparent pour les clients et les utilisateurs. La base de données est cryptée au niveau du système de fichiers, ce qui signifie que les fichiers de données contenant les données réelles sont cryptés. Le chiffrement et le déchiffrement des données sont effectués par MariaDB Server à l’aide d’une clé secrète. Tant que MariaDB peut accéder à la clé secrète, tout utilisateur qui a SELECT le privilège aux tables peut lire les données, et la même chose s’applique aux autres privilèges DML, INSERT, UPDATE et DELETE. Aucune de ces opérations n’est affectée par le chiffrement des données au repos ou TDE, comme je le démontrerai plus loin dans ce blog.

TDE et sécurité physique

Avec des contrôles appropriés, TDE peut protéger la base de données en cas de vol physique de serveurs ou de disques. Supposons que quelqu’un s’empare physiquement du lecteur de stockage HDD contenant le répertoire de données réel. Ils ne pourront pas démarrer le serveur même s’ils branchent le disque dur sur leur ordinateur à condition que le lecteur ne contienne pas également la clé de sécurité requise pour déchiffrer la base de données.

Une façon d’implémenter cela est un point de montage externe qui contient les clés, avec le propriétaire correct et les autorisations pour restreindre l’accès en lecture seule pour le propriétaire. Typiquement c’est mysql:mysql propriétaire et groupe, et 0400 autorisations, mais doit être adapté en conséquence s’il est personnalisé dans votre déploiement. De cette façon, en cas de vol physique du serveur réel ou du disque dur, les données seront toujours protégées car les clés seront manquantes.

Plugins de clé de chiffrement MariaDB

Dans ce blog, nous décrivons le plugin File Key Management Encryption. MariaDB Enterprise Server prend en charge plusieurs types de gestion de clés avec TDE :

• Plugin de chiffrement de gestion des clés de fichiers
  • Le fichier de clé est stocké dans le serveur MariaDB lui-même.
  • La meilleure pratique consiste à conserver le fichier de clé dans un montage séparé qui ne fait pas partie du serveur.
• Plug-in de chiffrement AWS Key Management
  • Le fichier de clé est stocké sur AWS et géré par AWS.
  • C’est très sécurisé, mais certains clients peuvent ne pas avoir accès à Internet depuis leurs serveurs de production. C’est un bon choix si la base de données s’exécute sur AWS.
• Plugin de cryptage de coffre-fort HashiCorp
  • HashiCorp Vault et MariaDB
  • HashiCorp (opensource) Vault peut être configuré dans l’environnement client et le plugin MariaDB HashiCorp Vault Encryption peut y accéder pour obtenir les clés sécurisées.
  • C’est le moyen le plus sûr de configurer des clés de cryptage si l’accès à Internet n’est pas disponible.

Processus d’activation de TDE

Voici les étapes de haut niveau requises pour implémenter le chiffrement de la base de données au repos :

• Générez une ou plusieurs clés de chiffrement.
• Chiffrez le fichier de clé en utilisant AES 256, 196 ou 128 bits.
• Protégez le fichier de clé afin que personne d’autre que l’utilisateur du propriétaire du processus MariaDB (mysql) ne puisse y accéder.
• Configurez le fichier de configuration MariaDB pour implémenter les paramètres de chiffrement.
  • Cela commencera à exécuter les threads de chiffrement en arrière-plan de l’ensemble de la base de données et des autres objets que nous configurons pour être chiffrés.
• Vérifiez la progression du chiffrement en interrogeant des tables de schéma d’informations spécifiques.
• Vérifiez que les fichiers de données physiques sont réellement chiffrés et illisibles.

N’oubliez pas que pour déployer le chiffrement pour les charges de travail de production, une planification et une mise en œuvre supplémentaires peuvent être nécessaires.

Génération de clés

Certains environnements nécessitent que les clés soient gérées à partir d’un hôte sécurisé. Dans ce blog, nous gardons les choses simples pour que vous puissiez voir comment fonctionne la fonctionnalité. Bien qu’il ne soit pas décrit ici, il est hautement recommandé que la clé soit montée sur un stockage externe de sorte que même si quelqu’un volait le serveur lui-même, le serveur ne pourrait pas démarrer à cause de la clé manquante.

Pour le bien de ce blog, nous allons créer un dossier sécurisé au sein de notre machine virtuelle MariaDB et le protégerons au mieux (non recommandé!).

Nous allons créer un nouveau dossier sous /etc/mysql/encryption pour ranger nos clés :

$ mkdir -p /etc/mysql/encryption
$ echo "1;"$(openssl rand -hex 32) > /etc/mysql/encryption/keyfile

Ce qui précède génère une clé aléatoire de 32 octets pour le /etc/mysql/encryption/keyfile fichier préfixé par « 1; ». Une clé de 32 octets est bonne pour le cryptage AES 256 bits.

Vérifions les clés :

$ cat /etc/mysql/encryption/keyfile
1;41c32aba5037876ae014f9a17c4bbf1f1de1266026ad77adfee502eb344dc59c

La clé qui sera utilisée pour le cryptage est maintenant prête. Mais avant de pouvoir l’utiliser, pour le sécuriser, nous devons chiffrer la clé elle-même !

Pour générer une autre clé, nous pouvons soit générer la clé de manière aléatoire, soit saisir un mot de passe. Ça dépend de nous.

Générons une clé aléatoire, puis chiffrons notre fichier de clé /etc/mysql/encryption/keyfile à l’aide de cette nouvelle clé :

$ openssl rand -hex 128 > /etc/mysql/encryption/keyfile.key
$ openssl enc -aes-256-cbc -md sha1 -pass file:/etc/mysql/encryption/keyfile.key -in /etc/mysql/encryption/keyfile -out /etc/mysql/encryption/keyfile.enc

La commande ci-dessus a chiffré notre fichier de clé avec la nouvelle clé de chiffrement, de sorte que tous les ID de clé et toutes les clés de chiffrement du fichier de clé sont désormais chiffrés.

Nous pouvons maintenant supprimer le fichier de clé non crypté d’origine :

$ rm -f /etc/mysql/encryption/keyfile

$ ls -lrt /etc/mysql/encryption/
total 8
-rw-r--r--. 1 root root 257 Mar 22 17:43 keyfile.key
-rw-r--r--. 1 root root  96 Mar 22 17:43 keyfile.enc

Enfin, nous devons changer la propriété du /etc/mysql dossier et tous les fichiers qu’il contient doivent appartenir à mysql:mysql utilisateur et groupe et définir l’autorisation en lecture seule et aucune autorisation pour group / global. (Adaptez-vous au bon utilisateur/groupe s’il est personnalisé dans votre installation, par exemple lors du déploiement à partir d’une archive binaire.)

$ chown -R mysql:mysql /etc/mysql
$ chmod -R 500 /etc/mysql
$ ls -lRt /etc/mysql
/etc/mysql:
total 0
dr-x------. 2 mysql mysql 44 Mar 22 17:45 encryption

/etc/mysql/encryption:
total 8
-r-x------. 1 mysql mysql  96 Mar 22 17:43 keyfile.enc
-r-x------. 1 mysql mysql 257 Mar 22 17:43 keyfile.key

Les fichiers clés sont désormais sécurisés avec la propriété et les autorisations appropriées. Nous sommes prêts pour le cryptage de la base de données au repos.

Activer le chiffrement dans MariaDB

Avant de chiffrer la base de données, faisons quelques tests rapides. Le simple SELECT l’instruction récupère les données normalement :

MariaDB [testdb]> select * from employee;
+----+--------------+
| id | c1           |
+----+--------------+
|  1 | Roger Rabbit |
|  2 | Peter Pan    |
|  3 | Bugs Bunny   |
+----+--------------+
3 rows in set (0.002 sec)

Regardons les données stockées dans le fichier brut /var/lib/mysql/testdb/employee.ibd.

$ strings /var/lib/mysql/testdb/employee.ibd | head -20
infimum
supremum
Roger Rabbit
Peter Pan
Bugs Bunny

Les données sont clairement visibles dans le texte ouvert comme prévu.

Nous pouvons maintenant implémenter la configuration de cryptage et redémarrer MariaDB Server.

Modifier le /etc/my.cnf.d/server.cnf fichier et ajoutez ce qui suit dans le [mariadb] rubrique comme suit :

plugin_load_add = file_key_management
file_key_management_filename = /etc/mysql/encryption/keyfile.enc
file_key_management_filekey = FILE:/etc/mysql/encryption/keyfile.key
file_key_management_encryption_algorithm = AES_CTR

innodb_encrypt_tables = FORCE
innodb_encrypt_log = ON
innodb_encrypt_temporary_tables = ON

encrypt_tmp_disk_tables = ON
encrypt_tmp_files = ON
encrypt_binlog = ON
aria_encrypt_tables = ON

innodb_encryption_threads = 4
innodb_encryption_rotation_iops = 2000

La première section de la configuration :

• charge le file_key_management brancher
• définit le chemin d’accès à la clé file_key_management_filename = /etc/mysql/encryption/keyfile.enc
• définit le chemin d’accès au fichier de clé crypté file_key_management_filekey = FILE:/etc/mysql/encryption/keyfile.key
• spécifie l’algorithme de cryptage à utiliser file_key_management_encryption_algorithm = AES_CTR (Noter: AES_CTR n’est disponible que si le mariadbd binaire utilise OpenSSL. Si la mariadbd binaire utilise yaSSL ou wolfSSL, alors seulement AES_CBC est disponible.)

La deuxième partie :

• permet le cryptage forcé de toutes les tables InnoDB avec innodb_encrypt_tables = FORCE
• crypte les journaux de rétablissement InnoDB à l’aide de innodb_encrypt_log = ON
• permet le chiffrement des tables temporaires InnoDB créées par l’utilisateur innodb_encrypt_temporary_tables = ON

La troisième partie :

• chiffre les tables temporaires sur disque qui sont basées sur le moteur de stockage « Aria » encrypt_tmp_disk_tables = ON
• chiffre les fichiers temporaires encrypt_tmp_files = ON,
• chiffre les journaux binaires encrypt_binlog = ON
• chiffre les tables ARIA aria_encrypt_tables = ON

La quatrième partie :

• définit le nombre de threads d’arrière-plan qui chiffreront/déchiffreront les données innodb_encryption_threads = 4
• définit la configuration IOPS pour accélérer le processus à l’aide de innodb_encryption_rotation_iops = 2000

Nous avons activé le chiffrement mais devons redémarrer le serveur pour démarrer le chiffrement des tables en arrière-plan.

Démarrer et surveiller le chiffrement

Redémarrons le serveur MariaDB en utilisant systemctl restart mariadb pour voir le chiffrement des tables. Il s’agit d’un processus d’arrière-plan qui n’a pas d’impact sur l’utilisation normale de la base de données.

Nous pouvons surveiller la progression du cryptage en arrière-plan en exécutant les opérations suivantes :