Mysql
 sql >> Base de données >  >> RDS >> Mysql

Comment sauvegarder une base de données chiffrée avec Percona Server pour MySQL 8.0

Les interruptions de production sont presque garanties de se produire à un moment donné. Nous le savons donc nous planifions des sauvegardes, créons des bases de données de secours de récupération, convertissons des instances uniques en clusters.

En admettant la nécessité d'un scénario de récupération approprié, nous devons analyser la chronologie des catastrophes et les scénarios d'échec possibles et mettre en œuvre des étapes pour mettre votre base de données en place. L'exécution d'une interruption planifiée peut aider à préparer, diagnostiquer et récupérer à partir de la suivante. Pour atténuer l'impact des temps d'arrêt, les organisations ont besoin d'un plan de reprise approprié, qui inclurait tous les facteurs nécessaires pour donner vie au service.

La gestion des sauvegardes n'est pas aussi légère que la simple planification d'une tâche de sauvegarde. Il y a de nombreux facteurs à prendre en compte, tels que la rétention, le stockage, la vérification, et si les sauvegardes que vous effectuez sont physiques ou logiques et ce qui est facile à négliger en matière de sécurité.

De nombreuses organisations varient leur approche des sauvegardes, essayant d'avoir une combinaison de sauvegardes d'images de serveur (instantanés), de sauvegardes logiques et physiques stockées dans plusieurs emplacements. Il s'agit d'éviter tout sinistre local ou régional qui effacerait nos bases de données et sauvegardes stockées dans le même centre de données.

Nous voulons le sécuriser. Les données et les sauvegardes doivent être cryptées. Mais il y a de nombreuses implications lorsque les deux options sont en place. Dans cet article, nous examinerons les procédures de sauvegarde lorsque nous traitons des bases de données chiffrées.

Chiffrement au repos pour Percona Server pour MySQL 8.0

À partir de MySQL 5.7.11, la version communautaire de MySQL a commencé à prendre en charge le chiffrement de l'espace de table InnoDB. C'est ce qu'on appelle le cryptage transparent de l'espace de table ou le cryptage au repos.

La principale différence par rapport à la version entreprise est la manière dont les clés sont stockées - les clés ne se trouvent pas dans un coffre-fort sécurisé, ce qui est requis pour la conformité réglementaire. Il en va de même pour Percona Server, à partir de la version 5.7.11, il est possible de chiffrer l'espace de table InnoDB. Dans Percona Server 8.0, la prise en charge du chiffrement des journaux binaires a été considérablement étendue. Version 8.0 ajoutée 

