Crittografia completa di MariaDB a riposo e in transito per la massima protezione dei dati

Nella prima parte di questa serie, abbiamo trattato la configurazione della crittografia in transito per i server di replica MariaDB, in cui abbiamo configurato le crittografie client-server e di replica. Preso dal primo post, in cui avevamo parzialmente configurato la nostra crittografia completa (come indicato dalle frecce verdi a sinistra nel diagramma) e in questo post del blog completeremo l'impostazione della crittografia con la crittografia a riposo per creare un configurazione della replica MariaDB completamente crittografata.

Il diagramma seguente illustra la nostra configurazione attuale e la configurazione finale che otterremo:

Crittografia a riposo

La crittografia a riposo significa che i dati a riposo, come i file di dati e i registri, sono crittografati sul disco, rendendo quasi impossibile per qualcuno accedere o rubare un disco rigido e ottenere l'accesso ai dati originali (a condizione che la chiave sia protetta e non archiviata localmente). La crittografia dei dati a riposo, nota anche come crittografia dei dati trasparenti (TDE), è supportata in MariaDB 10.1 e versioni successive. Tieni presente che l'utilizzo della crittografia comporta un sovraccarico di circa il 5-10%, a seconda del carico di lavoro e del tipo di cluster.

Per MariaDB, i seguenti componenti MariaDB possono essere crittografati a riposo:

File di dati InnoDB (tablespace condiviso o tablespace individuale, ad es. *.ibd e ibdata1)
Dati Aria e file di indice.
Annulla/ripristina registri (file di registro InnoDB, ad es. ib_logfile0 e ib_logfile1).
Registri binari/relè.
File e tabelle temporanei.

Al momento non è possibile crittografare i seguenti file:

File di metadati (ad esempio file .frm).
Registro generale basato su file/registro query lente. È possibile crittografare il registro generale basato su tabelle/il registro delle query lente.
Registro errori.

La crittografia dei dati inattivi di MariaDB richiede l'uso di una gestione delle chiavi e dei plugin di crittografia. In questo post del blog, utilizzeremo File Key Management Encryption Plugin, fornito per impostazione predefinita da MariaDB 10.1.3. Tieni presente che l'utilizzo di questo plug-in presenta numerosi inconvenienti, ad esempio, la chiave può ancora essere letta dall'utente root e MySQL, come spiegato nella pagina MariaDB Data-at-Rest Encryption.

Generazione file chiave

Creiamo una directory dedicata per archiviare il nostro materiale di crittografia a riposo:

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

Crea un file di chiavi. Questo è il cuore della crittografia:

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

Aggiungi una stringa "1;" come identificatore di chiave nel file di chiavi:

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

Quindi, durante la lettura del file di chiavi, dovrebbe assomigliare a questo:

$ cat /etc/mysql/rest/keyfile
1;4eb5770dcfa691bc634cbcd3c6bed9ed4ccd0111f3d3b1dae2c51a90fbf16ed7

Quello sopra significa semplicemente che per l'identificatore della chiave 1, la chiave è 4eb... Il file della chiave deve contenere due informazioni per ciascuna chiave di crittografia. Innanzitutto, ogni chiave di crittografia deve essere identificata con un numero intero a 32 bit come identificatore della chiave. In secondo luogo, la chiave di crittografia stessa deve essere fornita in forma con codifica esadecimale. Queste due informazioni devono essere separate da un punto e virgola.

Crea una password per crittografare la chiave sopra. Qui memorizzeremo la password all'interno di un file chiamato "keyfile.passwd":

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

Puoi saltare il passaggio precedente se desideri specificare la password direttamente nel file di configurazione utilizzando l'opzione file_key_management_filekey. Ad esempio:file_key_management_filekey=mySuperStrongPassword

Ma in questo esempio leggeremo la password che è memorizzata in un file, quindi dovremo definire la seguente riga nel file di configurazione in seguito:

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

Crittoficeremo il file di chiavi in chiaro in un altro file chiamato keyfile.enc, usando la password all'interno del file di password:

$  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

Quando elenchiamo la directory, dovremmo vedere questi 3 file:

$ ls -1 /etc/mysql/rest/
keyfile
keyfile.enc
keyfile.passwd

Il contenuto di keyfile.enc è semplicemente una versione crittografata di keyfile:

Per testare, possiamo decrittografare il file crittografato utilizzando OpenSSL fornendo il file password (keyfile.passwd):

$ openssl aes-256-cbc -d -md sha1 -pass file:/etc/mysql/rest/keyfile.passwd -in /etc/mysql/rest/keyfile.enc
1;4eb5770dcfa691bc634cbcd3c6bed9ed4ccd0111f3d3b1dae2c51a90fbf16ed7

Possiamo quindi rimuovere la semplice chiave perché utilizzeremo quella crittografata (.enc) insieme al file della password:

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

Ora possiamo procedere con la configurazione della crittografia a riposo di MariaDB.

Configurazione della crittografia a riposo

