🥇Šifrēšana MySQL: galvenās atslēgas izmantošana

Pirms jaunā kursa uzsākšanas „Datu bāzes” turpinām publicēt rakstu sēriju par šifrēšanu MySQL.

Iepriekšējā šīs sērijas rakstā (Šifrēšana MySQL: atslēgu krātuve) mēs runājām par atslēgu krātuvēm. Šajā rakstā mēs apskatīsim, kā tiek izmantots galvenais atslēga (master key), kā arī pārrunāsim šifrēšanas ar aploksnēm (envelope encryption) priekšrocības un trūkumus.

Aploksnes šifrēšanas ideja ir tāda, ka šifrēšanai izmantotās atslēgas (tabulu telpu atslēgas) tiek šifrētas ar citu atslēgu (galveno atslēgu, master key). Datu šifrēšanai faktiski tiek izmantotas tabulu telpu atslēgas. Grafiski to var attēlot šādi:

Galvenā atslēga (master key) atrodas atslēgu krātuvē (keyring), bet tabulu telpu atslēgas — šifrēto tabulu telpu virsrakstos (0. lapā tabulu telpas).

Augstāk redzamajā attēlā:

Tabula A ir šifrēta ar atslēgu 1 (Key 1). Atslēga 1 tiek šifrēta ar galveno atslēgu (master key) un tiek glabāta šifrētā veidā tabulas A virsrakstā.
Tabula B ir šifrēta ar atslēgu 2 (Key 2). Atslēga 2 tiek šifrēta ar galveno atslēgu (master key) un tiek glabāta šifrētā veidā tabulas B virsrakstā.
Un tā tālāk.

Kad serverim ir nepieciešams atšifrēt tabulu A, tas iegūst galveno atslēgu no krātuves, izlasa šifrēto atslēgu 1 no tabulas A virsraksta un atšifrē atslēgu 1. Atšifrētā atslēga 1 tiek kešota servera atmiņā un tiek izmantota tabulas A atšifrēšanai.

InnoDB

InnoDB faktiskā šifrēšana un atšifrēšana tiek veikta ievades-izvades līmenī. Proti, lapa tiek šifrēta tieši pirms tās rakstīšanas uz diska un atšifrēta uzreiz pēc nolasīšanas no diska.

InnoDB šifrēšana darbojas tikai tabulu telpu līmenī. Un pēc noklusējuma visas tabulas tiek veidotas atsevišķās tabulu telpās (file-per-table tablespace). Citiem vārdiem sakot, tiek izveidota tabulu telpa, kas var saturēt tikai vienu tabulu. Lai gan jūs varat veidot tabulas arī primārajā tabulu telpā (general tablespace). Tomēr tabula vienmēr atrodas kādā tabulā. Un, ņemot vērā, ka šifrēšana notiek tabulas līmenī, tā vai nu ir pilnībā šifrēta, vai nav. Proti, nav iespējams pamattablē šifrēt tikai daļu no tabulām.

Ja kāda iemesla dēļ jums ir atslēgta file-per-table, tad visas tabulas tiek izveidotas sistēmas tabulā (system tablespace). Katram Percona Server for MySQL var šifrēt sistēmas tabulu, izmantojot mainīgo innodbsystablespaceencrypt vai izmantojot šifrēšanas pavedienus (encryption threads), taču tā joprojām ir eksperimentāla funkcija. MySQL to nesniedz.

Pirms turpinām, mums ir jāizskata galvenā atslēgas identifikatora struktūra (master key ID). Tā sastāv no UUID, KEYID un prefiksa "INNODBKey". Tas izskatās šādi: INNODBKey-UUID-KEYID.

UUID ir servera UUID ar šifrēto tabulas telpu. KEYID ir vienkārši pastāvīgi pieaugoša vērtība. Sākotnējā galvenās atslēgas izveidē KEYID ir 1. Atslēgas rotācijas gadījumā, kad tiek veidota jauna galvenā atslēga, KEYID = 2 un tā tālāk. Par galvenās atslēgas rotāciju mēs runāsim nākamajos šīs sērijas rakstos.

Tagad, kad mēs zinām, kā izskatās galvenās atslēgas identifikators, aplūkosim šifrētās tabulas telpas galveni. Kad tabulas telpa tiek šifrēta, informācija par šifrēšanu tiek pievienota galvene. Tas izskatās šādi:

KEY ID ir KEYID no galvenās atslēgas identifikatora, par kuru mēs jau runājām. UUID ir servera UUID, kas arī tiek izmantots galvenās atslēgas identifikatorā. TABLESPACE KEY ir tabulas telpas atslēga, kas sastāv no 256 bitiem, ko nejauši ģenerējusi servera. Inicializācijas vektors (IV, initialization vector) arī sastāv no 256 nejauši ģenerētiem bitiem (lai gan tiem jābūt 128 biti). IV tiek izmantots šifrēšanas un atšifrēšanas AES inicializācijai (no 256 bitiem tiek izmantoti tikai 128). Beigās ir CRC32 kopsumma TABLESPACE KEY un IV.

