Vi tager os som regel af ting, vi værdsætter, hvad enten det er en dyr smartphone eller virksomhedens servere. Data er et af organisationens vigtigste aktiver, og selvom vi ikke kan se det, skal det beskyttes omhyggeligt. Vi implementerer data i hvile kryptering for at kryptere databasefiler eller hele mængder, som indeholder vores data. Vi implementerer data i transit-kryptering ved hjælp af SSL for at sikre, at ingen kan snuse og indsamle data sendt på tværs af netværk. Sikkerhedskopier er ikke anderledes. Lige meget om dette er en fuld sikkerhedskopi eller trinvis, vil den gemme mindst en del af dine data. Som sådan skal sikkerhedskopier også krypteres. I dette blogindlæg vil vi se nærmere på nogle muligheder, du kan have, når det kommer til at kryptere sikkerhedskopier. Lad os dog først se på, hvordan du kan kryptere dine sikkerhedskopier, og hvad der kunne bruges til disse metoder.
Hvordan krypterer du din sikkerhedskopi?
Krypter lokal fil
Først og fremmest kan du nemt kryptere eksisterende filer. Lad os forestille os, at du har en backup-proces, der gemmer alle dine backups på en backup-server. På et tidspunkt besluttede du, at det er på høje tid at implementere eksternt backuplager til katastrofegendannelse. Du kan bruge S3 eller lignende infrastruktur fra andre cloud-udbydere til det. Selvfølgelig ønsker du ikke at uploade ukrypterede sikkerhedskopier nogen steder uden for dit betroede netværk, derfor er det afgørende, at du implementerer backup-kryptering på den ene eller den anden måde. En meget simpel metode, der ikke kræver nogen ændringer i dine eksisterende backup-scripts, ville være at oprette et script, som tager en backup-fil, krypterer den og uploader den til S3. En af de metoder, du kan bruge til at kryptere dataene, er at bruge openssl:
openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpasswordDette vil oprette en ny, krypteret fil, 'backup_file.tar.gz.enc' i den aktuelle mappe. Du kan altid dekryptere det senere ved at køre:
openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpasswordDenne metode er meget enkel, men den har nogle ulemper. Den største er kravene til diskplads. Når du krypterer som vi har beskrevet ovenfor, skal du beholde både ukrypteret og krypteret fil, og i resultatet kræver du en diskplads dobbelt så stor som backupfilen. Afhængigt af dine krav kan dette selvfølgelig være noget, du ønsker - at holde ikke-krypterede filer lokalt vil forbedre gendannelseshastigheden - trods alt vil dekryptering af dataene også tage noget tid.
Kryptér sikkerhedskopiering i farten
For at undgå behovet for at gemme både krypterede og ukrypterede data, kan det være en god idé at implementere krypteringen på det tidligere stadie af backup-processen. Det kan vi gøre gennem rør. Pipes er kort sagt en måde at sende data fra en kommando til en anden. Dette gør det muligt at oprette en kæde af kommandoer, der behandler data. Du kan generere dataene, derefter komprimere dem og kryptere. Et eksempel på en sådan kæde kunne være:
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.encDu kan også bruge denne metode med xtrabackup eller mariabackup. Faktisk er dette eksemplet fra MariaDB-dokumentationen:
mariabackup --user=root --backup --stream=xbstream | openssl enc -aes-256-cbc -k mypass > backup.xb.encHvis du vil, kan du endda prøve at uploade data som en del af processen:
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 9991Som et resultat vil du se en lokal fil 'mysqldump.gz.enc', og kopi af dataene vil blive overført til et program, som vil gøre noget ved det. Vi brugte 'nc', som streamede data til en anden vært, hvor følgende blev udført:
nc -l 9991 > backup.gz.encI dette eksempel brugte vi mysqldump og nc, men du kan bruge xtrabackup eller mariabackup og et eller andet værktøj, som vil uploade streamen til Amazon S3, Google Cloud Storage eller en anden cloud-udbyder. Ethvert program eller script, der accepterer data på stdin, kan bruges i stedet for 'nc'.
Brug indlejret kryptering
I nogle af tilfældene har et backupværktøj indlejret understøttelse af kryptering. Et eksempel her er xtrabackup, som internt kan kryptere filen. Desværre understøtter mariabackup, selvom det er en gaffel af xtrabackup, ikke denne funktion.
Før vi kan bruge det, skal vi oprette en nøgle, som skal bruges til at kryptere dataene. Det kan gøres ved at køre følgende kommando:
[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1FhunjbXtrabackup kan acceptere nøglen i almindeligt tekstformat (ved hjælp af --encrypt-key option), eller den kan læse den fra fil (ved hjælp af --encrypt-key-file option). Sidstnævnte er sikrere, da det at videregive adgangskoder og nøgler som almindelig tekst til kommandoer resulterer i lagring af dem i bash-historikken. Du kan også se det tydeligt på listen over kørende processer, hvilket er ret dårligt:
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/Ideelt set vil du bruge nøglen, der er gemt i en fil, men så er der en lille gotcha, du skal være opmærksom på.
[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.Du kan undre dig over, hvad problemet er. Det bliver klart, hvornår vi åbner filen encrypt.key i en hexadecimal editor som 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.Du kan nu bemærke det sidste tegn kodet ved hjælp af '0A'. Dette er dybest set line feed-karakteren, men det tages i betragtning under evaluering af krypteringsnøglen. Når vi har fjernet det, kan vi endelig køre sikkerhedskopien.
[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] ...doneSom et resultat vil vi ende med en backup-mappe fuld af krypterede filer:
[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 har nogle andre variabler, som kan bruges til at justere krypteringsydelsen:
- --encrypt-threads giver mulighed for parallelisering af krypteringsprocessen
- --encrypt-chunk-size definerer en arbejdsbuffer for krypteringsprocessen.
Skulle du have brug for at dekryptere filerne, kan du bruge innobackupex med --decrypt mulighed for det:
[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/Da xtrabackup ikke renser krypterede filer, vil du måske fjerne dem ved at bruge følgende one-liner:
for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; doneSikkerhedskopikryptering i ClusterControl
Med ClusterControl er krypterede sikkerhedskopier kun et klik væk. Alle backupmetoder (mysqldump, xtrabackup eller mariabackup) understøtter kryptering. Du kan både oprette en ad hoc backup, eller du kan udarbejde en tidsplan for dine backups.
I vores eksempel valgte vi en fuld xtrabackup, vi gemmer den på controller-instansen.
På næste side aktiverede vi krypteringen. Som nævnt vil ClusterControl automatisk oprette en krypteringsnøgle til os. Dette er det, når du klikker på knappen "Opret sikkerhedskopi" vil en proces blive startet.
Ny backup er synlig på backuplisten. Det er markeret som krypteret (låseikonet).
Vi håber, at dette blogindlæg giver dig lidt indsigt i, hvordan du sikrer dig, at dine sikkerhedskopier er korrekt krypteret.