Dobbiamo spostare il file della chiave crittografata e la password sugli slave che verranno utilizzati da MariaDB per crittografare/decodificare i dati. In caso contrario, il backup di una tabella crittografata dal master utilizzando un backup fisico come MariaDB Backup avrebbe problemi di lettura da parte degli slave (a causa della diversa combinazione di chiave/password). Il backup logico come mysqldump dovrebbe funzionare con chiavi e password diverse.

Negli slave, crea una directory in cui archiviare elementi di crittografia a riposo:

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

Sul master, copia il file di chiavi crittografato e il file di password sugli altri slave:

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

Proteggi i file dall'accesso globale e assegna l'utente "mysql" come proprietà:

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

Aggiungi quanto segue nel file di configurazione di MariaDB nella sezione [mysqld] o [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

Prendi nota sulla variabile file_key_management_filekey, se la password è in un file, devi anteporre al percorso "FILE:". In alternativa, puoi anche specificare direttamente la stringa della password (non consigliato a causa della sua verbosità):

file_key_management_filekey=mySuperStrongPassword

Riavvia il server MariaDB un nodo alla volta, iniziando dagli slave:

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

Osserva il log degli errori e assicurati che la crittografia MariaDB sia attivata durante l'avvio:

$ 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
...

Dovresti vedere delle righe che indicano l'inizializzazione della crittografia nel registro degli errori. A questo punto, la maggior parte della configurazione della crittografia è ora completa.

Test della crittografia

Crea un database di test per testare sul master:

(master)MariaDB> CREATE SCHEMA sbtest;
(master)MariaDB> USE sbtest;

Crea una tabella standard senza crittografia e inserisci una riga:

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

Possiamo vedere i dati memorizzati in chiaro durante la navigazione nel file di dati InnoDB utilizzando uno strumento 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  ................

Crea una tabella crittografata e inserisci una riga:

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';

Non possiamo dire cosa è memorizzato nel file di dati InnoDB per le tabelle crittografate:

$ 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(....#......

Si noti che il file di metadati tbl_enc.frm non è crittografato a riposo. Viene crittografato solo il file di dati InnoDB (.ibd).

Quando confrontiamo i log binari o di inoltro "semplici", possiamo vederne chiaramente il contenuto usando lo strumento 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

Mentre per un registro binario crittografato, il contenuto sembra incomprensibile:

$ 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...

Crittografia delle tabelle Aria

Per il motore di archiviazione Aria, non supporta l'opzione ENCRYPTED nell'istruzione CREATE/ALTER poiché segue l'opzione globale aria_encrypt_tables. Pertanto, quando crei una tabella Aria, crea semplicemente la tabella con l'opzione 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;

Possiamo quindi verificare il contenuto del file di dati della tabella (tbl_aria_enc.MAD) o del file di indice (tbl_aria_enc.MAI) con lo strumento hexdump. Per crittografare una tabella Aria esistente, è necessario ricostruire la tabella:

MariaDB> ALTER TABLE db.aria_table ENGINE=Aria ROW_FORMAT=PAGE;

Questa istruzione fa sì che Aria ricostruisca la tabella usando l'opzione tabella ROW_FORMAT. Nel processo, con la nuova impostazione predefinita, crittografa la tabella quando scrive sul disco.

Crittografia registro generale/registro query lente

Per crittografare i log di query generali e lenti, possiamo impostare l'opzione log_output di MariaDB su 'TABLE' invece del predefinito 'FILE':

MariaDB> SET GLOBAL log_ouput = 'TABLE';

Tuttavia, MariaDB creerà per impostazione predefinita le tabelle necessarie utilizzando il motore di archiviazione CSV, che non è crittografato da MariaDB. Nessun motore diverso da CSV, MyISAM o Aria è legale per le tabelle di registro. Il trucco è ricostruire la tabella CSV predefinita con il motore di archiviazione Aria, a condizione che l'opzione aria_encrypt_tables sia impostata su ON. Tuttavia, la rispettiva opzione di registro deve essere disattivata affinché la modifica della tabella abbia esito positivo.

Quindi, i passaggi per crittografare la tabella di registro generale sono:

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

Allo stesso modo, per il registro delle query lente:

MariaDB> SET GLOBAL slow_query_log = OFF;
MariaDB> ALTER TABLE mysql.slow_log ENGINE=Aria;
MariaDB> SET GLOBAL slow_query_log = ON;

Verifica l'output dei log generali all'interno del server:

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    |
+----------------------------+---------------------------+-----------+-----------+--------------+------------------------------+

Oltre al contenuto crittografato del file di dati Aria all'interno della directory dei dati utilizzando lo strumento 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

La crittografia a riposo di MariaDB è ora completa. Combina questo con la crittografia in transito che abbiamo fatto nel primo post, la nostra architettura finale ora appare così:

Conclusione

È ora possibile proteggere completamente i database MariaDB tramite crittografia per la protezione da violazioni o furti fisici e virtuali. ClusterControl può aiutarti a mantenere anche questo tipo di sicurezza e puoi scaricarlo gratuitamente qui.