Fuld MariaDB-kryptering i hvile og under transport for maksimal databeskyttelse - del 2

I den første del af denne serie har vi dækket in-transit krypteringskonfiguration for MariaDB replikeringsservere, hvor vi konfigurerede klient-server og replikeringskrypteringer. Taget fra det første indlæg, hvor vi delvist havde konfigureret vores fulde kryptering (som angivet med de grønne pile til venstre i diagrammet) og i dette blogindlæg vil vi fuldføre krypteringsopsætningen med hvilende kryptering for at skabe en fuldt krypteret MariaDB-replikeringsopsætning.

Følgende diagram illustrerer vores nuværende opsætning og den endelige opsætning, som vi skal opnå:

Kryptering i hvile

Kryptering i hvile betyder, at data i hvile som datafiler og logfiler er krypteret på disken, hvilket gør det næsten umuligt for nogen at få adgang til eller stjæle en harddisk og få adgang til de originale data (forudsat at nøglen er sikret og ikke opbevares lokalt). Data-at-rest-kryptering, også kendt som Transparent Data Encryption (TDE), understøttes i MariaDB 10.1 og nyere. Bemærk, at brug af kryptering har en overhead på ca. 5-10 %, afhængigt af arbejdsbyrden og klyngetypen.

For MariaDB kan følgende MariaDB-komponenter krypteres i hvile:

• InnoDB-datafil (delt tablespace eller individuelt tablespace, f.eks. *.ibd og ibdata1)
• Aria-data og indeksfiler.
• Fortryd/gentag logfiler (InnoDB-logfiler, f.eks. ib_logfile0 og ib_logfile1).
• Binære/relælogfiler.
• Midlertidige filer og tabeller.

Følgende filer kan ikke krypteres i øjeblikket:

• Metadatafil (f.eks. .frm-filer).
• Filbaseret generel log/langsom forespørgselslog. Tabelbaseret generel log/langsom forespørgselslog kan krypteres.
• Fejllog.

MariaDBs data-at-rest-kryptering kræver brug af nøgleadministration og krypteringsplugins. I dette blogindlæg skal vi bruge File Key Management Encryption Plugin, som leveres som standard siden MariaDB 10.1.3. Bemærk, at der er en række ulemper ved at bruge dette plugin, f.eks. kan nøglen stadig læses af root- og MySQL-bruger, som forklaret på MariaDB Data-at-Rest Encryption-siden.

Generer nøglefil

Lad os oprette en dedikeret mappe til at gemme vores hvilende krypteringsting:

$ mkdir -p /etc/mysql/rest$ cd /etc/mysql/rest 

Opret en nøglefil. Dette er kernen i kryptering:

$ openssl rand -hex 32> /etc/mysql/rest/keyfile 

Tilføj en streng "1;" som nøgle-id i nøglefilen:

$ echo '1;' sed -i '1s/^/1;/' /etc/mysql/rest/keyfile 

Når du læser nøglefilen, skulle den således se sådan ud:

$ kat /etc/mysql/rest/keyfile1;4eb5770dcfa691bc634cbcd3c6bed9ed4ccd0111f3d3b1dae2c51a90fbf16ed7 

Ovenstående betyder ganske enkelt for nøgleidentifikator 1, at nøglen er 4eb... Nøglefilen skal indeholde to stykker information for hver krypteringsnøgle. For det første skal hver krypteringsnøgle identificeres med et 32-bit heltal som nøgleidentifikation. For det andet skal selve krypteringsnøglen leveres i hex-kodet form. Disse to oplysninger skal adskilles af et semikolon.

Opret en adgangskode for at kryptere nøglen ovenfor. Her skal vi gemme adgangskoden i en fil kaldet "keyfile.passwd":

$ echo -n 'mySuperStrongPassword'> /etc/mysql/rest/keyfile.passwd 

Du kan springe ovenstående trin over, hvis du ønsker at angive adgangskoden direkte i konfigurationsfilen ved hjælp af file_key_management_filekey. For eksempel:file_key_management_filekey=mySuperStrongPassword

Men i dette eksempel skal vi læse adgangskoden, der er gemt i en fil, og derfor skal vi definere følgende linje i konfigurationsfilen senere: 

file_key_management_filekey=FILE:/etc/mysql/encryption/keyfile.passwd 

Vi skal kryptere den klare tekst-nøglefil til en anden fil kaldet keyfile.enc, ved at bruge adgangskoden inde i adgangskodefilen:

$ 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 

Når vi viser mappen, bør vi se disse 3 filer:

$ ls -1 /etc/mysql/rest/keyfilekeyfile.enckeyfile.passwd 

