Obvykle se staráme o věci, kterých si ceníme, ať už jde o drahý smartphone nebo servery společnosti. Data jsou jedním z nejdůležitějších aktiv organizace, a přestože je nevidíme, je třeba je pečlivě chránit. Implementujeme šifrování dat v klidu pro šifrování databázových souborů nebo celých svazků, které obsahují naše data. Implementujeme data v přenosovém šifrování pomocí SSL, abychom zajistili, že nikdo nebude moci snímat a sbírat data odesílaná přes sítě. Zálohy se neliší. Bez ohledu na to, zda se jedná o úplnou zálohu nebo přírůstkovou zálohu, uloží alespoň část vašich dat. Proto musí být zálohy také šifrovány. V tomto příspěvku na blogu se podíváme na některé možnosti, které můžete mít, pokud jde o šifrování záloh. Nejprve se však podívejme, jak můžete šifrovat zálohy a jaké by mohly být případy použití těchto metod.
Jak zašifrovat zálohu?
Šifrovat místní soubor
Za prvé, můžete snadno zašifrovat existující soubory. Představme si, že máte proces zálohování, který ukládá všechny vaše zálohy na záložní server. V určitém okamžiku jste se rozhodli, že je nejvyšší čas implementovat externí záložní úložiště pro obnovu po havárii. K tomu můžete využít S3 nebo podobnou infrastrukturu od jiných cloudových poskytovatelů. Samozřejmě nechcete nahrávat nešifrované zálohy kamkoli mimo vaši důvěryhodnou síť, proto je důležité, abyste šifrování záloh implementovali tak či onak. Velmi jednoduchou metodou, která nevyžaduje žádné změny ve vašich stávajících zálohovacích skriptech, by bylo vytvoření skriptu, který vezme záložní soubor, zašifruje jej a nahraje do S3. Jednou z metod, kterou můžete použít k šifrování dat, je použití openssl:
openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpasswordTím se v aktuálním adresáři vytvoří nový zašifrovaný soubor „backup_file.tar.gz.enc“. Vždy jej můžete dešifrovat později spuštěním:
openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpasswordTato metoda je velmi jednoduchá, ale má některé nevýhody. Tím největším jsou požadavky na místo na disku. Při šifrování, jak jsme popsali výše, musíte ponechat nezašifrovaný i zašifrovaný soubor a ve výsledku potřebujete místo na disku dvakrát větší než záložní soubor. Samozřejmě, v závislosti na vašich požadavcích to může být něco, co chcete – uchovávání nešifrovaných souborů lokálně zvýší rychlost obnovy – koneckonců dešifrování dat bude také nějakou dobu trvat.
Zašifrovat zálohu za chodu
Abyste se vyhnuli nutnosti ukládat šifrovaná i nešifrovaná data, možná budete chtít implementovat šifrování v dřívější fázi procesu zálohování. Můžeme to udělat pomocí potrubí. Pipe jsou zkrátka způsob, jak posílat data z jednoho příkazu do druhého. To umožňuje vytvořit řetězec příkazů, které zpracovávají data. Data můžete vygenerovat, poté je zkomprimovat a zašifrovat. Příkladem takového řetězce může být:
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.encTuto metodu můžete také použít s xtrabackup nebo mariabackup. Ve skutečnosti je to příklad z dokumentace MariaDB:
mariabackup --user=root --backup --stream=xbstream | openssl enc -aes-256-cbc -k mypass > backup.xb.encPokud chcete, můžete dokonce zkusit nahrát data jako součást procesu:
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 9991Výsledkem je, že uvidíte místní soubor „mysqldump.gz.enc“ a kopie dat bude přesměrována do programu, který s tím něco udělá. Použili jsme „nc“, který streamoval data do jiného hostitele, na kterém bylo provedeno následující:
nc -l 9991 > backup.gz.encV tomto příkladu jsme použili mysqldump a nc, ale můžete použít xtrabackup nebo mariabackup a nějaký nástroj, který nahraje stream do Amazon S3, Google Cloud Storage nebo jiného poskytovatele cloudu. Namísto „nc“ lze použít jakýkoli program nebo skript, který přijímá data na stdin.
Použít vestavěné šifrování
V některých případech má zálohovací nástroj integrovanou podporu pro šifrování. Zde je příkladem xtrabackup, který dokáže interně zašifrovat soubor. Bohužel, mariabackup, i když se jedná o fork xtrabackup, tuto funkci nepodporuje.
Než jej budeme moci použít, musíme vytvořit klíč, který bude použit k šifrování dat. To lze provést spuštěním následujícího příkazu:
[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1FhunjbXtrabackup může přijmout klíč ve formátu prostého textu (pomocí volby --encrypt-key) nebo jej může načíst ze souboru (pomocí volby --encrypt-key-file). Ten je bezpečnější, protože předávání hesel a klíčů jako prostého textu příkazům vede k jejich ukládání do historie bash. Jasně to vidíte i na seznamu běžících procesů, což je dost špatné:
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/V ideálním případě použijete klíč uložený v souboru, ale pak je tu malý problém, kterého si musíte být vědomi.
[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.Možná se ptáte, v čem je problém. Bude jasné, když otevřeme soubor encrypt.key v hexadecimálním editoru, jako je 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.Nyní si můžete všimnout posledního znaku zakódovaného pomocí „0A“. Toto je v podstatě znak pro posun řádku, ale bere se v úvahu při vyhodnocování šifrovacího klíče. Jakmile jej odstraníme, můžeme konečně spustit zálohu.
[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] ...doneV důsledku toho skončíme se záložním adresářem plným zašifrovaných souborů:
[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 má některé další proměnné, které lze použít k vyladění výkonu šifrování:
- --encrypt-threads umožňuje paralelizaci procesu šifrování
- --encrypt-chunk-size definuje pracovní vyrovnávací paměť pro proces šifrování.
Pokud potřebujete dešifrovat soubory, můžete k tomu použít innobackupex s volbou --decrypt:
[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/Protože xtrabackup nečistí zašifrované soubory, možná je budete chtít odstranit pomocí následujícího řádku:
for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; doneŠifrování záloh v ClusterControl
S ClusterControl jsou šifrované zálohy vzdáleny pouze jedním kliknutím. Všechny metody zálohování (mysqldump, xtrabackup nebo mariabackup) podporují šifrování. Můžete buď vytvořit zálohu ad hoc, nebo si můžete připravit plán zálohování.
V našem příkladu jsme vybrali plnou zálohu xtrabackup, uložíme ji do instance řadiče.
Na další stránce jsme povolili šifrování. Jak bylo uvedeno, ClusterControl nám automaticky vytvoří šifrovací klíč. To je ono, když kliknete na tlačítko „Vytvořit zálohu“, proces se spustí.
Nová záloha je viditelná v seznamu záloh. Je označen jako zašifrovaný (ikona zámku).
Doufáme, že vám tento příspěvek na blogu poskytne nějaké informace o tom, jak zajistit, aby byly vaše zálohy správně zašifrovány.