Šifriranje v MySQL: uporaba glavnega ključa

V pričakovanju začetka novega vpisa na tečaj "Baza podatkov" nadaljujemo z objavo serije člankov o šifriranju v MySQL.

V prejšnjem članku v tej seriji (Šifriranje v MySQL: shramba ključev) smo govorili o shrambah ključev. V tem članku si bomo ogledali, kako se uporablja glavni ključ, in razpravljali o prednostih in slabostih šifriranja z ovojnico. 

Zamisel za šifriranje ovojnice je, da so ključi, ki se uporabljajo za šifriranje (ključi prostora tabel), šifrirani z drugim ključem (glavni ključ). Ključi tabele se dejansko uporabljajo za šifriranje podatkov. Grafično je to mogoče predstaviti na naslednji način:

Glavni ključ je v shrambi ključev, ključi prostora tabel pa so v šifriranih glavah prostora tabel (na strani 0 prostora tabel). 

Na zgornji sliki:

• Tabela A je šifrirana s ključem 1 (Key 1). Ključ 1 je šifriran z glavnim ključem in šifrirano shranjen v glavi tabele A.

• Tabela B je šifrirana s ključem 2 (Key 2). Ključ 2 je šifriran z maskirnim ključem in šifrirano shranjen v glavi tabele B.

• In tako naprej.

Ko mora strežnik dešifrirati tabelo A, dobi glavni ključ iz shrambe, prebere šifrirani ključ 1 iz glave tabele A in dešifrira ključ 1. Dešifrirani ključ 1 je predpomnjen v pomnilniku strežnika in se uporablja za dešifriranje tabele A .

InnoDB

V InnoDB se dejansko šifriranje in dešifriranje izvede na ravni I/O. To pomeni, da je stran šifrirana tik preden se splakne na disk in dešifrira takoj po branju z diska.

V InnoDB šifriranje deluje samo na ravni prostora tabel. In privzeto so vse tabele ustvarjene v ločenih prostorih tabel (tabelni prostor datoteke na tabelo). Z drugimi besedami, ustvarjen je prostor tabel, ki lahko vsebuje samo eno tabelo. Čeprav lahko ustvarite tabele tudi v glavnem prostoru tabel (splošni tabelni prostor). Toda v vsakem primeru je tabela vedno v nekem prostoru tabel. In ker se šifriranje izvede na ravni prostora tabel, je v celoti šifrirano ali ne. To pomeni, da ne morete šifrirati le dela tabel v glavnem prostoru tabel. 

Če ste iz nekega razloga onemogočili datoteko na tabelo, so vse tabele ustvarjene znotraj sistemskega prostora tabel. IN Strežnik Percona za MySQL sistemski prostor tabel lahko šifrirate s spremenljivko innodbsystabelni prostoršifriranje ali uporabo šifrirnih niti, vendar je to še vedno eksperimentalna funkcija. MySQL tega nima.

Preden nadaljujemo, moramo razmisliti o strukturi ID-ja glavnega ključa. Sestavljen je iz UUID, KEYID in predpona "INNODBKey". Videti je takole: INNODBKey-UUID-KEYID.

UUID je uuid strežnika s šifriranim prostorom tabel. ključID je le vedno večja vrednost. Ko prvič ustvarite glavni ključ KEYID je 1. Med rotacijo ključa, ko se ustvari nov glavni ključ, KEYID = 2 in tako naprej. Več o rotaciji glavnega ključa bomo govorili v naslednjih člankih te serije.

Zdaj, ko vemo, kako izgleda identifikator glavnega ključa, si poglejmo glavo šifriranega prostora tabel. Ko je prostor tabel šifriran, se informacije o šifriranju dodajo v glavo. Videti je takole:

KEYID je KEYID iz ID-ja glavnega ključa, o katerem smo že razpravljali. UUID je uuid strežnika in se uporablja tudi v identifikatorju glavnega ključa. TABLESPACE KEY - ključ prostora tabel, ki je sestavljen iz 256 bitov, naključno generiran s strani strežnika. Inicializacijski vektor (IV, initialization vector) je prav tako sestavljen iz 256 naključno generiranih bitov (čeprav bi moral biti 128 bitov). IV se uporablja za inicializacijo šifriranja in dešifriranja AES (od 256 bitov je uporabljenih le 128). Na koncu je kontrolna vsota CRC32 za TABLESPACE KEY in IV.