Indholdet af nøglefil.enc er simpelthen en krypteret version af nøglefil:

For at teste det kan vi dekryptere den krypterede fil ved hjælp af OpenSSL ved at levere adgangskodefil (keyfile.passwd):

Vi kan derefter fjerne den almindelige nøgle, fordi vi skal bruge den krypterede (.enc) sammen med adgangskodefilen:

$ rm -f /etc/mysql/encryption/keyfile 

Vi kan nu fortsætte med at konfigurere MariaDB hvilende kryptering.

Konfiguration af hvilende kryptering

Vi er nødt til at flytte den krypterede nøglefil og adgangskode til de slaver, der skal bruges af MariaDB til at kryptere/dekryptere dataene. Ellers ville en krypteret tabel, der sikkerhedskopieres fra masteren ved hjælp af fysisk backup som MariaDB Backup, have problemer med at læse af slaverne (på grund af en anden nøgle/adgangskodekombination). Logisk sikkerhedskopiering som mysqldump burde fungere med forskellige nøgler og adgangskoder.

Opret en mappe på slaverne til at gemme krypteringsting i hvile:

(slave1)$ mkdir -p /etc/mysql/rest(slave2)$ mkdir -p /etc/mysql/rest 

På masteren skal du kopiere den krypterede nøglefil og adgangskodefil til de andre slaver:

