In attesa dell'inizio di una nuova iscrizione al corso continuiamo a pubblicare una serie di articoli sulla crittografia in MySQL.
Nel precedente articolo di questa serie () abbiamo parlato di keystore. In questo articolo, esamineremo come viene utilizzata la chiave principale e discuteremo i vantaggi e gli svantaggi della crittografia della busta.
L'idea alla base della crittografia della busta è che le chiavi utilizzate per la crittografia (chiavi tablespace) sono crittografate con un'altra chiave (la chiave principale). Le chiavi tablespace vengono effettivamente utilizzate per crittografare i dati. Graficamente, questo può essere rappresentato come segue:
La chiave principale si trova nel keystore e le chiavi del tablespace si trovano nelle intestazioni dei tablespace crittografati (a pagina 0 del tablespace).
Nella foto sopra:
La tabella A è crittografata con la chiave 1 (Chiave 1). La chiave 1 viene crittografata utilizzando la chiave principale e memorizzata crittografata nell'intestazione della tabella A.
La tabella B è crittografata con la chiave 2 (Chiave 2). La chiave 2 viene crittografata utilizzando la chiave maschera e memorizzata crittografata nell'intestazione della tabella B.
E così via.
Quando il server deve decrittografare la tabella A, ottiene la chiave master dall'archivio, legge la chiave crittografata 1 dall'intestazione della tabella A e decrittografa la chiave 1. La chiave decrittografata 1 viene memorizzata nella cache del server e utilizzata per decrittografare la tabella A .
InnoDB
In InnoDB, la crittografia e la decrittografia effettive vengono eseguite a livello di I/O. Cioè, la pagina viene crittografata appena prima di essere scaricata 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 vengono create in tablespace separati (). In altre parole, viene creato un tablespace che può contenere solo una tabella. Sebbene sia possibile creare tabelle anche nel tablespace principale (). Ma in ogni caso, il tavolo è sempre in qualche tablespace. E poiché la crittografia viene eseguita a livello di tablespace, è completamente crittografata o meno. Cioè, non puoi crittografare solo una parte delle tabelle nel tablespace principale.
Se per qualche motivo hai disabilitato file per tabella, tutte le tabelle vengono create all'interno del tablespace di sistema. IN puoi crittografare il tablespace di sistema usando la variabile innodbsysspazio tabellacrittografare o utilizzare thread di crittografia, ma questa è ancora una funzionalità sperimentale. MySQL non ha questo.
Prima di andare avanti, dobbiamo considerare la struttura dell'ID della chiave master. Consiste di UUID, KEYID e prefisso "INNODBKey". Assomiglia a questo: INNODBKey-UUID-KEYID.
L'UUID è l'uuid del server con il tablespace crittografato. chiaveL'ID è solo un valore in continua crescita. Quando crei per la prima volta una chiave master KEYL'ID è 1. Durante la rotazione della chiave, quando viene creata una nuova chiave master, KEYID = 2 e così via. Parleremo di più sulla rotazione della chiave principale negli articoli successivi di questa serie.
Ora che sappiamo come appare l'identificatore della chiave principale, diamo un'occhiata all'intestazione del tablespace crittografato. Quando un tablespace viene crittografato, le informazioni sulla crittografia vengono aggiunte all'intestazione. Sembra così:
KEYID è CHIAVEL'ID dall'ID della chiave principale di cui abbiamo già discusso. L'UUID è l'uuid del server ed è utilizzato anche nell'identificatore della chiave master. TABLESPACE KEY - chiave tablespace, composta da 256 bit, generata casualmente dal server. Anche il vettore di inizializzazione (IV, vettore di inizializzazione) consiste di 256 bit generati casualmente (sebbene dovrebbe essere di 128 bit). IV viene utilizzato per inizializzare la crittografia e la decrittografia AES (su 256 bit, ne vengono utilizzati solo 128). Alla fine c'è un checksum CRC32 per TABLESPACE KEY e IV.
Per tutto questo tempo ho semplificato un po' dicendo che c'è una chiave tablespace crittografata nell'intestazione. Infatti, la chiave del tablespace e il vettore di inizializzazione vengono archiviati e crittografati insieme utilizzando la chiave master. Ricorda che prima che la chiave del tablespace e il vettore di inizializzazione vengano crittografati, CRC32 viene calcolato per loro.
Perché è necessario CRC32?
In poche parole, per assicurarsi che la chiave principale sia valida. Dopo aver decrittografato la chiave del tablespace e il vettore di inizializzazione, viene calcolato un checksum e confrontato con il CRC32 memorizzato nell'intestazione. Se i checksum corrispondono, abbiamo la chiave master e la chiave del tablespace corrette. In caso contrario, il tablespace viene contrassegnato come mancante (non è ancora possibile decrittografarlo).
Potresti chiedere: a che punto viene eseguita la verifica delle chiavi? La risposta è quando il server si avvia. Il server con tabelle/spazi tabella crittografati legge UUID, KEY all'avvioID dall'intestazione e genera un ID chiave master. Quindi ottiene la chiave master richiesta dal keyring, decrittografa la chiave del tablespace e verifica il checksum. Ancora una volta, se il checksum corrisponde, allora è tutto in ordine, no: il tablespace è contrassegnato come mancante.
Se leggi l'ultimo articolo di questa serie (), quindi forse ricorda che quando si utilizza un archivio di chiavi del server, il server riceve solo un elenco di identificatori di chiave all'avvio, più precisamente, id chiave e id utente, poiché questa coppia identifica in modo univoco la chiave. Quello che sto dicendo ora è che il server, all'avvio, ottiene tutte le chiavi di cui ha bisogno per verificare che le chiavi del tablespace possano essere decifrate. Allora perché, durante l'inizializzazione, nel caso dell'archiviazione del server, viene caricata solo la chiaveid e utenteid e non tutte le chiavi? Perché potresti non aver bisogno di tutte le chiavi. Ciò è dovuto principalmente alla rotazione della chiave principale. Quando una chiave master viene ruotata nel vault, viene creata una nuova chiave master, ma le vecchie chiavi non vengono eliminate. Pertanto, potresti avere molte chiavi nel keystore del server che non sono necessarie al server e quindi non recuperate all'avvio del server.
È ora di parlare un po' dei vantaggi e degli svantaggi della crittografia utilizzando una chiave master. Il più grande vantaggio è che hai solo bisogno di una chiave di crittografia (la chiave principale), che verrà tenuta separata dai tuoi dati crittografati. Ciò rende l'avvio del server rapido e lo spazio di archiviazione ridotto, semplificando la gestione. E anche l'unica chiave master è facile da rigenerare.
Tuttavia, la crittografia della chiave master ha un grosso svantaggio: una volta che un tablespace è crittografato con tablespace_key, rimane sempre crittografato con la stessa chiave. La rotazione della chiave principale non aiuta qui. Perché questo è uno svantaggio? Sappiamo che MySQL ha bug che possono causarne l'arresto anomalo e creare un file core. Poiché il file principale contiene un dump della memoria del server, può accadere che il dump contenga la chiave del tablespace decrittografata. Ancora peggio, le chiavi del tablespace decrittografate vengono archiviate in memoria, che può essere trasferita su disco. Puoi dire che questo non è uno svantaggio poiché hai bisogno dei permessi di root per accedere a questi file e alla partizione di swap. SÌ. Ma root è necessario solo per un po'. Una volta che qualcuno ha accesso alla chiave del tablespace decrittografata, può continuare a utilizzarla per decrittografare i dati, anche senza accesso root. Inoltre, il disco può essere rubato e i file swap / core possono essere letti utilizzando strumenti di terze parti. L'obiettivo di TDE è renderlo illeggibile anche se il disco viene rubato. IN è possibile crittografare nuovamente il tablespace con chiavi appena generate. Questa funzione è chiamata thread di crittografia ed è ancora sperimentale al momento della stesura di questo documento.
Per saperne di più:
Fonte: habr.com