(Doc de la version Percona 8.0) :

  • Chiffrement des fichiers temporaires
  • InnoDB Annuler le chiffrement de l'espace de table
  • Chiffrement de l'espace de table système InnoDB (chiffrement de l'espace de table système InnoDB)
  • default_table_encryption  =OFF/ON (chiffrement général de l'espace table)
  • table_encryption_privilege_check =OFF/ON (Vérification des paramètres de chiffrement)
  • Cryptage des journaux redo InnoDB (uniquement pour le chiffrement par clé principale) (Redo Log Encryption)
  • Chiffrement du fichier de fusion InnoDB (vérification du paramètre de chiffrement)
  • Cryptage de tampon à double écriture Percona Parallel (InnoDB Tablespace Encryption)

Pour ceux qui souhaitent migrer de la version MySQL Enterprise vers Percona : il est également possible d'intégrer le serveur Hashicorp Vault via un plug-in keyring_vault, correspondant aux fonctionnalités disponibles dans l'édition MySQL Enterprise d'Oracle.

Le chiffrement des données au repos nécessite un plug-in de trousseau de clés. Il y a deux options ici :

  • keyring_file - un fichier plat avec une clé de chiffrement
  • Plug-in Keyring Vault - un service

Comment activer le chiffrement de l'espace de table

Pour activer le chiffrement, démarrez votre base de données avec l'option --early-plugin-load :

soit à la main :

$ mysqld --early-plugin-load="keyring_file=keyring_file.so"

ou en modifiant le fichier de configuration :

[mysqld]

early-plugin-load=keyring_file.so

À partir de Percona Server 8.0, deux types d'espaces de table peuvent être chiffrés. Tablespace général et tablespace système. L'espace de table Sys est contrôlé via le paramètre innodb_sys_tablespace_encrypt. Par défaut, le tablespace sys n'est pas chiffré, et si vous en avez déjà un, il n'est pas possible de le convertir en état chiffré, une nouvelle instance doit être créée (démarrez une instance avec l'option --bootstrap).

Le tablespace général prend en charge le chiffrement de toutes les tables du tablespace ou aucun. Il n'est pas possible d'exécuter le chiffrement en mode mixte. Afin de créer un tablespace avec chiffrement, utilisez l'indicateur ENCRYPTION='Y/N'.

Exemple :

mysql> CREATE TABLESPACE severalnines ADD DATAFILE 'severalnines.ibd' ENCRYPTION='Y';

Sauvegarder une base de données chiffrée

Lorsque vous ajoutez des espaces de table chiffrés, il est nécessaire d'inclure le fichier de trousseau de clés dans la commande xtrabackup. Pour ce faire, vous devez spécifier le chemin d'accès à un fichier de trousseau de clés comme valeur de l'option --keyring-file-data.

$ xtrabackup --backup --target-dir=/u01/mysql/data/backup/ --user=root --keyring-file-data=/u01/secure_location/keyring_file

Assurez-vous de stocker le fichier de trousseau de clés dans un emplacement sécurisé. Assurez-vous également de toujours avoir une sauvegarde du fichier. Xtrabackup ne copiera pas le fichier de trousseau de clés dans le répertoire de sauvegarde. Pour préparer la sauvegarde, vous devez faire vous-même une copie du fichier de trousseau de clés.

Préparer la sauvegarde

Une fois que nous avons notre fichier de sauvegarde, nous devons le préparer pour la récupération. Ici, vous devez également spécifier les données du fichier de clés.

$ xtrabackup --prepare --target-dir=/u01/mysql/data/backup/ --keyring-file-data=/u01/secure_location/keyring_file

La sauvegarde est maintenant préparée et peut être restaurée avec l'option --copy-back. Dans le cas où le trousseau de clés a été tourné, vous devrez restaurer le trousseau de clés (qui a été utilisé pour prendre et préparer la sauvegarde).

Afin de préparer la sauvegarde xtrabackup, nous aurons besoin d'accéder au trousseau de clés. Xtrabackup ne communique pas directement avec le serveur MySQL et ne lit pas le fichier de configuration my.cnf par défaut lors de la préparation, spécifiez les paramètres du trousseau via la ligne de commande :

$ xtrabackup --prepare --target-dir=/data/backup --keyring-vault-config=/etc/vault.cnf

La sauvegarde est maintenant préparée et peut être restaurée avec l'option --copy-back :

$ xtrabackup --copy-back --target-dir=/u01/backup/ --datadir=/u01/mysql/data/

Exécuter des sauvegardes incrémentielles

Le processus de prise de sauvegardes incrémentielles avec le cryptage d'espace de table InnoDB est similaire à la prise des mêmes sauvegardes incrémentielles avec un tablespace non crypté.

Pour effectuer une sauvegarde incrémentielle, commencez par une sauvegarde complète. Le binaire xtrabackup écrit un fichier appelé xtrabackup_checkpoints dans le répertoire cible de la sauvegarde. Ce fichier contient une ligne indiquant le to_lsn, qui est le LSN de la base de données à la fin de la sauvegarde.

Tout d'abord, vous devez créer une sauvegarde complète avec la commande suivante :

$ xtrabackup --backup --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

Maintenant que vous disposez d'une sauvegarde complète, vous pouvez effectuer une sauvegarde incrémentielle basée sur celle-ci. Utilisez une commande telle que la suivante :

$ xtrabackup --backup --target-dir=/data/backups/inc1 \

--incremental-basedir=/data/backups/base \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Le répertoire /data/backups/inc1/ doit maintenant contenir des fichiers delta, tels que ibdata1.delta et test/table1.ibd.delta.

La signification doit être évidente. Il est maintenant possible d'utiliser ce répertoire comme base pour une autre sauvegarde incrémentielle :

$ xtrabackup --backup --target-dir=/data/backups/inc2 \

--incremental-basedir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Préparation des sauvegardes incrémentielles

Jusqu'à présent, le processus de sauvegarde de la base de données est similaire à une sauvegarde régulière, à l'exception du drapeau où nous avons spécifié l'emplacement du fichier de trousseau de clés.

Malheureusement, l'étape --prepare pour les sauvegardes incrémentielles n'est pas la même que pour les sauvegardes normales.

Dans les sauvegardes normales, deux types d'opérations sont effectuées pour rendre la base de données cohérente :les transactions validées sont relues à partir du fichier journal par rapport aux fichiers de données, et les transactions non validées sont annulées. Vous devez ignorer la restauration des transactions non validées lors de la préparation d'une sauvegarde, car les transactions qui n'étaient pas validées au moment de votre sauvegarde peuvent être en cours et il est probable qu'elles seront validées lors de la prochaine sauvegarde incrémentielle. Vous devez utiliser l'option --apply-log-only pour empêcher la phase de restauration.

Si vous n'utilisez pas l'option --apply-log-only pour empêcher la phase de restauration, vos sauvegardes incrémentielles seront inutiles. Une fois les transactions annulées, d'autres sauvegardes incrémentielles ne peuvent plus être appliquées.

En commençant par la sauvegarde complète que vous avez créée, vous pouvez la préparer, puis lui appliquer les différences incrémentielles. N'oubliez pas que vous disposez des sauvegardes suivantes :

/data/backups/base

/data/backups/inc1

/data/backups/inc2

Pour préparer la sauvegarde de base, vous devez exécuter --prepare comme d'habitude, mais empêcher la phase de restauration :

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base --keyring-file-data=/var/lib/mysql-keyring/keyring

Pour appliquer la première sauvegarde incrémentielle à la sauvegarde complète, vous devez utiliser la commande suivante :

$ xtrabackup --prepare --apply-log-only --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc1 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

si le trousseau de clés a été alterné entre la sauvegarde de base et la sauvegarde incrémentielle, vous devrez utiliser le trousseau de clés qui était utilisé lors de la première sauvegarde incrémentielle.

La préparation de la deuxième sauvegarde incrémentielle est un processus similaire

$ xtrabackup --prepare --target-dir=/data/backups/base \

--incremental-dir=/data/backups/inc2 \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Remarque ; --apply-log-only doit être utilisé lors de la fusion de tous les incréments sauf le dernier. C'est pourquoi la ligne précédente ne contient pas l'option --apply-log-only. Même si --apply-log-only était utilisé à la dernière étape, la sauvegarde serait toujours cohérente, mais dans ce cas, le serveur effectuerait la phase de restauration.
La dernière étape consiste à le restaurer avec --copy-back option. Dans le cas où le trousseau de clés a été tourné, vous devrez restaurer le trousseau de clés qui a été utilisé pour prendre et préparer la sauvegarde.

Bien que la méthode de restauration décrite fonctionne, elle nécessite un accès au même trousseau de clés que celui utilisé par le serveur. Cela peut ne pas être possible si la sauvegarde est préparée sur un serveur différent ou à une date beaucoup plus tardive, lorsque les clés du trousseau de clés sont purgées ou, en cas de dysfonctionnement, lorsque le serveur du coffre-fort du trousseau de clés n'est pas disponible du tout.

L'option --transition-key= doit être utilisée pour permettre à xtrabackup de traiter la sauvegarde sans accéder au serveur du coffre de clés. Dans ce cas, xtrabackup dérive la clé de chiffrement AES de la phrase de passe spécifiée et l'utilise pour chiffrer les clés d'espace de table des espaces de table en cours de sauvegarde.

Création d'une sauvegarde avec une phrase secrète

L'exemple suivant illustre comment la sauvegarde peut être créée dans ce cas :

$ xtrabackup --backup --user=root -p --target-dir=/data/backup \

--transition-key=MySecetKey

Restauration de la sauvegarde avec une clé générée

Lors de la restauration d'une sauvegarde, vous devrez générer une nouvelle clé principale. Voici l'exemple pour keyring_file :

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-file-data=/var/lib/mysql-keyring/keyring

Dans le cas de keyring_vault, cela ressemblera à ceci :

$ xtrabackup --copy-back --target-dir=/data/backup --datadir=/data/mysql \

--transition-key=MySecetKey --generate-new-master-key \

--keyring-vault-config=/etc/vault.cnf