{"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":"Kodifikimi n\u00eb MySQL: magazina e \u00e7el\u00ebsave","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Me para 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> p\u00ebrgatit\u00ebm p\u00ebr ju nj\u00eb p\u00ebrkthim t\u00eb artikullit t\u00eb dobish\u00ebm.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Kodifikimi n\u00eb MySQL: magazina 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 qen\u00eb i pranish\u00ebm 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 p\u00ebr nj\u00eb koh\u00eb t\u00eb gjat\u00eb. Por a keni menduar ndonj\u00ebher\u00eb se si funksionon ai n\u00ebn kapak dhe \u00e7far\u00eb ndikimi mund t\u00eb ket\u00eb TDE mbi serverin tuaj? N\u00eb k\u00ebt\u00eb seri artikujsh do t\u00eb shqyrtojm\u00eb se si punon TDE nga brenda. Le t\u00eb fillojm\u00eb me ruajtjen e \u00e7el\u00ebsave, pasi kjo \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 jan\u00eb mund\u00ebsit\u00eb shtes\u00eb q\u00eb ofron Percona Server for MySQL.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring \u00ebsht\u00eb nj\u00eb plugin q\u00eb lejon serverin t\u00eb k\u00ebrkoj\u00eb, krijoj\u00eb dhe fshij\u00eb \u00e7el\u00ebsa n\u00eb nj\u00eb skedar lokal (keyring_file) ose n\u00eb nj\u00eb server t\u00eb larg\u00ebt (p\u00ebr shembull, n\u00eb HashiCorp Vault). \u00c7el\u00ebsat gjithmon\u00eb ruhen n\u00eb m\u00ebnyr\u00eb t\u00eb p\u00ebrkohshme p\u00ebr t'i p\u00ebrshpejtuar ata. <\/p>\n<p>Plugin-t 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 t\u00eb \u00e7el\u00ebve 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 t\u00eb \u00e7el\u00ebve n\u00eb server, server-based keyring).<\/li>\n<\/ul>\n<p>\nKjo ndarje \u00ebsht\u00eb e r\u00ebnd\u00ebsishme, sepse lloje t\u00eb ndryshme ruajtjesh veprojn\u00eb disi ndryshe jo vet\u00ebm gjat\u00eb ruajtjes dhe marrjes s\u00eb \u00e7el\u00ebsave, por edhe gjat\u00eb nisjes.<\/p>\n<p>Kur p\u00ebrdorni ruajtjen e skedar\u00ebve, gjat\u00eb nisjes ngarkohet e gjith\u00eb p\u00ebrmbajtja e ruajtjes n\u00eb cache: id e \u00e7el\u00ebsit, p\u00ebrdoruesi i \u00e7el\u00ebsit, tipi i \u00e7el\u00ebsit dhe \u00e7el\u00ebsi vet\u00eb.<\/p>\n<p>N\u00eb rastin e ruajtjes n\u00eb server (p\u00ebr shembull, serveri Vault), gjat\u00eb nisjes ngarkohet vet\u00ebm id e \u00e7el\u00ebsit dhe p\u00ebrdoruesi i \u00e7el\u00ebsit, k\u00ebshtu q\u00eb marrja e t\u00eb gjith\u00eb \u00e7el\u00ebsave nuk ngadal\u00ebson nisjen. \u00c7el\u00ebsat ngarkohen me mosp\u00ebrfshirje. Kjo do t\u00eb thot\u00eb se \u00e7el\u00ebsi vet\u00eb ngarkohet nga Vault vet\u00ebm kur \u00ebsht\u00eb v\u00ebrtet e nevojshme. Pas ngarkimit, \u00e7el\u00ebsi ruhet n\u00eb memorien e p\u00ebrkohshme p\u00ebr t\u00eb shmangur nevoj\u00ebn p\u00ebr ta k\u00ebrkuar n\u00ebp\u00ebrmjet lidhjeve TLS me Vault Server. Le t\u00eb shohim se \u00e7far\u00eb informacioni \u00ebsht\u00eb i pranish\u00ebm n\u00eb ruajtjen e \u00e7el\u00ebsave.<\/p>\n<p>Informacioni mbi \u00e7el\u00ebsin p\u00ebrfshin:<\/p>\n<ul>\n<li><b>id e \u00e7el\u00ebsit<\/b> \u2014 identifikuesi i \u00e7el\u00ebsit, p\u00ebr shembull: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>tipi i \u00e7el\u00ebsit<\/b> \u2014 lloji i \u00e7el\u00ebsit, i bazuar n\u00eb algoritemin e enkriptimit t\u00eb p\u00ebrdorur, vlerat e mundshme: \"AES\", \"RSA\" ose \"DSA\".<\/li>\n<li><b>gjer\u00ebsia e \u00e7el\u00ebsit<\/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>user<\/b> \u2014 pronari i \u00e7el\u00ebsit. N\u00ebse \u00e7el\u00ebsi \u00ebsht\u00eb sistemik, p\u00ebr shembull, Master Key, at\u00ebher\u00eb ky fush\u00eb \u00ebsht\u00eb bosh. N\u00ebse \u00e7el\u00ebsi krijohet me keyring_udf, at\u00ebher\u00eb ky fush\u00eb p\u00ebrfaq\u00ebson pronarin e \u00e7el\u00ebsit.<\/li>\n<li><b>\u00e7el\u00ebsi vet\u00eb<\/b><\/li>\n<\/ul>\n<p>\n\u00c7el\u00ebsi identifikohet n\u00eb m\u00ebnyr\u00eb t\u00eb p\u00ebrcaktuar nga \u00e7ifti: key_id, user.<\/p>\n<p>Ka gjithashtu dallime n\u00eb ruajtjen dhe fshirjen e \u00e7el\u00ebsave.<\/p>\n<p>Ruajtja e skedar\u00ebve funksionon m\u00eb shpejt. Mund t\u00eb supozohet se ruajtja e \u00e7el\u00ebsave \u00ebsht\u00eb nj\u00eb shkrim i thjesht\u00eb i vet\u00ebm i \u00e7el\u00ebsit n\u00eb skedar, por jo - k\u00ebtu ndodhin m\u00eb shum\u00eb operacione. N\u00eb \u00e7do modifikim t\u00eb ruajtjes s\u00eb skedar\u00ebve, fillimisht krijohet nj\u00eb kopje rezerv\u00eb e t\u00eb gjith\u00eb p\u00ebrmbajtjes. Le t\u00eb supozojm\u00eb se skedari quhet my_biggest_secrets, k\u00ebshtu q\u00eb kopja rezerv\u00eb do t\u00eb jet\u00eb my_biggest_secrets.backup. Pastaj modifikohet ndihmesa (shtohen ose hiqen \u00e7el\u00ebsat) dhe, n\u00ebse gjith\u00e7ka \u00ebsht\u00eb kryer me sukses, ndihmesa e rinovohet n\u00eb skedar. N\u00eb raste t\u00eb rralla, si\u00e7 \u00ebsht\u00eb d\u00ebshtimi i serverit, mund t\u00eb shihni k\u00ebt\u00eb skedar kopje rezerv\u00eb. Skedari i kopjeve rezerv\u00eb fshihet gjat\u00eb ngarkimit t\u00eb ardhsh\u00ebm t\u00eb \u00e7el\u00ebsave (zakonisht pas rinisjes s\u00eb serverit).<\/p>\n<p>Kur ruhet ose fshihet nj\u00eb \u00e7el\u00ebs 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\" (\"send the key\" \/ \"request key deletion\").<\/p>\n<p>T\u00eb kthehemi te shpejt\u00ebsia e nisjes s\u00eb serverit. P\u00ebrve\u00e7 faktit se ruajtja vet\u00eb ndikon n\u00eb shpejt\u00ebsin\u00eb e nisjes, ka gjithashtu pyetje n\u00ebse 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 tregjeve dhe k\u00ebrkon \u00e7el\u00ebsin nga ruajtja. N\u00eb nj\u00eb server \"t\u00eb past\u00ebr\" me Master Key - enkriptimi duhet t\u00eb ket\u00eb nj\u00eb Master Key, i cili duhet t\u00eb nxirret nga ruajtja. Megjithat\u00eb, mund t\u00eb nevojitet gjithashtu nj\u00eb num\u00ebr m\u00eb i madh \u00e7el\u00ebsash, p\u00ebr shembull, kur nj\u00eb server rezerv\u00eb rikthen nj\u00eb kopje rezerv\u00eb nga serveri kryesor. N\u00eb k\u00ebso raste, duhet t\u00eb parashikohet rotacioni i Master Key. M\u00eb shum\u00eb informacione p\u00ebr k\u00ebt\u00eb do t\u00eb shqyrtohen n\u00eb artikujt e ardhsh\u00ebm, megjithat\u00eb k\u00ebtu do t\u00eb doja t\u00eb theksoja se nj\u00eb server 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\u00ebsave t\u00eb serverit.<\/p>\n<p>Tani le t\u00eb flasim edhe pak p\u00ebr keyring_file. Kur zhvilloja keyring_file, gjithashtu m\u00eb shqet\u00ebsonte se si t\u00eb kontrolloja ndryshimin e keyring_file gjat\u00eb funksionimit t\u00eb serverit. N\u00eb 5.7 kontrolli u krye n\u00eb baz\u00eb t\u00eb statistikave t\u00eb skedarit, q\u00eb nuk ishte nj\u00eb zgjidhje e p\u00ebrkryer, dhe n\u00eb 8.0 u z\u00ebvend\u00ebsua me nj\u00eb kontroll t\u00eb shum\u00ebs SHA256.<\/p>\n<p>Kur startimin e par\u00eb, keyring_file llogarit statistik\u00ebn e skedarit dhe shum\u00ebn kontrolluese, t\u00eb cilat regjistrohen nga serveri, dhe ndryshimet aplikohen vet\u00ebm n\u00ebse ato p\u00ebrputhen. Kur skedari ndryshohet, shuma kontrolluese p\u00ebrdit\u00ebsohet.<\/p>\n<p>Ne kemi shqyrtuar shum\u00eb \u00e7\u00ebshtje n\u00eb lidhje me depozitat e \u00e7el\u00ebsave. Megjithat\u00eb, ka nj\u00eb tem\u00eb tjet\u00ebr t\u00eb r\u00ebnd\u00ebsishme q\u00eb shpesh harrohet ose kuptohet gabimisht - ndarja e \u00e7el\u00ebsave sipas server\u00ebve. <\/p>\n<p>\u00c7far\u00eb kam n\u00eb mendje? \u00c7do server (p\u00ebr shembull, Percona Server) n\u00eb klaster duhet t\u00eb ket\u00eb nj\u00eb vend t\u00eb ve\u00e7ant\u00eb n\u00eb serverin Vault, n\u00eb t\u00eb cilin Percona Server duhet t\u00eb ruaj\u00eb \u00e7el\u00ebsat e tij. N\u00eb secil\u00ebn Master Key, t\u00eb ruajtur n\u00eb depozit\u00eb, p\u00ebrmban GUID-in e serverit Percona Server brenda identifikatorit t\u00eb saj. Pse \u00ebsht\u00eb kjo e r\u00ebnd\u00ebsishme? Imagjinoni se keni vet\u00ebm nj\u00eb Vault Server dhe t\u00eb gjith\u00eb Percona Server n\u00eb klaster p\u00ebrdorin k\u00ebt\u00eb server t\u00eb vet\u00ebm Vault. Problemi duket i qart\u00eb. N\u00ebse t\u00eb gjith\u00eb Percona Server do t\u00eb p\u00ebrdornin Master Key pa identifikator\u00eb unik\u00eb, p\u00ebr shembull, id = 1, id = 2 etj., at\u00ebher\u00eb t\u00eb gjith\u00eb server\u00ebt n\u00eb klaster do t\u00eb p\u00ebrdornin t\u00eb nj\u00ebjtin Master Key. Kjo q\u00eb siguron GUID-i - ndarjen midis server\u00ebve. Pse at\u00ebher\u00eb 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 t\u00eb 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 identifikator 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>\nPrit. T\u00eb dy server\u00ebt p\u00ebrdorin t\u00eb nj\u00ebjtin Vault Server, a nuk duhet q\u00eb funksioni keyring_key_store t\u00eb p\u00ebrfundoj\u00eb me nj\u00eb gabim n\u00eb serverin server2? \u00cbsht\u00eb interesante se n\u00ebse p\u00ebrpiqeni 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 kemi th\u00ebn\u00eb m\u00eb par\u00eb, keyring_vault ose cdo plugin tjet\u00ebr ruajt\u00ebs (keyring) ruan t\u00eb gjitha ID-t\u00eb e \u00e7el\u00ebsave n\u00eb memorie. K\u00ebshtu, pas krijimit t\u00eb nj\u00eb \u00e7el\u00ebsi t\u00eb ri, ROB_1 shtohet n\u00eb server1 dhe, p\u00ebrve\u00e7 d\u00ebrgimit t\u00eb k\u00ebtij \u00e7el\u00ebsi n\u00eb Vault, \u00e7el\u00ebsi gjithashtu shtohet n\u00eb ruajtjen e p\u00ebrkohshme. 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 ruajtje dhe jep nj\u00eb gabim. <\/p>\n<p>N\u00eb rastin e par\u00eb situata \u00ebsht\u00eb ndryshe. N\u00eb serverat server1 dhe server2 ekzistojn\u00eb ruajtje t\u00eb ve\u00e7anta. Pas shtimit t\u00eb ROB_1 n\u00eb ruajtjen e \u00e7el\u00ebve n\u00eb serverin server1 dhe serverin Vault, ruajtja e \u00e7el\u00ebve n\u00eb server2 nuk \u00ebsht\u00eb sinkronizuar. N\u00eb ruajtje n\u00eb server2 nuk ka \u00e7el\u00ebsin ROB_1. K\u00ebshtu, \u00e7el\u00ebsi ROB_1 shkruhet n\u00eb keyring_key_store dhe n\u00eb serverin Vault, i cili n\u00eb fakt riparon (!) vler\u00ebn e m\u00ebparshme. Tani \u00e7el\u00ebsi ROB_1 n\u00eb serverin Vault \u00ebsht\u00eb 543210987654321. \u00cbsht\u00eb e \u00e7uditshme q\u00eb serveri Vault nuk e ndalon nj\u00eb veprim t\u00eb till\u00eb dhe thjesht riparon vler\u00ebn e vjet\u00ebr.<\/p>\n<p>Tani ne shohim se pse ndarja n\u00eb servera 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 mund t\u00eb sigurohet nj\u00eb ndarje e till\u00eb n\u00eb serverin Vault? <\/p>\n<p>Ka dy m\u00ebnyra p\u00ebr t\u00eb b\u00ebr\u00eb ndarjen n\u00eb Vault. Mund t\u00eb krijoni pika t\u00eb ndryshme montimi p\u00ebr secilin server ose t\u00eb p\u00ebrdorni rrug\u00eb t\u00eb ndryshme brenda nj\u00eb pike montimi. M\u00eb s\u00eb miri k\u00ebt\u00eb e ilustrojn\u00eb shembujt. Pra, le t\u00eb shohim fillimisht pikat e ve\u00e7anta t\u00eb montimit: <\/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 shihet se server1 dhe server2 p\u00ebrdorin pika t\u00eb ndryshme montimi. Kur ndajm\u00eb 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\/sever2\ntoken = (...)\nvault_ca = (...)<\/code><\/pre>\n<p>\nN\u00eb k\u00ebt\u00eb rast, t\u00eb dy server\u00ebt p\u00ebrdorin t\u00eb nj\u00ebjt\u00ebn pik\u00eb montimi \"mount_point\", por rrug\u00eb t\u00eb ndryshme. Kur krijoni sekretin e par\u00eb n\u00eb serverin server1 n\u00eb k\u00ebt\u00eb rrug\u00eb, serveri Vault automatikisht krijon direktorin\u00eb \"server1\". P\u00ebr serverin server2, gjith\u00e7ka \u00ebsht\u00eb e ngjashme. Kur fshini sekretin e fundit n\u00eb mount_point\/server1 ose mount_point\/server2, serveri Vault gjithashtu fshin k\u00ebto direktorive. 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 q\u00eb server\u00ebt t\u00eb p\u00ebrdorin rrug\u00eb t\u00eb ndara. Pik\u00ebn e montimit mund ta krijoni p\u00ebrmes nj\u00eb k\u00ebrkese HTTP. Me CURL, mund ta b\u00ebni si n\u00eb vijim:<\/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 gjith\u00eb fushat (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) p\u00ebrputhen me parametrat e skedarit t\u00eb konfigurimit. Sigurisht, mund t\u00eb p\u00ebrdorni utilitar\u00ebt 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 t\u00eb automatizoni krijimin e pik\u00ebs s\u00eb montimit. Shpresoj se kjo informacion do 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=\"Kodifikimi n\u00eb MySQL: magazina 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 rast\u00ebsishme<\/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 5.0.2.1 - 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.\" \/>\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) 5.0.2.1\" \/>\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.\" \/>\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\", p\u00ebrgatit\u00ebm p\u00ebr ju p\u00ebrkthimin e nj\u00eb artikulli t\u00eb dobish\u00ebm.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}