Šifrovanie v MySQL: použitie Master Key

Pred spustením nového kurzu „Databázy“ pokračujeme v publikovaní série článkov o šifrovaní v MySQL.

V predchádzajúcom článku tejto série (Šifrovanie v MySQL: úložisko kľúčov) sme hovorili o úložiskách kľúčov. V tomto článku sa pozrieme, ako sa používa hlavný kľúč (master key) a prediskutujeme výhody a nevýhody šifrovania metódou obálok (envelope encryption). 

Myšlienka šifrovania obálok spočíva v tom, že kľúče používané na šifrovanie (kľúče tabuľkových priestorov) sú šifrované iným kľúčom (hlavným kľúčom, master key). Na šifrovanie údajov sa v skutočnosti používajú kľúče tabuľkových priestorov. Graficky to môžeme predstaviť takto:

Hlavný kľúč (master key) sa nachádza v úložisku kľúčov (keyring) a kľúče tabuľkových priestorov sú v hlavičkách zašifrovaných tabuľkových priestorov (na stránke 0 tabuľkového priestoru). 

Na obrázku vyššie:

• Tabuľka A je zašifrovaná kľúčom 1 (Key 1). Kľúč 1 sa šifruje pomocou hlavného kľúča (master key) a uchováva sa v zašifrovanej podobe v hlavičke tabuľky A.

• Tabuľka B je zašifrovaná kľúčom 2 (Key 2). Kľúč 2 sa šifruje pomocou hlavného kľúča (master key) a uchováva sa v zašifrovanej podobe v hlavičke tabuľky B.

• A tak ďalej.

Keď server potrebuje dešifrovať tabuľku A, získa hlavný kľúč z úložiska, prečíta zašifrovaný kľúč 1 z hlavičky tabuľky A a dešifruje kľúč 1. Dešifrovaný kľúč 1 sa ukladá do cache pamäte servera a používa sa na dešifrovanie tabuľky A.

InnoDB

V InnoDB sa skutočné šifrovanie a dešifrovanie vykonáva na úrovni vstupu/výstupu. Teda stránka sa šifruje priamo predtým, ako sa zapisuje na disk, a dešifruje sa hneď po načítaní z disku.

V InnoDB šifrovanie funguje iba na úrovni tabuľkových priestorov. A predvolene sú všetky tabuľky vytvárané v samostatných tabuľkových priestoroch (file-per-table tablespace). Inými slovami, vytvára sa tabuľkový priestor, ktorý môže obsahovať iba jednu tabuľku. Aj keď môžete vytvárať tabuľky aj v hlavnom tabuľkovom priestore (general tablespace). V každom prípade však tabuľka vždy existuje v nejakom tabuľkovom priestore. A keďže šifrovanie sa vykonáva na úrovni tabuľkového priestoru, môže byť buď úplne zašifrované, alebo nie. To znamená, že nie je možné zašifrovať iba časť tabuliek v hlavnom tabuľkovom priestore. 

Ak máte z nejakého dôvodu vypnutú funkciu file-per-table, všetky tabuľky sa vytvárajú v rámci systémového tabuľkového priestoru (system tablespace). V Percona Server for MySQL môžete zašifrovať systémový tabuľkový priestor pomocou premennej innodbsystablespaceencrypt alebo pomocou šifrovacích vláken (encryption threads), ale to je stále experimentálna funkcia. V MySQL to nie je.

Predtým, než pôjdeme ďalej, je potrebné preskúmať štruktúru identifikátora hlavného kľúča (master key ID). Skladá sa z UUID, KEYID a predpony „INNODBKey“. Vyzerá to takto: INNODBKey-UUID-KEYID.

UUID je uuid servera so zašifrovaným tabuľkovým priestorom. KEYID je len neustále sa zvyšujúca hodnota. Pri prvotnom vytvorení hlavného kľúča je KEYID rovné 1. Pri rotácii kľúča, keď sa vytvorí nový hlavný kľúč, KEYID = 2 a tak ďalej. O rotácii hlavných kľúčov budeme podrobnejšie hovoriť v nasledujúcich článkoch tejto série.

Teraz, keď vieme, aký je identifikátor hlavného kľúča, pozrime sa na hlavičku zašifrovaného tabuľkového priestoru. Keď sa tabuľkový priestor šifruje, informácie o šifrovaní sa pridávajú k hlavičke. Vyzerá to nasledovne:

