V předvečer zahájení nového zápisu do kurzu pokračujeme v publikování série článků o šifrování v MySQL.
V předchozím článku této série () jsme hovořili o úložištích klíčů. V tomto článku se zaměříme na to, jak se používá hlavní klíč, a také prodiskutujeme výhody a nevýhody šifrování metodou obálek.
Myšlenka šifrování obálek spočívá v tom, že klíče používané pro šifrování (klíče tabulkových prostorů) jsou šifrovány dalším klíčem (hlavním klíčem). Pro šifrování dat se ve skutečnosti používají klíče tabulkových prostorů. Graficky to lze představit takto:
Hlavní klíč se nachází v úložišti klíčů, zatímco klíče tabulkových prostorů jsou v záhlaví zašifrovaných tabulkových prostorů (na stránce 0 tabulkového prostoru).
Na obrázku výše:
Tabulka A je zašifrována klíčem 1. Klíč 1 je šifrován pomocí hlavního klíče a uchováván v zašifrované podobě v záhlaví tabulky A.
Tabulka B je zašifrována klíčem 2. Klíč 2 je šifrován pomocí hlavního klíče a uchováván v zašifrované podobě v záhlaví tabulky B.
A tak dále.
Když server potřebuje dešifrovat tabulku A, získá hlavní klíč z úložiště, přečte zašifrovaný klíč 1 ze záhlaví tabulky A a dešifruje klíč 1. Dešifrovaný klíč 1 je uložen v cache paměti serveru a používá se pro dešifrování tabulky A.
InnoDB
V InnoDB se skutečné šifrování a dešifrování provádí na úrovni vstupů a výstupů. Tedy stránka je šifrována těsně před tím, než je zapsána na disk, a dešifrována ihned po přečtení z disku.
V InnoDB šifrování funguje pouze na úrovni tabulkových prostorů. A ve výchozím nastavení jsou všechny tabulky vytvářeny ve vlastních tabulkových prostorech (). Jinými slovy, se vytváří tabulkový prostor, který může obsahovat pouze jednu tabulku. I když je také možné vytvářet tabulky v hlavním tabulkovém prostoru (). Ale v každém případě je tabulka vždy v nějakém tabulkovém prostoru. A jelikož se šifrování provádí na úrovni tabulkového prostoru, je buď zcela zašifrováno, nebo není. To znamená, že není možné zašifrovat pouze část tabulek ve hlavním tabulkovém prostoru.
Pokud je z jakéhokoli důvodu deaktivována možnost file-per-table, všechny tabulky budou vytvořeny v rámci systémového tabulkového prostoru (system tablespace). Můžete zašifrovat systémový tabulkový prostor pomocí proměnné innodbsystablespaceencrypt nebo pomocí šifrovacích vláken (encryption threads), ale to je stále experimentální funkce. MySQL to nenabízí.
Než se posuneme dál, je třeba si prohlédnout strukturu identifikátoru hlavního klíče (master key ID). Ten se skládá z UUID, KEYID a prefixu „INNODBKey“. Vypadá to takto: INNODBKey-UUID-KEYID.
UUID je uuid serveru se zašifrovaným tabulkovým prostorem. KEYID je prostě neustále zvyšující se hodnota. Při prvotním vytvoření hlavního klíče KEYID je rovno 1. Při rotaci klíče, kdy je vytvořen nový hlavní klíč, KEYID = 2 a tak dále. Podrobněji se o rotaci hlavních klíčů budeme bavit v následujících článcích této série.
Nyní když víme, jak vypadá identifikátor hlavního klíče, podívejme se na hlavičku zašifrovaného tabulkového prostoru. Když je tabulkový prostor šifrován, informace o šifrování se přidávají k hlavičce. Vypadá to takto:
KEY ID je KEYID z identifikátoru hlavního klíče, o kterém jsme již diskutovali. UUID je uuid serveru, který se také používá v identifikátoru hlavního klíče. TABLESPACE KEY je klíč tabulkového prostoru, který se skládá ze 256 bitů náhodně generovaných serverem. Inicializační vektor (IV, initialization vector) také sestává z 256 náhodně generovaných bitů (přičemž by měl být 128 bitů). IV se používá pro inicializaci šifrování a dešifrování AES (ze 256 bitů se používá pouze 128). Na konci je přítomna kontrolní suma CRC32 pro TABLESPACE KEY a IV.
Po celou dobu jsem poněkud zjednodušoval, když jsem říkal, že v hlavičce je zašifrovaný klíč tabulkového prostoru. Ve skutečnosti jsou klíč tabulkového prostoru a inicializační vektor uchovávány a šifrovány spolu pomocí hlavního klíče. Nezapomeňte, že před šifrováním klíče tabulkového prostoru a inicializačního vektoru se pro ně počítá CRC32.
Proč je potřeba CRC32?
Pokud to shrneme, validita hlavního klíče se kontroluje následujícím způsobem. Po dešifrování klíče tabulkového prostoru a iniciačního vektoru se vypočítá kontrolní součet, který se porovná s CRC32 uloženým v hlavičce. Pokud se kontrolní součty shodují, máme správný hlavní klíč a klíč tabulkového prostoru. V opačném případě se tabulkový prostor označí jako neexistující (nemůžeme jej dešifrovat).
Můžete se ptát: v jakém okamžiku probíhá kontrola klíčů? Odpověď zní — při spuštění serveru. Server se zašifrovanými tabulkami / tabulkovými prostory při startu čte UUID, KEYID z hlavičky a generuje identifikátor hlavního klíče. Poté získá potřebný hlavní klíč ze skladu (keyring), dešifruje klíč tabulkového prostoru a kontroluje kontrolní součet. Ještě jednou, pokud se kontrolní součet shoduje, vše je v pořádku; pokud ne, tabulkový prostor se označí jako neexistující.
Pokud jste četli předchozí článek této série (), možná si pamatujete, že při používání serverového skladu klíčů server při spuštění získává pouze seznam identifikátorů klíčů, konkrétně key id a user id, protože tato dvojice jednoznačně identifikuje klíč. A nyní říkám, že server při spuštění získává všechny klíče potřebné k ověření možnosti dešifrování klíčů tabulkových prostorů. Tak proč se při inicializaci, v případě serverového skladu, načítají pouze keyid a userid, a ne všechny klíče? Protože všechny klíče nemusíte mít. To většinou souvisí s rotací hlavního klíče. Při rotaci hlavního klíče se v skladu vytvoří nový hlavní klíč, ale staré klíče se nemažou. Takže v serverovém skladu klíčů můžete mít mnoho klíčů, které server nepotřebuje, a proto se při spuštění serveru nevytahují.
Nastal čas trochu promluvit o výhodách a nevýhodách šifrování pomocí hlavního klíče. Největší výhodou je, že potřebujete pouze jeden šifrovací klíč (hlavní klíč), který bude uchováván odděleně od vašich zašifrovaných dat. To zrychluje spouštění serveru a snižuje velikost úložiště, což usnadňuje správu. Navíc je snadné znovu vygenerovat jediný hlavní klíč.
Šifrování pomocí hlavního klíče má však jeden velký nedostatek: jakmile je tabulkový prostor zašifrován pomocí tablespace_key, zůstává vždy zašifrován stejným klíčem. Rotace hlavního klíče zde nepomůže. Proč je to nevýhoda? Víme, že v MySQL jsou chyby, které mohou vést k náhlému selhání a vytvoření core souboru. Jelikož core soubor obsahuje dump paměti serveru, je možné, že v dumpu bude dešifrovaný klíč tabulkového prostoru. Co je horší, dešifrované klíče tabulkového prostoru se uchovávají v paměti, která může být stránkována na disk. Můžete tvrdit, že to není nedostatek, protože pro přístup k těmto souborům a stránce podswapu jsou potřebná práva root. Ano, ale root je potřeba jen na chvíli. Jakmile se někdo dostane k dešifrovanému klíči tabulkového prostoru, může ho nadále používat pro dešifrování dat i bez práv root. Navíc disk může být ukraden a oddíl podswapu/core soubory lze přečíst pomocí třetích stran. Cílem TDE je zajistit, aby byl irelevantní, i když bude disk ukraden. existuje možnost opětovného šifrování tabulkového prostoru s nově vygenerovanými klíči. Tato funkce se nazývá šifrovací vlákna (encryption threads) a v době psaní tohoto článku je stále experimentální.
Číst víc:
Zdroj: habr.com
