В първата част от тази поредица разгледахме конфигурацията на криптиране по време на пренос за сървърите за репликация на MariaDB, където конфигурирахме криптиране клиент-сървър и репликация. Взето от първата публикация, където бяхме конфигурирали частично нашето пълно криптиране (както е показано със зелените стрелки вляво на диаграмата) и в тази публикация в блога ще завършим настройката на криптиране с криптиране в покой, за да създадем напълно криптирана настройка за репликация на MariaDB.
Следната диаграма илюстрира текущата ни настройка и окончателната настройка, която ще постигнем:
Криптиране в покой
Криптирането в покой означава, че данните в покой, като файлове с данни и регистрационни файлове, са криптирани на диска, което прави почти невъзможно някой да получи достъп или да открадне твърд диск и да получи достъп до оригиналните данни (при условие, че ключът е защитен и не се съхранява локално). Шифроването на данни в покой, известно още като прозрачно криптиране на данни (TDE), се поддържа в MariaDB 10.1 и по-нови. Обърнете внимание, че използването на шифроване има режийни разходи от приблизително 5-10%, в зависимост от работното натоварване и типа на клъстера.
За MariaDB следните компоненти на MariaDB могат да бъдат криптирани в състояние на покой:
- Файл с данни InnoDB (споделено таблично пространство или отделно пространство за таблици, напр. *.ibd и ibdata1)
- Aria данни и индексни файлове.
- Отмяна/повторяване на регистрационни файлове (регистрационни файлове на InnoDB, напр. ib_logfile0 и ib_logfile1).
- Двоични/релейни регистрационни файлове.
- Временни файлове и таблици.
Следните файлове не могат да бъдат шифровани в момента:
- Файл с метаданни (например .frm файлове).
- Базиран на файл общ дневник/дневник на бавни заявки. Базираният на таблица общ дневник/дневник на бавни заявки може да бъде криптиран.
- Регистър на грешките.
Криптирането на данни в покой на MariaDB изисква използването на плъгини за управление на ключове и криптиране. В тази публикация в блога ще използваме плъгин за криптиране на ключове за управление на файлове, който се предоставя по подразбиране от MariaDB 10.1.3. Имайте предвид, че има редица недостатъци при използването на този плъгин, например ключът все още може да бъде прочетен от root и потребител на MySQL, както е обяснено в страницата за шифроване на данни на MariaDB в покой.
Генериране на ключов файл
Нека създадем специална директория за съхраняване на нашите неща за криптиране в състояние на покой:
$ mkdir -p /etc/mysql/rest
$ cd /etc/mysql/restСъздайте ключов файл. Това е ядрото на криптирането:
$ openssl rand -hex 32 > /etc/mysql/rest/keyfileДобавяне на низ "1;" като идентификатор на ключа в ключовия файл:
$ echo '1;'
sed -i '1s/^/1;/' /etc/mysql/rest/keyfileПо този начин, когато четете ключовия файл, той трябва да изглежда така:
$ cat /etc/mysql/rest/keyfile
1;4eb5770dcfa691bc634cbcd3c6bed9ed4ccd0111f3d3b1dae2c51a90fbf16ed7Гореното просто означава за идентификатор на ключ 1, ключът е 4eb... Файлът с ключ трябва да съдържа две части информация за всеки ключ за криптиране. Първо, всеки ключ за криптиране трябва да бъде идентифициран с 32-битово цяло число като идентификатор на ключа. Второ, самият ключ за криптиране трябва да бъде предоставен в шестнадесетична форма. Тези две части от информация трябва да бъдат разделени с точка и запетая.
Създайте парола за шифроване на горния ключ. Тук ще съхраняваме паролата във файл, наречен "keyfile.passwd":
$ echo -n 'mySuperStrongPassword' > /etc/mysql/rest/keyfile.passwdМожете да пропуснете горната стъпка, ако искате да посочите паролата директно в конфигурационния файл, като използвате опцията file_key_management_filekey. Например:file_key_management_filekey=mySuperStrongPassword
Но в този пример ще прочетем паролата, която се съхранява във файл, така че по-късно трябва да дефинираме следния ред в конфигурационния файл:
file_key_management_filekey=FILE:/etc/mysql/encryption/keyfile.passwdЩе криптираме ключовия файл с чист текст в друг файл, наречен keyfile.enc, използвайки парола във файла с парола:
$ openssl enc -aes-256-cbc -md sha1 -pass file:/etc/mysql/rest/keyfile.passwd -in /etc/mysql/rest/keyfile -out /etc/mysql/rest/keyfile.encКогато изброяваме директорията, трябва да видим тези 3 файла:
$ ls -1 /etc/mysql/rest/
keyfile
keyfile.enc
keyfile.passwdСъдържанието на keyfile.enc е просто криптирана версия на keyfile:
За да тестваме, можем да дешифрираме криптирания файл с помощта на OpenSSL, като предоставим файл с парола (keyfile.passwd):
$ openssl aes-256-cbc -d -md sha1 -pass file:/etc/mysql/rest/keyfile.passwd -in /etc/mysql/rest/keyfile.enc
1;4eb5770dcfa691bc634cbcd3c6bed9ed4ccd0111f3d3b1dae2c51a90fbf16ed7След това можем да премахнем обикновения ключ, защото ще използваме криптирания (.enc) заедно с файла с парола:
$ rm -f /etc/mysql/encryption/keyfileСега можем да продължим с конфигурирането на MariaDB криптиране в покой.
Конфигуриране на криптиране в покой
Трябва да преместим криптирания ключов файл и парола в подчинените, които да бъдат използвани от MariaDB за криптиране/декриптиране на данните. В противен случай, криптирана таблица, която се архивира от главния, използвайки физическо архивиране като MariaDB Backup, би имала проблем при четене от подчинените (поради различна комбинация ключ/парола). Логическото архивиране като mysqldump трябва да работи с различни ключове и пароли.
На подчинените създайте директория за съхраняване на неща за криптиране в състояние на покой:
(slave1)$ mkdir -p /etc/mysql/rest
(slave2)$ mkdir -p /etc/mysql/restНа главния, копирайте криптирания файл с ключове и парола в другите подчинени устройства:
(master)$ cd /etc/mysql/rest
(master)$ scp keyfile.enc keyfile.passwd [email protected]:/etc/mysql/rest/
(master)$ scp keyfile.enc keyfile.passwd [email protected]:/etc/mysql/rest/Защита на файловете от глобален достъп и присвояване на потребител на "mysql" като собственост:
$ chown mysql:mysql /etc/mysql/rest/*
$ chmod 600 /etc/mysql/rest/*Добавете следното в конфигурационния файл на MariaDB в секцията [mysqld] или [mariadb]:
# at-rest encryption
plugin_load_add = file_key_management
file_key_management_filename = /etc/mysql/rest/keyfile.enc
file_key_management_filekey = FILE:/etc/mysql/rest/keyfile.passwd
file_key_management_encryption_algorithm = AES_CBC
innodb_encrypt_tables = ON
innodb_encrypt_temporary_tables = ON
innodb_encrypt_log = ON
innodb_encryption_threads = 4
innodb_encryption_rotate_key_age = 1
encrypt-tmp-disk-tables = 1
encrypt-tmp-files = 1
encrypt-binlog = 1
aria_encrypt_tables = ONОбърнете внимание на променливата file_key_management_filekey, ако паролата е във файл, трябва да поставите префикс към пътя с "FILE:". Като алтернатива можете също да посочите низа за парола директно (не се препоръчва поради многословието му):
file_key_management_filekey=mySuperStrongPasswordРестартирайте MariaDB сървъра един възел в даден момент, започвайки с подчинените:
(slave1)$ systemctl restart mariadb
(slave2)$ systemctl restart mariadb
(master)$ systemctl restart mariadbНаблюдавайте регистъра на грешките и се уверете, че криптирането на MariaDB е активирано по време на стартиране:
$ tail -f /var/log/mysql/mysqld.log
...
2019-12-17 6:44:47 0 [Note] InnoDB: Encrypting redo log: 2*67108864 bytes; LSN=143311
2019-12-17 6:44:48 0 [Note] InnoDB: Starting to delete and rewrite log files.
2019-12-17 6:44:48 0 [Note] InnoDB: Setting log file ./ib_logfile101 size to 67108864 bytes
2019-12-17 6:44:48 0 [Note] InnoDB: Setting log file ./ib_logfile1 size to 67108864 bytes
2019-12-17 6:44:48 0 [Note] InnoDB: Renaming log file ./ib_logfile101 to ./ib_logfile0
2019-12-17 6:44:48 0 [Note] InnoDB: New log files created, LSN=143311
2019-12-17 6:44:48 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2019-12-17 6:44:48 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2019-12-17 6:44:48 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2019-12-17 6:44:48 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2019-12-17 6:44:48 0 [Note] InnoDB: Waiting for purge to start
2019-12-17 6:44:48 0 [Note] InnoDB: 10.4.11 started; log sequence number 143311; transaction id 222
2019-12-17 6:44:48 0 [Note] InnoDB: Creating #1 encryption thread id 139790011840256 total threads 4.
2019-12-17 6:44:48 0 [Note] InnoDB: Creating #2 encryption thread id 139790003447552 total threads 4.
2019-12-17 6:44:48 0 [Note] InnoDB: Creating #3 encryption thread id 139789995054848 total threads 4.
2019-12-17 6:44:48 0 [Note] InnoDB: Creating #4 encryption thread id 139789709866752 total threads 4.
2019-12-17 6:44:48 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2019-12-17 6:44:48 0 [Note] Plugin 'FEEDBACK' is disabled.
2019-12-17 6:44:48 0 [Note] Using encryption key id 1 for temporary files
...Трябва да видите редове, показващи инициализиране на криптиране в регистъра за грешки. В този момент по-голямата част от конфигурацията за криптиране вече е завършена.
Тестване на вашето криптиране
Създайте тестова база данни за тестване на главния:
(master)MariaDB> CREATE SCHEMA sbtest;
(master)MariaDB> USE sbtest;Създайте стандартна таблица без криптиране и вмъкнете ред:
MariaDB> CREATE TABLE tbl_plain (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255));
MariaDB> INSERT INTO tbl_plain SET data = 'test data';Можем да видим съхранените данни в ясен текст, когато преглеждаме файла с данни InnoDB с помощта на инструмент hexdump:
$ xxd /var/lib/mysql/sbtest/tbl_plain.ibd | less
000c060: 0200 1c69 6e66 696d 756d 0002 000b 0000 ...infimum......
000c070: 7375 7072 656d 756d 0900 0000 10ff f180 supremum........
000c080: 0000 0100 0000 0000 0080 0000 0000 0000 ................
000c090: 7465 7374 2064 6174 6100 0000 0000 0000 test data.......
000c0a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................Създайте криптирана таблица и вмъкнете ред:
MariaDB> CREATE TABLE tbl_enc (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255)) ENCRYPTED=YES;
MariaDB> INSERT INTO tbl_enc SET data = 'test data';Не можем да кажем какво се съхранява във файла с данни InnoDB за криптирани таблици:
$ xxd /var/lib/mysql/sbtest/tbl_enc.ibd | less
000c060: 0c2c 93e4 652e 9736 e68a 8b69 39cb 6157 .,..e..6...i9.aW
000c070: 3cd1 581c 7eb9 84ca d792 7338 521f 0639 <.X.~.....s8R..9
000c080: d279 9eb3 d3f5 f9b0 eccb ed05 de16 f3ac .y..............
000c090: 6d58 5519 f776 8577 03a4 fa88 c507 1b31 mXU..v.w.......1
000c0a0: a06f 086f 28d9 ac17 8923 9412 d8a5 1215 .o.o(....#......Обърнете внимание, че файлът с метаданни tbl_enc.frm не е криптиран в състояние на покой. Само файлът с данни InnoDB (.ibd) е криптиран.
Когато сравняваме "обикновените" двоични или релейни регистрационни файлове, можем ясно да видим съдържанието им с помощта на инструмента hexdump:
$ xxd binlog.000002 | less
0000560: 0800 0800 0800 0b04 726f 6f74 096c 6f63 ........root.loc
0000570: 616c 686f 7374 0047 5241 4e54 2052 454c alhost.GRANT REL
0000580: 4f41 442c 4c4f 434b 2054 4142 4c45 532c OAD,LOCK TABLES,
0000590: 5245 504c 4943 4154 494f 4e20 434c 4945 REPLICATION CLIE
00005a0: 4e54 2c45 5645 4e54 2c43 5245 4154 4520 NT,EVENT,CREATE
00005b0: 5441 424c 4553 5041 4345 2c50 524f 4345 TABLESPACE,PROCE
00005c0: 5353 2c43 5245 4154 452c 494e 5345 5254 SS,CREATE,INSERT
00005d0: 2c53 454c 4543 542c 5355 5045 522c 5348 ,SELECT,SUPER,SH
00005e0: 4f57 2056 4945 5720 4f4e 202a 2e2a 2054 OW VIEW ON *.* TДокато за криптиран двоичен дневник съдържанието изглежда безсмислено:
$ xxd binlog.000004 | less
0000280: 4a1d 1ced 2f1b db50 016a e1e9 1351 84ba J.../..P.j...Q..
0000290: 38b6 72e7 8743 7713 afc3 eecb c36c 1b19 8.r..Cw......l..
00002a0: 7b3f 6176 208f 0000 00dc 85bf 6768 e7c6 {?av .......gh..
00002b0: 6107 5bea 241c db12 d50c 3573 48e5 3c3d a.[.$.....5sH.<=
00002c0: 3179 1653 2449 d408 1113 3e25 d165 c95b 1y.S$I....>%.e.[
00002d0: afb0 6778 4b26 f672 1bc7 567e da96 13f5 ..gxK&.r..V~....
00002e0: 2ac5 b026 3fb9 4b7a 3ef4 ab47 6c9f a686 *..&?.Kz>..Gl...Шифроване на таблици Aria
За механизма за съхранение на Aria, той не поддържа опцията ENCRYPTED в израза CREATE/ALTER, тъй като следва глобалната опция aria_encrypt_tables. Следователно, когато създавате таблица Aria, просто създайте таблицата с опция ENGINE=Aria:
MariaDB> CREATE TABLE tbl_aria_enc (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255)) ENGINE=Aria;
MariaDB> INSERT INTO tbl_aria_enc(data) VALUES ('test data');
MariaDB> FLUSH TABLE tbl_aria_enc;След това можем да проверим съдържанието на файла с данни на таблицата (tbl_aria_enc.MAD) или индексния файл (tbl_aria_enc.MAI) с инструмента hexdump. За да шифровате съществуваща таблица Aria, таблицата трябва да бъде изградена отново:
MariaDB> ALTER TABLE db.aria_table ENGINE=Aria ROW_FORMAT=PAGE;Този израз кара Aria да изгради отново таблицата с помощта на опцията за таблица ROW_FORMAT. В процеса, с новата настройка по подразбиране, той криптира таблицата, когато записва на диск.
Общ регистрационен файл за шифроване/Регистър на бавените заявки
За да шифроваме общи и бавни регистрационни файлове за заявки, можем да зададем опцията MariaDB log_output на 'TABLE' вместо 'FILE' по подразбиране:
MariaDB> SET GLOBAL log_ouput = 'TABLE';Въпреки това, MariaDB по подразбиране ще създаде необходимите таблици, използвайки CSV машина за съхранение, която не е криптирана от MariaDB. Никакви двигатели, различни от CSV, MyISAM или Aria, не са законни за регистрационните таблици. Номерът е да възстановите CSV таблицата по подразбиране с машина за съхранение на Aria, при условие че опцията aria_encrypt_tables е настроена на ON. Въпреки това съответната опция за дневник трябва да бъде изключена, за да успее промяната на таблицата.
По този начин стъпките за шифроване на общата регистрационна таблица са:
MariaDB> SET GLOBAL general_log = OFF;
MariaDB> ALTER TABLE mysql.general_log ENGINE=Aria;
MariaDB> SET GLOBAL general_log = ON;По същия начин, за бавен журнал на заявки:
MariaDB> SET GLOBAL slow_query_log = OFF;
MariaDB> ALTER TABLE mysql.slow_log ENGINE=Aria;
MariaDB> SET GLOBAL slow_query_log = ON;Проверете изхода от общи регистрационни файлове в сървъра:
MariaDB> SELECT * FROM mysql.general_log;
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------+
| event_time | user_host | thread_id | server_id | command_type | argument |
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------+
| 2019-12-17 07:45:53.109558 | root[root] @ localhost [] | 19 | 28001 | Query | select * from sbtest.tbl_enc |
| 2019-12-17 07:45:55.504710 | root[root] @ localhost [] | 20 | 28001 | Query | select * from general_log |
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------+Както и криптираното съдържание на файла с данни Aria в директорията с данни с помощта на инструмента hexdump:
$ xxd /var/lib/mysql/mysql/general_log.MAD | less
0002040: 1d45 820d 7c53 216c 3fc6 98a6 356e 1b9e .E..|S!l?...5n..
0002050: 6bfc e193 7509 1fa7 31e2 e22a 8f06 3c6f k...u...1..*..<o
0002060: ae71 bb63 e81b 0b08 7120 0c99 9f82 7c33 .q.c....q ....|3
0002070: 1117 bc02 30c1 d9a7 c732 c75f 32a6 e238 ....0....2._2..8
0002080: d1c8 5d6f 9a08 455a 8363 b4f4 5176 f8a1 ..]o..EZ.c..Qv..
0002090: 1bf8 113c 9762 3504 737e 917b f260 f88c ...<.b5.s~.{.`..
00020a0: 368e 336f 9055 f645 b636 c5c1 debe fbe7 6.3o.U.E.6......
00020b0: d01e 028f 8b75 b368 0ef0 8889 bb63 e032 .....u.h.....c.2Криптирането на MariaDB в покой вече е завършено. Комбинирайте това с криптирането по време на транспортиране, което направихме в първата публикация, нашата окончателна архитектура сега изглежда така:
Заключение
Вече е възможно напълно да защитите своите бази данни MariaDB чрез криптиране за защита срещу физическо и виртуално нарушение или кражба. ClusterControl също може да ви помогне да поддържате този тип сигурност и можете да го изтеглите безплатно тук.
