V první části této série jsme se zabývali konfigurací šifrování během přenosu pro replikační servery MariaDB, kde jsme konfigurovali šifrování klient-server a šifrování replikace. Převzato z prvního příspěvku, kde jsme částečně nakonfigurovali naše úplné šifrování (jak je naznačeno zelenými šipkami vlevo v diagramu), a v tomto příspěvku na blogu dokončíme nastavení šifrování s klidovým šifrováním, abychom vytvořili plně šifrované nastavení replikace MariaDB.
Následující diagram ilustruje naše aktuální nastavení a konečné nastavení, kterého dosáhneme:
Šifrování v klidu
Šifrování v klidu znamená, že data v klidu, jako jsou datové soubory a protokoly, jsou na disku zašifrovány, takže je téměř nemožné, aby někdo získal nebo ukradl pevný disk a získal přístup k původním datům (za předpokladu, že je klíč zabezpečen a není uložen lokálně). Data-at-Rest Encryption, také známý jako Transparent Data Encryption (TDE), je podporován v MariaDB 10.1 a novějších. Pamatujte, že použití šifrování má režii zhruba 5–10 % v závislosti na pracovní zátěži a typu clusteru.
Pro MariaDB lze v klidu zašifrovat následující součásti MariaDB:
- Datový soubor InnoDB (sdílený tabulkový prostor nebo samostatný tabulkový prostor, např. *.ibd a ibdata1)
- Data a indexové soubory Aria.
- Vrácení/opakování protokolů (soubory protokolu InnoDB, např. ib_logfile0 a ib_logfile1).
- Binární/reléové protokoly.
- Dočasné soubory a tabulky.
Následující soubory nelze v tuto chvíli zašifrovat:
- Soubor metadat (například soubory .frm).
- Obecný protokol založený na souborech / protokol pomalých dotazů. Tabulkový obecný protokol/protokol pomalých dotazů lze šifrovat.
- Protokol chyb.
Šifrování dat v klidu MariaDB vyžaduje použití zásuvných modulů pro správu klíčů a šifrování. V tomto příspěvku na blogu budeme používat modul File Key Management Encryption Plugin, který je standardně poskytován od MariaDB 10.1.3. Všimněte si, že používání tohoto pluginu má řadu nevýhod, např. klíč může stále číst uživatel root a MySQL, jak je vysvětleno na stránce MariaDB Data-at-Rest Encryption.
Generování souboru klíče
Pojďme vytvořit vyhrazený adresář pro uložení našich věcí v klidovém šifrování:
$ mkdir -p /etc/mysql/rest
$ cd /etc/mysql/rest
Vytvořte soubor klíče. Toto je jádro šifrování:
$ openssl rand -hex 32 > /etc/mysql/rest/keyfile
Připojit řetězec "1;" jako identifikátor klíče do souboru klíčů:
$ echo '1;'
sed -i '1s/^/1;/' /etc/mysql/rest/keyfile
Při čtení souboru klíče by tedy měl vypadat nějak takto:
$ cat /etc/mysql/rest/keyfile
1;4eb5770dcfa691bc634cbcd3c6bed9ed4ccd0111f3d3b1dae2c51a90fbf16ed7
Výše uvedené jednoduše znamená, že pro identifikátor klíče 1 je klíč 4eb... Soubor klíče musí obsahovat dvě informace pro každý šifrovací klíč. Za prvé, každý šifrovací klíč musí být identifikován pomocí 32bitového celého čísla jako identifikátoru klíče. Za druhé, samotný šifrovací klíč musí být poskytnut v hex-kódované formě. Tyto dvě informace je třeba oddělit středníkem.
Vytvořte heslo pro zašifrování výše uvedeného klíče. Zde uložíme heslo do souboru s názvem "keyfile.passwd":
$ echo -n 'mySuperStrongPassword' > /etc/mysql/rest/keyfile.passwd
Výše uvedený krok můžete přeskočit, pokud chcete zadat heslo přímo v konfiguračním souboru pomocí volby file_key_management_filekey. Například:file_key_management_filekey=mySuperStrongPassword
V tomto příkladu ale budeme číst heslo, které je uloženo v souboru, takže musíme později v konfiguračním souboru definovat následující řádek:
file_key_management_filekey=FILE:/etc/mysql/encryption/keyfile.passwd
Chystáme se zašifrovat soubor klíčů ve formátu prostého textu do jiného souboru s názvem keyfile.enc pomocí hesla v souboru s hesly:
$ 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
Při výpisu adresáře bychom měli vidět tyto 3 soubory:
$ ls -1 /etc/mysql/rest/
keyfile
keyfile.enc
keyfile.passwd
Obsah souboru keyfile.enc je jednoduše zašifrovaná verze souboru klíče:
Zašifrovaný soubor můžeme dešifrovat pomocí OpenSSL poskytnutím soubor hesla (keyfile.passwd):
$ openssl aes-256-cbc -d -md sha1 -pass file:/etc/mysql/rest/keyfile.passwd -in /etc/mysql/rest/keyfile.enc
1;4eb5770dcfa691bc634cbcd3c6bed9ed4ccd0111f3d3b1dae2c51a90fbf16ed7
Potom můžeme odstranit prostý klíč, protože budeme používat šifrovaný (.enc) společně se souborem s hesly:
$ rm -f /etc/mysql/encryption/keyfile
Nyní můžeme přistoupit ke konfiguraci klidového šifrování MariaDB.
Konfigurace šifrování v klidu
Musíme přesunout soubor zašifrovaného klíče a heslo do slave, aby je MariaDB použila k šifrování/dešifrování dat. V opačném případě by šifrovaná tabulka zálohovaná z hlavního serveru pomocí fyzické zálohy, jako je MariaDB Backup, měla problém číst podřízené (kvůli jiné kombinaci klíče a hesla). Logické zálohování jako mysqldump by mělo fungovat s různými klíči a hesly.
Na podřízených zařízeních vytvořte adresář, do kterého budete ukládat šifrování v klidu:
(slave1)$ mkdir -p /etc/mysql/rest
(slave2)$ mkdir -p /etc/mysql/rest
Na hlavním zařízení zkopírujte zašifrovaný soubor s klíčem a soubor s hesly do ostatních podřízených zařízení:
(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/
Chraňte soubory před globálním přístupem a jako vlastníka přiřaďte uživatele "mysql":
$ chown mysql:mysql /etc/mysql/rest/*
$ chmod 600 /etc/mysql/rest/*
Přidejte následující do konfiguračního souboru MariaDB v sekci [mysqld] nebo [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
Všimněte si proměnné file_key_management_filekey, pokud je heslo v souboru, musíte před cestu zadat "FILE:". Alternativně můžete také zadat řetězec hesla přímo (nedoporučujeme kvůli jeho upovídanosti):
file_key_management_filekey=mySuperStrongPassword
Restartujte server MariaDB jeden uzel po druhém, počínaje podřízenými:
(slave1)$ systemctl restart mariadb
(slave2)$ systemctl restart mariadb
(master)$ systemctl restart mariadb
Prohlédněte si protokol chyb a ujistěte se, že je během spouštění aktivováno šifrování 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
...
V protokolu chyb byste měli vidět řádky označující inicializaci šifrování. V tomto okamžiku je nyní většina konfigurace šifrování dokončena.
Testování vašeho šifrování
Vytvořte testovací databázi pro testování na hlavním serveru:
(master)MariaDB> CREATE SCHEMA sbtest;
(master)MariaDB> USE sbtest;
Vytvořte standardní tabulku bez šifrování a vložte řádek:
MariaDB> CREATE TABLE tbl_plain (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255));
MariaDB> INSERT INTO tbl_plain SET data = 'test data';
Uložená data můžeme vidět jako čistý text při procházení datového souboru InnoDB pomocí nástroje 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 ................
Vytvořte zašifrovanou tabulku a vložte řádek:
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';
Nemůžeme říct, co je uloženo v datovém souboru InnoDB pro šifrované tabulky:
$ 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(....#......
Upozorňujeme, že soubor metadat tbl_enc.frm není v klidu zašifrován. Šifrován je pouze datový soubor InnoDB (.ibd).
Při porovnávání „obyčejných“ binárních nebo reléových protokolů můžeme jasně vidět jejich obsah pomocí nástroje 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
Zatímco u zašifrovaného binárního protokolu vypadá obsah nesmyslně:
$ 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...
Šifrování tabulek Aria
U úložiště Aria nepodporuje možnost ENCRYPTED v příkazu CREATE/ALTER, protože se řídí globální možností aria_encrypt_tables. Proto při vytváření tabulky Aria jednoduše vytvořte tabulku s volbou 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;
Potom můžeme ověřit obsah datového souboru tabulky (tbl_aria_enc.MAD) nebo indexového souboru (tbl_aria_enc.MAI) pomocí nástroje hexdump. Chcete-li zašifrovat existující tabulku Aria, je třeba tabulku znovu sestavit:
MariaDB> ALTER TABLE db.aria_table ENGINE=Aria ROW_FORMAT=PAGE;
Toto prohlášení způsobí, že Aria znovu sestaví tabulku pomocí volby tabulky ROW_FORMAT. V tomto procesu s novým výchozím nastavením zašifruje tabulku při zápisu na disk.
Šifrování obecného protokolu/protokol pomalých dotazů
Pro šifrování obecných a pomalých protokolů dotazů můžeme nastavit možnost MariaDB log_output na 'TABLE' namísto výchozího 'FILE':
MariaDB> SET GLOBAL log_ouput = 'TABLE';
MariaDB však ve výchozím nastavení vytvoří potřebné tabulky pomocí úložiště CSV, které není šifrováno MariaDB. Pro tabulky protokolů nejsou legální žádné jiné enginy než CSV, MyISAM nebo Aria. Trik je přestavět výchozí CSV tabulku s Aria storage enginem za předpokladu, že volba aria_encrypt_tables je nastavena na ON. Aby však změna tabulky proběhla úspěšně, musí být příslušná možnost protokolu vypnuta.
Postup k šifrování obecné tabulky protokolu je tedy:
MariaDB> SET GLOBAL general_log = OFF;
MariaDB> ALTER TABLE mysql.general_log ENGINE=Aria;
MariaDB> SET GLOBAL general_log = ON;
Podobně pro protokol pomalého dotazu:
MariaDB> SET GLOBAL slow_query_log = OFF;
MariaDB> ALTER TABLE mysql.slow_log ENGINE=Aria;
MariaDB> SET GLOBAL slow_query_log = ON;
Ověřte výstup obecných protokolů na serveru:
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 |
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------+
Stejně jako zašifrovaný obsah datového souboru Aria v datovém adresáři pomocí nástroje 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
Klidové šifrování MariaDB je nyní dokončeno. Zkombinujte to s přenosovým šifrováním, které jsme provedli v prvním příspěvku, naše konečná architektura nyní vypadá takto:
Závěr
Nyní je možné zcela zabezpečit vaše databáze MariaDB pomocí šifrování pro ochranu před fyzickým a virtuálním porušením nebo krádeží. ClusterControl vám také může pomoci udržovat tento typ zabezpečení a můžete si jej zdarma stáhnout zde.