Nous nous occupons généralement des choses que nous apprécions, qu'il s'agisse d'un smartphone coûteux ou des serveurs de l'entreprise. Les données sont l'un des actifs les plus importants de l'organisation, et même si nous ne le voyons pas, elles doivent être soigneusement protégées. Nous mettons en œuvre le chiffrement des données au repos pour chiffrer des fichiers de base de données ou des volumes entiers contenant nos données. Nous mettons en œuvre le cryptage des données en transit à l'aide de SSL pour nous assurer que personne ne peut renifler et collecter les données envoyées sur les réseaux. Les sauvegardes ne sont pas différentes. Qu'il s'agisse d'une sauvegarde complète ou incrémentielle, elle stockera au moins une partie de vos données. En tant que telles, les sauvegardes doivent également être cryptées. Dans cet article de blog, nous examinerons certaines options que vous pouvez avoir en matière de chiffrement des sauvegardes. Voyons d'abord comment vous pouvez chiffrer vos sauvegardes et quels pourraient être les cas d'utilisation de ces méthodes.
Comment chiffrer votre sauvegarde ?
Crypter le fichier local
Tout d'abord, vous pouvez facilement chiffrer les fichiers existants. Imaginons que vous ayez un processus de sauvegarde stockant toutes vos sauvegardes sur un serveur de sauvegarde. À un moment donné, vous avez décidé qu'il était grand temps d'implémenter un stockage de sauvegarde hors site pour la reprise après sinistre. Vous pouvez utiliser S3 ou une infrastructure similaire d'autres fournisseurs de cloud pour cela. Bien sûr, vous ne voulez pas télécharger des sauvegardes non chiffrées n'importe où en dehors de votre réseau de confiance, il est donc essentiel que vous implémentiez le chiffrement des sauvegardes d'une manière ou d'une autre. Une méthode très simple, ne nécessitant aucune modification de vos scripts de sauvegarde existants, consiste à créer un script qui prendra un fichier de sauvegarde, le chiffrera et le téléchargera sur S3. L'une des méthodes que vous pouvez utiliser pour chiffrer les données consiste à utiliser openssl :
openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpasswordCela créera un nouveau fichier crypté, "backup_file.tar.gz.enc" dans le répertoire actuel. Vous pourrez toujours le déchiffrer plus tard en exécutant :
openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpasswordCette méthode est très simple, mais elle présente quelques inconvénients. Le plus important est l'espace disque requis. Lors du cryptage comme nous l'avons décrit ci-dessus, vous devez conserver les fichiers non cryptés et cryptés et, par conséquent, vous avez besoin d'un espace disque deux fois plus grand que le fichier de sauvegarde. Bien sûr, selon vos besoins, cela peut être quelque chose que vous souhaitez - conserver localement des fichiers non chiffrés améliorera la vitesse de récupération - après tout, le déchiffrement des données prendra également un certain temps.
Crypter la sauvegarde à la volée
Pour éviter d'avoir à stocker à la fois des données cryptées et non cryptées, vous souhaiterez peut-être implémenter le cryptage à un stade antérieur du processus de sauvegarde. Nous pouvons le faire à travers des tuyaux. Les pipes sont, en bref, un moyen d'envoyer les données d'une commande à une autre. Cela permet de créer une chaîne de commandes qui traite les données. Vous pouvez générer les données, puis les compresser et les chiffrer. Un exemple d'une telle chaîne pourrait être :
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.encVous pouvez également utiliser cette méthode avec xtrabackup ou mariabackup. En fait, voici l'exemple de la documentation de MariaDB :
mariabackup --user=root --backup --stream=xbstream | openssl enc -aes-256-cbc -k mypass > backup.xb.encSi vous le souhaitez, vous pouvez même essayer de télécharger des données dans le cadre du processus :
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mysecretpassword | tee -a mysqldump.gz.enc | nc 10.0.0.102 9991En conséquence, vous verrez un fichier local "mysqldump.gz.enc" et une copie des données sera transmise à un programme qui fera quelque chose à ce sujet. Nous avons utilisé « nc », qui a transmis des données à un autre hôte sur lequel ce qui suit a été exécuté :
nc -l 9991 > backup.gz.encDans cet exemple, nous avons utilisé mysqldump et nc mais vous pouvez utiliser xtrabackup ou mariabackup et un outil qui téléchargera le flux sur Amazon S3, Google Cloud Storage ou un autre fournisseur de cloud. Tout programme ou script qui accepte des données sur stdin peut être utilisé à la place de "nc".
Utiliser le chiffrement intégré
Dans certains cas, un outil de sauvegarde intègre une prise en charge du chiffrement. Un exemple ici est xtrabackup, qui peut chiffrer le fichier en interne. Malheureusement, mariabackup, même s'il s'agit d'un fork de xtrabackup, ne prend pas en charge cette fonctionnalité.
Avant de pouvoir l'utiliser, nous devons créer une clé qui sera utilisée pour chiffrer les données. Cela peut être fait en exécutant la commande suivante :
[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1FhunjbXtrabackup peut accepter la clé au format texte brut (à l'aide de l'option --encrypt-key) ou la lire à partir du fichier (à l'aide de l'option --encrypt-key-file). Ce dernier est plus sûr car le fait de transmettre des mots de passe et des clés sous forme de texte brut aux commandes entraîne leur stockage dans l'historique bash. Vous pouvez également le voir clairement sur la liste des processus en cours d'exécution, ce qui est plutôt mauvais :
root 1130 0.0 0.6 65508 4988 ? Ss 00:46 0:00 /usr/sbin/sshd -D
root 13826 0.0 0.8 93100 6648 ? Ss 01:26 0:00 \_ sshd: [email protected]
root 25363 0.0 0.8 92796 6700 ? Ss 08:54 0:00 \_ sshd: vagrant [priv]
vagrant 25393 0.0 0.6 93072 4936 ? S 08:54 0:01 | \_ sshd: [email protected]/1
vagrant 25394 0.0 0.4 21196 3488 pts/1 Ss 08:54 0:00 | \_ -bash
root 25402 0.0 0.4 52700 3568 pts/1 S 08:54 0:00 | \_ sudo su -
root 25403 0.0 0.4 52284 3264 pts/1 S 08:54 0:00 | \_ su -
root 25404 0.0 0.4 21196 3536 pts/1 S 08:54 0:00 | \_ -su
root 26686 6.0 4.0 570008 30980 pts/1 Sl+ 09:48 0:00 | \_ innobackupex --encrypt=AES256 --encrypt-key=TzIZ7g+WzLt0PXWf8WDPf/sjIt7UzCKw /backup/Idéalement, vous utiliserez la clé stockée dans un fichier, mais il y a ensuite un petit piège dont vous devez être conscient.
[email protected]:~# openssl rand -base64 24 > encrypt.key
[email protected]:~# innobackupex --encrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/
.
.
.
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
encryption: unable to set libgcrypt cipher key - User defined source 1 : Invalid key length
encrypt: failed to create worker threads.
Error: failed to initialize datasink.Vous vous demandez peut-être quel est le problème. Cela deviendra clair quand nous ouvrirons le fichier encrypt.key dans un éditeur hexadécimal comme hexedit :
00000000 6D 6B 2B 4B 66 69 55 4E 5A 49 48 77 39 42 36 72 68 70 39 79 6A 56 44 72 47 61 79 45 6F 75 6D 70 0A mk+KfiUNZIHw9B6rhp9yjVDrGayEoump.Vous pouvez maintenant remarquer le dernier caractère encodé en utilisant '0A'. Il s'agit essentiellement du caractère de saut de ligne, mais il est pris en compte lors de l'évaluation de la clé de chiffrement. Une fois que nous l'avons supprimé, nous pouvons enfin exécuter la sauvegarde.
[email protected]:~# innobackupex --encrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/
xtrabackup: recognized server arguments: --datadir=/var/lib/mysql --innodb_buffer_pool_size=185M --innodb_flush_log_at_trx_commit=2 --innodb_file_per_table=1 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_read_io_threads=4 --innodb_write_io_threads=4 --innodb_doublewrite=1 --innodb_log_file_size=64M --innodb_log_buffer_size=16M --innodb_log_files_in_group=2 --innodb_flush_method=O_DIRECT --server-id=1
xtrabackup: recognized client arguments: --datadir=/var/lib/mysql --innodb_buffer_pool_size=185M --innodb_flush_log_at_trx_commit=2 --innodb_file_per_table=1 --innodb_data_file_path=ibdata1:100M:autoextend --innodb_read_io_threads=4 --innodb_write_io_threads=4 --innodb_doublewrite=1 --innodb_log_file_size=64M --innodb_log_buffer_size=16M --innodb_log_files_in_group=2 --innodb_flush_method=O_DIRECT --server-id=1 --databases-exclude=lost+found --ssl-mode=DISABLED
encryption: using gcrypt 1.6.5
181116 10:11:25 innobackupex: Starting the backup operation
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackupex
prints "completed OK!".
181116 10:11:25 version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;mysql_socket=/var/lib/mysql/mysql.sock' as 'backupuser' (using password: YES).
181116 10:11:25 version_check Connected to MySQL server
181116 10:11:25 version_check Executing a version check against the server...
181116 10:11:25 version_check Done.
181116 10:11:25 Connecting to MySQL server host: localhost, user: backupuser, password: set, port: not set, socket: /var/lib/mysql/mysql.sock
Using server version 5.7.23-23-57
innobackupex version 2.4.12 based on MySQL server 5.7.19 Linux (x86_64) (revision id: 170eb8c)
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /var/lib/mysql
xtrabackup: open files limit requested 0, set to 1024
xtrabackup: using the following InnoDB configuration:
xtrabackup: innodb_data_home_dir = .
xtrabackup: innodb_data_file_path = ibdata1:100M:autoextend
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 2
xtrabackup: innodb_log_file_size = 67108864
xtrabackup: using O_DIRECT
InnoDB: Number of pools: 1
181116 10:11:25 >> log scanned up to (2597648)
xtrabackup: Generating a list of tablespaces
InnoDB: Allocated tablespace ID 19 for mysql/server_cost, old maximum was 0
181116 10:11:25 [01] Encrypting ./ibdata1 to /backup/2018-11-16_10-11-25/ibdata1.xbcrypt
181116 10:11:26 >> log scanned up to (2597648)
181116 10:11:27 >> log scanned up to (2597648)
181116 10:11:28 [01] ...done
181116 10:11:28 [01] Encrypting ./mysql/server_cost.ibd to /backup/2018-11-16_10-11-25/mysql/server_cost.ibd.xbcrypt
181116 10:11:28 [01] ...done
181116 10:11:28 [01] Encrypting ./mysql/help_category.ibd to /backup/2018-11-16_10-11-25/mysql/help_category.ibd.xbcrypt
181116 10:11:28 [01] ...done
181116 10:11:28 [01] Encrypting ./mysql/slave_master_info.ibd to /backup/2018-11-16_10-11-25/mysql/slave_master_info.ibd.xbcrypt
181116 10:11:28 [01] ...doneEn conséquence, nous nous retrouverons avec un répertoire de sauvegarde rempli de fichiers cryptés :
[email protected]:~# ls -alh /backup/2018-11-16_10-11-25/
total 101M
drwxr-x--- 5 root root 4.0K Nov 16 10:11 .
drwxr-xr-x 16 root root 4.0K Nov 16 10:11 ..
-rw-r----- 1 root root 580 Nov 16 10:11 backup-my.cnf.xbcrypt
-rw-r----- 1 root root 515 Nov 16 10:11 ib_buffer_pool.xbcrypt
-rw-r----- 1 root root 101M Nov 16 10:11 ibdata1.xbcrypt
drwxr-x--- 2 root root 4.0K Nov 16 10:11 mysql
drwxr-x--- 2 root root 12K Nov 16 10:11 performance_schema
drwxr-x--- 2 root root 12K Nov 16 10:11 sys
-rw-r----- 1 root root 113 Nov 16 10:11 xtrabackup_checkpoints
-rw-r----- 1 root root 525 Nov 16 10:11 xtrabackup_info.xbcrypt
-rw-r----- 1 root root 2.7K Nov 16 10:11 xtrabackup_logfile.xbcryptXtrabackup possède d'autres variables qui peuvent être utilisées pour régler les performances de chiffrement :
- --encrypt-threads permet la parallélisation du processus de chiffrement
- --encrypt-chunk-size définit un tampon de travail pour le processus de chiffrement.
Si vous avez besoin de décrypter les fichiers, vous pouvez utiliser innobackupex avec l'option --decrypt pour cela :
[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/Comme xtrabackup ne nettoie pas les fichiers chiffrés, vous pouvez les supprimer en utilisant la ligne suivante :
for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; doneCryptage de sauvegarde dans ClusterControl
Avec ClusterControl, les sauvegardes cryptées ne sont qu'à un clic. Toutes les méthodes de sauvegarde (mysqldump, xtrabackup ou mariabackup) prennent en charge le chiffrement. Vous pouvez à la fois créer une sauvegarde ad hoc ou vous pouvez préparer un calendrier pour vos sauvegardes.
Dans notre exemple, nous avons choisi une xtrabackup complète, nous la stockerons sur l'instance du contrôleur.
Sur la page suivante, nous avons activé le cryptage. Comme indiqué, ClusterControl créera automatiquement une clé de cryptage pour nous. Ça y est, lorsque vous cliquez sur le bouton "Créer une sauvegarde", un processus sera lancé.
La nouvelle sauvegarde est visible dans la liste des sauvegardes. Il est marqué comme crypté (l'icône du cadenas).
Nous espérons que cet article de blog vous donnera un aperçu de la façon de vous assurer que vos sauvegardes sont correctement chiffrées.
