În așteptarea începerii unei noi înscrieri la curs continuăm să publicăm o serie de articole despre criptare în MySQL.
În articolul anterior din această serie, am discutat . Astăzi, pe baza cunoștințelor acumulate mai devreme, să ne uităm la rotația cheilor principale.
Rotația cheii master implică generarea unei noi chei master și recriptarea cheilor de spațiu tabel (care sunt stocate în antetele spațiului tabel) cu această nouă cheie.
Să ne amintim cum arată antetul unui tablespace criptat:
Din articolul anterior, știm că serverul citește anteturile tuturor tablespace-urilor criptate la pornire și își amintește cel mai mare ID-CHEIE. De exemplu, dacă avem trei tabele cu KEYID = 3 și un tabel cu CHEIEID = 4, atunci ID-ul maxim al cheii va fi 4. Să numim acest ID KEY - ID MAX KEY.
Cum funcționează rotația cheii principale
1. Utilizatorul execută ALTER INNODB MASTER KEY.
2. Serverul solicită inelului de chei să genereze o nouă cheie principală cu UUID-ul și CHEIA serveruluiID egal cu unu plus MAXCHEIEID. Deci obținem ID-ul cheii principale egal cu INNODBKEY-UUID-(MAXCHEIEID + 1). După generarea cu succes a cheii principale, ID-ul MAX KEY este incrementat cu unu (adică MAXCHEIEID=MAXCHEIEID + 1).
3. Serverul scanează toate spațiile de masă criptate cu cheia principală și pentru fiecare spațiu de masă:
-
criptează cheia tablespace cu noua cheie principală;
-
actualizează ID-ul cheii la noul MAXCHEIEID;
-
dacă UUID-ul este diferit de UUID-ul serverului, atunci actualizați UUID-ul serverului.
După cum știm, ID-ul cheii principale folosit pentru a decripta un tabel constă dintr-un UUID și un ID-CHEie citit din antetul spațiului de masă. Ceea ce facem acum este să actualizăm aceste informații în antetul de criptare a spațiului de masă, astfel încât serverul să primească cheia principală corectă.
Dacă avem spații de masă din locații diferite, cum ar fi copii de rezervă diferite, atunci acestea pot folosi chei principale diferite. Toate aceste chei principale vor trebui să fie preluate din depozit atunci când serverul este pornit. Acest lucru poate încetini pornirea serverului, mai ales dacă este utilizat un depozit de chei pe partea serverului. Odată cu rotația cheii principale, re-criptăm cheile tablespace cu o singură cheie principală care este aceeași pentru toate tablespaces. Serverul ar trebui să primească acum o singură cheie principală la pornire.
Acesta, desigur, este doar un efect secundar plăcut. Scopul principal al rotației cheii principale este de a face serverul nostru mai sigur. În cazul în care cheia principală a fost într-un fel furată din seif (de exemplu, de pe Vault Server), este posibil să se genereze o nouă cheie principală și să se recripteze cheile tablespace, invalidând cheia furată. Suntem în siguranță... aproape.
Într-un articol anterior, am vorbit despre cum, odată ce o cheie de spațiu de masă este furată, o terță parte o poate folosi pentru a decripta datele. Cu condiția să existe acces la discul nostru. Dacă cheia principală este furată și aveți acces la datele criptate, puteți utiliza cheia principală furată pentru a decripta cheia spațiului de masă și a obține datele decriptate. După cum puteți vedea, rotirea cheii principale nu ajută în acest caz. Re-criptăm cheia tablespace cu noua cheie principală, dar cheia reală folosită pentru a cripta/decripta datele rămâne aceeași. Prin urmare, „hackerul” îl poate folosi în continuare pentru a decripta datele. Mai devreme am sugerat că poate efectua o adevărată recriptare a spațiului de masă, nu doar o simplă recriptare a cheilor de spațiu de masă. Această caracteristică se numește fire de criptare. Cu toate acestea, această funcționalitate este încă experimentală în acest moment.
Rotirea cheii principale este utilă atunci când cheia principală este furată, dar nu există nicio modalitate ca un atacator să o folosească și să decripteze cheile spațiului de masă.
Citeste mai mult:
Sursa: www.habr.com