(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/ 

Beskyt filerne mod global adgang og tildel "mysql"-bruger som ejerskab:

$ chown mysql:mysql /etc/mysql/rest/*$ chmod 600 /etc/mysql/rest/* 

Tilføj følgende til MariaDB-konfigurationsfilen under [mysqld] eller [mariadb] sektionen:

# at-rest encryptionplugin_load_add =file_key_managementfile_key_management_filename =/etc/mysql/rest/keyfile.encfile_key_management_filekey =FILE:/etc/mysql/rest/keyfile.passwdfile_key_management_encryption_algorithm =AES_CBCinnodb_encrypt_tables =ONinnodb_encrypt_temporary_tables =ONinnodb_encrypt_log =ONinnodb_encryption_threads =4innodb_encryption_rotate_key_age =1encrypt- tmp-disk-tables =1encrypt-tmp-filer =1encrypt-binlog =1aria_encrypt_tables =TIL 

Vær opmærksom på variabelen file_key_management_filekey, hvis adgangskoden er i en fil, skal du foranstille stien med "FILE:". Alternativt kan du også angive adgangskodestrengen direkte (anbefales ikke på grund af dens omfang): 

file_key_management_filekey=mySuperStrongPassword 

Genstart MariaDB-serveren én node ad gangen, startende med slaverne:

(slave1)$ systemctl genstart mariadb(slave2)$ systemctl genstart mariadb(master)$ systemctl genstart mariadb 

Observer fejlloggen og sørg for, at MariaDB-kryptering er aktiveret under opstart:

$ tail -f /var/log/mysql/mysqld.log...2019-12-17 6:44:47 0 [Bemærk] InnoDB:Kryptering af redolog:2*67108864 bytes; LSN=1433112019-12-17 6:44:48 0 [Bemærk] InnoDB:Begynder at slette og omskrive logfiler.2019-12-17 6:44:48 0 [Bemærk] InnoDB:Indstiller logfil ./ib_logfile101 størrelse til 67108864 bytes2019-12-17 6:44:48 0 [Bemærk] InnoDB:Indstilling af logfil ./ib_logfile1 størrelse til 67108864 bytes2019-12-17 6:44:48 0 [Bemærk] InnoDB:Omdøbning af logfil ./1b_logfil. /ib_logfile02019-12-17 6:44:48 0 [Bemærk] InnoDB:Nye logfiler oprettet, LSN=1433112019-12-17 6:44:48 0 [Bemærk] InnoDB:128 ud af 128 rollback-segmenter er aktive.2019 -12-17 6:44:48 0 [Bemærk] InnoDB:Oprettelse af delt tablespace til midlertidige tabeller2019-12-17 6:44:48 0 [Bemærk] InnoDB:Indstiller filstørrelsen './ibtmp1' til 12 MB. Fysisk at skrive filen fuld; Vent venligst ...2019-12-17 6:44:48 0 [Bemærk] InnoDB:Fil './ibtmp1' størrelse er nu 12 MB.2019-12-17 6:44:48 0 [Bemærk] InnoDB:Venter for udrensning til start2019-12-17 6:44:48 0 [Bemærk] InnoDB:10.4.11 startede; log sekvensnummer 143311; transaktions-id 2222019-12-17 6:44:48 0 [Bemærk] InnoDB:Oprettelse af #1 krypteringstråd-id 139790011840256 samlede tråde 4.2019-12-17 6:44:48 0 [Bemærk] #21DB3979000111840256 krypteringstråd 59790000 samlede tråde 4.2019-12-17 6:44:48 0 [Bemærk] InnoDB:Opretter #3 krypteringstråd-id 139789995054848 samlede tråde 4.2019-12-17 6:44:48 0 [Bemærk] InnoDB3 krypteringstråd 8id 90 74 kryptering #6id 90 samlede tråde 4.2019-12-17 6:44:48 0 [Bemærk] InnoDB:Indlæser bufferpuljer fra /var/lib/mysql/ib_buffer_pool2019-12-17 6:44:48 0 [Bemærk] Plugin 'FEEDBACK' er deaktiveret.2019-12-17 6:44:48 0 [Bemærk] Brug af krypteringsnøgle id 1 til midlertidige filer... 

Du bør se linjer, der indikerer initialisering af kryptering i fejlloggen. På dette tidspunkt er størstedelen af ​​krypteringskonfigurationen nu fuldført.

Test af din kryptering

Opret en testdatabase for at teste på masteren:

(master)MariaDB> OPRET SKEMA sbtest;(master)MariaDB> BRUG sbtest; 

Opret en standardtabel uden kryptering og indsæt en række:

MariaDB> CREATE TABLE tbl_plain (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255));MariaDB> INSERT INTO tbl_plain SET data ='testdata'; 

Vi kan se de lagrede data i klartekst, når vi gennemser InnoDB-datafilen ved hjælp af et hexdump-værktøj:

$ xxd /var/lib/mysql/sbtest/tbl_plain.ibd | Mindre000C060:0200 1C69 6E66 696D 756D 0002 000B 0000 ... INFIMIME ...... 000C070:7375 7072 656D 756D 0900 0000 10FF F180 SOPREMUM ........ 000C080:0000 010000 000000 0080 00000000000000000000000000000000000000000000000000000000000000 00 ...............000c090:7465 7374 2064 6174 6100 0000 0000 0000 testdata......... .......... 

Opret en krypteret tabel og indsæt en række:

MariaDB> CREATE TABLE tbl_enc (id INT AUTO_INCREMENT PRIMARY KEY, data VARCHAR(255)) ENCRYPTED=YES;MariaDB> INSERT INTO tbl_enc SET data ='testdata'; 

Vi kan ikke se, hvad der er gemt i InnoDB-datafilen til krypterede tabeller:

$ xxd /var/lib/mysql/sbtest/tbl_enc.ibd | less000c060:0c2c 93e4 652e 9736 e68a 8b69 39cb 6157 .,..e..6...i9.aW000c070:3cd1 581c 7eb9 84ca 84ca d792 371:092 372 372 371 392 392 372 391 d3f5 f9b0 eccb ed05 de16 f3ac .y............. d8a5 1215 .o.o(....#...... 

Bemærk at metadatafilen tbl_enc.frm ikke er krypteret ved hvile. Kun InnoDB-datafilen (.ibd) er krypteret.

Når vi sammenligner de "almindelige" binære eller relælogfiler, kan vi tydeligt se indholdet af det ved hjælp af hexdump-værktøjet:

$ xxd binlog.000002 | MINDRE0000560:0800 0800 0800 0B04 726F 6F74 096C 6F63 ........ ROOT.LOC0000570:616C 686F 7374 0047 5241 4E54 2052 454C ALHOST.GRANT REL00580:4F41 442C 4C4F 434B 5245 504c 4943 4154 494f 4e20 434c 4945 REPLICATION CLIE00005a0:4e54 2c45 5645 4e54 2c43 5245 4154 4520 NT,EVENT,CREATE00005b0:5441 424c 4553 5041 4345 2c50 524f 4345 TABLESPACE,PROCE00005c0:5353 2c43 5245 4154 452c 494e 5345 5254 SS,CREATE,INSERT00005d0 :2c53 454c 4543 542c 5355 5045 522c 5348 ,SELECT,SUPER,SH00005e0:4f57 2056 4945 5720 4f4e 202a 2e2a 205ON. 

Mens for en krypteret binær log, ser indholdet vrøvl ud:

$ xxd binlog.000004 | less0000280:4a1d 1ced 2f1b db50 016a e1e9 1351 84ba J.../..P.j...Q..0000290:38b6 72e7 8743 7713 afc3 eecb c396c .01b .01b c396c .01b .01b c396c. 7b3f 6176 208f 0000 00dc 85bf 6768 e7c6 {?av .......gh..00002b0:6107 5bea 241c db12 d50c 3573 48e5 3c3d a. d408 1113 3e25 d165 c95b 1y.S$I....>%.e.[00002d0:afb0 6778 4b26 f672 1bc7 567e da96 13f5 ..gxK&.r..V~....0022ac 9b ab47 6c9f a686 *..&?.Kz>..Gl... 

Kryptering af Aria-tabeller

For Aria-lagringsmotoren understøtter den ikke ENCRYPTED-indstillingen i CREATE/ALTER-sætningen, da den følger den globale indstilling aria_encrypt_tables. Derfor, når du opretter en Aria-tabel, skal du blot oprette tabellen med indstillingen 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 ('testdata');MariaDB> FLUSH_ TABLE;  

Vi kan derefter verificere indholdet af tabellens datafil (tbl_aria_enc.MAD) eller indeksfil (tbl_aria_enc.MAI) med hexdump-værktøjet. For at kryptere en eksisterende Aria-tabel skal tabellen genopbygges:

MariaDB> ÆNDRINGSTABEL db.aria_table ENGINE=Aria ROW_FORMAT=PAGE; 

Denne sætning får Aria til at genopbygge tabellen ved hjælp af tabelindstillingen ROW_FORMAT. I processen, med den nye standardindstilling, krypterer den tabellen, når den skriver til disk.

Kryptering af generel log/langsom forespørgselslog

For at kryptere generelle og langsomme forespørgselslogfiler kan vi indstille MariaDB log_output-indstillingen til 'TABLE' i stedet for standarden 'FILE':

MariaDB> SET GLOBAL log_ouput ='TABEL'; 

Men MariaDB vil som standard oprette de nødvendige tabeller ved hjælp af CSV storage engine, som ikke er krypteret af MariaDB. Ingen andre motorer end CSV, MyISAM eller Aria er lovlige til logtabellerne. Tricket er at genopbygge standard CSV-tabellen med Aria-lagringsmotor, forudsat at aria_encrypt_tables-indstillingen er sat til ON. Dog skal den respektive logindstilling være slået fra, for at tabelændringen lykkes.

Således er trinene til at kryptere den generelle logtabel:

MariaDB> SET GLOBAL general_log =OFF;MariaDB> ALTER TABLE mysql.general_log ENGINE=Aria;MariaDB> INDSTIL GLOBAL general_log =TIL; 

Tilsvarende for langsom forespørgselslog:

MariaDB> INDSTIL GLOBAL slow_query_log =FRA;MariaDB> ÆNDRINGSTABEL mysql.slow_log ENGINE=Aria;MariaDB> INDSTIL GLOBAL slow_query_log =TIL; 

Bekræft outputtet af generelle logfiler på serveren:

MariaDB> VÆLG * FRA mysql.general_log;+----------------------------+----- ----------------------+------------+------ -----------+-------------------------------------+| begivenhed_tid | bruger_vært | tråd_id | server_id | kommandotype | argument |+------------------------------------+------------------------ ------------------------------------------- ----------------------------+| 2019-12-17 07:45:53.109558 | root[root] @ localhost [] | 19 | 28001 | Forespørgsel | vælg * fra sbtest.tbl_enc || 2019-12-17 07:45:55.504710 | root[root] @ localhost [] | 20 | 28001 | Forespørgsel | vælg * fra general_log |+-----------------------------+-------------- --------------+------------+------------+------- --+-------------------------------------+ 

Såvel som det krypterede indhold af Aria-datafilen i databiblioteket ved hjælp af hexdump-værktøjet:

$ xxd /var/lib/mysql/mysql/general_log.MAD | less0002040:1d45 820d 7c53 216c 3fc6 98a6 356e 1b9e .E..|S!l?...5n..0002050:6bfc e193 7509 1fa7 221e2 6fe2...1cf. o0002060:ae71 bb63 e81b 0b08 7120 0c99 9f82 7c33 .q.c....q ....|30002070:1117 bc02 30c1 d9a7 ... 455a 8363 b4f4 5176 f8a1 ..]o..EZ.c..Qv..0002090:1bf8 113c 9762 3504 737e 917b f260 f88c ...<.b5.0a 0:0360 b636 c5c1 debe fbe7 6.3o.U.E.6......00020b0:d01e 028f 8b75 b368 0ef0 8889 bb63 e032 .....u.h.....c.2 

MariaDB at-rest-kryptering er nu fuldført. Kombiner dette med in-transit kryptering, vi har lavet i det første indlæg, vores endelige arkitektur ser nu sådan ud:

Konklusion

Det er nu muligt helt at sikre dine MariaDB-databaser via kryptering til beskyttelse mod fysisk og virtuelt brud eller tyveri. ClusterControl kan også hjælpe dig med at opretholde denne type sikkerhed, og du kan downloade den gratis her.