MySQL InnoDB Tablespace Encryption (TDE)

MySQL e' il piu' diffuso DBMS relazionale Open Source. MySQL fornisce la funzionalita' di crittografia "at rest" ovvero i dati, visibili in chiaro accedendo alla base dati, vengono scritti in forma crittografata su disco.

La versione di MySQL cui fa riferimento il documento e' la 5.7 in cui e' stata introdotta la funzionalita' di tablespace encryption per InnoDB [NdE la 5.7 e' l'ultima versione di produzione disponibile da ottobre 2015].

La prima parte del documento contiene un poco di teoria: chi ha fretta puo' partire da qui!

Questa pagina ha un taglio pratico e presenta le configurazioni possibili tuttavia non e' un documento introduttivo ed e' consigliato ad un pubblico informaticamente adulto... Un documento introduttivo su MySQL e' Introduzione a MySQL, un documento piu' completo e' Qualcosa in piu' su MySQL ed infine Problematiche di sicurezza su database MySQL riporta le principali tecnologie relative alla sicurezza di MySQL.

Architettura MySQL

Un breve accenno all'architettura di MySQL puo' essere utile... L'architettura di MySQL e' molto semplice: vi e' un singolo processo che gestisce un thread per ogni connessione! Le connessioni sono locali o via rete sulla porta 3306 (default che puo' essere cambiato). MySQL Architecture

Ogni database MySQL corrisponde ad una directory posta sotto la directory indicata dal parametro datadir. All'interno della directory si trovano i file relativi ad ogni tabella. La memorizzazione dei dati dipende dallo Storage Engine. E' sempre presente un file tabella.frm che contiene la struttura della tabella, eventuali altri file dipendono dall'Engine di memorizzazione (eg. .frm, .MYD e .MYI per MyISAM, .frm e .ibd per InnoDB). InnoDB, nelle versioni piu' recenti, utilizza per default il formato file-per-table che impiega un file diverso per ogni tabella.

