In vista dell'inizio di un nuovo ciclo del corso continuiamo a pubblicare una serie di articoli sulla crittografia in MySQL.
Nell'articolo precedente di questa serie () abbiamo parlato dei portafogli delle chiavi. In questo articolo vedremo come viene utilizzata la chiave principale (master key) e discuteremo i pro e i contro della crittografia tramite buste (envelope encryption).
L'idea della crittografia tramite buste è che le chiavi utilizzate per la crittografia (le chiavi degli spazi delle tabelle) sono crittografate con un'altra chiave (la chiave principale, master key). Per crittografare i dati si utilizzano effettivamente le chiavi degli spazi delle tabelle. Graficamente, può essere rappresentato in questo modo:
La chiave principale (master key) si trova nel portafoglio delle chiavi (keyring), mentre le chiavi degli spazi delle tabelle sono negli header delle tabelle crittografate (sulla pagina 0 dello spazio delle tabelle).
Nell'immagine sopra:
La Tabella A è crittografata con la chiave 1 (Key 1). La chiave 1 è crittografata con la chiave principale (master key) e conservata in forma crittografata nell'header della Tabella A.
La Tabella B è crittografata con la chiave 2 (Key 2). La chiave 2 è crittografata con la chiave principale (master key) e conservata in forma crittografata nell'header della Tabella B.
E così via.
Quando un server deve decifrare la tabella A, ottiene la chiave principale dallo storage, legge la chiave crittografata 1 dall'intestazione della tabella A e decifra la chiave 1. La chiave decifrata 1 viene memorizzata nella cache della memoria del server e utilizzata per decifrare la tabella A.
InnoDB
In InnoDB, la crittografia e la decrittografia effettive avvengono a livello di input/output. Ciò significa che la pagina viene crittografata immediatamente prima di essere scritta su disco e decrittografata immediatamente dopo essere stata letta dal disco.
In InnoDB, la crittografia funziona solo a livello di tablespace. E per impostazione predefinita, tutte le tabelle sono create in spazi di tabella separati (). In altre parole, viene creato uno spazio di tabella che può contenere solo una tabella. Anche se è possibile creare tabelle anche nello spazio tabella generale (). Tuttavia, in qualsiasi caso, la tabella si trova sempre all'interno di uno spazio tabellare. E poiché la crittografia avviene a livello di spazio tabellare, è completamente crittografata o non lo è affatto. Non è possibile crittografare solo alcune tabelle all'interno dello spazio tabellare principale.
Se per qualche motivo file-per-table è disabilitato, tutte le tabelle vengono create all'interno dello spazio tabellare di sistema (system tablespace). In è possibile crittografare lo spazio tabellare di sistema utilizzando la variabile innodbsystablespaceencrypt o tramite flussi 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). Esso consiste in UUID, KEYID e nel prefisso «INNODBKey». Si presenta così: INNODBKey-UUID-KEYID.
UUID è l'uuid del server con lo spazio tabellare crittografato. KEYID è semplicemente un valore che aumenta continuamente. Quando viene creato inizialmente, KEYID è uguale a 1. Durante la rotazione della chiave, quando viene creato un nuovo master key, KEYID = 2 e così via. Parleremo più nel dettaglio della rotazione delle chiavi primarie nei prossimi articoli di questa serie.
Ora che sappiamo come appare l'identificatore della chiave primaria, diamo un'occhiata all'intestazione dello tablespace criptato. Quando lo tablespace è crittografato, le informazioni sulla crittografia vengono aggiunte all'intestazione. Questo è come appare:
KEY ID — è la KEYID dell'identificatore della chiave primaria di cui abbiamo già discusso. UUID è l'uuid del server, che viene utilizzato anche nell'identificatore della chiave primaria. TABLESPACE KEY — la chiave dello tablespace, composta da 256 bit generati casualmente dal server. Il vettore di inizializzazione (IV, initialization vector) è anch'esso composto da 256 bit generati casualmente (anche se dovrebbe essere di 128 bit). L'IV viene utilizzato per l'inizializzazione della crittografia e della decrittografia AES (da 256 bit vengono utilizzati solo 128). Alla fine è presente un checksum CRC32 per il TABLESPACE KEY e l'IV.
Fino ad ora ho semplificato un po', dicendo che nell'intestazione si trova una chiave cifrata dello spazio tabelle. In realtà, la chiave dello spazio tabelle e il vettore di inizializzazione sono memorizzati e cifrati insieme mediante una chiave principale. Ricordate che prima della cifratura della chiave dello spazio tabelle e del vettore di inizializzazione, viene calcolato CRC32.
A cosa serve il CRC32?
In poche parole, serve a garantire la validità della chiave principale. Dopo che la chiave dello spazio tabelle e il vettore di inizializzazione sono stati decrittografati, viene calcolata una 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 tabelle. Altrimenti, lo spazio tabelle viene contrassegnato come mancante (non saremo comunque in grado di decrittografarlo).
Potreste chiedere: a quale punto vengono verificati i tasti? La risposta è: all'avvio del server. Un server con tabelle cifrate / spazi tabelle legge il UUID, la chiave all'avvio.L'ID dall'intestazione genera un identificatore principale. Successivamente, ottiene la chiave principale necessaria dal keyring, decrittografa la chiave dello spazio di tabella e verifica la somma di controllo. Ancora una volta, se la somma di controllo corrisponde, tutto è a posto; in caso contrario, lo spazio di tabella viene contrassegnato come mancante.
Se hai letto il precedente articolo di questa serie (), potresti ricordare che, quando si utilizza un server di memorizzazione chiavi, il server all'avvio riceve solo un elenco di identificatori chiave, più precisamente, key id e user id, poiché questa coppia identifica inequivocabilmente la chiave. E ora dico che il server all'avvio riceve tutte le chiavi necessarie per verificare la possibilità di decrittografare le chiavi degli spazi di tabella. Quindi, perché durante l'inizializzazione, nel caso di un'archiviazione di server, vengono caricati solo keyid e userid, e non tutte le chiavi? Perché potresti non aver bisogno di tutte le chiavi. Questo è principalmente legato alla rotazione della chiave principale. Quando la chiave principale viene ruotata, viene creata una nuova chiave principale nel vault, ma le chiavi esistenti non vengono eliminate. In questo modo, nel vault del server potrebbero esserci molte chiavi che non servono al server e quindi non vengono estratte all'avvio del server.
È tempo di parlare un po' dei vantaggi e degli svantaggi della crittografia utilizzando la chiave principale. Il principale vantaggio è che hai bisogno solo di una chiave di crittografia (la chiave principale), che sarà conservata separatamente dai tuoi dati crittografati. Questo rende l'avvio del server rapido e il vault di dimensioni contenute, facilitando la gestione. Inoltre, l'unica chiave principale è facile da rigenerare.
Tuttavia, la crittografia con la chiave principale ha un grande svantaggio: una volta che lo spazio di tabella è crittografato con la tablespace_key, rimane sempre crittografato con la stessa chiave. La rotazione della chiave principale non aiuta in questo caso. Perché è uno svantaggio? Sappiamo che in MySQL ci sono bug che possono portare a un arresto improvviso e alla creazione di un file core. Poiché il file core contiene un dump della memoria del server, può succedere che nel dump ci sia la chiave di spazio tabella decrittografata. Peggio ancora, le chiavi decrittografate dello spazio tabella vengono memorizzate in memoria, che può essere scambiata su disco. Potresti dire che non è uno svantaggio, in quanto sono necessari i diritti di root per accedere a questi file e alla partizione di swap. Sì. Ma i diritti di root sono necessari solo per un certo periodo. Una volta che qualcuno riesce ad accedere alla chiave decrittografata dello spazio tabella, potrà continuare a utilizzarla per decrittografare i dati, anche senza diritti di root. Inoltre, il disco può essere rubato e la partizione di swap/file core possono essere letti con strumenti di terze parti. L'obiettivo del TDE è renderlo illeggibile, anche se il disco viene rubato. è possibile rieseguire la crittografia dello spazio tabellare con nuove chiavi generate. Questa funzione è chiamata thread di crittografia (encryption threads) ed è ancora sperimentale al momento della scrittura di questo articolo.
Leggi di più:
Fonte: habr.com
