Me para 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 () ne 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 envelopes (envelope encryption).Â
Ideja e enkriptimit me envelopes është se çelësat e përdorur për enkriptimin e të dhënave (çelësat e hapësirave të tabelave) enkriptohen me një çelës tjetër (çelësi kryesor, master key). Për të enkriptuar të dhënat, në të vërtetë përdoren çelësat e hapësirave të tabelave. Grafisht, kjo mund të paraqitet si më poshtë:
ĂelĂ«si kryesor (master key) ndodhet nĂ« magazinĂ«n e çelĂ«save (keyring), ndĂ«rsa çelĂ«sat e hapĂ«sirave tĂ« tabelave janĂ« nĂ« titujt e hapĂ«sirave tĂ« tabelave tĂ« enkriptuara (nĂ« faqen 0 tĂ« hapĂ«sirĂ«s sĂ« tabelave).Â
Në figurën më lart:
Tabelat A Ă«shtĂ« e enkriptuar me çelĂ«sin 1 (Key 1). ĂelĂ«si 1 enkriptohet me çelĂ«sin kryesor (master key) dhe ruhet nĂ« formĂ« tĂ« enkriptuar nĂ« titullin e tabelĂ«s A.
Tabelat B Ă«shtĂ« e enkriptuar me çelĂ«sin 2 (Key 2). ĂelĂ«si 2 enkriptohet me çelĂ«sin kryesor (master key) dhe ruhet nĂ« formĂ« tĂ« enkriptuar nĂ« titullin e tabelĂ«s B.
Dhe kështu me radhë.
Kur serveri ka nevojĂ« tĂ« dekriptojĂ« tabelĂ«n A, ai merr çelĂ«sin kryesor nga magazina, lexon çelĂ«sin e enkriptuar 1 nga titulli i tabelĂ«s A dhe e dekripton çelĂ«sin 1. ĂelĂ«si 1 i dekriptuar ruhet nĂ« memorie dhe pĂ«rdoret pĂ«r tĂ« dekriptuar tabelĂ«n 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ë shkruhet në disk dhe dekriptohet menjëherë pas leximit nga disku.
NĂ« InnoDB, enkriptimi funksionon vetĂ«m nĂ« nivelin e hapĂ«sirave tĂ« tabelave. Dhe me default, tĂ« gjitha tabelat krijohen nĂ« hapĂ«sira tĂ« veçanta tabelash (). Duke e thĂ«nĂ« 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 kryesore tĂ« tabelĂ«s (). Por nĂ« çdo rast, tabela gjithmonĂ« ndodhet nĂ« ndonjĂ« hapĂ«sirĂ« tabelash. Dhe pĂ«r shkak se enkriptimi realizohet nĂ« nivelin e hapĂ«sirĂ«s sĂ« tabelĂ«s, ajo Ă«shtĂ« ose e enkriptuar plotĂ«sisht, ose jo. Kjo do tĂ« thotĂ« se nuk Ă«shtĂ« e mundur tĂ« enkriptohet vetĂ«m njĂ« pjesĂ« e tabelave nĂ« hapĂ«sirĂ«n kryesore tĂ« tabelĂ«s.Â
Nëse për ndonjë arsye ju është çaktivizuar file-per-table, të gjitha tabelat krijohen brenda hapësirës tabelare sistemore (system tablespace). Në mund të enkriptohet hapësira tabelare sistemore me anë të variablit innodbsystablespaceencrypt ose duke përdorur rrjedhat e enkriptimit (encryption threads), por kjo është ende një funksion eksperimental. Në MySQL nuk është i pranishëm.
Para se të vazhdojmë, na duhet të shqyrtojmë strukturën e identifikuesit të çelësit master (master key ID). Ai përbëhet nga UUID, KEYID dhe prefiksin "INNODBKey". Duket kështu: INNODBKey-UUID-KEYID.
UUID është uuid i serverit me hapësirën tabelare të enkriptuar. KEYID është thjesht një vlerë që rritet vazhdimisht. Në krijimin fillestar të çelësit master, KEYID është 1. Kur rrotullohet çelësi, kur krijohet një çelës i ri master, KEYID = 2 dhe kështu me radhë. Më shumë detaje mbi rrotullimin e çelësve master do të flasim në artikujt e ardhshëm të kësaj serie.
Tani që e dimë se si duket identifikuesi i çelësit master, le të shohim në titullin e hapësirës tabelare të enkriptuar. Kur hapësira tabelare është e enkriptuar, informata për enkriptimin shtohet në titull. Duket kështu:
KEY ID është KEYID nga identifikuesi i çelësit master që tashmë e kemi diskutuar. UUID është uuid i serverit, i cili gjithashtu përdoret në identifikuesin e çelësit master. TABLESPACE KEY është çelësi i hapësirës tabelare, i cili përbëhet nga 256 bits të gjeneruar rastësisht nga serveri. Vektori i inicializimit (IV, initialization vector) gjithashtu përbëhet nga 256 bits të gjeneruar rastësisht (megjithëse duhet të jetë 128 bits). IV përdoret për të inicializuar enkriptimin dhe dekriptimin AES (nga 256 bits përdoren vetëm 128). Në fund, ndodhet një kontrolle CRC32 për TABLESPACE KEY dhe IV.
Të gjithë këtë kohë kam thënë pak më thjesht, duke thënë se në titull ndodhet një çelës tabelar i enkriptuar. Në të vërtetë, çelësi i hapësirës tabelare dhe vektori i inicializimit ruhen dhe enkriptohen së bashku me anë të çelësit master. Mos harroni se para se të enkriptohet çelësi i hapësirës tabelare dhe vektori i inicializimit, për ta llogaritet CRC32.
Pse është e nevojshme CRC32?
Nëse e shprehim në dy fjalë, qëllimi është të sigurohemi për vlefshmërinë e çelësit kryesor. Pasi të dekriptohet çelësi i hapësirës së tabelës dhe vektori i inicializimit, llogaritet një kontroll i shumës dhe krahasohet me CRC32, të ruajtur në titull. Nëse kontrolli i shumës përputhet, atëherë kemi çelësin kryesor të saktë dhe çelësin e hapësirës së tabelës. Përndryshe, hapësira e tabelës shënohet si e munguar (ne prapë nuk do të jemi në gjendje ta dekodojmë).
Mund tĂ« pyesni: nĂ« ç'moment bĂ«het kontrolli i çelĂ«save? PĂ«rgjigja Ă«shtĂ« â gjatĂ« fillimit tĂ« serverit. Serveri me tabela tĂ« enkriptuara \/ hapĂ«sira tĂ« tabelave, gjatĂ« nisjes lexon UUID, KEYID nga titulli dhe gjeneron identifikuesin e çelĂ«sit kryesor. MĂ« pas, ai merr çelĂ«sin kryesor tĂ« nevojshĂ«m nga depoja (keyring), dekripton çelĂ«sin e hapĂ«sirĂ«s sĂ« tabelĂ«s dhe kontrollon kontrollin e shumĂ«s. PĂ«rsĂ«ri, nĂ«se kontrolli i shumĂ«s 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 (), ndoshta e mbani mend se kur përdoret depoja e çelësave në server, serveri gjatë nisjes merr vetëm listën e identifikuesve të çelësave, më saktë, id e çelësit dhe id e përdoruesit, pasi kjo çift e identifikon qartë çelësin. Tani po them se serveri gjatë nisjes merr të gjithë çelësat e nevojshëm për të verifikuar mundësinë e dekriptimit të çelësave të hapësirave të tabelave. Pse atëherë gjatë inicializimit, në rastin e depozita të çelësave në server, ngarkohen vetëm id e çelësitdhe id e përdoruesit, e jo të gjithë çelësat? Sepse mund të mos keni nevojë për të gjithë çelësat. Kjo lidhet kryesisht me rotacionin e çelësit kryesor. Gjatë rotacionit të çelësit kryesor, në depo krijohet një çelës i ri kryesor, por çelësat e vjetër nuk fshihen. Pra, në depozitat e çelësave në server mund të keni shumë çelësa që serveri nuk i nevojitet dhe, për pasojë, nuk shkarkohen gjatë nisjes së 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), i cili do të ruhet ndaras nga të dhënat tuaja të enkriptuara. Kjo e bën lançimin e serverit të shpejtë dhe ruajtjen e vogël, duke lehtësuar menaxhimin. Gjithashtu, çelësi kryesor është e lehtë për t'u rinovuar.
MegjithatĂ«, enkriptimi me çelĂ«sin kryesor ka njĂ« disavantazh tĂ« madh: pasi qĂ« hapĂ«sira e tabelĂ«s Ă«shtĂ« enkriptuar duke pĂ«rdorur tablespace_key, ajo gjithmonĂ« mbetet e enkriptuar me tĂ« njĂ«jtin çelĂ«s. Rrotullimi i çelĂ«sit kryesor kĂ«tu nuk ndihmon. Pse Ă«shtĂ« kjo njĂ« disavantazh? Ne e dimĂ« se nĂ« MySQL ka bugs qĂ« mund tĂ« çojnĂ« nĂ« dĂ«shtimin e papritur dhe krijimin e njĂ« skedari core. Duke qenĂ« se skedari core pĂ«rmban njĂ« dump tĂ« memories sĂ« serverit, mund tĂ« ndodhi qĂ« nĂ« dump tĂ« ketĂ« çelĂ«sin e dekriptuar tĂ« hapĂ«sirĂ«s sĂ« tabelĂ«s. ĂfarĂ« Ă«shtĂ« edhe mĂ« keq, çelĂ«sat e dekriptuar tĂ« hapĂ«sirĂ«s sĂ« tabelĂ«s ruhen nĂ« memorie, e cila mund tĂ« shkĂ«mbehet nĂ« disk. Mund tĂ« thoni se kjo nuk Ă«shtĂ« njĂ« disavantazh, pasi ju nevojiten tĂ« drejtat root pĂ«r tĂ« aksesuar kĂ«to skedarĂ« dhe seksionin swap. Po. Por root-i kĂ«rkohet vetĂ«m pĂ«r njĂ« periudhĂ« tĂ« shkurtĂ«r. Sapo dikush tĂ« fitojĂ« akses nĂ« çelĂ«sin e dekriptuar tĂ« hapĂ«sirĂ«s sĂ« tabelĂ«s, ai / ajo do tĂ« jetĂ« nĂ« gjendje ta pĂ«rdorĂ« atĂ« pĂ«r tĂ« dekriptuar tĂ« dhĂ«nat, edhe pa tĂ« drejta root. PĂ«r mĂ« tepĂ«r, disku mund tĂ« vidhet, ndĂ«rsa seksioni swap / skedarĂ«t core mund tĂ« lexohen me mjete tĂ« jashtme. QĂ«llimi i TDE Ă«shtĂ« ta bĂ«jĂ« atĂ« tĂ« pa lexueshĂ«m, edhe nĂ«se disku do tĂ« vidhet. ka mundĂ«sinĂ« pĂ«r tĂ« ripĂ«rfunduar hapĂ«sirĂ«n e tabelĂ«s me çelĂ«sa tĂ« rinj tĂ« gjeneruar. Kjo funksion quhet rrjedha e enkriptimit (encryption threads) dhe nĂ« momentin e shkruar tĂ« kĂ«tij artikulli akoma Ă«shtĂ« eksperimentale.
Lexoni më shumë:
Burimi: habr.com
