Înainte de începerea unui nou grup pentru curs Continuăm să publicăm o serie de articole despre criptarea în MySQL.
În articolul anterior din această serie () am discutat despre stocarea cheilor. În acest articol, vom analiza utilizarea cheii principale (master key) și vom discuta avantajele și dezavantajele criptării prin metoda enveloperii (envelope encryption).
Ideea criptării prin enveloperie este că cheile utilizate pentru criptare (cheile spațiilor de tabel) sunt criptate cu o altă cheie (cheia principală, master key). Cheile spațiilor de tabel sunt cele care sunt folosite pentru criptarea efectivă a datelor. Grafic, aceasta poate fi reprezentată astfel:
Cheia principală (master key) se află în depozitul de chei (keyring), iar cheile spațiilor de tabel sunt în anteturile spațiilor de tabel criptate (pe pagina 0 a spațiului de tabel).
În figura de mai sus:
Tabelul A este criptat cu cheia 1 (Key 1). Cheia 1 este criptată folosind cheia principală (master key) și este stocată într-o formă criptată în antetul tabelului A.
Tabelul B este criptat cu cheia 2 (Key 2). Cheia 2 este criptată folosind cheia principală (master key) și este stocată într-o formă criptată în antetul tabelului B.
Și așa mai departe.
Când serverul trebuie să decripteze tabelul A, el obține cheia principală din depozit, citește cheia 1 criptată din antetul tabelului A și decriptează cheia 1. Cheia 1 decriptată este stocată în cache în memoria serverului și este folosită pentru decriptarea tabelului A.
InnoDB
În InnoDB, criptarea efectivă și decriptarea se realizează la nivel de input-output. Astfel, pagina este criptată imediat înainte de a fi scrisă pe disc și este decriptată imediat după ce este citită de pe disc.
În InnoDB, criptarea funcționează doar la nivelul spațiilor de tabel. Și în mod implicit, toate tabelele sunt create în spații de tabel separate (). Cu alte cuvinte, se creează un spațiu de tabel care poate conține doar o tabelă. Deși poți crea tabele și în spațiul de tabel principal (). Dar, în orice caz, o tabelă se află întotdeauna într-un spațiu de tabel. Și deoarece criptarea se realizează la nivelul spațiului de tabel, aceasta este fie complet criptată, fie nu. Asta înseamnă că nu poți cripta doar o parte a tabelelor într-un spațiu de tabel principal.
Dacă, din orice motiv, aveți dezactivat file-per-table, toate tabelele sunt create în cadrul spațiului de tabele de sistem (system tablespace). În poate fi criptat spațiul de tabele de sistem cu ajutorul variabilei innodbsystablespaceencrypt sau folosind firele de criptare (encryption threads), dar aceasta este încă o funcție experimentală. În MySQL nu există acest lucru.
Înainte de a merge mai departe, trebuie să discutăm despre structura identificatorului cheii principale (master key ID). Acesta constă din UUID, KEYID și prefixul „INNODBKey”. Arată astfel: INNODBKey-UUID-KEYID.
UUID este uuid-ul serverului cu spațiul de tabele criptat. KEYID este pur și simplu o valoare în creștere continuă. La prima creare a cheii principale, KEYID este 1. La rotirea cheii, când se creează o nouă cheie principală, KEYID = 2 și așa mai departe. Vom discuta mai detaliat despre rotirea cheilor principale în articolele următoare din această serie.
Acum, când știm cum arată identificatorul cheii principale, să ne uităm la antetul spațiului de tabele criptat. Atunci când spațiul de tabele este criptat, informațiile despre criptare sunt adăugate în antet. Arată astfel:
KEY ID este KEYID din identificatorul cheii principale pe care l-am discutat deja. UUID este uuid-ul serverului, care este de asemenea folosit în identificatorul cheii principale. TABLESPACE KEY este cheia spațiului de tabele, care constă din 256 de biți, generați aleatoriu de server. Vectorul de inițializare (IV, initialization vector) constă de asemenea din 256 de biți generați aleatoriu (deși ar trebui să fie 128 de biți). IV este utilizat pentru inițializarea criptării și decriptării AES (din 256 de biți se utilizează doar 128). La final, există un sumă de control CRC32 pentru TABLESPACE KEY și IV.
Toată această vreme am simplificat puțin, spunând că în antet există o cheie criptată a spațiului de tabele. În realitate, cheia spațiului de tabele și vectorul de inițializare sunt stocate și criptate împreună cu ajutorul cheii principale. Amintiți-vă că, înainte de criptarea cheii spațiului de tabele și a vectorului de inițializare, pentru ele se calculează CRC32.
De ce este necesar CRC32?
Dacă ar fi să rezumăm, scopul este de a verifica validitatea cheii principale. După decriptarea cheii spațiului de tabele și a vectorului de inițializare, se calculează suma de control și se compară cu CRC32, stocată în antet. Dacă sumele de control coincid, avem cheia principală corectă și cheia spațiului de tabele. În caz contrar, spațiul de tabele este marcat ca inexistent (nu vom putea oricum să-l decriptăm).
Puteți întreba: în ce moment are loc verificarea cheilor? Răspunsul este — la pornirea serverului. Serverul cu tabele criptate / spații de tabele citește UUID, KEYID din antet și generează identificatorul cheii principale. Apoi obține cheia principală necesară din stocare (keyring), decriptează cheia spațiului de tabele și verifică suma de control. Încă o dată, dacă suma de control coincide, totul este în regulă, altfel, spațiul de tabele este marcat ca inexistent.
Dacă ați citit articolul anterior din această serie (), atunci poate că vă amintiți că atunci când folosiți stocarea cheilor pe server, serverul la pornire primește doar lista identificatorilor cheilor, mai exact, key id și user id, deoarece acest cuplu identifică în mod clar cheia. Acum spun că serverul la pornire primește toate cheile necesare pentru a verifica posibilitatea decriptării cheilor spațiilor de tabele. De ce, atunci, în cazul stocării pe server, se încarcă doar keyid și userid, și nu toate cheile? Pentru că s-ar putea să nu aveți nevoie de toate cheile. Aceasta se leagă de rotația cheii principale. Când se rotește cheia principală, se creează o nouă cheie principală în stocare, dar cheile vechi nu sunt șterse. Astfel, în stocarea cheilor pe server pot exista multe chei care nu sunt necesare serverului și, prin urmare, nu sunt extrase la pornirea serverului.
A venit timpul să discutăm despre avantajele și dezavantajele criptării prin intermediul unei chei principale. Cel mai mare avantaj este că aveți nevoie de o singură cheie de criptare (cheia principală), care va fi stocată separat de datele dvs. criptate. Aceasta face ca pornirea serverului să fie rapidă și spațiul de stocare să fie mic, facilitând gestionarea. De asemenea, cheia principală este ușor de regenerat.
Cu toate acestea, criptarea utilizând cheia principală are un dezavantaj major: odată ce spațiul tabelar este criptat cu tablespace_key, acesta rămâne întotdeauna criptat cu aceeași cheie. Rotirea cheii principale nu ajută aici. De ce este acesta un dezavantaj? Știm că în MySQL există bug-uri care pot duce la o defecțiune bruscă și la crearea unui fișier core. Deoarece fișierul core conține o copie de memorie a serverului, se poate întâmpla ca în dump-ul să existe cheia de decriptare a spațiului tabelar. Ce este și mai rău, cheile de decriptare ale spațiului tabelar sunt stocate în memorie, care poate fi swap-uită pe disc. Puteți spune că acesta nu este un dezavantaj, deoarece aveți nevoie de drepturi root pentru a accesa aceste fișiere și zona de swap. Da. Dar drepturile root sunt necesare doar pentru o perioadă scurtă. Odată ce cineva obține acces la cheia de decriptare a spațiului tabelar, el/ea poate continua să o folosească pentru decriptarea datelor, chiar și fără drepturi root. În plus, discurile pot fi furate, iar fișierele de swap/core pot fi citite cu ajutorul unor instrumente externe. Scopul TDE este de a face conținutul său ilizibil, chiar dacă discul este furat. există posibilitatea de a recripta spațiul tabelar cu chei generate noi. Această funcționalitate se numește fire de criptare (encryption threads) și, la momentul redactării acestui articol, este încă experimentală.
Citește mai mult:
Sursa: habr.com
