Vi brukar ta hand om saker vi värdesätter, oavsett om det är en dyr smartphone eller företagets servrar. Data är en av organisationens viktigaste tillgångar, och även om vi inte ser dem måste de skyddas noggrant. Vi implementerar data at rest-kryptering för att kryptera databasfiler eller hela volymer som innehåller våra data. Vi implementerar kryptering av data under överföring med SSL för att se till att ingen kan sniffa och samla in data som skickas över nätverk. Säkerhetskopiering är inte annorlunda. Oavsett om detta är en fullständig säkerhetskopia eller inkrementell, kommer den att lagra åtminstone en del av dina data. Som sådan måste säkerhetskopior också krypteras. I det här blogginlägget kommer vi att undersöka några alternativ du kan ha när det gäller att kryptera säkerhetskopior. Men låt oss först titta på hur du kan kryptera dina säkerhetskopior och vad som kan användas för dessa metoder.
Hur krypterar du din säkerhetskopia?
Kryptera lokal fil
Först och främst kan du enkelt kryptera befintliga filer. Låt oss föreställa oss att du har en säkerhetskopieringsprocess som lagrar alla dina säkerhetskopior på en backupserver. Vid någon tidpunkt bestämde du dig för att det är hög tid att implementera extern backuplagring för katastrofåterställning. Du kan använda S3 eller liknande infrastruktur från andra molnleverantörer för det. Naturligtvis vill du inte ladda upp okrypterade säkerhetskopior någonstans utanför ditt betrodda nätverk, därför är det viktigt att du implementerar säkerhetskopieringskryptering på ett eller annat sätt. En mycket enkel metod som inte kräver några ändringar i dina befintliga säkerhetskopieringsskript är att skapa ett skript som tar en säkerhetskopia, krypterar den och laddar upp den till S3. En av metoderna du kan använda för att kryptera data är att använda openssl:
openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpasswordDetta kommer att skapa en ny, krypterad fil, 'backup_file.tar.gz.enc' i den aktuella katalogen. Du kan alltid dekryptera det senare genom att köra:
openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpasswordDenna metod är mycket enkel, men den har några nackdelar. Den största är kraven på diskutrymme. Vid kryptering som vi beskrev ovan måste du behålla både okrypterad och krypterad fil och i resultatet kräver du ett diskutrymme som är dubbelt så stort som backupfilen. Naturligtvis, beroende på dina krav, kan detta vara något du vill ha - att behålla okrypterade filer lokalt kommer att förbättra återställningshastigheten - trots allt kommer det att ta lite tid att dekryptera data.
Kryptera säkerhetskopiering i farten
För att undvika behovet av att lagra både krypterad och okrypterad data, kanske du vill implementera krypteringen i ett tidigare skede av säkerhetskopieringsprocessen. Vi kan göra det genom rör. Pipes är kort sagt ett sätt att skicka data från ett kommando till ett annat. Detta gör det möjligt att skapa en kedja av kommandon som bearbetar data. Du kan generera data, sedan komprimera den och kryptera. Ett exempel på en sådan kedja kan vara:
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.encDu kan också använda den här metoden med xtrabackup eller mariabackup. Faktum är att detta är exemplet från MariaDB-dokumentationen:
mariabackup --user=root --backup --stream=xbstream | openssl enc -aes-256-cbc -k mypass > backup.xb.encOm du vill kan du till och med försöka ladda upp data som en del av 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 ett resultat kommer du att se en lokal fil 'mysqldump.gz.enc' och en kopia av data kommer att skickas till ett program som kommer att göra något åt det. Vi använde 'nc', som strömmade data till en annan värd där följande exekverades:
nc -l 9991 > backup.gz.encI det här exemplet använde vi mysqldump och nc men du kan använda xtrabackup eller mariabackup och något verktyg som laddar upp strömmen till Amazon S3, Google Cloud Storage eller någon annan molnleverantör. Alla program eller skript som accepterar data på stdin kan användas istället för 'nc'.
Använd inbäddad kryptering
I några av fallen har ett säkerhetskopieringsverktyg inbäddat stöd för kryptering. Ett exempel här är xtrabackup, som internt kan kryptera filen. Tyvärr stöder inte mariabackup den här funktionen, även om det är en gaffel av xtrabackup.
Innan vi kan använda den måste vi skapa en nyckel som kommer att användas för att kryptera data. Det kan göras genom att köra följande kommando:
[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1FhunjbXtrabackup kan acceptera nyckeln i vanligt textformat (med alternativet --encrypt-key) eller så kan det läsa den från filen (med alternativet --encrypt-key-file). Det senare är säkrare eftersom att skicka lösenord och nycklar som vanlig text till kommandon resulterar i att de lagras i bash-historiken. Du kan också se det tydligt på listan över pågående processer, vilket är ganska dåligt:
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/Helst kommer du att använda nyckeln som är lagrad i en fil, men sedan finns det en liten gotcha du måste vara medveten om.
[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 kanske undrar vad problemet är. Det kommer att bli klart när vi kommer att öppna encrypt.key-filen 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 lägga märke till det sista tecknet som kodats med "0A". Detta är i princip linjematningstecknet, men det beaktas vid utvärdering av krypteringsnyckeln. När vi har tagit bort det kan vi äntligen köra säkerhetskopieringen.
[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 ett resultat kommer vi att sluta med en säkerhetskopieringskatalog full av krypterade 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 några andra variabler som kan användas för att justera krypteringsprestanda:
- --encrypt-threads möjliggör parallellisering av krypteringsprocessen
- --encrypt-chunk-size definierar en fungerande buffert för krypteringsprocessen.
Om du skulle behöva dekryptera filerna kan du använda innobackupex med --decrypt-alternativet för det:
[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/Eftersom xtrabackup inte rensar krypterade filer, kanske du vill ta bort dem med följande one-liner:
for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; doneSäkerhetskopiera kryptering i ClusterControl
Med ClusterControl är krypterade säkerhetskopior bara ett klick bort. Alla säkerhetskopieringsmetoder (mysqldump, xtrabackup eller mariabackup) stöder kryptering. Du kan både skapa en säkerhetskopia ad hoc eller så kan du förbereda ett schema för dina säkerhetskopior.
I vårt exempel valde vi en fullständig xtrabackup, vi kommer att lagra den på kontrollerinstansen.
På nästa sida aktiverade vi krypteringen. Som sagt kommer ClusterControl automatiskt att skapa en krypteringsnyckel åt oss. Detta är det, när du klickar på knappen "Skapa säkerhetskopia" kommer en process att startas.
Ny säkerhetskopia är synlig på säkerhetskopieringslistan. Den är markerad som krypterad (låsikonen).
Vi hoppas att det här blogginlägget ger dig lite insikter i hur du ser till att dina säkerhetskopior är korrekt krypterade.