KEY ID je KEYID z identifikátora hlavného kľúča, ktorý sme už preberali. UUID je uuid servera, ktorý sa tiež používa v identifikátore hlavného kľúča. TABLESPACE KEY je kľúč tabuľkového priestoru, ktorý sa skladá z 256 bitov náhodne generovaných serverom. Iniciačný vektor (IV, initialization vector) sa tiež skladá z 256 náhodne generovaných bitov (aj keď by mal byť 128 bitov). IV sa používa na inicializáciu šifrovania a dešifrovania AES (z 256 bitov sa používa len 128). Na konci je prítomná kontrolná suma CRC32 pre TABLESPACE KEY a IV.

Celý čas som to trochu zjednodušoval, keď som hovoril, že v hlavičke je zašifrovaný kľúč tabuľkového priestoru. V skutočnosti sú kľúč tabuľkového priestoru a iniciačný vektor uložené a šifrované spolu pomocou hlavného kľúča. Pamätajte, že pred šifrovaním kľúča tabuľkového priestoru a iniciačného vektora sa pre nich vypočítava CRC32.

Na čo je CRC32 dobré?

Ak v dvoch slovách, aby ste sa uistili o platnosti hlavného kľúča. Po dešifrovaní kľúča tabuľkového priestoru a inicializačného vektora sa vypočíta kontrolná suma a porovná s CRC32 uloženým v hlavičke. Ak sa kontrolné sumy zhodujú, máme správny hlavný kľúč a kľúč tabuľkového priestoru. V opačnom prípade je tabuľkový priestor označený ako chýbajúci (aj tak ho nebudeme môcť dešifrovať).

Môžete sa pýtať: kedy sa kontrola kľúčov vykonáva? Odpoveď — pri spustení servera. Server so šifrovanými tabuľkami / tabuľkovými priestorami pri štarte načíta UUID, KEYID z hlavičky a generuje identifikátor hlavného kľúča. Potom získa potrebný hlavný kľúč z úložiska (keyring), dešifruje kľúč tabuľkového priestoru a kontroluje kontrolnú sumu. Ešte raz, ak sa kontrolná suma zhoduje, potom je všetko v poriadku, ak nie — tabuľkový priestor je označený ako chýbajúci.

Ak ste čítali predchádzajúci článok tejto série (Šifrovanie v MySQL: úložisko kľúčov), možno si pamätáte, že pri použití serverového úložiska kľúčov server pri spustení dostáva iba zoznam identifikátorov kľúčov, presnejšie, key id a user id, pretože táto dvojica jednoznačne identifikuje kľúč. A teraz hovorím, že server pri spustení dostáva všetky kľúče, ktoré potrebuje na overenie možnosti dešifrovania kľúčov tabuľkových priestorov. Tak prečo pri inicializácii, v prípade serverového úložiska, načítavajú iba keyid a userid, a nie všetky kľúče? Pretože vám nemusia byť potrebné všetky kľúče. Hlavne to súvisí s rotáciou hlavného kľúča. Pri rotácii hlavného kľúča sa v úložisku vytvorí nový hlavný kľúč, ale staré kľúče nie sú odstraňované. Takto môže byť v serverovom úložisku kľúčov veľa kľúčov, ktoré server nepotrebuje a preto sa pri spustení servera nevytiahnu.

Je čas trochu pohovořit 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 uložen odděleně od vašich zašifrovaných dat. To urychluje spuštění serveru a zmenšuje úložiště, což usnadňuje správu. A také, jediný hlavní klíč lze snadno znovu vygenerovat.

Šifrování pomocí hlavního klíče však má jednu velkou nevýhodu: jakmile je tabulkový prostor zašifrován pomocí tablespace_key, vždy zůstává šifrován stejným klíčem. Rotace hlavního klíče zde nepomáhá. Proč je to nevýhoda? Víme, že v MySQL existují chyby, které mohou vést k náhlému selhání a vytvoření core souboru. Protože core soubor obsahuje dump paměti serveru, může se stát, že v dumpu bude dešifrovaný klíč tabulkového prostoru. Co je ještě horší, dešifrované klíče tabulkového prostoru se ukládají do paměti, která může být swapována na disk. Můžete říct, že to není nevýhoda, protože potřebujete root práva k přístupu k těmto souborům a swapové oblasti. Ano. Ale root je potřeba jen na chvíli. Jakmile někdo získá přístup k dešifrovanému klíči tabulkového prostoru, může pokračovat v jeho používání pro dešifrování dat, i když nemá root práva. Navíc může být disk ukraden, a swapové oblasti / core soubory lze číst pomocí třetích stran. Cílem TDE je učinit je nečitelnými, i když bude disk ukraden. Percona Server for MySQL 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í.

Zistiť viac o kurze

Čítať ďalej:

• Šifrovanie v MySQL: úložisko kľúčov

Zdroj: habr.com