Me para fillimit të një grupi të ri për kursin përgatitëm për ju një përkthim të artikullit të dobishëm.
Enkriptimi i transparencës së të dhënave (Transparent Data Encryption, TDE) ka qenë i pranishëm në dhe MySQL për një kohë të gjatë. Por a keni menduar ndonjëherë se si funksionon ai nën kapak dhe çfarë ndikimi mund të ketë TDE mbi serverin tuaj? Në këtë seri artikujsh do të shqyrtojmë se si punon TDE nga brenda. Le të fillojmë me ruajtjen e çelësave, pasi kjo është e nevojshme për funksionimin e çdo enkriptimi. Pastaj do të shqyrtojmë me detaje se si funksionon enkriptimi në Percona Server for MySQL/MySQL dhe cilat janë mundësitë shtesë që ofron Percona Server for MySQL.
MySQL Keyring
Keyring Ă«shtĂ« njĂ« plugin qĂ« lejon serverin tĂ« kĂ«rkojĂ«, krijojĂ« dhe fshijĂ« çelĂ«sa nĂ« njĂ« skedar lokal (keyring_file) ose nĂ« njĂ« server tĂ« largĂ«t (pĂ«r shembull, nĂ« HashiCorp Vault). ĂelĂ«sat gjithmonĂ« ruhen nĂ« mĂ«nyrĂ« tĂ« pĂ«rkohshme pĂ«r t'i pĂ«rshpejtuar ata.
Plugin-t mund të ndahen në dy kategori:
- Ruajtje lokale. Për shembull, një skedar lokal (ne e quajmë këtë ruajtje të çelëve në skedar, file-based keyring).
- Ruajtje të largët. Për shembull, Vault Server (ne e quajmë këtë ruajtje të çelëve në server, server-based keyring).
Kjo ndarje është e rëndësishme, sepse lloje të ndryshme ruajtjesh veprojnë disi ndryshe jo vetëm gjatë ruajtjes dhe marrjes së çelësave, por edhe gjatë nisjes.
Kur përdorni ruajtjen e skedarëve, gjatë nisjes ngarkohet e gjithë përmbajtja e ruajtjes në cache: id e çelësit, përdoruesi i çelësit, tipi i çelësit dhe çelësi vetë.
NĂ« rastin e ruajtjes nĂ« server (pĂ«r shembull, serveri Vault), gjatĂ« nisjes ngarkohet vetĂ«m id e çelĂ«sit dhe pĂ«rdoruesi i çelĂ«sit, kĂ«shtu qĂ« marrja e tĂ« gjithĂ« çelĂ«save nuk ngadalĂ«son nisjen. ĂelĂ«sat ngarkohen me mospĂ«rfshirje. Kjo do tĂ« thotĂ« se çelĂ«si vetĂ« ngarkohet nga Vault vetĂ«m kur Ă«shtĂ« vĂ«rtet e nevojshme. Pas ngarkimit, çelĂ«si ruhet nĂ« memorien e pĂ«rkohshme pĂ«r tĂ« shmangur nevojĂ«n pĂ«r ta kĂ«rkuar nĂ«pĂ«rmjet lidhjeve TLS me Vault Server. Le tĂ« shohim se çfarĂ« informacioni Ă«shtĂ« i pranishĂ«m nĂ« ruajtjen e çelĂ«save.
Informacioni mbi çelësin përfshin:
- id e çelĂ«sit â identifikuesi i çelĂ«sit, pĂ«r shembull:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - tipi i çelĂ«sit â lloji i çelĂ«sit, i bazuar nĂ« algoritemin e enkriptimit tĂ« pĂ«rdorur, vlerat e mundshme: "AES", "RSA" ose "DSA".
- gjerĂ«sia e çelĂ«sit â gjatĂ«sia e çelĂ«sit nĂ« byte, AES: 16, 24 ose 32, RSA 128, 256, 512 dhe DSA 128, 256 ose 384.
- user â pronari i çelĂ«sit. NĂ«se çelĂ«si Ă«shtĂ« sistemik, pĂ«r shembull, Master Key, atĂ«herĂ« ky fushĂ« Ă«shtĂ« bosh. NĂ«se çelĂ«si krijohet me keyring_udf, atĂ«herĂ« ky fushĂ« pĂ«rfaqĂ«son pronarin e çelĂ«sit.
- çelësi vetë
ĂelĂ«si identifikohet nĂ« mĂ«nyrĂ« tĂ« pĂ«rcaktuar nga çifti: key_id, user.
Ka gjithashtu dallime në ruajtjen dhe fshirjen e çelësave.
Ruajtja e skedarëve funksionon më shpejt. Mund të supozohet se ruajtja e çelësave është një shkrim i thjeshtë i vetëm i çelësit në skedar, por jo - këtu ndodhin më shumë operacione. Në çdo modifikim të ruajtjes së skedarëve, fillimisht krijohet një kopje rezervë e të gjithë përmbajtjes. Le të supozojmë se skedari quhet my_biggest_secrets, kështu që kopja rezervë do të jetë my_biggest_secrets.backup. Pastaj modifikohet ndihmesa (shtohen ose hiqen çelësat) dhe, nëse gjithçka është kryer me sukses, ndihmesa e rinovohet në skedar. Në raste të rralla, siç është dështimi i serverit, mund të shihni këtë skedar kopje rezervë. Skedari i kopjeve rezervë fshihet gjatë ngarkimit të ardhshëm të çelësave (zakonisht pas rinisjes së serverit).
Kur ruhet ose fshihet një çelës në ruajtjen e serverit, ruajtja duhet të lidhet me serverin MySQL me komandat "dërgo çelësin" / "kërko fshirjen e çelësit" ("send the key" / "request key deletion").
Të kthehemi te shpejtësia e nisjes së serverit. Përveç faktit se ruajtja vetë ndikon në shpejtësinë e nisjes, ka gjithashtu pyetje nëse sa çelësa nga ruajtja duhet të merren gjatë nisjes. Sigurisht, kjo është veçanërisht e rëndësishme për ruajtjet e serverëve. Gjatë nisjes, serveri kontrollon se cili çelës është i nevojshëm për tabelat e enkriptuara / hapësirat e tregjeve dhe kërkon çelësin nga ruajtja. Në një server "të pastër" me Master Key - enkriptimi duhet të ketë një Master Key, i cili duhet të nxirret nga ruajtja. Megjithatë, mund të nevojitet gjithashtu një numër më i madh çelësash, për shembull, kur një server rezervë rikthen një kopje rezervë nga serveri kryesor. Në këso raste, duhet të parashikohet rotacioni i Master Key. Më shumë informacione për këtë do të shqyrtohen në artikujt e ardhshëm, megjithatë këtu do të doja të theksoja se një server që përdor disa Master Key mund të nisë pak më ngadalë, veçanërisht kur përdoret ruajtja e çelësave të serverit.
Tani le të flasim edhe pak për keyring_file. Kur zhvilloja keyring_file, gjithashtu më shqetësonte se si të kontrolloja ndryshimin e keyring_file gjatë funksionimit të serverit. Në 5.7 kontrolli u krye në bazë të statistikave të skedarit, që nuk ishte një zgjidhje e përkryer, dhe në 8.0 u zëvendësua me një kontroll të shumës SHA256.
Kur startimin e parë, keyring_file llogarit statistikën e skedarit dhe shumën kontrolluese, të cilat regjistrohen nga serveri, dhe ndryshimet aplikohen vetëm nëse ato përputhen. Kur skedari ndryshohet, shuma kontrolluese përditësohet.
Ne kemi shqyrtuar shumë çështje në lidhje me depozitat e çelësave. Megjithatë, ka një temë tjetër të rëndësishme që shpesh harrohet ose kuptohet gabimisht - ndarja e çelësave sipas serverëve.
ĂfarĂ« kam nĂ« mendje? Ădo server (pĂ«r shembull, Percona Server) nĂ« klaster duhet tĂ« ketĂ« njĂ« vend tĂ« veçantĂ« nĂ« serverin Vault, nĂ« tĂ« cilin Percona Server duhet tĂ« ruajĂ« çelĂ«sat e tij. NĂ« secilĂ«n Master Key, tĂ« ruajtur nĂ« depozitĂ«, pĂ«rmban GUID-in e serverit Percona Server brenda identifikatorit tĂ« saj. Pse Ă«shtĂ« kjo e rĂ«ndĂ«sishme? Imagjinoni se keni vetĂ«m njĂ« Vault Server dhe tĂ« gjithĂ« Percona Server nĂ« klaster pĂ«rdorin kĂ«tĂ« server tĂ« vetĂ«m Vault. Problemi duket i qartĂ«. NĂ«se tĂ« gjithĂ« Percona Server do tĂ« pĂ«rdornin Master Key pa identifikatorĂ« unikĂ«, pĂ«r shembull, id = 1, id = 2 etj., atĂ«herĂ« tĂ« gjithĂ« serverĂ«t nĂ« klaster do tĂ« pĂ«rdornin tĂ« njĂ«jtin Master Key. Kjo qĂ« siguron GUID-i - ndarjen midis serverĂ«ve. Pse atĂ«herĂ« tĂ« flasim pĂ«r ndarjen e çelĂ«save midis serverĂ«ve, nĂ«se tashmĂ« ekziston njĂ« GUID unik? Ka njĂ« plugin tĂ« tjetĂ«r - keyring_udf. Me kĂ«tĂ« plugin, pĂ«rdoruesi i serverit tuaj mund tĂ« ruajĂ« çelĂ«sat e tij nĂ« serverin Vault. Problemi lind kur pĂ«rdoruesi krijon njĂ« çelĂ«s, pĂ«r shembull, nĂ« serverin server1, dhe pastaj pĂ«rpiqet tĂ« krijojĂ« njĂ« çelĂ«s me tĂ« njĂ«jtin identifikator nĂ« server2, pĂ«r shembull:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 do të thotë përfundim të suksesshëm
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Prit. TĂ« dy serverĂ«t pĂ«rdorin tĂ« njĂ«jtin Vault Server, a nuk duhet qĂ« funksioni keyring_key_store tĂ« pĂ«rfundojĂ« me njĂ« gabim nĂ« serverin server2? ĂshtĂ« interesante se nĂ«se pĂ«rpiqeni tĂ« bĂ«ni tĂ« njĂ«jtĂ«n gjĂ« nĂ« njĂ« server, do tĂ« merrni njĂ« gabim:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Saktë, ROB_1 tashmë ekziston.
Le të diskutojmë fillimisht shembullin e dytë. Siç e kemi thënë më parë, keyring_vault ose cdo plugin tjetër ruajtës (keyring) ruan të gjitha ID-të e çelësave në memorie. Kështu, pas krijimit të një çelësi të ri, ROB_1 shtohet në server1 dhe, përveç dërgimit të këtij çelësi në Vault, çelësi gjithashtu shtohet në ruajtjen e përkohshme. Tani, kur përpiqemi të shtojmë të njëjtin çelës për herë të dytë, keyring_vault kontrollon nëse ky çelës ekziston në ruajtje dhe jep një gabim.
NĂ« rastin e parĂ« situata Ă«shtĂ« ndryshe. NĂ« serverat server1 dhe server2 ekzistojnĂ« ruajtje tĂ« veçanta. Pas shtimit tĂ« ROB_1 nĂ« ruajtjen e çelĂ«ve nĂ« serverin server1 dhe serverin Vault, ruajtja e çelĂ«ve nĂ« server2 nuk Ă«shtĂ« sinkronizuar. NĂ« ruajtje nĂ« server2 nuk ka çelĂ«sin ROB_1. KĂ«shtu, çelĂ«si ROB_1 shkruhet nĂ« keyring_key_store dhe nĂ« serverin Vault, i cili nĂ« fakt riparon (!) vlerĂ«n e mĂ«parshme. Tani çelĂ«si ROB_1 nĂ« serverin Vault Ă«shtĂ« 543210987654321. ĂshtĂ« e çuditshme qĂ« serveri Vault nuk e ndalon njĂ« veprim tĂ« tillĂ« dhe thjesht riparon vlerĂ«n e vjetĂ«r.
Tani ne shohim se pse ndarja nĂ« servera nĂ« Vault mund tĂ« jetĂ« e rĂ«ndĂ«sishme â kur pĂ«rdorni keyring_udf dhe dĂ«shironi tĂ« ruani çelĂ«sat nĂ« Vault. Si mund tĂ« sigurohet njĂ« ndarje e tillĂ« nĂ« serverin Vault?
Ka dy mënyra për të bërë ndarjen në Vault. Mund të krijoni pika të ndryshme montimi për secilin server ose të përdorni rrugë të ndryshme brenda një pike montimi. Më së miri këtë e ilustrojnë shembujt. Pra, le të shohim fillimisht pikat e veçanta të montimit:
--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)Këtu shihet se server1 dhe server2 përdorin pika të ndryshme montimi. Kur ndajmë rrugët, konfigurimi do të duket si më poshtë:
--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)Në këtë rast, të dy serverët përdorin të njëjtën pikë montimi "mount_point", por rrugë të ndryshme. Kur krijoni sekretin e parë në serverin server1 në këtë rrugë, serveri Vault automatikisht krijon direktorinë "server1". Për serverin server2, gjithçka është e ngjashme. Kur fshini sekretin e fundit në mount_point/server1 ose mount_point/server2, serveri Vault gjithashtu fshin këto direktorive. Nëse përdorni ndarjen e rrugëve, duhet të krijoni vetëm një pikë montimi dhe të ndryshoni skedarët e konfigurimit që serverët të përdorin rrugë të ndara. Pikën e montimit mund ta krijoni përmes një kërkese HTTP. Me CURL, mund ta bëni si në vijim:
curl -L -H "X-Vault-Token: TOKEN" âcacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTTë gjithë fushat (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) përputhen me parametrat e skedarit të konfigurimit. Sigurisht, mund të përdorni utilitarët e Vault për të bërë të njëjtën gjë. Por kështu është më e lehtë të automatizoni krijimin e pikës së montimit. Shpresoj se kjo informacion do të jetë e dobishme për ju, dhe do të takohemi në artikujt e tjerë të kësaj serie.
Lexoni më shumë:
Burimi: habr.com
