In attesa dell'avvio di un nuovo ciclo di corsi continuiamo a pubblicare una serie di articoli sulla crittografia in MySQL.
Nell'articolo precedente di questa serie () abbiamo parlato dei key store. In questo articolo esamineremo come viene utilizzata la chiave principale (master key) e discuteremo i vantaggi e gli svantaggi della crittografia con il metodo degli envelope (envelope encryption).
L'idea della crittografia con envelope è che le chiavi utilizzate per la crittografia (chiavi degli spazi di tabella) sono crittografate da un'altra chiave (chiave principale, master key). Per la crittografia dei dati vengono effettivamente utilizzate le chiavi degli spazi di tabella. Graficamente, questo può essere rappresentato così:
La chiave principale (master key) si trova nel keyring, mentre le chiavi degli spazi di tabella sono negli header degli spazi di tabella criptati (nella pagina 0 dello spazio di tabella).
Nell'immagine sopra:
La tabella A è crittografata con la chiave 1 (Key 1). La chiave 1 è crittografata usando la chiave principale (master key) e memorizzata in forma crittografata nell'header della tabella A.
La tabella B è crittografata con la chiave 2 (Key 2). La chiave 2 è crittografata utilizzando la chiave principale (master key) e memorizzata in forma crittografata nell'header della tabella B.
E così via.
Quando il server deve decifrare la tabella A, ottiene la chiave principale dal keyring, legge la chiave crittografata 1 dall'header della tabella A e decifra la chiave 1. La chiave decifrata 1 viene memorizzata in cache nella memoria del server e utilizzata per decifrare la tabella A.
InnoDB
In InnoDB, la crittografia e la decrittografia vengono effettuate a livello di input-output. Cioè, la pagina viene crittografata immediatamente prima di essere scritta su disco e decrittografata subito dopo la lettura dal disco.
In InnoDB, la crittografia funziona solo a livello di spazi di tabella. Per impostazione predefinita, tutte le tabelle vengono create in spazi di tabella separati (). In altre parole, viene creato uno spazio di tabella che può contenere solo una tabella. Sebbene tu possa anche creare tabelle anche nello spazio di tabella principale (). Ma in ogni caso, una tabella si trova sempre in qualche spazio di tabella. E poiché la crittografia avviene a livello di spazio di tabella, essa è o completamente crittografata o non lo è affatto. Cioè, non è possibile crittografare solo parte delle tabelle nello spazio di tabella principale.
Se per qualche motivo hai disattivato file-per-table, tutte le tabelle vengono create all'interno dello spazio di tabella di sistema (system tablespace). In è possibile crittografare lo spazio di tabella di sistema utilizzando la variabile innodbsystablespaceencrypt o utilizzando thread di crittografia (encryption threads), ma questa è ancora una funzione sperimentale. In MySQL non è presente.
Prima di procedere, dobbiamo esaminare la struttura dell'identificatore della chiave principale (master key ID). È costituita da UUID, KEYID e dal prefisso "INNODBKey". Appare in questo modo: INNODBKey-UUID-KEYID.
UUID è l'uuid del server con lo spazio di tabella crittografato. KEYID è semplicemente un valore che cresce costantemente. Durante la creazione iniziale della chiave principale, il KEYID è pari a 1. Durante la rotazione della chiave, quando viene creata una nuova chiave principale, il KEYID = 2 e così via. Parleremo più dettagliatamente della rotazione delle chiavi principali nei prossimi articoli di questa serie.
Ora che sappiamo come appare l'identificatore della chiave principale, diamo un'occhiata all'intestazione dello spazio di tabella crittografato. Quando lo spazio di tabella viene crittografato, le informazioni sulla crittografia vengono aggiunte all'intestazione. Appare nel seguente modo:
KEY ID è il KEYID dall'identificatore della chiave principale che abbiamo già discusso. UUID è l'uuid del server, che viene utilizzato anche nell'identificatore della chiave principale. TABLESPACE KEY è la chiave dello spazio di tabella, che consiste in 256 bit generati casualmente dal server. Il vettore di inizializzazione (IV, initialization vector) consiste anch'esso di 256 bit generati casualmente (anche se dovrebbe essere 128 bit). L'IV è utilizzato per inizializzare la crittografia e la decrittografia AES (di 256 bit vengono utilizzati solo 128). Infine, è presente una somma di controllo CRC32 per il TABLESPACE KEY e l'IV.
Tutto questo tempo ho semplificato, dicendo che nell'intestazione c'è una chiave crittografata dello spazio di tabella. In realtà, la chiave dello spazio di tabella e il vettore di inizializzazione sono memorizzati e crittografati insieme utilizzando la chiave principale. Ricorda che prima di crittografare la chiave dello spazio di tabella e il vettore di inizializzazione, per essi viene calcolato il CRC32.
A cosa serve il CRC32?
In breve, per verificare la validità della chiave principale. Dopo la decodifica della chiave dello spazio tabellare e del vettore di inizializzazione, viene calcolata la somma di controllo e confrontata con il CRC32 memorizzato nell'intestazione. Se le somme di controllo coincidono, abbiamo la chiave principale corretta e la chiave dello spazio tabellare. In caso contrario, lo spazio tabellare viene contrassegnato come mancante (non saremo comunque in grado di decodificarlo).
Puoi chiederti: in quale momento viene effettuato il controllo delle chiavi? La risposta è: all'avvio del server. Il server con tabelle / spazi tabellari crittografati legge il UUID, la KEYID dall'intestazione e genera l'identificatore della chiave principale. Successivamente ottiene la chiave principale necessaria dal deposito (keyring), decodifica la chiave dello spazio tabellare e verifica la somma di controllo. Ancora una volta, se la somma di controllo coincide, tutto è a posto, altrimenti lo spazio tabellare viene contrassegnato come mancante.
Se hai letto il precedente articolo di questa serie (), potresti ricordare che quando si utilizza un deposito di chiavi server, al momento dell'avvio il server ottiene solo l'elenco degli identificatori delle chiavi, precisamente, key id e user id, poiché questa coppia identifica in modo univoco la chiave. E adesso dico che il server al momento dell'avvio ottiene tutte le chiavi necessarie per controllare la possibilità di decodificare le chiavi degli spazi tabellari. Perché quindi, all'inizializzazione, nel caso del deposito server, vengono caricati solo keyid e userid, e non tutte le chiavi? Perché potrebbero non servirti tutte le chiavi. Questo è principalmente legato alla rotazione della chiave principale. Durante la rotazione della chiave principale, viene creata una nuova chiave principale nel deposito, ma le chiavi vecchie non vengono rimosse. Pertanto, nel deposito del server potrebbero esserci molte chiavi inutili per il server e, di conseguenza, non vengono estratte all'avvio del server.
È giunto il momento di parlare un po' dei vantaggi e degli svantaggi della crittografia utilizzando una chiave master. Il principale vantaggio è che hai bisogno di una sola chiave di crittografia (la chiave master), che sarà conservata separatamente dai tuoi dati crittografati. Questo rende veloce l'avvio del server e lo storage ridotto, facilitando la gestione. Inoltre, è facile rigenerare la singola chiave master.
Tuttavia, la crittografia tramite chiave master ha un grande svantaggio: una volta che lo spazio di tabella è crittografato con tablespace_key, rimane sempre crittografato con la stessa chiave. La rotazione della chiave master non è d'aiuto qui. Perché è uno svantaggio? Sappiamo che in MySQL ci sono bug che possono causare crash improvvisi e la creazione di un file di core. Poiché il file di core contiene un dump della memoria del server, potrebbe succedere che nel dump sia presente la chiave decifrata dello spazio di tabella. Ancora peggio, le chiavi decifrate dello spazio di tabella sono memorizzate in memoria, che potrebbe essere scambiata su disco. Potresti dire che non è uno svantaggio, dato che hai bisogno dei privilegi di root per accedere a questi file e alla partizione di swap. È vero. Ma il root è necessario solo per un certo periodo. Una volta che qualcuno ottiene accesso alla chiave decifrata dello spazio di tabella, può continuare a usarla per decifrare i dati, anche senza privilegi di root. Inoltre, il disco potrebbe essere rubato e la partizione di swap / i file di core possono essere letti tramite strumenti di terze parti. L'obiettivo del TDE è renderlo illeggibile anche se il disco viene rubato. c'è la possibilità di rieseguire la crittografia dello spazio di tabella con nuove chiavi generate. Questa funzione è nota come thread di crittografia (encryption threads) ed è ancora sperimentale al momento della scrittura di questo articolo.
Leggi anche:
Fonte: habr.com
