Uoči početka novog upisa na kurs Nadaljevanje serije člankov o šifriranju v MySQL.
V prejšnjem članku te serije () smo govorili o skladiščih ključev. V tem članku bomo preučili, kako se uporablja glavni ključ (master key), ter razpravljali o prednostih in slabostih šifriranja z uporabo konvertnic (envelope encryption).
Ideja konvertnice je, da so ključi, uporabljeni za šifriranje (ključi tabel), šifrirani z drugim ključem (glavnim ključem, master key). Dejanske podatke šifrirajo ključi tabel. Grafično to lahko predstavimo takole:
Glavni ključ (master key) se nahaja v skladišču ključev (keyring), ključi tabel pa so v naslovih šifriranih tabel (na strani 0 tabele).
Na sliki zgoraj:
Tabela A je šifrirana s ključem 1 (Key 1). Ključ 1 se šifrira z glavnim ključem (master key) in se hrani v šifrirani obliki v naslovu tabele A.
Tabela B je šifrirana s ključem 2 (Key 2). Ključ 2 se šifrira z glavnim ključem (master key) in se hrani v šifrirani obliki v naslovu tabele B.
In tako naprej.
Ko strežniku onemogoča dešifriranje tabele A, pridobi glavni ključ iz skladišča, prebere šifrirani ključ 1 iz naslova tabele A in dešifrira ključ 1. Dešifrirani ključ 1 se shranjuje v pomnilniku strežnika in se uporablja za dešifriranje tabele A.
InnoDB
V InnoDB se dejansko šifriranje in dešifriranje izvajata na ravni vnosa-izvoda. Torej se stran šifrira neposredno pred zapisom na disk in dešifrira takoj po branju z diska.
V InnoDB šifriranje deluje samo na ravni tabel. In privzeto se vse tabele ustvarijo v ločenih tabelah (). Z drugimi besedami, ustvarja se tabela, ki lahko vsebuje samo eno tabelo. Čeprav lahko tabele ustvarjate tudi v glavni tabeli (). V vsakem primeru je tabela vedno v neki tabeli. In ker se šifriranje izvaja na ravni tabele, je bodisi popolnoma šifrirano bodisi ne. To pomeni, da v glavni tabeli ni mogoče šifrirati le dela tabel.
Če imate iz kakršnegakoli razloga onemogočen file-per-table, se vse tabele ustvarijo znotraj sistemskega tabelarskega prostora (system tablespace). V lahko šifrirate sistemski tabelarski prostor z uporabo spremenljivke innodbsystablespaceencrypt ali z uporabo šifrirnih niti (encryption threads), vendar je to še vedno eksperimentalna funkcija. V MySQL tega ni.
Preden nadaljujemo, moramo obravnavati strukturo identifikatorja glavnega ključa (master key ID). Sestavljen je iz UUID, KEYID in predpone „INNODBKey“. Izgleda tako: INNODBKey-UUID-KEYID.
UUID je uuid strežnika s šifriranim tabelarskim prostorom. KEYID je preprosto nenehno naraščajoča vrednost. Pri prvotnem ustvarjanju glavnega ključa KEYID je enak 1. Pri rotaciji ključa, ko je ustvarjen nov glavni ključ, KEYID = 2 in tako naprej. O rotaciji glavnih ključev bomo podrobneje govorili v naslednjih člankih te serije.
Zdaj, ko vemo, kako izgleda identifikator glavnega ključa, si poglejmo glavo šifriranega tabelarskega prostora. Ko je tabelarski prostor šifriran, se informacije o šifriranju dodajo glavi. Izgleda tako:
KEY ID je KEYID iz identifikatorja glavnega ključa, o katerem smo že razpravljali. UUID je uuid strežnika, ki se prav tako uporablja v identifikatorju glavnega ključa. TABLESPACE KEY je ključ tabelarskega prostora, ki je sestavljen iz 256 bitov, naključno generiranih s strani strežnika. Inicializacijski vektor (IV, initialization vector) prav tako sestavlja 256 naključno generiranih bitov (čeprav bi moral biti 128 bit). IV se uporablja za inicializacijo šifriranja in dešifriranja AES (od 256 bitov se uporablja le 128). Na koncu je prisotna kontrolna suma CRC32 za TABLESPACE KEY in IV.
Vse to vreme sem nekoliko poenostavil, ko sem rekel, da je v glavi šifriran ključ tabelarskega prostora. V resnici sta ključ tabelarskega prostora in inicializacijski vektor shranjena in šifrirana skupaj z glavnim ključem. Ne pozabite, da se pred šifriranjem ključa tabelarskega prostora in inicializacijskega vektorja zanje izračuna CRC32.
Zakaj potrebujemo CRC32?
If we put it briefly, it's to ensure the validity of the main key. After decrypting the tablespace key and the initialization vector, a checksum is computed and compared with the CRC32 stored in the header. If the checksums match, we have a correct main key and tablespace key. Otherwise, the tablespace is marked as missing (we still won't be able to decrypt it).
You may ask: at what point are the keys checked? The answer is — when the server starts. A server with encrypted tables/tablespaces reads the UUID, KEYID from the header upon starting and generates the main key identifier. It then retrieves the necessary main key from the storage (keyring), decrypts the tablespace key, and checks the checksum. Again, if the checksum matches, everything is fine; if not, the tablespace is marked as missing.
If you read the previous article in this series (), you might remember that when using a server key storage, the server at startup retrieves only a list of key identifiers, more precisely, the key id and user id, as this pair uniquely identifies the key. Now I say that at startup, the server retrieves all keys needed for verifying the decryption of tablespace keys. So why, during initialization, does it load only the keyid and userid, and not all keys? Because you may not need all keys. This is primarily related to the rotation of the main key. When the main key is rotated, a new main key is created in the storage, but the old keys are not deleted. Thus, your server key storage can contain many keys that the server doesn’t need and, therefore, are not retrieved when the server starts.
Čas je, da se pogovorimo o prednostih in slabostih šifriranja z uporabo glavnega ključa. Največja prednost je, da potrebujete le en šifrirni ključ (glavni ključ), ki bo shranjen ločeno od vaših šifriranih podatkov. To omogoča hitro zagon strežnika in zmanjšuje shranjevanje, kar olajša upravljanje. Poleg tega je enostavno ponovno generirati enoten glavni ključ.
Vendar pa ima šifriranje z glavnim ključem eno veliko slabost: po tem, ko je prostor za tabele šifriran z uporabo tablespace_key, ostaja vedno šifriran z istim ključem. Tukaj rotacija glavnega ključa ne pomaga. Zakaj je to slabost? Vemo, da v MySQL obstajajo napake, ki lahko povzročijo nenaden zlom in ustvarjanje core datoteke. Ker core datoteka vsebuje odlagališče pomnilnika strežnika, se lahko zgodi, da bo v odlagališču dešifriran ključ prostora za tabele. Še huje, dešifrirani ključi prostora za tabele so shranjeni v spominu, ki se lahko zamenja na disk. Lahko bi rekli, da to ni slabost, saj potrebujete root pravice za dostop do teh datotek in stranske datoteke. Ja. Ampak root je potreben le za kratek čas. Ko nekdo dostopa do dešifriranega ključa prostora za tabele, lahko nadaljuje z njegovo uporabo za dešifriranje podatkov, tudi brez pravic root. Poleg tega je disk lahko ukraden, stranske datoteke ali core datoteke pa se lahko preberejo s pomočjo tretjih orodij. Cilj TDE je, da ga naredi neberljivega, tudi če je disk ukraden. obstaja možnost ponovnega šifriranja prostora za tabele z novimi generiranimi ključi. Ta funkcija se imenuje šifrirni niti (encryption threads) in je ob pisanju tega članka še vedno eksperimentalna.
Preberi več:
Izvor: habr.com
