Dans ce blog, nous présentons un moyen de déplacer d'abord une base de données existante vers un état chiffré, puis comment déplacer votre base de données vers un état non chiffré.
Pour utiliser le chiffrement, vous devez charger un plugin pour gérer les clés de chiffrement. Voir les plugins de chiffrement actuellement pris en charge. Chaque clé utilise un entier 32 bits comme identifiant de clé (key_id) et clé réelle. Les clés peuvent être versionnées afin que les données soient rechiffrées de l'ancienne clé vers la version la plus récente de la clé. Dans ce blog, nous utiliserons le plugin de gestion des clés de fichiers comme exemple (voir gestion des clés de chiffrement). Nous supposons également que vous utilisez la version la plus récente de MariaDB Server (ce blog suppose que MDEV-15566 est corrigé, c'est-à-dire que la version de MariaDB doit être 10.1.33, 10.2.15 ou 10.3.6).
Le déplacement d'une base de données vers un état chiffré ou vers un état non chiffré s'effectue à l'aide d'un key_rotation. La rotation des clés fait passer la base de données d'un état chiffré existant à un autre. Notez qu'ici, l'espace de table peut n'avoir aucun état chiffré (c'est-à-dire que l'espace de table n'est pas chiffré) ou que l'espace de table peut avoir un état de chiffrement qui est déplacé vers un état non chiffré. La rotation des clés peut se produire périodiquement (basée sur la variable de configuration innodb-encryption-rotate-key-age c'est-à-dire l'ancienneté de la clé avant sa rotation), demandée par l'administrateur de la base de données (par exemple, en émettant set global innodb_encrypt_tables=ON; ) ou par système de gestion des clés de chiffrement (voir par exemple rotation des clés).
Les administrateurs de base de données doivent décider s'il suffit de chiffrer uniquement des tables individuelles (voir Chiffrement des données pour InnoDB) ou l'ensemble de la base de données, y compris l'espace de table système. Notez que les données de la table sont également écrites dans le journal de rétablissement et le journal d'annulation. Ainsi, si la base de données contient des tables contenant des données très sensibles innodb-encrypt-log doit également être activé. Dans ce blog, nous montrons comment chiffrer toute la base de données.
Déplacement de la base de données vers l'état chiffré
Avant que la base de données puisse être déplacée vers un état chiffré, nous devons ajouter la configuration du plug-in de chiffrement au fichier de configuration (voir la description détaillée des paramètres) :
# File Key Management
plugin-load-add = file_key_management
file-key-management-filename = /mnt/flash/keys.txt
file-key-management-encryption-algorithm = aes_ctr
# InnoDB encryption setup
innodb-encrypt-tables=ON
innodb-encrypt-log=ON
innodb-encryption-rotate-key-age=1024
innodb-encryption-threads=4
innodb-tablespaces-encryption
Après le redémarrage, la progression de l'opération de chiffrement peut être surveillée à partir de la table INFORMATION_SCHEMA.INNODB_TABLESPACES_ENCRYPTION. Dans l'exemple suivant, nous interrogeons le nom de l'espace de table, la page actuelle sous rotation de clé et la page maximale dans l'espace de table pour les tables qui ne sont pas encore chiffrées :
MariaDB [(none)]> select name, KEY_ROTATION_PAGE_NUMBER, KEY_ROTATION_MAX_PAGE_NUMBER from information_schema.innodb_tablespaces_encryption where min_key_version = 0 or ROTATING_OR_FLUSHING = 1;
+---------------+--------------------------+------------------------------+
| name | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER |
+---------------+--------------------------+------------------------------+
| innodb_system | 17641 | 1397504 |
+---------------+--------------------------+------------------------------+
1 row in set (0.000 sec)
Naturellement, vous pouvez également interroger l'état de toutes les tables :
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption;
+-------+-------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| SPACE | NAME | ENCRYPTION_SCHEME | KEYSERVER_REQUESTS | MIN_KEY_VERSION | CURRENT_KEY_VERSION | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER | CURRENT_KEY_ID | ROTATING_OR_FLUSHING |
+-------+-------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| 0 | innodb_system | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 3 | tpcc1000/customer | 1 | 1 | 0 | 1 | 2401 | 1317888 | 1 | 1 |
+-------+-------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
2 rows in set (0.000 sec)
À partir de là, nous pouvons voir que l'espace de table système est déjà chiffré, mais que la table client de la base de données tpcc1000 est actuellement chiffrée. Si votre système dispose de ressources matérielles et que le processus de chiffrement semble lent, vous pouvez essayer les paramètres suivants :
# Set close to number of cores
set global innodb_encryption_threads=16;
# For SSD increase number of I/O operations used for encryption in second
set global innodb_encryption_rotation_iops=40000;
Le chiffrement de la base de données est terminé lorsqu'il n'y a plus de tables dans un état non chiffré :
MariaDB [tpcc1000]> select name, KEY_ROTATION_PAGE_NUMBER, KEY_ROTATION_MAX_PAGE_NUMBER from information_schema.innodb_tablespaces_encryption where min_key_version = 0 or ROTATING_OR_FLUSHING = 1;
Empty set (0.001 sec)
Et pour vérifier, listez toutes les tables chiffrées :
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption where min_key_version != 0;
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| SPACE | NAME | ENCRYPTION_SCHEME | KEYSERVER_REQUESTS | MIN_KEY_VERSION | CURRENT_KEY_VERSION | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER | CURRENT_KEY_ID | ROTATING_OR_FLUSHING |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| 0 | innodb_system | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 3 | tpcc1000/customer | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 2 | tpcc1000/district | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 4 | tpcc1000/history | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 8 | tpcc1000/item | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 5 | tpcc1000/new_orders | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 7 | tpcc1000/order_line | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 6 | tpcc1000/orders | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 9 | tpcc1000/stock | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 1 | tpcc1000/warehouse | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
10 rows in set (0.000 sec)
Comme on peut le voir, tous les tablespaces utilisent ENCRYPTION_SCHEME=1 (chiffré) et MIN_KEY_VERSION=1 . Après cette phase, l'administrateur de la base de données doit envisager de réduire le nombre de threads de chiffrement utilisés et d'iops de rotation. En outre, la nécessité d'une rotation supplémentaire des clés doit également être prise en compte, car le plug-in de gestion des clés de fichier ne prend pas en charge la rotation réelle des clés. La rotation des clés peut être désactivée en utilisant innodb-encryption-rotate-key-age=0 . Notez que même avec cette configuration, toutes les nouvelles tables créées sont prises en compte pour le chiffrement.
Déplacement de la base de données vers un état non chiffré
Ici, nous supposons que vous disposez d'une base de données cryptée et qu'il n'est plus nécessaire de crypter les données ou que la protection des données se fait différemment. Nous utiliserons la même base de données comme exemple que dans le déplacement de la base de données vers l'état chiffré. À ce stade, il n'est pas nécessaire de redémarrer le serveur. Au lieu de cela, le déplacement de la base de données vers un état non chiffré peut être effectué en tant qu'opération en ligne. Tout d'abord, l'administrateur de la base de données doit vérifier qu'il n'y a pas de tables utilisant un cryptage explicite, c'est-à-dire qu'il existe une table où créer une table a utilisé l'option de table ENCRYPTED=YES. Désormais, le déplacement de la base de données vers un état non chiffré peut être effectué simplement en émettant :
SET GLOBAL innodb_encrypt_tables=OFF;
Cela commencera à déchiffrer tous les espaces de table, y compris l'espace de table système, et la progression de cette opération peut être surveillée par :
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption where min_key_version != 0;
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| SPACE | NAME | ENCRYPTION_SCHEME | KEYSERVER_REQUESTS | MIN_KEY_VERSION | CURRENT_KEY_VERSION | KEY_ROTATION_PAGE_NUMBER | KEY_ROTATION_MAX_PAGE_NUMBER | CURRENT_KEY_ID | ROTATING_OR_FLUSHING |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
| 7 | tpcc1000/order_line | 1 | 1 | 1 | 1 | 76564 | 1947904 | 1 | 1 |
| 6 | tpcc1000/orders | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 9 | tpcc1000/stock | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 1 | tpcc1000/warehouse | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
| 10 | tpcc1000/t1 | 1 | 1 | 1 | 1 | NULL | NULL | 1 | 0 |
+-------+---------------------+-------------------+--------------------+-----------------+---------------------+--------------------------+------------------------------+----------------+----------------------+
5 rows in set (0.001 sec)
À partir de cela, nous pouvons voir que la table order_line de la base de données tpcc1000 est en cours de rotation. L'opération est terminée lorsqu'aucune table n'utilise le cryptage, c'est-à-dire que min_key_version !=0.
MariaDB [tpcc1000]> select * from information_schema.innodb_tablespaces_encryption where min_key_version != 0 or rotating_or_flushing = 1;
Empty set (0.000 sec)
Si la configuration du chiffrement doit être supprimée de la configuration, il est maintenant temps d'arrêter le serveur. Si la configuration utilise le chiffrement de journalisation, c'est-à-dire innodb-encrypt-log=ON effectuez des sauvegardes de votre base de données, y compris les fichiers journaux InnoDB, puis supprimez les fichiers journaux InnoDB car ils sont inutilisables s'ils contiennent des données chiffrées.
rm -rf ib_logfile*
Supprimez la configuration du chiffrement de la configuration et redémarrez le serveur. Vous avez maintenant une instance de base de données où aucun cryptage n'est utilisé.
Conclusion
Le déplacement d'une base de données vers un état crypté, comme indiqué ci-dessus, nécessite le redémarrage du serveur et nécessite une configuration minutieuse du plug-in de cryptage. La durée de cette opération dépend du nombre de tables et de la taille de ces tables. Nous avons présenté un moyen de suivre cette progression et comment l'accélérer si le matériel utilisé dispose de suffisamment de ressources. Le déplacement d'une base de données vers un état non chiffré ne nécessite la définition que d'une seule variable globale. Cependant, si le chiffrement est nécessaire depuis plus longtemps et qu'il est nécessaire de supprimer toutes les références à celui-ci, un redémarrage est nécessaire. Nous avons montré comment surveiller cette transition et comment supprimer complètement la configuration du chiffrement de la base de données et de la configuration.
