ProHoster > Blog > administratë > Kriptimi në MySQL: Keystore

Kriptimi në MySQL: Keystore

Në pritje të fillimit të një regjistrimi të ri për kursin "Baza e të dhënave" Ne kemi përgatitur një përkthim të një artikulli të dobishëm për ju.

Kriptimi në MySQL: Keystore

Kriptimi transparent i të dhënave (TDE) u shfaq në Serveri Percona për MySQL dhe MySQL për mjaft kohë. Por a keni menduar ndonjëherë se si funksionon nën kapuç dhe çfarë ndikimi mund të ketë TDE në serverin tuaj? Në këtë seri artikujsh do të shikojmë se si funksionon TDE nga brenda. Le të fillojmë me ruajtjen e çelësave, pasi kjo kërkohet që çdo kriptim të funksionojë. Më pas do të hedhim një vështrim më të afërt se si funksionon kriptimi në Percona Server për MySQL/MySQL dhe cilat veçori shtesë ka Percona Server për MySQL.

MySQL Keyring

Keyring janë shtojca që lejojnë serverin të kërkojë, krijojë dhe fshijë çelësat në një skedar lokal (keyring_file) ose në një server të largët (siç është HashiCorp Vault). Çelësat ruhen gjithmonë në memorie lokale për të përshpejtuar marrjen e tyre.

Pluginat mund të ndahen në dy kategori:

  • Magazinimi lokal. Për shembull, një skedar lokal (ne e quajmë këtë një çelës të bazuar në skedar).
  • Ruajtja në distancë. Për shembull, Vault Server (ne e quajmë këtë një çelës të bazuar në server).

Kjo ndarje është e rëndësishme sepse lloje të ndryshme të ruajtjes sillen paksa ndryshe, jo vetëm gjatë ruajtjes dhe marrjes së çelësave, por edhe gjatë përdorimit të tyre.

Kur përdorni një ruajtje skedari, pas nisjes, e gjithë përmbajtja e ruajtjes ngarkohet në cache: ID e çelësit, përdoruesi i çelësit, lloji i çelësit dhe vetë çelësi.

Në rastin e një dyqani nga ana e serverit (siç është Vault Server), vetëm id-ja e çelësit dhe përdoruesi kryesor ngarkohen gjatë nisjes, kështu që marrja e të gjithë çelësave nuk e ngadalëson fillimin. Çelësat janë të ngarkuar me dembelizëm. Kjo do të thotë, vetë çelësi ngarkohet nga Vault vetëm kur është i nevojshëm. Pasi të shkarkohet, çelësi ruhet në memorie në mënyrë që të mos ketë nevojë të aksesohet nëpërmjet lidhjeve TLS me serverin Vault në të ardhmen. Tjetra, le të shohim se çfarë informacioni është i pranishëm në dyqanin e çelësave.

Informacioni kryesor përmban sa vijon:

  • id i çelësit — identifikuesi kryesor, për shembull:
    INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
  • lloji i çelësit — lloji i çelësit bazuar në algoritmin e enkriptimit të përdorur, vlerat e mundshme: "AES", "RSA" ose "DSA".
  • gjatësia e çelësit — gjatësia e çelësit në bajt, AES: 16, 24 ose 32, RSA 128, 256, 512 dhe DSA 128, 256 ose 384.
  • përdorues - pronari i çelësit. Nëse çelësi është sistemi, për shembull, Master Key, atëherë kjo fushë është bosh. Nëse një çelës krijohet duke përdorur keyring_udf, atëherë kjo fushë identifikon pronarin e çelësit.
  • vetë çelësi

Çelësi identifikohet në mënyrë unike nga çifti: key_id, përdorues.

Ekzistojnë gjithashtu ndryshime në ruajtjen dhe fshirjen e çelësave.

Ruajtja e skedarëve është më e shpejtë. Ju mund të mendoni se një dyqan çelësash thjesht po shkruan një herë çelësin e një skedari, por jo, ka më shumë që ndodh këtu. Sa herë që bëhet një modifikim i ruajtjes së skedarëve, fillimisht krijohet një kopje rezervë e të gjithë përmbajtjes. Le të themi se skedari quhet my_biggest_secrets, atëherë kopja rezervë do të jetë my_biggest_secrets.backup. Më pas, cache-ja ndryshohet (çelësat shtohen ose fshihen) dhe, nëse gjithçka është e suksesshme, cache-ja rivendoset në një skedar. Në raste të rralla, siç është dështimi i serverit, mund ta shihni këtë skedar rezervë. Skedari rezervë fshihet herën tjetër që të ngarkohen çelësat (zakonisht pasi serveri të riniset).

Kur ruani ose fshini një çelës në një ruajtje të serverit, ruajtja duhet të lidhet me serverin MySQL me komandat "dërgo çelësin" / "kërkoni fshirjen e çelësit".

Le të kthehemi te shpejtësia e nisjes së serverit. Përveç faktit që shpejtësia e nisjes ndikohet nga vetë kasaforta, ekziston edhe çështja se sa çelësa nga kasaforta duhet të merren në fillim. Sigurisht, kjo është veçanërisht e rëndësishme për ruajtjen e serverit. Në nisje, serveri kontrollon se cili çelës kërkohet për tabelat/hapësirat e enkriptuara dhe kërkon çelësin nga ruajtja. Në një server "të pastër" me enkriptim të çelësit kryesor, duhet të ketë një çelës kryesor, i cili duhet të merret nga ruajtja. Megjithatë, mund të kërkohet një numër më i madh çelësash, për shembull, kur serveri rezervë po rikthen një kopje rezervë nga serveri primar. Në raste të tilla, duhet të sigurohet rrotullimi i çelësit kryesor. Kjo do të trajtohet më në detaje në artikujt e ardhshëm, megjithëse këtu do të doja të vëreja se një server që përdor shumë çelësa Master mund të marrë pak më shumë kohë për t'u ndezur, veçanërisht kur përdorni një dyqan çelësash nga ana e serverit.

