Înainte de începerea unui nou grup pentru curs Continuăm să publicăm o serie de articole despre criptarea în MySQL.
În articolul precedent din această serie, am discutat despre . Astăzi, bazându-ne pe cunoștințele dobândite anterior, vom analiza rotația cheilor principale.
Rotația cheilor principale constă în generarea unei noi chei principale, iar cu această nouă cheie se recriptează cheile spațiilor de tabele (care sunt stocate în anteturile spațiilor de tabele).
Să ne amintim cum arată antetul unui spațiu de tabele criptat:
Din articolul precedent știm că serverul, la pornire, citește anteturile tuturor spațiilor de tabele criptate și reține cel mai mare KEY ID. De exemplu, dacă avem trei tabele cu KEYID = 3 și o tabelă cu KEYID = 4, atunci identificatorul maxim al cheii va fi 4. Să numim acest KEY ID — MAX KEY ID.
Cum funcționează rotația cheii principale
1. Utilizatorul execută ALTER INNODB MASTER KEY.
2. Serverul solicită în stocarea cheilor (keyring) generarea unei noi chei principale cu UUID-ul serverului și KEYID, egal cu MAXKEYID crescut cu unu. Astfel, obținem un identificator al cheii principale, egal cu INNODBKEY-UUID-(MAXKEYID + 1). La generarea cu succes a cheii principale, MAX KEY ID crește cu unu (adică MAXKEYID = MAXKEYID + 1).
3. Serverul examinează toate spațiile de tabele criptate cu ajutorul cheii principale și, pentru fiecare spațiu de tabele:
criptează cheia spațiului de tabele cu noua cheie principală;
actualizează identificatorul cheii la noul MAXKEYID;
dacă UUID-ul diferă de UUID-ul serverului, actualizează UUID-ul serverului.
Așa cum știm, identificatorul cheii principale (Master Key ID) utilizat pentru decriptarea tabelului constă din UUID și KEY ID, citite din antetul spațiului de tabele. Ceea ce facem acum este să actualizăm aceste informații în antetul de criptare al spațiului de tabele, astfel încât serverul să primească cheia principală corectă.
Dacă avem spații de tabel obținute din diferite locuri, de exemplu, din diverse backup-uri, acestea pot avea chei principale diferite. Toate aceste chei principale trebuie obținute din stocare la pornirea serverului. Acest lucru poate întârzia pornirea serverului, mai ales dacă se folosește o stocare de chei server. Prin rotirea cheii principale, recriptăm cheile spațiilor de tabel cu o cheie principală, aceeași pentru toate spațiile de tabel. Acum, la pornire, serverul trebuie să obțină doar o cheie principală.
Acesta este, desigur, doar un efect secundar plăcut. Scopul principal al rotirii cheilor principale este de a face serverul nostru mai sigur. În cazul în care cheia principală a fost furată din stocare (de exemplu, din Vault Server), se poate genera o nouă cheie principală și recriptăm cheile spațiilor de tabel, făcând cheia furată inexistentă. Suntem în siguranță... aproape.
În articolul anterior am menționat că, după furtul cheii spațiului de tabel, o terță parte o poate folosi pentru a decripta datele, având acces la discul nostru. În cazul furtului cheii principale și a accesului la datele criptate, se poate folosi cheia principală furată pentru a decripta cheia spațiului de tabel și a obține datele decriptate. Așa cum vedem, rotirea cheii principale nu ajută în acest caz. Recriptăm cheia spațiului de tabel cu o nouă cheie principală, dar cheia efectivă folosită pentru criptare/decriptare rămâne aceeași. Prin urmare, „hackerul” poate continua să o folosească pentru a decripta datele. Anterior am sugerat că poate executa o recriptare reală a spațiilor de tabel, nu doar o simplă recriptare a cheii spațiului de tabel. Această funcționalitate se numește fire de criptare (encryption threads). Cu toate acestea, în acest moment, această funcționalitate este încă experimentală.
Rotirea cheii principale este utilă atunci când cheia principală a fost furată, dar atacatorul nu are capacitatea de a o folosi și de a decripta cheile spațiilor de tabel.
Citește mai mult:
Sursa: habr.com
