Enkripcija u MySQL: rotacija glavnog ključa

U iščekivanju početka novih upisa na tečaj "Baza podataka" nastavljamo objavljivati ​​seriju članaka o enkripciji u MySQL-u.

U prethodnom članku u ovoj seriji raspravljali smo kako radi enkripcija glavnog ključa. Danas, na temelju ranije stečenog znanja, pogledajmo rotaciju glavnih tipki.

Rotacija glavnog ključa uključuje generiranje novog glavnog ključa i ponovno šifriranje ključeva tabličnog prostora (koji su pohranjeni u zaglavljima tabličnog prostora) s tim novim ključem.

Prisjetimo se kako izgleda zaglavlje šifriranog tabličnog prostora:

Enkripcija u MySQL: rotacija glavnog ključa

Iz prethodnog članka znamo da poslužitelj prilikom pokretanja čita zaglavlja svih šifriranih tabličnih prostora i pamti najveći KEY ID. Na primjer, ako imamo tri tablice s KEYID = 3 i jedna tablica s KLJUČEMID = 4, tada će maksimalni ID ključa biti 4. Nazovimo ovaj ID KLJUČA - MAX KEY ID.

Kako funkcionira rotacija glavnog ključa

1. Korisnik izvršava ALTER INNODB MASTER KEY.

2. Poslužitelj zahtijeva da privjesak ključeva generira novi glavni ključ s UUID-om poslužitelja i KEY-omID jednak jedan plus MAXKLJUČISKAZNICA. Dakle, dobivamo ID glavnog ključa jednak INNODB-uKEY-UUID-(MAXKLJUČID + 1). Nakon uspješnog generiranja glavnog ključa, MAX KEY ID se povećava za jedan (tj. MAXKLJUČID=MAXKLJUČID + 1).

3. Poslužitelj skenira sve tablične prostore šifrirane glavnim ključem, a za svaki tablični prostor:

  • šifrira ključ prostora tablice s novim glavnim ključem;

  • ažurira ID ključa na novi MAXKLJUČISKAZNICA;

  • ako se UUID razlikuje od UUID-a poslužitelja, ažurirajte UUID poslužitelja.

Kao što znamo, ID glavnog ključa koji se koristi za dešifriranje tablice sastoji se od UUID-a i KEY ID-a koji se čita iz zaglavlja prostora tablice. Ono što sada radimo je ažuriranje ovih informacija u zaglavlju šifriranja tabličnog prostora tako da poslužitelj primi ispravan glavni ključ.

Ako imamo tablične prostore s različitih lokacija, kao što su različite sigurnosne kopije, tada oni mogu koristiti različite glavne ključeve. Svi ovi glavni ključevi morat će se dohvatiti iz repozitorija kada se poslužitelj pokrene. To može usporiti pokretanje poslužitelja, posebno ako se koristi pohrana ključeva na strani poslužitelja. Uz rotaciju glavnog ključa, ponovno šifriramo ključeve tabličnog prostora s jednim glavnim ključem koji je isti za sve tablične prostore. Poslužitelj bi sada trebao primiti samo jedan glavni ključ pri pokretanju.

Ovo je, naravno, samo ugodna nuspojava. Glavna svrha rotacije glavnog ključa je učiniti naš poslužitelj sigurnijim. U slučaju da je glavni ključ na neki način ukraden iz trezora (na primjer, iz Vault Servera), moguće je generirati novi glavni ključ i ponovno šifrirati ključeve tabličnog prostora, poništavajući ukradeni ključ. Sigurni smo... skoro.

U prethodnom sam članku govorio o tome kako jednom kada je ključ tabličnog prostora ukraden, treća strana ga može upotrijebiti za dešifriranje podataka. Pod uvjetom da postoji pristup našem disku. Ako je glavni ključ ukraden, a vi imate pristup šifriranim podacima, možete koristiti ukradeni glavni ključ za dešifriranje ključa prostora tablice i dobivanje dešifriranih podataka. Kao što vidite, rotacija glavnog ključa u ovom slučaju ne pomaže. Ponovno šifriramo ključ tabličnog prostora s novim glavnim ključem, ali stvarni ključ korišten za šifriranje/dekriptiranje podataka ostaje isti. Stoga ga "haker" može nastaviti koristiti za dekriptiranje podataka. Ranije sam to nagovijestio Percona poslužitelj za MySQL može izvršiti pravu ponovnu enkripciju prostora tablice, a ne samo jednostavnu ponovnu enkripciju ključa prostora tablice. Ova se značajka naziva niti šifriranja. Međutim, ova je funkcija trenutačno još uvijek eksperimentalna.

Rotacija glavnog ključa je korisna kada je glavni ključ ukraden, ali ne postoji način da ga napadač upotrijebi i dekriptira ključeve tabličnog prostora.

Prijavite se za besplatnu demo lekciju.

Čitaj više:

Izvor: www.habr.com