Tani le të flasim pak më shumë për keyring_file. Kur po zhvilloja keyring_file, isha i shqetësuar gjithashtu se si të kontrolloja ndryshimet e keyring_file ndërsa serveri po funksiononte. Në 5.7, kontrolli u krye në bazë të statistikave të skedarëve, që nuk ishte një zgjidhje ideale, dhe në 8.0 u zëvendësua me një kontroll SHA256.

Herën e parë që ekzekutoni keyring_file, llogariten statistikat e skedarëve dhe një kontroll, të cilat mbahen mend nga serveri dhe ndryshimet zbatohen vetëm nëse përputhen. Kur skedari ndryshon, shuma e kontrollit përditësohet.

Ne kemi mbuluar tashmë shumë pyetje në lidhje me kasafortat kryesore. Sidoqoftë, ekziston një temë tjetër e rëndësishme që shpesh harrohet ose keqkuptohet: ndarja e çelësave nëpër serverë.

Çfarë dua të them? Çdo server (për shembull, Percona Server) në grup duhet të ketë një vendndodhje të veçantë në Serverin Vault në të cilin Serveri Percona duhet të ruajë çelësat e tij. Çdo çelës kryesor i ruajtur në ruajtje përmban GUID-in e serverit Percona brenda identifikuesit të tij. Pse është e rëndësishme? Imagjinoni që keni vetëm një Server Vault dhe të gjithë Serverët Percona në grup përdorin atë server të vetëm Vault. Problemi duket i qartë. Nëse të gjithë serverët Percona përdornin një çelës kryesor pa identifikues unikë, si p.sh. id = 1, id = 2, etj., atëherë të gjithë serverët në grup do të përdornin të njëjtin çelës kryesor. Ajo që ofron GUID është dallimi midis serverëve. Pse atëherë të flasim për ndarjen e çelësave midis serverëve nëse tashmë ekziston një GUID unik? Ekziston një shtesë tjetër - keyring_udf. Me këtë shtojcë, përdoruesi i serverit tuaj mund të ruajë çelësat e tij në serverin Vault. Problemi ndodh kur një përdorues krijon një çelës në server1, për shembull, dhe më pas përpiqet të krijojë një çelës me të njëjtën ID në server2, për shembull:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

Prisni. Të dy serverët përdorin të njëjtin server Vault, a nuk duhet të dështojë funksioni keyring_key_store në server2? Është interesante, 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");
0

Është e drejtë, ROB_1 ekziston tashmë.

Le të diskutojmë së pari shembullin e dytë. Siç thamë më herët, keyring_vault ose ndonjë shtesë tjetër çelësash ruan të gjitha ID-të e çelësave në memorie. Pra, 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 shtohet edhe në cache. Tani, kur përpiqemi të shtojmë të njëjtin çelës për herë të dytë, keyring_vault kontrollon nëse çelësi ekziston në cache dhe hedh një gabim.

Në rastin e parë situata është ndryshe. Serveri 1 dhe serveri 2 kanë cache të veçanta. Pas shtimit të ROB_1 në cache-in e çelësit në server1 dhe serverin Vault, memoria e çelësit në server2 është jashtë sinkronizimit. Nuk ka asnjë çelës ROB_2 në cache në server1. Kështu, çelësi ROB_1 është i shkruar në keyring_key_store dhe në serverin Vault, i cili në të vërtetë mbishkruan (!) vlerën e mëparshme. Tani çelësi ROB_1 në serverin Vault është 543210987654321. Është interesante që serveri Vault nuk i bllokon veprime të tilla dhe e rishkruan lehtësisht vlerën e vjetër.

Tani mund të shohim pse ndarja e serverit në Vault mund të jetë e rëndësishme - kur jeni duke përdorur keyring_udf dhe dëshironi të ruani çelësat në Vault. Si të arrihet kjo ndarje në një server Vault?

Ka dy mënyra për të ndarë në Vault. Mund të krijoni pika të ndryshme montimi për secilin server, ose të përdorni shtigje të ndryshme brenda së njëjtës pikë montimi. Kjo ilustrohet më së miri me shembuj. Pra, le të shohim së pari pikat individuale 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 mund të shihni se serveri1 dhe server2 po përdorin pika të ndryshme montimi. Kur ndani shtigjet, konfigurimi do të duket si ky:

--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 shtigje të ndryshme. Kur krijoni sekretin e parë në server1 duke përdorur këtë shteg, serveri Vault krijon automatikisht një direktori "server1". Për server2 gjithçka është e ngjashme. Kur fshini sekretin e fundit në mount_point/server1 ose mount_point/server2, serveri Vault gjithashtu i fshin ato drejtori. Në rast se përdorni ndarjen e shtigjeve, duhet të krijoni vetëm një pikë montimi dhe të ndryshoni skedarët e konfigurimit në mënyrë që serverët të përdorin shtigje të veçanta. Një pikë montimi mund të krijohet duke përdorur një kërkesë HTTP. Duke përdorur CURL kjo mund të bëhet si kjo:

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

Të gjitha fushat (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) korrespondojnë me parametrat e skedarit të konfigurimit. Sigurisht, ju mund të përdorni shërbimet Vault për të bërë të njëjtën gjë. Por është më e lehtë të automatizosh krijimin e një pike montimi. Shpresoj që ky informacion t'ju duket i dobishëm dhe do t'ju shohim në artikujt e ardhshëm në këtë seri.

Kriptimi në MySQL: Keystore

Lexo më shumë:

Burimi: www.habr.com

Shto një koment