{"id":97664,"date":"2020-10-20T08:42:20","date_gmt":"2020-10-20T06:42:20","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej"},"modified":"2020-10-20T08:42:20","modified_gmt":"2020-10-20T06:42:20","slug":"shifrovanie-v-mysql-hranilishhe-klyuchej","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"Kriptimi n\u00eb MySQL: depoja e \u00e7el\u00ebsave","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>N\u00eb prag t\u00eb fillimit t\u00eb nj\u00eb grupi t\u00eb ri p\u00ebr kursin <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">\u00abBaza t\u00eb dh\u00ebnash\u00bb<\/a><\/noindex> kemi p\u00ebrgatitur nj\u00eb p\u00ebrkthim t\u00eb nj\u00eb artikulli t\u00eb dobish\u00ebm p\u00ebr ju.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Kriptimi n\u00eb MySQL: depoja e \u00e7el\u00ebsave\" src=\"\/wp-content\/uploads\/2020\/10\/aeca40f53fe6bdf2a9897aa835ff597d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Enkriptimi i transparenc\u00ebs s\u00eb t\u00eb dh\u00ebnave (Transparent Data Encryption, TDE) ka dal\u00eb n\u00eb <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\">Percona Server p\u00ebr MySQL<\/a><\/noindex> dhe MySQL prej koh\u00ebsh. Por, a keni menduar ndonj\u00ebher\u00eb se si funksionon ai n\u00ebn kapak dhe \u00e7far\u00eb ndikimi mund t\u00eb ket\u00eb TDE n\u00eb serverin tuaj? N\u00eb k\u00ebt\u00eb seri artikujsh, ne do t\u00eb shqyrtojm\u00eb se si funksionon TDE nga brenda. Le t\u00eb fillojm\u00eb me ruajtjen e \u00e7el\u00ebsave, pasi \u00ebsht\u00eb e nevojshme p\u00ebr funksionimin e \u00e7do enkriptimi. Pastaj do t\u00eb shqyrtojm\u00eb me detaje se si funksionon enkriptimi n\u00eb Percona Server for MySQL\/MySQL dhe cilat mund\u00ebsi shtes\u00eb ka n\u00eb Percona Server for MySQL.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring jan\u00eb plgin\u00eb q\u00eb lejojn\u00eb serverin t\u00eb k\u00ebrkoj\u00eb, krijoj\u00eb dhe fshij\u00eb \u00e7el\u00ebsat n\u00eb nj\u00eb skedarin lokal (keyring_file) ose n\u00eb nj\u00eb server t\u00eb larg\u00ebt (p.sh., n\u00eb HashiCorp Vault). \u00c7el\u00ebsat gjithmon\u00eb ruhen n\u00eb cache lokal, p\u00ebr t\u00eb p\u00ebrshpejtuar marrjen e tyre. <\/p>\n<p>Plgin\u00ebt mund t\u00eb ndahen n\u00eb dy kategori:<\/p>\n<ul>\n<li>Ruajtje lokale. P\u00ebr shembull, nj\u00eb skedar lokal (ne e quajm\u00eb k\u00ebt\u00eb ruajtje \u00e7el\u00ebsash n\u00eb skedar, file-based keyring).<\/li>\n<li>Ruajtje t\u00eb larg\u00ebt. P\u00ebr shembull, Vault Server (ne e quajm\u00eb k\u00ebt\u00eb ruajtje \u00e7el\u00ebsash n\u00eb server, server-based keyring).<\/li>\n<\/ul>\n<p>\nKy\u00e7 i ndarjes \u00ebsht\u00eb i r\u00ebnd\u00ebsish\u00ebm, sepse llojet e ndryshme t\u00eb ruajtjes sjellin ndarje t\u00eb ndryshme jo vet\u00ebm gjat\u00eb ruajtjes dhe marrjes s\u00eb \u00e7el\u00ebsave, por edhe gjat\u00eb aktivizimit.<\/p>\n<p>Me p\u00ebrdorimin e ruajtjes me skedar\u00eb, gjat\u00eb aktivizimit ngarkohet n\u00eb cache p\u00ebrmbajtja e gjith\u00eb ruajtjes: key id, key user, key type dhe vet\u00eb \u00e7el\u00ebsi.<\/p>\n<p>N\u00eb rastin e ruajtjes n\u00eb server (p.sh., n\u00eb serverin Vault) gjat\u00eb aktivizimit ngarkohet vet\u00ebm key id dhe key user, k\u00ebshtu q\u00eb marrja e t\u00eb gjith\u00eb \u00e7el\u00ebsave nuk e ngadal\u00ebson aktivizimin. \u00c7el\u00ebsat ngarkohen n\u00eb m\u00ebnyr\u00eb lenjike. Kjo do t\u00eb thot\u00eb se \u00e7el\u00ebsi ngarkohet nga Vault vet\u00ebm kur ai n\u00eb fakt ka nevoj\u00eb. Pasi q\u00eb \u00ebsht\u00eb ngarkuar, \u00e7el\u00ebsi ruhet n\u00eb kujtes\u00eb, p\u00ebr t\u00eb shmangur nevoj\u00ebn p\u00ebr ta k\u00ebrkuar p\u00ebrmes lidhjeve TLS me Serverin Vault. M\u00eb pas, do t\u00eb shqyrtojm\u00eb se \u00e7far\u00eb informacioni p\u00ebrmban ruajtja e \u00e7el\u00ebsave.<\/p>\n<p>Informacioni mbi \u00e7el\u00ebsin p\u00ebrmban sa vijon:<\/p>\n<ul>\n<li><b>key id<\/b> \u2014 identifikuesi i \u00e7el\u00ebsit, p.sh.: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>key type<\/b> \u2014 tipi i \u00e7el\u00ebsit, i bazuar n\u00eb algoritmin e enkriptimit t\u00eb p\u00ebrdorur, vlerat e mundshme: \"AES\", \"RSA\" ose \"DSA\".<\/li>\n<li><b>key length<\/b> \u2014 gjat\u00ebsia e \u00e7el\u00ebsit n\u00eb byte, AES: 16, 24 ose 32, RSA 128, 256, 512 dhe DSA 128, 256 ose 384.<\/li>\n<li><b>p\u00ebrdorues<\/b> \u2014 pronari i \u00e7el\u00ebsit. N\u00ebse \u00e7el\u00ebsi \u00ebsht\u00eb sistemik, si\u00e7 \u00ebsht\u00eb Master Key, at\u00ebher\u00eb kjo fush\u00eb \u00ebsht\u00eb bosh. N\u00ebse \u00e7el\u00ebsi krijohet me keyring_udf, at\u00ebher\u00eb kjo fush\u00eb tregon pronarin e \u00e7el\u00ebsit.<\/li>\n<li><b>\u00e7el\u00ebsi vet\u00eb<\/b><\/li>\n<\/ul>\n<p>\n\u00c7el\u00ebsi identifikohet nj\u00ebher\u00eb e p\u00ebrgjithmon\u00eb me \u00e7iftin: key_id, user.<\/p>\n<p>Gjithashtu ka dallime n\u00eb ruajtjen dhe fshirjen e \u00e7el\u00ebsave.<\/p>\n<p>Ruajtja n\u00eb skedar punon m\u00eb shpejt. Mund t\u00eb supozohet se depozita e \u00e7el\u00ebsave \u00ebsht\u00eb nj\u00eb regjistrim i thjesht\u00eb i nj\u00eb her\u00ebsh i \u00e7el\u00ebsit n\u00eb nj\u00eb skedar, por jo \u2014 k\u00ebtu ndodhin m\u00eb shum\u00eb operacione. Me \u00e7do modifikim t\u00eb depozit\u00ebs s\u00eb skedar\u00ebve, fillimisht krijohet nj\u00eb kopje e gjith\u00eb p\u00ebrmbajtjes. Supozoni se skedari quhet my_biggest_secrets, at\u00ebher\u00eb kopja do t\u00eb jet\u00eb my_biggest_secrets.backup. M\u00eb pas modifikohet cache (shtohen ose hiqen \u00e7el\u00ebsat) dhe, n\u00ebse gjith\u00e7ka kalon me sukses, at\u00ebher\u00eb cache-et p\u00ebrshtatet n\u00eb skedar. N\u00eb raste t\u00eb rralla, si\u00e7 \u00ebsht\u00eb nj\u00eb d\u00ebshtim serveri, mund t\u00eb shihni k\u00ebt\u00eb skedar kopje rezerv\u00eb. Skedari i kopjes rezerv\u00eb fshihet kur ngarkohen \u00e7el\u00ebsat ndjek\u00ebs (zakonisht pas rib\u00ebr\u00ebjes s\u00eb serverit).<\/p>\n<p>Kur savahen ose fshihet \u00e7el\u00ebsi n\u00eb ruajtjen e serverit, ruajtja duhet t\u00eb lidhet me serverin MySQL me komandat \"d\u00ebrgo \u00e7el\u00ebsin\" \/ \"k\u00ebrko fshirjen e \u00e7el\u00ebsit\".<\/p>\n<p>Le t\u00eb kthehemi te shpejt\u00ebsia e nisjes s\u00eb serverit. P\u00ebrve\u00e7 faktit se ruajtja e vet ndikon n\u00eb shpejt\u00ebsin\u00eb e nisjes, pyetja \u00ebsht\u00eb gjithashtu se sa \u00e7el\u00ebsa nga ruajtja duhet t\u00eb merren gjat\u00eb nisjes. Sigurisht, kjo \u00ebsht\u00eb ve\u00e7an\u00ebrisht e r\u00ebnd\u00ebsishme p\u00ebr ruajtjet e server\u00ebve. Gjat\u00eb nisjes, serveri kontrollon se cili \u00e7el\u00ebs \u00ebsht\u00eb i nevojsh\u00ebm p\u00ebr tabelat e enkriptuara \/ hap\u00ebsirat e tabelave dhe k\u00ebrkon \u00e7el\u00ebsin nga ruajtja. N\u00eb nj\u00eb server \"t\u00eb past\u00ebr\" me Master Key \u2014 enkriptimi duhet t\u00eb ket\u00eb nj\u00eb Master Key t\u00eb vet\u00ebm, q\u00eb duhet t\u00eb nxirret nga ruajtja. Megjithat\u00eb, mund t\u00eb k\u00ebrkohen edhe m\u00eb shum\u00eb \u00e7el\u00ebsa, p\u00ebr shembull, kur nj\u00eb server rezerv\u00eb rikuperon nj\u00eb kopje rezerv\u00eb nga serveri kryesor. N\u00eb k\u00ebto raste, duhet t\u00eb parashikohet rotacioni i Master Key. Kjo do t\u00eb shqyrtohet m\u00eb n\u00eb detaje n\u00eb artikujt e ardhsh\u00ebm, megjithat\u00eb k\u00ebtu do t\u00eb doja t\u00eb theksoja se serveri q\u00eb p\u00ebrdor disa Master Key mund t\u00eb nis\u00eb pak m\u00eb ngadal\u00eb, ve\u00e7an\u00ebrisht, kur p\u00ebrdoret ruajtja e \u00e7el\u00ebsit t\u00eb serverit.<\/p>\n<p>Tani tani, le t\u00eb flasim pak m\u00eb shum\u00eb p\u00ebr keyring_file. Gjat\u00eb zhvillimit t\u00eb keyring_file, isha gjithashtu i shqet\u00ebsuar p\u00ebr m\u00ebnyr\u00ebn e kontrollit t\u00eb ndryshimit t\u00eb keyring_file gjat\u00eb funksionimit t\u00eb serverit. N\u00eb versionin 5.7, kontrolli u bazua n\u00eb statistikat e skedarit, e cila nuk ishte zgjidhja m\u00eb e mir\u00eb, dhe n\u00eb versionin 8.0 kjo u z\u00ebvend\u00ebsua me nj\u00eb checksum SHA256.<\/p>\n<p>Kur ekzekutohet p\u00ebr her\u00eb t\u00eb par\u00eb, keyring_file llogarit statistik\u00ebn e skedarit dhe checksum-in, t\u00eb cilat regjistrohen nga serveri, dhe ndryshimet zbatohen vet\u00ebm n\u00ebse ato p\u00ebrkasin pjes\u00ebs. Kur skedari ndryshon, checksum-i p\u00ebrdit\u00ebsohet.<\/p>\n<p>Kemi shqyrtuar shum\u00eb pyetje rreth depozitave t\u00eb \u00e7el\u00ebsave. Megjithat\u00eb, ka nj\u00eb tem\u00eb tjet\u00ebr t\u00eb r\u00ebnd\u00ebsishme, e cila shpesh harrohet ose keqkuptohet \u2014 ndarja e \u00e7el\u00ebsave sipas server\u00ebve. <\/p>\n<p>\u00c7far\u00eb po them? \u00c7do server (p\u00ebr shembull, Percona Server) n\u00eb kluster duhet t\u00eb ket\u00eb nj\u00eb vend t\u00eb ve\u00e7ant\u00eb n\u00eb serverin Vault, ku Percona Server duhet t\u00eb ruaj\u00eb \u00e7el\u00ebsat e tij. \u00c7do \u00c7el\u00ebs kryesor, i ruajtur n\u00eb depo, p\u00ebrmban GUID-in e serverit Percona Server brenda identifikuesit t\u00eb tij. Pse \u00ebsht\u00eb kjo e r\u00ebnd\u00ebsishme? Imagjinoni q\u00eb keni vet\u00ebm nj\u00eb server Vault dhe t\u00eb gjith\u00eb serverat Percona n\u00eb klaster p\u00ebrdorin k\u00ebt\u00eb server t\u00eb vet\u00ebm Vault. Problemi duket i qart\u00eb. Po sikur t\u00eb gjith\u00eb serverat Percona t\u00eb p\u00ebrdorin \u00e7el\u00ebsin kryesor pa identifikator\u00eb unik\u00eb, p\u00ebr shembull, id = 1, id = 2 etj., t\u00eb gjith\u00eb serverat n\u00eb klaster do t\u00eb p\u00ebrdornin t\u00eb nj\u00ebjtin \u00e7el\u00ebs kryesor. \u00c7far\u00eb ofron GUID - ndarjen nd\u00ebrmjet server\u00ebve. Pse pastaj t\u00eb flasim p\u00ebr ndarjen e \u00e7el\u00ebsave midis server\u00ebve, n\u00ebse tashm\u00eb ekziston nj\u00eb GUID unik? Ka nj\u00eb plugin tjet\u00ebr - keyring_udf. Me k\u00ebt\u00eb plugin, p\u00ebrdoruesi i serverit tuaj mund t\u00eb ruaj\u00eb \u00e7el\u00ebsat e tij n\u00eb serverin Vault. Problemi lind kur p\u00ebrdoruesi krijon nj\u00eb \u00e7el\u00ebs, p\u00ebr shembull, n\u00eb serverin server1, dhe pastaj p\u00ebrpiqet t\u00eb krijoj\u00eb nj\u00eb \u00e7el\u00ebs me t\u00eb nj\u00ebjtin identifikues n\u00eb server2, p\u00ebr shembull:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 do t\u00eb thot\u00eb p\u00ebrfundim t\u00eb suksessh\u00ebm\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\nPritni pak. T\u00eb dy server\u00ebt p\u00ebrdorin t\u00eb nj\u00ebjtin Vault Server, nuk duhet t\u00eb p\u00ebrfundoj\u00eb funksioni keyring_key_store me nj\u00eb gabim n\u00eb serverin server2? E \u00e7uditshme, sepse n\u00ebse provoni t\u00eb b\u00ebni t\u00eb nj\u00ebjt\u00ebn gj\u00eb n\u00eb nj\u00eb server, do t\u00eb merrni nj\u00eb gabim:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n0<\/code><\/pre>\n<p>\nSakt\u00eb, ROB_1 tashm\u00eb ekziston.<\/p>\n<p>Le t\u00eb diskutojm\u00eb fillimisht shembullin e dyt\u00eb. Si\u00e7 e tham\u00eb m\u00eb par\u00eb, keyring_vault ose \u00e7do plugin tjet\u00ebr depozite (keyring) ruan n\u00eb memory t\u00eb gjitha identifikuesit e \u00e7el\u00ebsave. Pra, pasi t\u00eb krijohet nj\u00eb \u00e7el\u00ebs i ri, ROB_1 shtohet n\u00eb serverin 1, dhe p\u00ebrve\u00e7 d\u00ebrgimit t\u00eb k\u00ebtij \u00e7el\u00ebsi n\u00eb Vault, \u00e7el\u00ebsi gjithashtu shtohet n\u00eb cache. Tani, kur p\u00ebrpiqemi t\u00eb shtojm\u00eb t\u00eb nj\u00ebjtin \u00e7el\u00ebs p\u00ebr her\u00eb t\u00eb dyt\u00eb, keyring_vault kontrollon n\u00ebse ky \u00e7el\u00ebs ekziston n\u00eb cache dhe kthen nj\u00eb gabim. <\/p>\n<p>N\u00eb rastin e par\u00eb situata \u00ebsht\u00eb ndryshe. N\u00eb server\u00ebt server1 dhe server2 ka cache t\u00eb ve\u00e7ant\u00eb. Pas shtimit t\u00eb ROB_1 n\u00eb cache-n e \u00e7el\u00ebsave n\u00eb serverin server1 dhe serverin Vault, cache-i i \u00e7el\u00ebsave n\u00eb serverin server2 nuk \u00ebsht\u00eb sinkronizuar. N\u00eb cache-n e serverit server2 nuk ka \u00e7el\u00ebs ROB_1. K\u00ebshtu, \u00e7el\u00ebsi ROB_1 shkruhet n\u00eb keyring_key_store dhe n\u00eb serverin Vault, i cili faktikisht rip\u0451rshkruan (!) vler\u00ebn e m\u00ebparshme. Tani \u00e7el\u00ebsi ROB_1 n\u00eb serverin Vault \u00ebsht\u00eb i barabart\u00eb me 543210987654321. \u00cbsht\u00eb interesante q\u00eb serveri Vault nuk e bllokon nj\u00eb veprim t\u00eb till\u00eb dhe leht\u00ebsisht rip\u0451rshkruan vler\u00ebn e vjet\u00ebr.<\/p>\n<p>Tani ne shohim pse ndarja sipas server\u00ebve n\u00eb Vault mund t\u00eb jet\u00eb e r\u00ebnd\u00ebsishme \u2014 kur p\u00ebrdorni keyring_udf dhe d\u00ebshironi t\u00eb ruani \u00e7el\u00ebsat n\u00eb Vault. Si t\u00eb sigurojm\u00eb nj\u00eb ndarje t\u00eb till\u00eb n\u00eb serverin Vault? <\/p>\n<p>Ka dy m\u00ebnyra p\u00ebr ndarjen n\u00eb Vault. Mund t\u00eb krijoni pika montimi t\u00eb ndryshme p\u00ebr \u00e7do server ose t\u00eb p\u00ebrdorni rrug\u00eb t\u00eb ndryshme brenda nj\u00eb pike montimi. M\u00eb s\u00eb miri kjo mund t\u00eb demonstrohet me shembuj. Le t\u00eb shikojm\u00eb fillimisht pikat e montimit t\u00eb ve\u00e7anta: <\/p>\n<pre><code class=\"sql\">--server1:\nvault_url = http:\/\/127.0.0.1:8200\nsecret_mount_point = server1_mount\ntoken = (...)\nvault_ca = (...)\n\n--server2:\nvault_url = http:\/\/127.0.0.1:8200\nsecret_mount_point = sever2_mount\ntoken = (...)\nvault_ca = (...)<\/code><\/pre>\n<p>\nK\u00ebtu duket se server1 dhe server2 p\u00ebrdorin pika t\u00eb montimit t\u00eb ndryshme. Kur ndahen rrug\u00ebt, konfigurimi do t\u00eb duket si m\u00eb posht\u00eb:<\/p>\n<pre><code class=\"sql\">--server1:\nvault_url = http:\/\/127.0.0.1:8200\nsecret_mount_point = mount_point\/server1\ntoken = (...)\nvault_ca = (...)\n--server2:\nvault_url = http:\/\/127.0.0.1:8200\nsecret_mount_point = mount_point\/server2\ntoken = (...)\nvault_ca = (...)<\/code><\/pre>\n<p>\nN\u00eb k\u00ebt\u00eb rast, t\u00eb dy serverat p\u00ebrdorin t\u00eb nj\u00ebjt\u00ebn pik\u00eb montimi \"mount_point\", por rrug\u00eb t\u00eb ndryshme. Kur krijoni sekreti e par\u00eb n\u00eb serverin server1 n\u00eb k\u00ebt\u00eb rrug\u00eb, serveri Vault automatikisht krijon drejtorin\u00eb \"server1\". P\u00ebr server2 gjith\u00e7ka \u00ebsht\u00eb e ngjashme. Kur hiqni sekreti e fundit n\u00eb mount_point\/server1 ose mount_point\/server2, serveri Vault gjithashtu hiqet k\u00ebto drejtorit\u00eb. N\u00ebse p\u00ebrdorni ndarjen e rrug\u00ebve, duhet t\u00eb krijoni vet\u00ebm nj\u00eb pik\u00eb montimi dhe t\u00eb ndryshoni skedar\u00ebt e konfigurimit n\u00eb m\u00ebnyr\u00eb q\u00eb serverat t\u00eb p\u00ebrdorin rrug\u00eb t\u00eb ve\u00e7anta. Pika e montimit mund t\u00eb krijohet me an\u00eb t\u00eb nj\u00eb k\u00ebrkese HTTP. Me CURL, kjo mund t\u00eb b\u00ebhet si m\u00eb posht\u00eb:<\/p>\n<pre><code class=\"sql\">curl -L -H \"X-Vault-Token: TOKEN\" \u2013cacert VAULT_CA\n--data '{\"type\":\"generic\"}' --request POST VAULT_URL\/v1\/sys\/mounts\/SECRET_MOUNT_POINT<\/code><\/pre>\n<p>\nT\u00eb gjitha fushat (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) p\u00ebrputhen me parametrat e skedarit t\u00eb konfigurimit. Sigurisht, mund t\u00eb p\u00ebrdorni mjetet e Vault p\u00ebr t\u00eb b\u00ebr\u00eb t\u00eb nj\u00ebjt\u00ebn gj\u00eb. Por k\u00ebshtu \u00ebsht\u00eb m\u00eb e leht\u00eb p\u00ebr t\u00eb automatizuar krijimin e pik\u00ebs s\u00eb montimit. Shpresoj q\u00eb kjo informacion t\u00eb jet\u00eb e dobishme p\u00ebr ju dhe do t\u00eb takohemi n\u00eb artikujt e tjer\u00eb t\u00eb k\u00ebsaj serie.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"Kriptimi n\u00eb MySQL: depoja e \u00e7el\u00ebsave\" src=\"\/wp-content\/uploads\/2020\/10\/291dcdd68660bfc312021582baa628ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<blockquote>\n<h4>Lexoni m\u00eb shum\u00eb:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench dhe shp\u00ebrndarja e vlerave t\u00eb rastit<\/a><\/noindex><\/li>\n<\/ul>\n<\/blockquote>\n<p>Burimi: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/522092\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u043e\u0433\u043e \u043d\u0430\u0431\u043e\u0440\u0430 \u043d\u0430 \u043a\u0443\u0440\u0441 \u00ab\u0411\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445\u00bb \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438. \u041f\u0440\u043e\u0437\u0440\u0430\u0447\u043d\u043e\u0435 \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 (Transparent Data Encryption, TDE) \u043f\u043e\u044f\u0432\u0438\u043b\u043e\u0441\u044c \u0432 Percona Server for MySQL \u0438 MySQL \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0434\u0430\u0432\u043d\u043e. \u041d\u043e \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u043b\u0438\u0441\u044c \u043b\u0438 \u0432\u044b \u043a\u043e\u0433\u0434\u0430-\u043d\u0438\u0431\u0443\u0434\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442\u043e\u043c \u0438 \u043a\u0430\u043a\u043e\u0435 \u0432\u043b\u0438\u044f\u043d\u0438\u0435 TDE \u043c\u043e\u0436\u0435\u0442 \u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043d\u0430 \u0432\u0430\u0448 \u0441\u0435\u0440\u0432\u0435\u0440? \u0412 \u044d\u0442\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97665,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97664","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u043e\u0433\u043e \u043d\u0430\u0431\u043e\u0440\u0430 \u043d\u0430 \u043a\u0443\u0440\u0441 \u00ab\u0411\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445\u00bb \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438. \u041f\u0440\u043e\u0437\u0440\u0430\u0447\u043d\u043e\u0435 \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 (Transparent Data Encryption, TDE) \u043f\u043e\u044f\u0432\u0438\u043b\u043e\u0441\u044c \u0432 Percona Server for MySQL \u0438 MySQL \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0434\u0430\u0432\u043d\u043e. \u041d\u043e \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u043b\u0438\u0441\u044c \u043b\u0438 \u0432\u044b \u043a\u043e\u0433\u0434\u0430-\u043d\u0438\u0431\u0443\u0434\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442\u043e\u043c \u0438 \u043a\u0430\u043a\u043e\u0435 \u0432\u043b\u0438\u044f\u043d\u0438\u0435 TDE \u043c\u043e\u0436\u0435\u0442 \u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043d\u0430 \u0432\u0430\u0448 \u0441\u0435\u0440\u0432\u0435\u0440? \u0412 \u044d\u0442\u043e\u0439\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"sq_AL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0428\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0432 MySQL: \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0435 \u043a\u043b\u044e\u0447\u0435\u0439 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u043e\u0433\u043e \u043d\u0430\u0431\u043e\u0440\u0430 \u043d\u0430 \u043a\u0443\u0440\u0441 \u00ab\u0411\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445\u00bb \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438. \u041f\u0440\u043e\u0437\u0440\u0430\u0447\u043d\u043e\u0435 \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 (Transparent Data Encryption, TDE) \u043f\u043e\u044f\u0432\u0438\u043b\u043e\u0441\u044c \u0432 Percona Server for MySQL \u0438 MySQL \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0434\u0430\u0432\u043d\u043e. \u041d\u043e \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u043b\u0438\u0441\u044c \u043b\u0438 \u0432\u044b \u043a\u043e\u0433\u0434\u0430-\u043d\u0438\u0431\u0443\u0434\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442\u043e\u043c \u0438 \u043a\u0430\u043a\u043e\u0435 \u0432\u043b\u0438\u044f\u043d\u0438\u0435 TDE \u043c\u043e\u0436\u0435\u0442 \u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043d\u0430 \u0432\u0430\u0448 \u0441\u0435\u0440\u0432\u0435\u0440? \u0412 \u044d\u0442\u043e\u0439\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-10-20T06:42:20+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-10-20T06:42:20+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Enkriptimi n\u00eb MySQL: depoja e \u00e7el\u00ebsave | ProHoster","description":"N\u00eb prag t\u00eb fillimit t\u00eb nj\u00eb grupi t\u00eb ri p\u00ebr kursin \"Baza t\u00eb dh\u00ebnash\", kemi p\u00ebrgatitur p\u00ebr ju p\u00ebrkthimin e nj\u00eb artikulli t\u00eb dobish\u00ebm. Enkriptimi i transparenc\u00ebs s\u00eb t\u00eb dh\u00ebnave (Transparent Data Encryption, TDE) \u00ebsht\u00eb shfaqur n\u00eb Percona Server for MySQL dhe MySQL q\u00eb prej nj\u00eb kohe. Por, a keni menduar ndonj\u00ebher\u00eb se si funksionon ajo n\u00ebn kapak dhe \u00e7far\u00eb ndikimi mund t\u00eb ket\u00eb TDE n\u00eb serverin tuaj? N\u00eb k\u00ebt\u00eb","canonical_url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sq_AL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0428\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0432 MySQL: \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0435 \u043a\u043b\u044e\u0447\u0435\u0439 | ProHoster","og:description":"\u0412 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u043e\u0433\u043e \u043d\u0430\u0431\u043e\u0440\u0430 \u043d\u0430 \u043a\u0443\u0440\u0441 \u00ab\u0411\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445\u00bb \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438. \u041f\u0440\u043e\u0437\u0440\u0430\u0447\u043d\u043e\u0435 \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 (Transparent Data Encryption, TDE) \u043f\u043e\u044f\u0432\u0438\u043b\u043e\u0441\u044c \u0432 Percona Server for MySQL \u0438 MySQL \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0434\u0430\u0432\u043d\u043e. \u041d\u043e \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u043b\u0438\u0441\u044c \u043b\u0438 \u0432\u044b \u043a\u043e\u0433\u0434\u0430-\u043d\u0438\u0431\u0443\u0434\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442\u043e\u043c \u0438 \u043a\u0430\u043a\u043e\u0435 \u0432\u043b\u0438\u044f\u043d\u0438\u0435 TDE \u043c\u043e\u0436\u0435\u0442 \u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043d\u0430 \u0432\u0430\u0448 \u0441\u0435\u0440\u0432\u0435\u0440? \u0412 \u044d\u0442\u043e\u0439","og:url":"https:\/\/prohoster.info\/sq\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-20T06:42:20+00:00","article:modified_time":"2020-10-20T06:42:20+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97664","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:15:28","updated":"2022-10-03 07:13:50"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sq\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}