A parte le password degli utenti, che vengono mantenute sul database solo in forma crittografata, tutti gli altri dati sono salvati "in chiaro" sul disco. Questo consente, accedendo dal sistema operativo ai file e conoscendo la struttura dei dati (che e' relativamente semplice in MySQL), di estrarre informazioni senza connettersi a MySQL. E' un'operazione molto semplice per l'utente root di amministrazione e per chiunque abbia accesso ai backup dei file system o all'immagine del sistema (come avviene per le VM ed in Cloud).

Ecco la ragione di questo documento!
Con la InnoDB Tablespace Encryption i dati salvati su disco sono crittografati.

Encryption at-rest (TL;DR)

Come dice il titolo non e' necessario leggere questo paragrafo, chi ha fretta puo' partire da qui!

Per Encryption at-rest si intende la crittografazione dei dati sul supporto fisico (il file system) su cui vengono memorizzati. Gli utenti del DB vedono i dati senza alcuna differenza utilizzando l'SQL ma un accesso diretto ai file del database non permette di ricavare alcuna informazione.

MySQL supporta la crittografia at-rest per le tabelle su Engine InnoDB memorizzate su tablespace file-per-table. Non sono supportati altri Engine e non sono crittografabili le informazioni poste sui tablespace InnoDB che non siano file-per-table: general tablespace, system tablespace, undo log tablespace e temporary tablespace.

I dati contenuti nel tablespace sono crittografati con l'algoritmo CBC (Cipher Block Chaining) dell'AES-256 che garantisce un ottimo livello di sicurezza con un costo computazionale limitato.
Ma qual e' la chiave utilizzata e come viene mantenuta? Dal punto di vista tecnico viene utilizzata una soluzione a due livelli: e' presente una chiave master ed una chiave per ogni tablespace. Quando viene richiesta una tablespace crittografata si genera a caso una nuova chiave che viene posta, crittografata a sua volta con la master key, nell'header della tablespace.
E' possibile cambiare la master key con un comando SQL se si ritiene sia stata compromessa. Quando viene cambiata la master key vengono aggiornati gli header di tutte le tablespace ma non e' necessario crittografare nuovamente la parte dei dati che resta immutata.

Per la gestione della master key MySQL utilizza un plugin. Sono disponibili 3 differenti plugin:

Quando si utilizza l'InnoDB tablespace encryption con il plugin OKV la funzionalita' viene commercialmente chiamata "MySQL Enterprise Transparent Data Encryption (TDE)".

E' possibile utilizzare un solo plugin alla volta e non e' possibile cambiare plugin se vi sono dati crittografati.
E' disponibile un ulteriore plugin che fornisce un interfaccia SQL alla gestione delle chiavi tramite UDF (User Defined Function): keyring_udf.

Configurazione

Per configurare la Tablespace Encryption e' sufficiente attivare il plugin del keyring con: 

[mysqld]
early-plugin-load=keyring_file.so

Ovviamente e' necessario riavviare MySQL.
La sintassi e' un poco diversa rispetto ad altri plugin semplicemente perche' questo plugin deve essere attivato prima dell'Engine InnoDB.

Per i plugin keyring_okv e keyring_aws disponibili con la versione enterprise la sintassi e' la stessa.

Utilizzo

Una volta configurato il plugin, l'utilizzo del TDE e' semplicissimo:

CREATE TABLE t1 (c1 INT, c2 VARCHAR(64)) ENCRYPTION='Y'; ALTER TABLE t2 ENCRYPTION='Y';

Non c'e' nessuna differenza per gli utenti o per i DBA nell'utilizzo di una tabella crittografata rispetto ad una in chiaro.

Se il non viene caricato un plugin per la gestione della master key qualsiasi tentativo di creare una tabella crittografata restituisce l'errore:
  ERROR 3185 (HY000): Can't find master key from keyring, please check keyring plugin is loaded.

Per eliminare la crittografia da una tabella:

ALTER TABLE t1 ENCRYPTION='N';

Periodicamente e' opportuno variare la master key. Si fa in modo semplice con un comando SQL:

ALTER INSTANCE ROTATE INNODB MASTER KEY;

Infine per ottenere l'elenco delle tabelle crittografate:

SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE CREATE_OPTIONS LIKE '%ENCRYPTION="Y"%';

Dal punto di vista SQL non vi e' nessuna differenza tra le tabelle crittografate at-rest e le tabelle in chiaro. Anche dal punto di vista prestazionale tipicamente non vi sono differenze significative nell'accesso.

Verifica

Mai fidarsi... sono veramente crittografati i dati? 

mysql> CREATE TABLE t1 (c1 INT, c2 VARCHAR(64));
mysql> insert into t1 values(1,'Hello world!');

$ ls -l
-rw-r-----   1 meo  staff       8582 Dec 29 22:10 t1.frm
-rw-r-----   1 meo  staff      98304 Dec 29 22:12 t1.ibd

$ od -c t1.ibd
0000000  342   1   =   V  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000020   \0  \0  \0  \0   ' 253   V 036  \0  \b  \0  \0  \0  \0  \0  \0
...
0140140  002  \0 034   i   n   f   i   m   u   m  \0 002  \0  \v  \0  \0
0140160    s   u   p   r   e   m   u   m  \f  \0  \0  \0 020 377 361  \0
0140200   \0  \0  \0 006 001  \0  \0  \0  \0 233  \r 255  \0  \0 001 001
0140220  001 020 200  \0  \0 001   H   e   l   l   o       w   o   r   l
0140240    d   !  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
...

mysql> ALTER TABLE t1 ENCRYPTION='Y';

$ od -c t1.ibd
0000000    4   ^ 227 024  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
0000020   \0  \0  \0  \0   ' 253   I 215  \0  \b  \0  \0  \0  \0  \0  \0
...
0140140  302   p   U 256 006 036 355 340   |   z 356 177   K 354  \a   N
0140160    [ 306   . 325 027 235  \n 336 271 272 310   & 212 270 205   H
0140200  003 223 220 032 207   z 177  \0   x 204   G   4   = 257   g 016
0140220  016 201 242 211   !   \ 023   = 204   V 355 017   ( 261 117 211
0140240    O 351 327   !   F   #   w 370   e   g  \v 004   A 376   8   N
...

I dati sono crittografati, il file non cambia dimensioni, in caso di modifica della master key viene modificato solo l'header del file di tablespace di tutte le tabelle crittografate.

Varie ed eventuali

Per una documentazione completa e tutti i dettagli si rimanda alla documentazione MySQL ufficiale.

L'utilizzo di VM e del Cloud sono tecnologie sempre piu' diffuse e questo presenta nuove sfide perche' in precedenza i sistemi che ospitavano le basi dati venivano acceduti solo dai DBA; ora vi sono potenzialmente piu' figure che possono accedere agli ambienti, ai loro cloni ed ai loro backup fisici.
La crittografia at-rest diventa quindi sempre piu' importante.

L'aggiornamento e' sempre molto importante per tutte le problematiche di sicurezza. Solo le versioni piu' recenti di MySQL forniscono l'insieme piu' completo di funzionalita'. Importante l'upgrade MySQL 5.7.21 [NdA 2018-01-15] che fissa alcune vulnerabilita', introduce il plugin keyring_encrypted_file e consente la migrazione tra keystore differenti...
Con la versione 8.0 sono state aggiunte ulteriori funzionalita' e si e' passati dall'utilizzo di plugin all'utilizzo di component [NdA component_keyring_file, component_keyring_encrypted_file da MySQL 8.0.24; component_keyring_oci da MySQL 8.0.31] che consentono l'utilizzo di chiavi di maggiori dimensioni. Per maggiori dettagli e' opportuno fare riferimento alla documentazione ufficiale.

Il PATH di default del keyring file e': /var/lib/mysql-keyring/keyring e' utile conoscerlo perche' senza di esso un backup fisico delle tabelle crittografate non serve a nulla!
Il file e' di piccole dimensioni e contiene un header facilmente riconoscibile e la chiave:

0000000 K e y r i n g f i l e v e r 0000020 s i o n : 1 . 0 200 \0 \0 \0 \0 \0 \0 \0 0000040 0 \0 \0 \0 \0 \0 \0 \0 003 \0 \0 \0 \0 \0 \0 \0 0000060 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000100 I N N O D B K e y - 5 3 9 b 6 9 0000120 6 9 - 4 c a e - 6 9 6 9 - 6 c a 0000140 3 - 0 0 5 0 5 6 a 0 4 6 c f - 2 0000160 A E S f 345 g 6 9 6 9 364 031 334 213 _ 346 ...

Titolo: MySQL InnoDB Tablespace Encryption (TDE)
Livello: Esperto (4/5)
Data: 14 Febbraio 2016 ❤️
Versione: 1.0.1 - 31 Ottobre 2023 🎃
Autore: mail [AT] meo.bogliolo.name