Ves ta čas sem nekoliko poenostavljal z besedami, da je v glavi šifriran ključ prostora tabel. Pravzaprav sta ključ prostora tabel in inicializacijski vektor shranjena in šifrirana skupaj z glavnim ključem. Ne pozabite, da preden sta ključ prostora tabel in inicializacijski vektor šifrirana, se zanju izračuna CRC32.

Zakaj je CRC32 potreben?

Na kratko, da se prepričate, da je glavni ključ veljaven. Po dešifriranju ključa prostora tabel in inicializacijskega vektorja se izračuna kontrolna vsota in primerja s CRC32, shranjenim v glavi. Če se kontrolni vsoti ujemata, potem imamo pravilen glavni ključ in ključ prostora tabel. V nasprotnem primeru je tabelni prostor označen kot manjkajoči (še vedno ga ne moremo dešifrirati).

Lahko se vprašate: na kateri točki se izvaja preverjanje ključev? Odgovor je, ko se strežnik zažene. Strežnik s šifriranimi tabelami / prostori tabel ob zagonu prebere UUID, KEYID iz glave in ustvari ID glavnega ključa. Nato pridobi zahtevani glavni ključ iz obeska ključev, dešifrira ključ prostora tabel in preveri kontrolno vsoto. Še enkrat, če se kontrolna vsota ujema, je vse v redu, ne - prostor tabel je označen kot manjkajoči.

Če ste prebrali zadnji članek v tej seriji (Šifriranje v MySQL: shramba ključev), potem morda ne pozabite, da pri uporabi strežniške shrambe ključev strežnik ob zagonu prejme samo seznam identifikatorjev ključev, natančneje ID ključa in ID uporabnika, saj ta par enolično identificira ključ. Zdaj pravim, da strežnik ob zagonu dobi vse ključe, ki jih potrebuje za preverjanje, ali je ključe prostora tabel mogoče dešifrirati. Zakaj se torej pri inicializaciji v primeru strežniškega pomnilnika naloži samo ključid in uporabnikid in ne vsi ključi? Ker morda ne boste potrebovali vseh ključev. To je predvsem posledica vrtenja glavnega ključa. Ko se glavni ključ zavrti v trezorju, se ustvari nov glavni ključ, vendar se stari ključi ne izbrišejo. Tako imate lahko v shrambi ključev strežnika veliko ključev, ki jih strežnik ne potrebuje in zato niso pridobljeni, ko se strežnik zažene.

Čas je, da se malo pogovorimo o prednostih in slabostih šifriranja z glavnim ključem. Največja prednost je, da potrebujete samo en šifrirni ključ (glavni ključ), ki bo ločen od vaših šifriranih podatkov. Zaradi tega je zagon strežnika hiter, prostor za shranjevanje pa majhen, kar olajša upravljanje. In tudi edini glavni ključ je enostavno regenerirati.

Vendar ima šifriranje z glavnim ključem eno veliko pomanjkljivost: ko je prostor tabel šifriran s ključem tablespace_key, vedno ostane šifriran z istim ključem. Vrtenje glavnega ključa tukaj ne pomaga. Zakaj je to pomanjkljivost? Vemo, da ima MySQL napake, zaradi katerih se lahko zruši in ustvari jedrno datoteko. Ker jedrna datoteka vsebuje izpis pomnilnika strežnika, se lahko zgodi, da izpis vsebuje dešifriran ključ prostora tabel. Še huje, dešifrirani ključi prostora tabel so shranjeni v pomnilniku, ki ga je mogoče zamenjati na disk. Lahko rečete, da to ni pomanjkljivost, saj potrebujete korenska dovoljenja za dostop do teh datotek in izmenjalne particije. ja Toda root je potreben le za nekaj časa. Ko ima nekdo dostop do dešifriranega ključa prostora tabel, ga lahko še naprej uporablja za dešifriranje podatkov, tudi brez korenskega dostopa. Poleg tega lahko disk ukradejo in datoteke swap / core lahko preberejo z orodji tretjih oseb. Cilj TDE je, da postane neberljiv, tudi če je disk ukraden. IN Strežnik Percona za MySQL prostor tabel je mogoče ponovno šifrirati z novo generiranimi ključi. Ta funkcija se imenuje šifrirne niti in je v času tega pisanja še eksperimentalna.

Izvedite več o tečaju

Preberi več:

• Šifriranje v MySQL: shramba ključev

Vir: www.habr.com