Në prag të fillimit të një grupi të ri për kursin  vazhdojmë të publikojmë një seri artikujsh mbi enkriptimin në MySQL.
NĂ« artikullin e kaluar tĂ« kĂ«saj serie () folĂ«m pĂ«r magazinat e çelĂ«save. NĂ« kĂ«tĂ« artikull do tĂ« shqyrtojmĂ« se si pĂ«rdoret çelĂ«si kryesor (master key), si dhe do tĂ« diskutojmĂ« pĂ«r avantazhet dhe disavantazhet e enkriptimit me metodĂ«n e enĂ«ve (envelope encryption).Â
Ideja e enkriptimit me enë është që çelësat e përdorur për enkriptim (çelësa të tabelave) enkriptohen me një çelës tjetër (çelësi kryesor, master key). Për enkriptimin e të dhënave, në fakt, përdoren çelësat e tabelave. Kjo mund të paraqitet grafikisht si:
ĂelĂ«si kryesor (master key) Ă«shtĂ« nĂ« magazinĂ«n e çelĂ«save (keyring), ndĂ«rsa çelĂ«sat e tabelave janĂ« nĂ« titujt e tabelave tĂ« enkriptura (nĂ« faqen 0 tĂ« tabelĂ«s).Â
Në figurën më sipër:
Tabeli A Ă«shtĂ« enkriptuar me çelĂ«sin 1 (Key 1). ĂelĂ«si 1 Ă«shtĂ« enkriptuar me çelĂ«sin kryesor (master key) dhe ruhet nĂ« formĂ« tĂ« enkriptuar nĂ« titullin e tabelit A.
Tabeli B Ă«shtĂ« enkriptuar me çelĂ«sin 2 (Key 2). ĂelĂ«si 2 Ă«shtĂ« enkriptuar me çelĂ«sin kryesor (master key) dhe ruhet nĂ« formĂ« tĂ« enkriptuar nĂ« titullin e tabelit B.
Dhe kështu me radhë.
Kur serveri ka nevojĂ« tĂ« dekriptojĂ« tabelĂ«n A, ai merr çelĂ«sin kryesor nga depoja, lexon çelĂ«sin e enkriptuar 1 nga titulli i tabelĂ«s A dhe dekripton çelĂ«sin 1. ĂelĂ«si i dekriptuar 1 ruhet nĂ« memorien e serverit dhe pĂ«rdoret pĂ«r dekriptimin e tabelĂ«s A.
InnoDB
Në InnoDB, enkriptimi dhe dekriptimi realizohen në nivelin e hyrjes-daljes. Kjo do të thotë se faqja enkriptohet menjëherë para se të shkarkohet në disk dhe dekriptohet menjëherë pas leximit nga disku.
NĂ« InnoDB, enkriptimi funksionon vetĂ«m nĂ« nivelin e hapĂ«sirave tĂ« tabelave. Dhe si rregull, tĂ« gjitha tabelat krijohen nĂ« hapĂ«sira tĂ« veçanta tabelash (). Duke folur ndryshe, krijohet njĂ« hapĂ«sirĂ« tabelash qĂ« mund tĂ« pĂ«rmbajĂ« vetĂ«m njĂ« tabelĂ«. MegjithatĂ«, ju gjithashtu mund tĂ« krijoni tabela nĂ« hapĂ«sirĂ«n e pĂ«rgjithshme tĂ« tabelave (). Por çdo rast, tabela gjithmonĂ« ndodhet nĂ« ndonjĂ« hapĂ«sirĂ« tabelash. Dhe pĂ«r shkak se enkriptingu kryhet nĂ« nivelin e hapĂ«sirĂ«s tabelore, ajo Ă«shtĂ« ose e gjithĂ« e enkriptuar, ose jo. Do tĂ« thotĂ« se nĂ« hapĂ«sirĂ«n kryesore tabelore nuk mund tĂ« enkriptohet vetĂ«m njĂ« pjesĂ« e tabelave.Â
Nëse për ndonjë arsye keni çaktivizuar file-per-table, të gjitha tabelat krijohen brenda hapësirës tabelore sistematike (system tablespace). Në hapësirën tabelore sistematike mund të enkriptohet me anë të variablës innodbsystablespaceencrypt ose duke përdorur rrjedha enkriptimi (encryption threads), por kjo është ende një funksion eksperimental. Kjo nuk ndodhet në MySQL.
Para se të vazhdojmë, na nevojitet të shqyrtojmë strukturën e identifikuesit të çelësit kryesor (master key ID). Ai përbëhet nga UUID, KEYID dhe prefiksi «INNODBKey». Kjo duket kështu: INNODBKey-UUID-KEYID.
UUID â Ă«shtĂ« uuid i serverit me hapĂ«sirĂ«n tabelore tĂ« enkriptuar. KEYID â Ă«shtĂ« vetĂ«m njĂ« vlerĂ« qĂ« rritet vazhdimisht. NĂ« krijimin fillestar tĂ« çelĂ«sit kryesor, KEYID Ă«shtĂ« e barabartĂ« me 1. NĂ« rrotullimin e çelĂ«sit, kur krijohet njĂ« çelĂ«s i ri kryesor, KEYID = 2 dhe kĂ«shtu me radhĂ«. NĂ« vazhdim do tĂ« flasim mĂ« nĂ« detaje pĂ«r rotacionin e çelĂ«save kryesorĂ« nĂ« artikujt e tjerĂ« tĂ« kĂ«saj serie.
Tani që dimë se si duket identifikuesi i çelësit kryesor, le të shikojmë titullin e hapësirës së tabelave të enkriptuara. Kur hapësira e tabelave është e enkriptuar, informacioni mbi enkriptimin i shtohet titullit. Kjo duket si më poshtë:
ĂELSI ID â Ă«shtĂ« ĂELSIID nga identifikuesi i çelĂ«sit kryesor, i cili Ă«shtĂ« diskutuar mĂ« parĂ«. UUID Ă«shtĂ« uuid i serverit, i cili gjithashtu pĂ«rdoret nĂ« identifikuesin e çelĂ«sit kryesor. ĂELSI I HAPĂSIRĂS SĂ TABELAVE â Ă«shtĂ« çelĂ«si i hapĂ«sirĂ«s sĂ« tabelave, i cili pĂ«rbĂ«het nga 256 bit, tĂ« gjeneruar rastĂ«sisht nga serveri. Vektori i inicializimit (IV, initialization vector) gjithashtu pĂ«rbĂ«het nga 256 bit tĂ« gjeneruar rastĂ«sisht (ndonĂ«se duhet tĂ« jetĂ« 128 bit). IV pĂ«rdoret pĂ«r tĂ« inicializuar enkriptime dhe dekriptime AES (nga 256 bit, pĂ«rdoren vetĂ«m 128). NĂ« fund, prihet njĂ« kontrollues CRC32 pĂ«r ĂELSIN E HAPĂSIRĂS SĂ TABELAVE dhe IV.
Gjatë gjithë këtij kohë kam thënë pak më thjesht që në titull ka një çelës të koduar të hapësirës së tabelës. Në të vërtetë, çelësi i hapësirës së tabelës dhe vektori i inicializimit ruhen dhe kodohen së bashku me çelësin kryesor. Kini parasysh se para se të kodohen çelësi i hapësirës së tabelës dhe vektori i inicializimit, për to llogaritet CRC32.
Pse është e nevojshme CRC32?
Nëse e shprehim në dy fjalë, që të sigurohemi për vlefshmërinë e çelësit kryesor. Pas çkodimit të çelësit të hapësirës së tabelës dhe vektorit të inicializimit, llogaritet një shumë kontrolli dhe krahasohet me CRC32-në e ruajtur në titull. Nëse shumat e kontrollit përputhen, atëherë kemi çelësin kryesor të duhur dhe çelësin e hapësirës së tabelës. Në të kundërt, hapësira e tabelës shënohet si e munguar (ndonëse ende nuk do të mund ta çkodojmë).
Mund tĂ« pyesni: nĂ« cilin moment kryhet verifikimi i çelĂ«save? PĂ«rgjigja Ă«shtĂ« â gjatĂ« nisjes sĂ« serverit. Serveri me tabela tĂ« koduara / hapĂ«sira tabelash lexon UUID-nĂ«, KEY nĂ« fillim.ID nga titulli dhe gjeneron identifikuesin e çelĂ«sit kryesor. Pastaj, ai merr çelĂ«sin kryesor tĂ« nevojshĂ«m nga depoja (keyring), çelon çelĂ«sin e hapĂ«sirĂ«s sĂ« tabelĂ«s dhe kontrollon shenjĂ«n e kontrollit. PĂ«rsĂ«ri, nĂ«se shenja e kontrollit pĂ«rputhet, gjithçka Ă«shtĂ« nĂ« rregull, nĂ«se jo â hapĂ«sira e tabelĂ«s shĂ«nohet si e munguar.
Nëse keni lexuar artikullin e kaluar të kësaj serie (), mund të mbani mend se kur përdoret depoja e çelësave në server, serveri, në fillim, merr vetëm listën e identifikuesve të çelësave, më saktësisht, key id dhe user id, pasi kjo çift e identifikon qartë çelësin. Dhe tani po them, se serveri, në fillim, merr të gjithë çelësat e nevojshëm për verifikimin e mundësisë për të çelësuar çelësat e hapësirave të tabelave. Pra, pse gjatë inicializimit, në rastin e depojes së çelësit në server, ngarkohen vetëm keyid dhe userid, dhe jo të gjitha çelësat? Sepse ndoshta nuk keni nevojë për të gjithë çelësat. Kjo kryesisht lidhet me rotacionin e çelësit kryesor. Kur çelësi kryesor rotullohet në magazinë, krijohet një çelës i ri kryesor, por çelësat e vjetër nuk fshihen. Prandaj, në magazinën e serverit të çelësave mund të keni shumë çelësa që nuk i nevojiten serverit dhe, si pasojë, nuk nxirren gjatë aktivizimit të serverit.
Ka ardhur koha për të biseduar pak për avantazhet dhe disavantazhet e enkriptimit duke përdorur çelësin kryesor. Avantazhi më i madh është se ju nevojitet vetëm një çelës enkriptimi (çelësi kryesor), që do të ruhet veçmas nga të dhënat tuaja të enkriptuara. Kjo e bën aktivizimin e serverit të shpejtë, dhe magazinën të vogël, gjë që e lehtëson menaxhimin. Dhe gjithashtu çelësi kryesor i vetëm është lehtësisht i riparueshëm.
Megjithatë, enkriptimi me çelësin kryesor ka një të metë të madhe: një herë që hapësira e tabelave është enkriptuar me tablespace_key, ajo mbetet gjithmonë e enkriptuar me të njëjtin çelës. Rrotullimi i çelësit kryesor këtu nuk ndihmon. Pse është kjo një e metë? Ne e dimë se në MySQL ka bugs që mund të çojnë në dështim të papritur dhe krijimin e një skedari core. Duke qenë se skedari core përmban një dump të memories së serverit, mund të ndodhë që në dump të ketë çelësin e enkriptuar të hapësirës së tabelave. Ajo që është edhe më e keqe, çelësat e enkriptuar të hapësirës së tabelave ruhen në memory, e cila mund të swap në disk. Mund të thoni se kjo nuk është një e metë, pasi ju nevojiten të drejtat root për të aksesuar këto skedarë dhe seksionin e swap. Po, por root është i nevojshëm vetëm për një kohë të shkurtër. Sa herë që dikush të ketë akses në çelësin e enkriptuar të hapësirës së tabelave, ai/ajo do të jetë në gjendje ta përdorë atë për të dekoduar të dhënat, madje pa pasur nevojë për të drejtat root. Për më tepër, disku mund të vidhet, dhe skedarët e swapit/core mund të lexohen me ndihmën e mjeteve të jashtme. Qëllimi i TDE është ta bëjë atë të padukshëm, edhe nëse disku vidhet. ka mundësi për rishifrimin e hapësirës tablike me çelësa të rinj të gjeneruar. Kjo funksion quhet rrjedha e enkriptimit (encryption threads) dhe në momentin e shkruajtjes së këtij artikulli ende përfundimisht është eksperimentale.
Lexoni më shumë:
Burimi: habr.com
