Обикновено се грижим за нещата, които ценим, независимо дали е скъп смартфон или сървърите на компанията. Данните са един от най-важните активи на организацията и въпреки че не ги виждаме, те трябва да бъдат внимателно защитени. Ние прилагаме криптиране на данни в покой, за да криптираме файлове на база данни или цели томове, които съдържат нашите данни. Ние внедряваме криптиране на данни при транзит, използвайки SSL, за да сме сигурни, че никой не може да надуши и събира данни, изпратени през мрежи. Архивите не са по-различни. Без значение дали това е пълно архивиране или инкрементално, то ще съхранява поне част от вашите данни. Като такива, архивите също трябва да бъдат криптирани. В тази публикация в блога ще разгледаме някои опции, които може да имате, когато става въпрос за криптиране на резервни копия. Първо обаче, нека разгледаме как можете да шифровате вашите архивни копия и какви могат да бъдат случаите на използване за тези методи.
Как да шифровате резервното си копие?
Шифроване на локален файл
На първо място, можете лесно да шифровате съществуващи файлове. Нека си представим, че имате процес на архивиране, който съхранява всичките ви архиви на резервен сървър. В един момент решихте, че е крайно време да внедрите резервно съхранение извън сайта за възстановяване при бедствия. За това можете да използвате S3 или подобна инфраструктура от други доставчици на облак. Разбира се, не искате да качвате некриптирани архиви навсякъде извън вашата надеждна мрежа, затова е от решаващо значение да приложите криптиране на архивиране по един или друг начин. Много прост метод, който не изисква никакви промени в съществуващите ви архивни скриптове, би бил да създадете скрипт, който ще вземе архивен файл, ще го криптира и ще го качи в S3. Един от методите, които можете да използвате за криптиране на данните, е да използвате openssl:
openssl enc -aes-256-cbc -salt -in backup_file.tar.gz -out backup_file.tar.gz.enc -k yoursecretpasswordТова ще създаде нов, криптиран файл, „backup_file.tar.gz.enc“ в текущата директория. Винаги можете да го дешифрирате по-късно, като изпълните:
openssl aes-256-cbc -d -in backup_file.tar.gz.enc -out backup_file.tar.gz -k yoursecretpasswordТози метод е много прост, но има някои недостатъци. Най-голямото е изискванията за дисково пространство. Когато криптирате, както описахме по-горе, трябва да запазите както некриптиран, така и криптиран файл и в резултат се нуждаете от дисково пространство, два пъти по-голямо от размера на архивния файл. Разбира се, в зависимост от вашите изисквания, това може да е нещо, което искате - запазването на некриптирани файлове локално ще подобри скоростта на възстановяване - в края на краищата декриптирането на данните също ще отнеме известно време.
Шифроване на архивиране в движение
За да избегнете необходимостта от съхраняване както на криптирани, така и на некриптирани данни, може да искате да приложите криптирането на по-ранния етап от процеса на архивиране. Можем да направим това чрез тръби. Накратко, тръбите са начин за изпращане на данни от една команда към друга. Това прави възможно създаването на верига от команди, която обработва данни. Можете да генерирате данните, след това да ги компресирате и шифровате. Пример за такава верига може да бъде:
mysqldump --all-databases --single-transaction --triggers --routines | gzip | openssl enc -aes-256-cbc -k mypass > backup.xb.encМожете също да използвате този метод с xtrabackup или mariabackup. Всъщност това е примерът от документацията на MariaDB:
mariabackup --user=root --backup --stream=xbstream | openssl enc -aes-256-cbc -k mypass > backup.xb.encАко искате, можете дори да опитате да качите данни като част от процеса:
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 9991В резултат на това ще видите локален файл „mysqldump.gz.enc“ и копието на данните ще бъде изпратено по канал към програма, която ще направи нещо по въпроса. Използвахме „nc“, който предаваше поточно данни към друг хост, на който беше изпълнено следното:
nc -l 9991 > backup.gz.encВ този пример използвахме mysqldump и nc, но можете да използвате xtrabackup или mariabackup и някакъв инструмент, който ще качи потока в Amazon S3, Google Cloud Storage или друг доставчик на облак. Всяка програма или скрипт, който приема данни на stdin, може да се използва вместо „nc“.
Използвайте вградено криптиране
В някои от случаите инструментът за архивиране има вградена поддръжка за криптиране. Пример тук е xtrabackup, който може вътрешно да криптира файла. За съжаление, mariabackup, въпреки че е разклонение на xtrabackup, не поддържа тази функция.
Преди да можем да го използваме, трябва да създадем ключ, който ще се използва за криптиране на данните. Това може да стане, като изпълните следната команда:
[email protected]:~# openssl rand -base64 24
HnliYiaRo7NUvc1dbtBMvt4rt1FhunjbXtrabackup може да приеме ключа в обикновен текстов формат (използвайки опцията --encrypt-key) или да го прочете от файл (използвайки опцията --encrypt-key-file). Последното е по-безопасно, тъй като предаването на пароли и ключове като обикновен текст към командите води до съхраняването им в историята на bash. Можете също да го видите ясно в списъка с работещи процеси, което е доста лошо:
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/В идеалния случай ще използвате ключа, съхранен във файл, но след това трябва да сте наясно с малка грешка.
[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.Може да се чудите какъв е проблемът. Ще стане ясно кога ще отворим файла encrypt.key в шестнадесетичен редактор като 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.Вече можете да забележите последния знак, кодиран с „0A“. Това е основно символът за подаване на ред, но се взема предвид при оценката на ключа за криптиране. След като го премахнем, най-накрая можем да стартираме архивирането.
[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] ...doneВ резултат на това ще получим резервна директория, пълна с криптирани файлове:
[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 има някои други променливи, които могат да се използват за настройка на ефективността на криптиране:
- --encrypt-threads позволява паралелизиране на процеса на криптиране
- --encrypt-chunk-size дефинира работещ буфер за процеса на криптиране.
Ако трябва да дешифрирате файловете, можете да използвате innobackupex с опция --decrypt за това:
[email protected]:~# innobackupex --decrypt=AES256 --encrypt-key-file=/root/encrypt.key /backup/2018-11-16_10-11-25/Тъй като xtrabackup не почиства криптирани файлове, може да искате да ги премахнете, като използвате следния едноред:
for i in `find /backup/2018-11-16_10-11-25/ -iname "*\.xbcrypt"`; do rm $i ; doneРезервно криптиране в ClusterControl
С ClusterControl криптираните архиви са само с едно щракване. Всички методи за архивиране (mysqldump, xtrabackup или mariabackup) поддържат криптиране. Можете както да създадете резервно копие ad hoc, така и да подготвите график за вашите архивни копия.
В нашия пример избрахме пълен xtrabackup, ще го съхраняваме в екземпляра на контролера.
На следващата страница активирахме криптирането. Както беше посочено, ClusterControl автоматично ще създаде ключ за криптиране за нас. Това е всичко, когато щракнете върху бутона „Създаване на резервно копие“, ще започне процес.
Новото архивиране се вижда в списъка с архиви. Той е маркиран като криптиран (иконата на заключване).
Надяваме се, че тази публикация в блога ви дава известна информация как да се уверите, че вашите архивни копия са правилно криптирани.
