Î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 depozitele de chei. În acest articol, vom examina modul în care este utilizat cheia principală (master key) și vom discuta avantajele și dezavantajele criptării prin metoda plicului (envelope encryption).
Ideea criptării prin plicuri constă în faptul că cheile utilizate pentru criptarea datelor (cheile spațiilor de tabele) sunt criptate cu o altă cheie (cheia principală, master key). Pentru criptarea datelor se utilizează de fapt cheile spațiilor de tabele. Grafic, acest lucru poate fi reprezentat astfel:
Cheia principală (master key) se află în depozitul de chei (keyring), iar cheile spațiilor de tabele se află în anteturile spațiilor de tabele criptate (pe pagina 0 a spațiului de tabele).
În ilustrația de mai sus:
Tabela A este criptată cu cheia 1 (Key 1). Cheia 1 este criptată cu cheia principală (master key) și este stocată în formă criptată în antetul tabelei A.
Tabela B este criptată cu cheia 2 (Key 2). Cheia 2 este criptată cu cheia principală (master key) și este stocată în formă criptată în antetul tabelei B.
Și așa mai departe.
Când serverul trebuie să decripteze tabela A, obține cheia principală din depozit, citește cheia criptată 1 din antetul tabelei A și decriptează cheia 1. Cheia 1 decriptată este stocată în memoria serverului și este utilizată pentru decriptarea tabelei A.
InnoDB
În InnoDB, criptarea și decriptarea se efectuează la nivelul de intrare-ieșire. Cu alte cuvinte, pagina este criptată imediat înainte de a fi scrisă pe disc și decriptată imediat după ce este citită de pe disc.
În InnoDB, criptarea funcționează doar la nivelul spațiilor de tabele. Și, în mod implicit, toate tabelele sunt create în spații de tabele separate (). Cu alte cuvinte, se creează un spațiu de tabele care poate conține doar o singură tabelă. Deși puteți crea tabele și în spațiul de tabele principal (). Dar, în orice caz, tabela se află întotdeauna într-un anumit spațiu de tabele. Și, deoarece criptarea se realizează la nivelul spațiului de tabele, ea este fie complet criptată, fie nu. Asta înseamnă că nu puteți cripta doar o parte a tabelelor în spațiul de tabele principal.
Dacă din orice motiv aveți dezactivată opțiunea file-per-table, atunci toate tabelele sunt create în cadrul spațiului tabelar sistemic (system tablespace). În poate fi criptat spațiul tabelar sistemic folosind variabila innodbsystablespaceencrypt sau folosind fire de criptare (encryption threads), dar aceasta este încă o funcție experimentală. Aceasta nu există în MySQL.
Înainte de a merge mai departe, trebuie să examinăm 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 tabelar criptat. KEYID este pur și simplu o valoare în creștere continuă. La prima creare a cheii principale, KEYID este 1. La rotația cheii, când se creează o nouă cheie principală, KEYID = 2 și așa mai departe. Vom discuta mai detaliat despre rotația cheilor principale în articolele viitoare din această serie.
Acum că știm cum arată identificatorul cheii principale, să ne uităm la antetul spațiului tabelar criptat. Atunci când spațiul tabelar este criptat, informațiile despre criptare sunt adăugate la 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, utilizat în identificatorul cheii principale. TABLESPACE KEY este cheia spațiului tabelar, 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 cei 256 de biți, se folosesc doar 128). La final, există o sumă de validare CRC32 pentru TABLESPACE KEY și IV.
Tot timpul acesta am simplificat puțin, spunând că în antet există o cheie criptată a spațiului tabelar. De fapt, cheia spațiului tabelar și vectorul de inițializare sunt stocate și criptate împreună cu cheia principală. Amintiți-vă că înainte de criptarea cheii spațiului tabelar și vectorului de inițializare, pentru ele se calculează CRC32.
De ce este necesar CRC32?
Pe scurt, pentru a verifica validitatea cheii principale. După decriptarea cheii spațiului de tabele și a vectorului de inițializare, se calculează o sumă de control și se compară cu CRC32 stocată în antet. Dacă sumele de control coincid, atunci avem cheia principală corectă și cheia spațiului de tabele. În caz contrar, spațiul de tabele este marcat ca lipsă (nu vom putea să-l decriptăm oricum).
Te-ai putea întreba: când se efectuează verificarea cheilor? Răspunsul: la pornirea serverului. Serverul cu tabele criptate / spații de tabele citește UUID, KEYID-ul din antet și generează un identificator al cheii principale. Apoi obține cheia principală necesară din depozit (keyring), decriptează cheia spațiului de tabele și verifică suma de control. Din nou, dacă suma de control coincide, totul este în regulă, dacă nu — spațiul de tabele este marcat ca lipsă.
Dacă ai citit articolul precedent din această serie (), atunci poate îți amintești că, atunci când folosești depotul de chei pe server, serverul la pornire primește doar lista identificatorilor cheilor, mai exact, key id și user id, deoarece această pereche identifică univoc cheia. Și acum spun că serverul la pornire primește toate cheile necesare pentru a verifica capacitatea de decriptare a cheilor spațiilor de tabele. De ce atunci, la inițializare, în cazul depotului pe server, sunt încărcate doar keyid și userid, și nu toate cheile? Pentru că s-ar putea să nu ai nevoie de toate cheile. Acest lucru este legat în principal de rotația cheii principale. Atunci când cheia principală este rotită, se creează o nouă cheie principală în depozit, dar cheile vechi nu sunt șterse. Astfel, în depozitul serverului poți avea multe chei care nu sunt necesare serverului și, prin urmare, nu sunt extrase la pornirea serverului.
A venit timpul să discutăm puțin despre avantajele și dezavantajele criptării cu cheia principală. Cel mai mare avantaj este că aveți nevoie de o singură cheie de criptare (cheia principală), care va fi stocată separat de datele criptate. Acest lucru face ca pornirea serverului să fie rapidă, iar stocarea să fie redusă, facilitând managementul. De asemenea, cheia principală unică este ușor de regenerat.
Cu toate acestea, criptarea cu cheia principală are un mare dezavantaj: odată ce spațiul de tabele 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 cădere bruscă și la generarea unui fișier core. Deoarece fișierul core conține un dump de memorie al serverului, este posibil ca cheia de decriptare a spațiului de tabele să fie prezentă în dump. Ce este și mai rău, cheile de decriptare ale spațiului de tabele sunt stocate în memorie, care poate fi swap-uită pe disc. Puteți spune că aceasta nu este o problemă, deoarece aveți nevoie de drepturi root pentru a accesa aceste fișiere și swap space. Așa este. Dar drepturile root sunt necesare doar pentru o perioadă scurtă. Odată ce cineva obține acces la cheia de decriptare a spațiului de tabele, el sau ea va putea continua să o folosească pentru decriptarea datelor, chiar și fără drepturi root. În plus, discul poate fi furat, iar swap space / fișierele core pot fi citite cu ajutorul unor instrumente externe. Scopul TDE este de a face datele ilizibile, chiar dacă discul este furat. există posibilitatea de a recripta spațiul de tabele cu noi chei generate. Această funcție 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
