{"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\/sl\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"\u0160ifriranje u MySQL-u: skladi\u0161te klju\u010deva","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Uo\u010di po\u010detka novog upisa na kurs <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">\u201eBaze podataka\u201c<\/a><\/noindex> pripremili smo za vas prevod korisnog \u010dlanka.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"\u0160ifriranje u MySQL-u: skladi\u0161te klju\u010deva\" src=\"\/wp-content\/uploads\/2020\/10\/aeca40f53fe6bdf2a9897aa835ff597d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Transparentno \u0161ifriranje podataka (Transparent Data Encryption, TDE) uvedeno je u <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\">Percona Server za MySQL<\/a><\/noindex> i MySQL ve\u0107 dugo. Ali jeste li se ikad zapitali kako to funkcioni\u0161e ispod haube i koji uticaj TDE mo\u017ee imati na va\u0161 server? U ovoj seriji \u010dlanaka razmotri\u0107emo kako TDE funkcioni\u0161e unutra. Po\u010de\u0107emo s skladi\u0161tenjem klju\u010deva, jer je to neophodno za funkcionisanje svakog \u0161ifriranja. Zatim \u0107emo detaljno razmotriti kako \u0161ifriranje funkcioni\u0161e u Percona Server za MySQL\/MYSQL i koje dodatne mogu\u0107nosti postoje u Percona Server za MySQL.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring je plugin koji omogu\u0107ava serveru da zahteva, kreira i bri\u0161e klju\u010deve u lokalnoj datoteci (keyring_file) ili na udaljenom serveru (npr. u HashiCorp Vault-u). Klju\u010devi se uvek ke\u0161iraju lokalno za br\u017ei pristup. <\/p>\n<p>Plugin mo\u017eemo podeliti u dve kategorije:<\/p>\n<ul>\n<li>Lokalno skladi\u0161te. Na primer, lokalna datoteka (ovo nazivamo skladi\u0161tem klju\u010deva zasnovano na datoteci, file-based keyring).<\/li>\n<li>Udaljeno skladi\u0161te. Na primer Vault Server (ovo nazivamo skladi\u0161tem klju\u010deva zasnovano na serveru, server-based keyring).<\/li>\n<\/ul>\n<p>\nOva podela je va\u017ena jer se razli\u010diti tipovi skladi\u0161ta pona\u0161aju malo druga\u010dije ne samo pri skladi\u0161tenju i dobijanju klju\u010deva, ve\u0107 i pri pokretanju.<\/p>\n<p>Kada koristite skladi\u0161te zasnovano na datoteci, prilikom pokretanja se ke\u0161ira sav sadr\u017eaj skladi\u0161ta: key id, key user, key type i sam klju\u010d.<\/p>\n<p>U slu\u010daju skladi\u0161ta zasnovanog na serveru (npr. Vault server), prilikom pokretanja se ke\u0161ira samo key id i key user, stoga preuzimanje svih klju\u010deva ne usporava pokretanje. Klju\u010devi se u\u010ditavaju lenjo. To zna\u010di da se klju\u010d preuzima iz Vault-a samo kada zaista zatreba. Nakon preuzimanja, klju\u010d se ke\u0161ira u memoriji kako ne bi bilo potrebe da se u budu\u0107nosti obra\u0107a za njim putem TLS veza prema Vault Server-u. Sada \u0107emo razmotriti koju informaciju skladi\u0161te klju\u010deva sadr\u017ei.<\/p>\n<p>Informacije o klju\u010du sadr\u017ee slede\u0107e:<\/p>\n<ul>\n<li><b>key id<\/b> \u2014 identifikator klju\u010da, na primer: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>key type<\/b> \u2014 tip klju\u010da, zasnovan na kori\u0161\u0107enom algoritmu \u0161ifriranja, mogu\u0107e vrednosti: \u201eAES\u201c, \u201eRSA\u201c ili \u201eDSA\u201c.<\/li>\n<li><b>key length<\/b> \u2014 du\u017eina klju\u010da u bajtovima, AES: 16, 24 ili 32; RSA: 128, 256, 512 i DSA: 128, 256 ili 384.<\/li>\n<li><b>uporabnik<\/b> \u2014 lastnik klju\u010da. \u010ce je klju\u010d sistemski, na primer, Master Key, je to polje prazno. \u010ce se klju\u010d ustvari z uporabo keyring_udf, to polje ozna\u010duje lastnika klju\u010da.<\/li>\n<li><b>sam klju\u010d<\/b><\/li>\n<\/ul>\n<p>\nKlju\u010d se nedvoumno identificira s parom: key_id, user.<\/p>\n<p>Obstajajo tudi razlike v shranjevanju in brisanja klju\u010dev.<\/p>\n<p>Datote\u010dno shranjevanje deluje hitreje. Lahko bi domnevali, da je shranjevanje klju\u010dev preprosto enkratno bele\u017eenje klju\u010da v datoteko, vendar ni tako \u2014 tukaj poteka ve\u010d operacij. Pri vsaki spremembi datote\u010dnega shranjevanja se najprej ustvari varnostna kopija vsebine. Recimo, da se datoteka imenuje my_biggest_secrets, potem bo varnostna kopija my_biggest_secrets.backup. Nato se spremeni predpomnilnik (dodajo ali odstranijo se klju\u010di) in, \u010de je vse uspe\u0161no, se predpomnilnik zapi\u0161e v datoteko. V redkih primerih, kot je napaka stre\u017enika, lahko vidite to varnostno kopijo. Varnostna kopija se odstrani ob naslednjem nalaganju klju\u010dev (ponavadi po ponovnem zagonu stre\u017enika).<\/p>\n<p>Pri shranjevanju ali brisanju klju\u010da v stre\u017eni\u0161kem shranjevanju se mora shranjevanje povezati s stre\u017enikom MySQL s ukazi \"po\u0161lji klju\u010d\" \/ \"zahtevaj brisanje klju\u010da\" (\"send the key\" \/ \"request key deletion\").<\/p>\n<p>Poglejmo nazaj na hitrost zagona stre\u017enika. Poleg tega, da na hitrost zagona vpliva samo shranjevanje, je tudi vpra\u0161anje, koliko klju\u010dev iz shranjevanja je treba pridobiti ob zagonu. Seveda je to \u0161e posebej pomembno za stre\u017eni\u0161ka shranjevanja. Ob zagonu stre\u017enik preveri, kateri klju\u010d je potreben za \u0161ifrirane tabele \/ tabelarna prostora in zahteva klju\u010d iz shranjevanja. Na \"\u010distem\" stre\u017eniku s \u0161ifriranjem Master Key mora biti en Master Key, ki ga je treba pridobiti iz shranjevanja. Vendar pa je lahko potreben tudi ve\u010dji \u0161tevil klju\u010dev, na primer, ko se na rezervnem stre\u017eniku obnavlja varnostna kopija iz glavnega stre\u017enika. V takih primerih je treba predvideti rotacijo Master Key. O tem bo ve\u010d govorjeno v prihodnjih \u010dlankih, \u010deprav bi rad opozoril, da se stre\u017enik, ki uporablja ve\u010d Master Key, lahko za\u017eene nekoliko dlje, zlasti ob uporabi stre\u017enega shranjevanja klju\u010dev.<\/p>\n<p>Zdaj pa se pogovoriva \u0161e malo o keyring_file. Ko sem razvil keyring_file, me je skrbelo tudi, kako preveriti spremembo keyring_file med delovanjem stre\u017enika. V 5.7 je bila preverba izvedena na podlagi statistike datoteke, kar ni bilo idealna re\u0161itev, in v 8.0 je bila zamenjana s kontrolno vsoto SHA256.<\/p>\n<p>Ob prvem zagonu keyring_file se izra\u010duna statistika datoteke in kontrolna vsota, ki ju stre\u017enik zapomni, in spremembe se uporabijo le, \u010de se ujemajo. Ob spremembi datoteke se kontrolna vsota posodobi.<\/p>\n<p>\u017de smo obravnavali mnoge zadeve glede skladi\u0161\u010d klju\u010dev. Vendar pa je \u0161e ena pomembna tema, ki jo pogosto pozabljamo ali napa\u010dno razumemo \u2014 lo\u010ditev klju\u010dev po stre\u017enikih. <\/p>\n<p>Kaj mislim s tem? Vsak stre\u017enik (na primer, Percona Server) v klastru mora imeti lo\u010den prostor na stre\u017eniku Vault, kjer mora Percona Server hraniti svoje klju\u010de. V vsakem Master Key, shranjenem v skladi\u0161\u010du, je GUID stre\u017enika Percona Server znotraj svojega identifikatorja. Zakaj je to pomembno? Predstavljajte si, da imate le en Vault Server in vsi Percona Serverji v klastru uporabljajo ta edini Vault Server. Te\u017eava se zdi o\u010ditna. \u010ce bi vsi Percona Serverji uporabljali Master Key brez edinstvenih identifikatorjev, na primer, id = 1, id = 2 itd., bi vsi stre\u017eniki v klastru uporabljali isti Master Key. Kar zagotavlja GUID \u2014 lo\u010ditev med stre\u017eniki. Zakaj torej govoriti o lo\u010ditvi klju\u010dev med stre\u017eniki, \u010de \u017ee obstaja edinstven GUID? Obstaja \u0161e en vti\u010dnik \u2014 keyring_udf. S pomo\u010djo tega vti\u010dnika lahko uporabnik va\u0161ega stre\u017enika hrani svoje klju\u010de na stre\u017eniku Vault. Te\u017eava se pojavi, ko uporabnik ustvari klju\u010d, na primer, na stre\u017eniku server1, nato pa posku\u0161a ustvariti klju\u010da z enakim identifikatorjem na server2, na primer:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 pomeni uspe\u0161no dokon\u010danje\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\nPo\u010dakajte. Obe stre\u017eniki uporabljata isti Vault Server, ali ne bi morala funkcija keyring_key_store kon\u010dati s napako na stre\u017eniku server2? Zanimivo je, da \u010de poskusite narediti isto na enem stre\u017eniku, boste dobili napako:<\/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>\nPrav, ROB_1 \u017ee obstaja.<\/p>\n<p>Najprej se pogovorimo o drugem primeru. Kot smo \u017ee prej omenili, keyring_vault ali kateri koli drug vti\u010dnik shrambe (keyring) predpomni vse identifikatorje klju\u010dev v pomnilniku. Tako, po tem, ko je bilo ustvarjeno novo klju\u010de, ROB_1 dodano na server1, in poleg po\u0161iljanja tega klju\u010da v Vault, se klju\u010d tudi doda v predpomnilnik. Zdaj, ko posku\u0161amo dodati enak klju\u010d drugi\u010d, keyring_vault preveri, ali ta klju\u010d obstaja v predpomnilniku, in izda napako. <\/p>\n<p>V prvem primeru je situacija druga\u010dna. Na stre\u017enikih server1 in server2 so lo\u010deni predpomnilniki. Po dodajanju ROB_1 v predpomnilnik klju\u010dev na stre\u017eniku server1 in stre\u017eniku Vault, se predpomnilnik klju\u010dev na server2 ne sinhronizira. V predpomnilniku na server2 ni klju\u010da ROB_1. Tako se klju\u010d ROB_1 shrani v keyring_key_store in na stre\u017eniku Vault, kar dejansko prepisuje (!) prej\u0161njo vrednost. Sedaj je klju\u010d ROB_1 na stre\u017eniku Vault enak 543210987654321. Zanimivo je, da stre\u017enik Vault ne blokira tak\u0161nih dejanj in preprosto prepisuje staro vrednost.<\/p>\n<p>Zdaj vidimo, zakaj je razdelitev po stre\u017enikih na Vaultu lahko pomembna \u2014 kadar uporabljate keyring_udf in \u017eelite shraniti klju\u010de v Vault. Kako zagotoviti tak\u0161no razdelitev na stre\u017eniku Vault? <\/p>\n<p>Obstajata dva na\u010dina za razdelitev na Vault. Lahko ustvarite razli\u010dne to\u010dke monta\u017ee za vsak stre\u017enik ali uporabite razli\u010dne poti znotraj ene to\u010dke monta\u017ee. Najbolje bo to pokazati na primerih. Torej, najprej poglejmo lo\u010dene to\u010dke monta\u017ee: <\/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>\nTukaj je razvidno, da server1 in server2 uporabljata razli\u010dne to\u010dke monta\u017ee. Pri razdelitvi poti bo konfiguracija videti takole:<\/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>\nV tem primeru oba stre\u017enika uporabljata isto to\u010dko monta\u017ee \"mount_point\", vendar razli\u010dne poti. Ko ustvarite prvo skrivnost na stre\u017eniku server1 po tej poti, stre\u017enik Vault samodejno ustvari imenik \"server1\". Za server2 je vse enako. Ko izbri\u0161ete zadnjo skrivnost v mount_point\/server1 ali mount_point\/server2, stre\u017enik Vault prav tako izbri\u0161e te imenike. V primeru, da uporabljate razdelitev poti, morate ustvariti le eno to\u010dko monta\u017ee in spremeniti konfiguracijske datoteke, da stre\u017eniki uporabljajo lo\u010dene poti. To\u010dko monta\u017ee lahko ustvarite s pomo\u010djo HTTP zahtevka. S CURL to lahko storite takole:<\/p>\n<pre><code class=\"sql\">curl -L -H \"X-Vault-Token: TOKEN\" --cacert VAULT_CA\n--data '{\"type\":\"generic\"}' --request POST VAULT_URL\/v1\/sys\/mounts\/SECRET_MOUNT_POINT<\/code><\/pre>\n<p>\nVsa polja (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) ustrezajo parametrom konfiguracijske datoteke. Seveda lahko uporabite orodja Vault, da naredite isto. A tako je preprosteje avtomatizirati ustvarjanje to\u010dke monta\u017ee. Upam, da vam bo ta informacija koristna in se vidimo v naslednjih \u010dlankih te serije.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"\u0160ifriranje u MySQL-u: skladi\u0161te klju\u010deva\" src=\"\/wp-content\/uploads\/2020\/10\/291dcdd68660bfc312021582baa628ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<blockquote>\n<h4>Preberi ve\u010d:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench in porazdelitev naklju\u010dnih velikosti<\/a><\/noindex><\/li>\n<\/ul>\n<\/blockquote>\n<p>Izvor: <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.4 - 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\/sl\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sl_SI\" \/>\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\/sl\/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\udd47\u0160ifriranje v MySQL: shranjevanje klju\u010dev | ProHoster","description":"Pred za\u010detkom novega niza na te\u010daju \"Baze podatkov\" smo pripravili prevod koristnega \u010dlanka.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}