Wir kümmern uns normalerweise um Dinge, die uns wichtig sind, sei es ein teures Smartphone oder die Server des Unternehmens. Daten sind eines der wichtigsten Vermögenswerte der Organisation, und obwohl wir sie nicht sehen, müssen sie sorgfältig geschützt werden. Wir implementieren Data-at-Rest-Verschlüsselung, um Datenbankdateien oder ganze Volumes zu verschlüsseln, die unsere Daten enthalten. Wir implementieren die Verschlüsselung von Daten während der Übertragung mit SSL, um sicherzustellen, dass niemand Daten ausspionieren und sammeln kann, die über Netzwerke gesendet werden. Backups sind nicht anders. Unabhängig davon, ob es sich um eine vollständige oder inkrementelle Sicherung handelt, wird zumindest ein Teil Ihrer Daten gespeichert. Daher müssen auch Backups verschlüsselt werden. In diesem Blogbeitrag werden wir uns mit einigen Optionen befassen, die Sie möglicherweise haben, wenn es um die Verschlüsselung von Backups geht. Sehen wir uns zunächst an, wie Sie Ihre Backups verschlüsseln können und welche Anwendungsfälle diese Methoden bieten könnten.
Wie verschlüsseln Sie Ihr Backup?
Lokale Datei verschlüsseln
Zunächst einmal können Sie vorhandene Dateien einfach verschlüsseln. Stellen wir uns vor, Sie haben einen Backup-Prozess, der alle Ihre Backups auf einem Backup-Server speichert. Irgendwann haben Sie entschieden, dass es an der Zeit ist, einen Offsite-Backup-Speicher für die Notfallwiederherstellung zu implementieren. Sie können dafür S3 oder eine ähnliche Infrastruktur von anderen Cloud-Anbietern verwenden. Natürlich möchten Sie nirgendwo außerhalb Ihres vertrauenswürdigen Netzwerks unverschlüsselte Backups hochladen, daher ist es wichtig, dass Sie die Backup-Verschlüsselung auf die eine oder andere Weise implementieren. Eine sehr einfache Methode, die keine Änderungen an Ihren vorhandenen Sicherungsskripten erfordert, wäre die Erstellung eines Skripts, das eine Sicherungsdatei erstellt, verschlüsselt und in S3 hochlädt. Eine der Methoden, die Sie zum Verschlüsseln der Daten verwenden können, ist die Verwendung von openssl:
openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpasswordDadurch wird eine neue, verschlüsselte Datei „backup_file.tar.gz.enc“ im aktuellen Verzeichnis erstellt. Sie können es später jederzeit entschlüsseln, indem Sie Folgendes ausführen:
openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpasswordDiese Methode ist sehr einfach, hat aber einige Nachteile. Der größte ist der Speicherplatzbedarf. Wenn Sie wie oben beschrieben verschlüsseln, müssen Sie sowohl die unverschlüsselte als auch die verschlüsselte Datei aufbewahren und benötigen im Ergebnis einen Festplattenspeicher, der doppelt so groß ist wie die Sicherungsdatei. Abhängig von Ihren Anforderungen kann dies natürlich etwas sein, das Sie möchten - das lokale Speichern von nicht verschlüsselten Dateien verbessert die Wiederherstellungsgeschwindigkeit - schließlich wird das Entschlüsseln der Daten auch einige Zeit in Anspruch nehmen.
Backup on the fly verschlüsseln
Um zu vermeiden, dass sowohl verschlüsselte als auch unverschlüsselte Daten gespeichert werden müssen, sollten Sie die Verschlüsselung in einer früheren Phase des Sicherungsprozesses implementieren. Wir können das durch Rohre tun. Pipes sind kurz gesagt eine Möglichkeit, die Daten von einem Befehl zum anderen zu senden. Dadurch ist es möglich, eine Kette von Befehlen zu erstellen, die Daten verarbeitet. Sie können die Daten generieren, dann komprimieren und verschlüsseln. Ein Beispiel für eine solche Kette könnte sein:
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.encSie können diese Methode auch mit xtrabackup oder mariabackup verwenden. Tatsächlich ist dies das Beispiel aus der MariaDB-Dokumentation:
mariabackup --user=root --backup --stream=xbstream | openssl enc -aes-256-cbc -k mypass > backup.xb.encWenn Sie möchten, können Sie sogar versuchen, Daten als Teil des Prozesses hochzuladen:
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 9991Als Ergebnis sehen Sie eine lokale Datei „mysqldump.gz.enc“ und eine Kopie der Daten wird an ein Programm weitergeleitet, das etwas dagegen unternimmt. Wir haben „nc“ verwendet, das Daten zu einem anderen Host gestreamt hat, auf dem Folgendes ausgeführt wurde:
nc -l 9991 > backup.gz.encIn diesem Beispiel haben wir mysqldump und nc verwendet, aber Sie können xtrabackup oder mariabackup und ein Tool verwenden, das den Stream auf Amazon S3, Google Cloud Storage oder einen anderen Cloud-Anbieter hochlädt. Jedes Programm oder Skript, das Daten auf stdin akzeptiert, kann anstelle von „nc“ verwendet werden.
Eingebettete Verschlüsselung verwenden
In einigen Fällen bietet ein Backup-Tool eingebettete Unterstützung für die Verschlüsselung. Ein Beispiel hier ist xtrabackup, das die Datei intern verschlüsseln kann. Leider unterstützt mariabackup diese Funktion nicht, obwohl es ein Fork von xtrabackup ist.
Bevor wir es verwenden können, müssen wir einen Schlüssel erstellen, der zum Verschlüsseln der Daten verwendet wird. Dies kann durch Ausführen des folgenden Befehls erfolgen:
[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1FhunjbXtrabackup kann den Schlüssel im Nur-Text-Format akzeptieren (mit der Option --encrypt-key) oder ihn aus einer Datei lesen (mit der Option --encrypt-key-file). Letzteres ist sicherer, da die Übergabe von Passwörtern und Schlüsseln als Klartext an Befehle dazu führt, dass sie im Bash-Verlauf gespeichert werden. Sie können es auch deutlich an der Liste der laufenden Prozesse sehen, was ziemlich schlecht ist:
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/Idealerweise verwenden Sie den in einer Datei gespeicherten Schlüssel, aber dann gibt es einen kleinen Haken, den Sie beachten müssen.
[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.Sie fragen sich vielleicht, was das Problem ist. Es wird klar, wann wir die Datei encrypt.key in einem Hexadezimal-Editor wie hexedit öffnen:
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.Sie können jetzt das letzte Zeichen sehen, das mit „0A“ codiert wurde. Dies ist im Grunde das Zeilenvorschubzeichen, wird jedoch bei der Auswertung des Verschlüsselungsschlüssels berücksichtigt. Sobald wir es entfernt haben, können wir endlich die Sicherung ausführen.
[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] ...doneAls Ergebnis erhalten wir ein Backup-Verzeichnis voller verschlüsselter Dateien:
[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 hat einige andere Variablen, die verwendet werden können, um die Verschlüsselungsleistung zu optimieren:
- --encrypt-threads ermöglicht die Parallelisierung des Verschlüsselungsprozesses
- --encrypt-chunk-size definiert einen Arbeitspuffer für den Verschlüsselungsprozess.
Sollten Sie die Dateien entschlüsseln müssen, können Sie dafür innobackupex mit der Option --decrypt verwenden:
[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/Da xtrabackup verschlüsselte Dateien nicht säubert, möchten Sie sie vielleicht mit dem folgenden Einzeiler entfernen:
for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; doneBackup-Verschlüsselung in ClusterControl
Mit ClusterControl sind verschlüsselte Backups nur einen Klick entfernt. Alle Backup-Methoden (mysqldump, xtrabackup oder mariabackup) unterstützen die Verschlüsselung. Sie können ein Backup ad hoc erstellen oder einen Zeitplan für Ihre Backups erstellen.
In unserem Beispiel haben wir ein vollständiges xtrabackup ausgewählt, wir werden es auf der Controller-Instanz speichern.
Auf der nächsten Seite haben wir die Verschlüsselung aktiviert. Wie bereits erwähnt, erstellt ClusterControl automatisch einen Verschlüsselungsschlüssel für uns. Das ist es, wenn Sie auf die Schaltfläche „Backup erstellen“ klicken, wird ein Prozess gestartet.
Das neue Backup ist in der Backup-Liste sichtbar. Es ist als verschlüsselt gekennzeichnet (das Schlosssymbol).
Wir hoffen, dass Ihnen dieser Blogbeitrag einige Einblicke gibt, wie Sie sicherstellen können, dass Ihre Sicherungen ordnungsgemäß verschlüsselt sind.
