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.
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).
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.
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.
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.
Una volta configurato il plugin, l'utilizzo del TDE e' semplicissimo:
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:
Periodicamente e' opportuno variare la master key. Si fa in modo semplice con un comando SQL:
Infine per ottenere l'elenco delle tabelle crittografate:
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.
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.
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:
Titolo: MySQL InnoDB Tablespace Encryption (TDE)
Livello: Esperto
Data:
14 Febbraio 2016 ❤️
Versione: 1.0.1 - 31 Ottobre 2023 🎃
Autore: mail [AT] meo.bogliolo.name