Visu šo laiku esmu nedaudz vienkāršojis, sakot, ka virsrakstā ir šifrēts tabulu telpas atslēga. Patiesībā tabulu telpas atslēga un inicializācijas vektors tiek glabāti un šifrēti kopā ar galveno atslēgu. Atcerieties, ka pirms tabulu telpas atslēgas un inicializācijas vektora šifrēšanas tiem tiek aprēķināta CRC32.

Kāpēc ir vajadzīga CRC32?

Ja runā divos vārdos, lai pārliecinātos par galvenās atslēgas derīgumu. Pēc tabulu telpas atslēgas un inicializācijas vektora atšifrēšanas tiek aprēķināta kontroles summa un salīdzināta ar virsrakstā glabāto CRC32. Ja kontroles summas sakrīt, tad mums ir pareiza galvenā atslēga un tabulu telpas atslēga. Pretējā gadījumā tabulu telpa tiek atzīmēta kā trūkstoša (mēs tāpat nevarēsim to atšifrēt).

Jūs varat vaicāt: kurā brīdī tiek veikta atslēgu pārbaude? Atbilde — servera palaišanas brīdī. Serveris ar šifrētām tabulām / tabulu telpām palaišanas laikā nolasīt UUID, KEYID no virsraksta un ģenerē galvenās atslēgas identifikatoru. Pēc tam tas saņem nepieciešamo galveno atslēgu no glabātavas (keyring), atšifrē tabulu telpas atslēgu un pārbauda kontroles summu. Vēlreiz, ja kontroles summa sakrīt, tad viss ir kārtībā, ja nē — tabulu telpa tiek atzīmēta kā trūkstoša.

Ja jūs lasījāt iepriekšējo šīs sērijas rakstu (Šifrēšana MySQL: atslēgu krātuve), tad iespējams, ka jūs atceraties, ka, izmantojot servera atslēgu glabātuvi, serveris palaišanas laikā saņem tikai atslēgu identifikatoru sarakstu, precīzāk, key id un user id, jo šī pāris viennozīmīgi identificē atslēgu. Un tagad es saku, ka serveris palaišanas laikā saņem visas atslēgas, kas nepieciešamas, lai pārbaudītu iespēju atšifrēt tabulu telpu atslēgas. Tātad kāpēc, inicializācijas laikā, servera atslēgu glabātavas gadījumā, tiek ielādēti tikai keyid un userid, nevis visas atslēgas? Jo jums var nebūt nepieciešamas visas atslēgas. Tas galvenokārt saistīts ar galvenās atslēgas rotāciju. Kad galvenā atslēga tiek rotēta, glabātavā tiek izveidota jauna galvenā atslēga, bet vecās atslēgas netiek dzēstas. Tādējādi servera atslēgu glabātavā jums var būt daudz atslēgu, kas nav nepieciešamas serverim un tādējādi netiek iegūtas servera palaišanas laikā.

Ir pienācis laiks nedaudz parunāt par šifrēšanas ar galveno atslēgu priekšrocībām un trūkumiem. Lielākā priekšrocība ir tāda, ka jums ir nepieciešama tikai viena šifrēšanas atslēga (galvenā atslēga), kuru glabājat atsevišķi no saviem šifrētajiem datiem. Tas padara servera palaišanu ātru, un krātuve ir neliela, kas atvieglo pārvaldību. Turklāt vienu galveno atslēgu ir viegli pārgenerēt.

Tomēr šifrēšana ar galveno atslēgu ir ar vienu lielu trūkumu: pēc tam, kad tabulu telpa ir šifrēta, izmantojot tablespace_key, tā vienmēr paliek šifrēta ar to pašu atslēgu. Šeit galvenās atslēgas rotācija nepalīdz. Kāpēc tas ir trūkums? Mēs zinām, ka MySQL ir kļūmes, kas var izraisīt pēkšņu sabrukumu un core faila izveidi. Tā kā core fails satur servera atmiņas dumpu, var gadīties, ka dumpā būs atšifrēta tabulu telpas atslēga. Vēl sliktāk, atšifrētās tabulu telpas atslēgas tiek glabātas atmiņā, kas var tikt apmainīta uz disku. Jūs varat teikt, ka tas nav trūkums, jo nepieciešama root piekļuve, lai piekļūtu šiem failiem un swap nodalījumam. Jā. Bet root ir nepieciešams tikai uz kādu laiku. Kad kāds iegūst piekļuvi atšifrētajai tabulu telpas atslēgai, viņš vai viņa varēs turpināt to izmantot datu atšifrēšanai pat bez root piekļuves. Turklāt disks var tikt nozagts, un swap nodalījums/core faili var tikt nolasīti ar trešo pušu rīkiem. TDE mērķis ir padarīt tos neizlasāmus, pat ja disks tiek nozags. Percona Server for MySQL tiek piedāvāta iespēja atkārtoti šifrēt tabulu telpu ar jauniem ģenerētiem atslēgām. Šī funkcija tiek saukta par šifrēšanas pavedieniem (encryption threads) un rakstības brīdī joprojām ir eksperimantāla.

Teorija un prakse ClickHouse izmantošanā reālās lietojumprogrammās. Aleksandrs Zaitsevs (2018.g.)