Uoči početka novog upisa na tečaj nastavljamo s objavljivanjem serije članaka o šifriranju u MySQL-u.
U prethodnom članku ove serije () razgovarali smo o skladištima ključeva. U ovom članku razmotrit ćemo kako se koristi glavni ključ, kao i raspraviti prednosti i nedostatke šifriranja metodom omota (envelope encryption).
Ideja šifriranja omota je da se ključevi korišteni za šifriranje (ključevi tabličnih prostora) šifriraju drugim ključem (glavnim ključem). Ključevi tabličnih prostora se zapravo koriste za šifriranje podataka. Grafički se to može prikazati ovako:
Glavni ključ se nalazi u skladištu ključeva, dok su ključevi tabličnih prostora u zaglavljima šifriranih tabličnih prostora (na stranici 0 tabličnog prostora).
Na slici iznad:
Tablica A je šifrirana ključem 1. Ključ 1 se šifrira pomoću glavnog ključa i pohranjuje u šifriranom obliku u zaglavlju tablice A.
Tablica B je šifrirana ključem 2. Ključ 2 se šifrira pomoću glavnog ključa i pohranjuje u šifriranom obliku u zaglavlju tablice B.
I tako dalje.
Kada serveru zatreba dešifriranje tablice A, on dobiva glavni ključ iz skladišta, čita šifrirani ključ 1 iz zaglavlja tablice A i dešifrira ključ 1. Dešifrirani ključ 1 se pohranjuje u kešu servera i koristi za dešifriranje tablice A.
InnoDB
U InnoDB, stvarno šifriranje i dešifriranje odvijaju se na razini ulaza-izlaza. To znači da se stranica šifrira neposredno prije nego što se isprazni na disk i dešifrira odmah nakon čitanja s diska.
U InnoDB, šifriranje djeluje samo na razini tabličnih prostora. I po defaultu, sve tablice se stvaraju u posebnim tabličnim prostorima (). Drugim riječima, stvara se tablični prostor koji može sadržavati samo jednu tablicu. Iako možete stvarati tablice i u glavnom tabličnom prostoru (). No, u svakom slučaju, tablica se uvijek nalazi u nekom tabličnom prostoru. A budući da se šifriranje vrši na razini tabličnog prostora, ono je ili potpuno šifrirano ili nije. To jest, nije moguće u glavnom tabličnom prostoru šifrirati samo dio tablica.
Ako je iz nekog razloga isključen file-per-table, sve tablice se stvaraju unutar sistemskog tabličnog prostora (system tablespace). U možete enkriptirati sistemski tablični prostor pomoću varijable innodbsystablespaceencrypt ili koristeći tokove enkripcije (encryption threads), ali to je još uvijek eksperimentalna funkcija. U MySQL-u toga nema.
Prije nego što krenemo dalje, trebamo razmotriti strukturu identifikatora glavnog ključa (master key ID). Sastoji se od UUID-a, KEYID-a i prefiksa "INNODBKey". Izgleda ovako: INNODBKey-UUID-KEYID.
UUID je uuid servera s enkriptiranim tabličnim prostorom. KEYID je jednostavno konstantno rastuća vrijednost. Pri prvotnom stvaranju glavnog ključa KEYID je jednak 1. Prilikom rotacije ključa, kada se stvara novi glavni ključ, KEYID = 2 i tako dalje. O rotaciji glavnih ključeva razgovarat ćemo u sljedećim člancima ove serije.
Sada, kada znamo kako izgleda identifikator glavnog ključa, pogledajmo zaglavlje enkriptiranog tabličnog prostora. Kada se tablični prostor enkriptira, informacije o enkripciji dodaju se u zaglavlje. Izgleda ovako:
KEY ID je KEYID iz identifikatora glavnog ključa, koji smo već raspravljali. UUID je uuid servera, koji se također koristi u identifikatoru glavnog ključa. TABLESPACE KEY je ključ tabličnog prostora, koji se sastoji od 256 bita, nasumično generiranih od strane servera. Vektor inicijalizacije (IV, initialization vector) također se sastoji od 256 nasumično generiranih bitova (iako bi trebao biti 128 bita). IV se koristi za inicijalizaciju enkripcije i dekripcije AES-a (od 256 bita se koristi samo 128). Na kraju se nalazi CRC32 kontrolna suma za TABLESPACE KEY i IV.
Sve to vrijeme malo sam pojednostavio, govoreći da u zaglavlju postoji enkriptirani ključ tabličnog prostora. U stvarnosti, ključ tabličnog prostora i vektor inicijalizacije pohranjuju se i enkriptiraju zajedno s pomoću glavnog ključa. Zapamtite, prije enkripcije ključa tabličnog prostora i vektora inicijalizacije, za njih se izračunava CRC32.
Zašto je CRC32 potreban?
Ukratko, kako biste se uvjerili u valjanost glavnog ključa. Nakon dešifriranja ključa tabelarnog prostora i vektora inicijalizacije, izračunava se kontrolna suma i uspoređuje s CRC32, pohranjenom u zaglavlju. Ako se kontrolne sume podudaraju, imamo ispravni glavni ključ i ključ tabelarnog prostora. U suprotnom, tabelarni prostor se označava kao nedostupan (nećemo ga moći dešifrirati).
Možete pitati: u kojem trenutku se provodi provjera ključeva? Odgovor je — prilikom pokretanja servera. Server sa šifriranim tabelama / tabelarnim prostorima pri pokretanju čita UUID, KEYID iz zaglavlja i generira identifikator glavnog ključa. Zatim dobiva potrebni glavni ključ iz spremišta (keyring), dešifrira ključ tabelarnog prostora i provjerava kontrolnu sumu. Ponovno, ako se kontrolna suma podudara, sve je u redu, ako ne — tabelarni prostor se označava kao nedostupan.
Ako ste čitali prethodni članak ove serije (), mogli biste se sjetiti da prilikom korištenja serverskog spremišta ključeva, server pri pokretanju dobiva samo popis identifikatora ključeva, odnosno key id i user id, jer se ovaj par jednoznačno identificira kao ključ. A sada kažem da server pri pokretanju dobiva sve ključeve potrebne za provjeru mogućnosti dešifriranja ključeva tabelarnih prostora. Zašto se pri inicijalizaciji, u slučaju serverskog spremišta, učitavaju samo keyid i userid, a ne svi ključevi? Zato što vam možda nisu potrebni svi ključevi. Uglavnom se to odnosi na rotaciju glavnog ključa. Pri rotaciji glavnog ključa u spremištu se stvara novi glavni ključ, ali stari ključevi se ne brišu. Tako u serverskom spremištu ključeva može biti mnogo ključeva koji nisu potrebni serveru i stoga se ne izvlače prilikom pokretanja servera.
Došlo je vrijeme da malo razgovaramo o prednostima i nedostacima šifriranja pomoću glavnog ključa. Najveća prednost je što vam je potreban samo jedan ključno šifriranje (glavni ključ), koji će se čuvati odvojeno od vaših šifriranih podataka. To ubrzava pokretanje poslužitelja, a skladište ostaje malo, što olakšava upravljanje. Također, jedini glavni ključ se lako može ponovo generirati.
Međutim, šifriranje pomoću glavnog ključa ima jednu veliku manu: nakon što je prostor tablice šifriran pomoću tablespace_key, uvijek ostaje šifriran istim ključem. Rotacija glavnog ključa ovdje ne pomaže. Zašto je to mana? Znamo da u MySQL-u postoje greške koje mogu dovesti do iznenadnog kvara i stvaranja core datoteke. Budući da core datoteka sadrži snimak memorije poslužitelja, može se dogoditi da u snimku bude dešifrirani ključ prostora tablice. Što je još gore, dešifrirani ključevi prostora tablice pohranjuju se u memoriji koja se može zamijeniti na disku. Možda ćete reći da to nije mana, jer su vam potrebne root privilegije za pristup tim datotekama i swap particiji. Da. Ali root je potreban samo na trenutak. Nakon što netko dobije pristup dešifriranom ključu prostora tablice, on/ona će moći dalje koristiti taj ključ za dešifriranje podataka, čak i bez root privilegija. Osim toga, disk se može ukrasti, a swap particija/core datoteke se mogu pročitati pomoću vanjskih alata. Cilj TDE-a je učiniti ih nečitljivima, čak i ako se disk ukrade. postoji mogućnost ponovnog šifriranja prostora tablice s novim generiranim ključevima. Ova funkcija se naziva tokovi šifriranja (encryption threads) i u trenutku pisanja ovog članka još uvijek je eksperimentalna.
Čitajte više:
Izvor: habr.com
