{"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\/hr\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"Enkripcija u MySQL: skladi\u0161te klju\u010deva","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Uo\u010di po\u010detka novog upisa na te\u010daj <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">\u00abBaze podataka\u00bb<\/a><\/noindex> pripremili smo za vas prijevod korisnog \u010dlanka.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Enkripcija u MySQL: 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 for MySQL<\/a><\/noindex> i MySQL ve\u0107 dosta davno. No, jeste li se ikada zapitali kako to funkcionira ispod haube i kakav utjecaj TDE mo\u017ee imati na va\u0161 server? U ovoj seriji \u010dlanaka istra\u017eit \u0107emo kako TDE funkcionira iznutra. Po\u010det \u0107emo od pohrane klju\u010deva, budu\u0107i da je ona potrebna za rad svakog \u0161ifriranja. Zatim \u0107emo detaljno razmotriti kako \u0161ifriranje radi u Percona Server for MySQL\/MySQL i koje dodatne mogu\u0107nosti postoje u Percona Server for MySQL.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring su dodaci koji omogu\u0107uju serveru zahtijevanje, stvaranje i brisanje klju\u010deva u lokalnoj datoteci (keyring_file) ili na udaljenom serveru (na primjer, u HashiCorp Vault). Klju\u010devi se uvijek lokalno ke\u0161iraju kako bi se ubrzalo njihovo preuzimanje. <\/p>\n<p>Dodaci se mogu podijeliti u dvije kategorije:<\/p>\n<ul>\n<li>Lokalna pohrana. Na primjer, lokalna datoteka (nazivamo je pohranom klju\u010deva temeljenom na datoteci, file-based keyring).<\/li>\n<li>Udaljena pohrana. Na primjer, Vault Server (nazivamo ga pohranom klju\u010deva temeljenom na serveru, server-based keyring).<\/li>\n<\/ul>\n<p>\nOva podjela je va\u017ena jer se razli\u010diti tipovi pohrana pona\u0161aju malo druga\u010dije ne samo pri pohranjivanju i preuzimanju klju\u010deva, ve\u0107 i pri pokretanju.<\/p>\n<p>Kada se koristi pohrana temeljena na datoteci, pri pokretanju se u\u010ditava sav sadr\u017eaj pohrane u ke\u0161: key id, key user, key type i sam klju\u010d.<\/p>\n<p>U slu\u010daju pohrane temeljenje na serveru (kao \u0161to je server Vault), pri pokretanju se u\u010ditava samo key id i key user, stoga preuzimanje svih klju\u010deva ne usporava pokretanje. Klju\u010devi se u\u010ditavaju lijeno. To zna\u010di da se sam klju\u010d u\u010ditava iz Vault-a samo kada zaista zatreba. Nakon u\u010ditavanja, klju\u010d se ke\u0161ira u memoriji, kako ne bi bilo potrebe ponovno se obra\u0107ati za njim putem TLS veza na Vault Server. Dalje \u0107emo razmotriti koje informacije sadr\u017ei pohrana klju\u010deva.<\/p>\n<p>Informacije o klju\u010du sadr\u017ee sljede\u0107e:<\/p>\n<ul>\n<li><b>key id<\/b> \u2014 identifikator klju\u010da, na primjer: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>key type<\/b> \u2014 tip klju\u010da, temeljen na kori\u0161tenom algoritmu \u0161ifriranja, mogu\u0107e vrijednosti: \u00abAES\u00bb, \u00abRSA\u00bb ili \u00abDSA\u00bb.<\/li>\n<li><b>key length<\/b> \u2014 duljina klju\u010da u bajtovima, AES: 16, 24 ili 32, RSA 128, 256, 512 i DSA 128, 256 ili 384.<\/li>\n<li><b>korisnik<\/b> \u2014 vlasnik klju\u010da. Ako je klju\u010d sistemski, na primjer, Master Key, ovo polje \u0107e biti prazno. Ako je klju\u010d kreiran pomo\u0107u keyring_udf, ovo polje ozna\u010dava vlasnika klju\u010da.<\/li>\n<li><b>sam klju\u010d<\/b><\/li>\n<\/ul>\n<p>\nKlju\u010d se jedinstveno identificira parom: key_id, user.<\/p>\n<p>Tako\u0111er postoje razlike u pohranjivanju i brisanju klju\u010deva.<\/p>\n<p>Datote\u010dko pohranjivanje radi br\u017ee. Mo\u017eemo pretpostaviti da je pohrana klju\u010deva jednostavna jednokratna upisivanje klju\u010da u datoteku, ali nije \u2014 ovdje se odvija vi\u0161e operacija. Prilikom svake modifikacije datote\u010dkog pohranjivanja prvo se izra\u0111uje sigurnosna kopija cijelog sadr\u017eaja. Recimo da datoteka zove my_biggest_secrets, tada \u0107e sigurnosna kopija biti my_biggest_secrets.backup. Zatim se mijenja predmemorija (dodaju ili uklanjaju klju\u010devi) i, ako je sve uspje\u0161no provedeno, predmemorija se vra\u0107a u datoteku. U rijetkim slu\u010dajevima, kao \u0161to je kvar poslu\u017eitelja, mo\u017eete vidjeti ovu datoteku sigurnosne kopije. Datoteka sigurnosne kopije se bri\u0161e pri sljede\u0107em u\u010ditavanju klju\u010deva (obi\u010dno nakon ponovnog pokretanja poslu\u017eitelja).<\/p>\n<p>Prilikom spremanja ili brisanja klju\u010da u poslu\u017eiteljskom pohranjivanju, pohrana se mora povezati s MySQL poslu\u017eiteljem s naredbama \"po\u0161alji klju\u010d\" \/ \"zatra\u017ei brisanje klju\u010da\".<\/p>\n<p>Vratimo se brzini pokretanja poslu\u017eitelja. Osim \u0161to na brzinu pokretanja utje\u010de samo pohranjivanje, postoji i pitanje koliko klju\u010deva iz pohrane treba dobiti prilikom pokretanja. Naravno, to je posebno va\u017eno za poslu\u017eiteljske pohrane. Prilikom pokretanja, poslu\u017eitelj provjerava koji klju\u010d je potreban za \u0161ifrirane tablice \/ tabli\u010dne prostore i zatra\u017ei klju\u010d iz pohrane. Na \"\u010distom\" poslu\u017eitelju s Master Key \u2014 \u0161ifriranjem trebao bi biti jedan Master Key koji treba izvu\u0107i iz pohrane. Me\u0111utim, mo\u017ee biti potrebno i vi\u0161e klju\u010deva, na primjer, kada se na rezervnom poslu\u017eitelju obnavlja sigurnosna kopija s glavnog poslu\u017eitelja. U takvim slu\u010dajevima treba predvidjeti rotaciju Master Key. O tome \u0107e se detaljnije raspravljati u budu\u0107im \u010dlancima, iako bih ovdje \u017eelio napomenuti da poslu\u017eitelj koji koristi vi\u0161e Master Key mo\u017ee se pokretati malo du\u017ee, posebno pri kori\u0161tenju poslu\u017eiteljske pohrane klju\u010deva.<\/p>\n<p>Sada razgovarajmo malo vi\u0161e o keyring_file. Kada sam razvijao keyring_file, tako\u0111er me brinulo kako provjeriti promjenu keyring_file tijekom rada poslu\u017eitelja. U 5.7 provjera se vr\u0161ila na temelju statistike datoteke, \u0161to nije bilo idealno rje\u0161enje, i u 8.0 zamijenjeno je kontrolnom sumom SHA256.<\/p>\n<p>Pri prvom pokretanju keyring_file izra\u010dunava se statistika datoteke i kontrolna suma, koje poslu\u017eitelj pohranjuje, a promjene se rade samo ako se podudaraju. Kada se datoteka promijeni, kontrolna suma se a\u017eurira.<\/p>\n<p>Ve\u0107 smo razmotrili mnoga pitanja o spremi\u0161tima klju\u010deva. Me\u0111utim, postoji jo\u0161 jedna va\u017ena tema o kojoj se \u010desto zaboravlja ili se pogre\u0161no razumije \u2014 razdvajanje klju\u010deva po poslu\u017eiteljima. <\/p>\n<p>\u0160to mislim? Svaki poslu\u017eitelj (npr. Percona Server) u klasteru mora imati posebno mjesto na poslu\u017eitelju Vault, gdje Percona Server treba pohranjivati svoje klju\u010deve. U svakom Master Key pohranjenom u spremi\u0161tu nalazi se GUID poslu\u017eitelja Percona Server unutar svog identifikatora. Za\u0161to je to va\u017eno? Zamislite da imate samo jedan Vault Server i svi Percona Server u klasteru koriste taj jedan Vault Server. Problem se \u010dini o\u010ditim. Da su svi Percona Server koristili Master Key bez jedinstvenih identifikatora, npr. id = 1, id = 2 itd., svi bi poslu\u017eitelji u klasteru koristili isti Master Key. A to je ono \u0161to osigurava GUID \u2014 razdvajanje izme\u0111u poslu\u017eitelja. Za\u0161to onda govoriti o razdvajanju klju\u010deva izme\u0111u poslu\u017eitelja, ako ve\u0107 postoji jedinstveni GUID? Postoji jo\u0161 jedan dodatak \u2014 keyring_udf. Uz pomo\u0107 ovog dodatka korisnik va\u0161eg poslu\u017eitelja mo\u017ee pohranjivati svoje klju\u010deve na poslu\u017eitelju Vault. Problem nastaje kada korisnik stvara klju\u010d, npr. na poslu\u017eitelju server1, a zatim poku\u0161ava stvoriti klju\u010d s istim identifikatorom na server2, na primjer:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 ozna\u010dava uspje\u0161an zavr\u0161etak\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\n\u010cekajte. Obojica poslu\u017eitelja koriste isti Vault Server, zar funkcija keyring_key_store ne bi trebala zavr\u0161iti s gre\u0161kom na poslu\u017eitelju server2? Zanimljivo je da ako poku\u0161ate u\u010diniti isto na jednom poslu\u017eitelju, dobit \u0107ete gre\u0161ku:<\/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>\nTo\u010dno, ROB_1 ve\u0107 postoji.<\/p>\n<p>Prvo \u0107emo razgovarati o drugom primjeru. Kao \u0161to smo ranije spomenuli, keyring_vault ili bilo koji drugi spremnik (keyring) ke\u0161ira sve identifikatore klju\u010deva u memoriji. Tako, nakon \u0161to se novi klju\u010d kreira, ROB_1 se dodaje na server1, i osim slanja tog klju\u010da u Vault, klju\u010d se tako\u0111er dodaje u ke\u0161. Sada, kada poku\u0161avamo dodati taj isti klju\u010d drugi put, keyring_vault provjerava postoji li taj klju\u010d u ke\u0161u i izbacuje gre\u0161ku. <\/p>\n<p>U prvom slu\u010daju situacija je druga\u010dija. Na serverima server1 i server2 postoje odvojeni ke\u0161evi. Nakon dodavanja ROB_1 u ke\u0161 klju\u010deva na serveru server1 i serveru Vault, ke\u0161 klju\u010deva na serveru server2 nije sinkroniziran. U ke\u0161u na serveru server2 nema klju\u010da ROB_1. Tako se klju\u010d ROB_1 zapisuje u keyring_key_store i na server Vault, koji zapravo prepisuje (!) prethodnu vrijednost. Sada je klju\u010d ROB_1 na serveru Vault jednak 543210987654321. Zanimljivo je da server Vault ne blokira takve radnje i jednostavno prepisuje staru vrijednost.<\/p>\n<p>Sada vidimo za\u0161to je odvajanje po serverima na Vaultu bitno \u2014 kada koristite keyring_udf i \u017eelite pohraniti klju\u010deve u Vault. Kako osigurati takvo odvajanje na serveru Vault? <\/p>\n<p>Postoje dva na\u010dina odvajanja na Vaultu. Mo\u017eete stvoriti razli\u010dite to\u010dke montiranja za svaki server ili koristiti razli\u010dite puteve unutar jedne to\u010dke montiranja. Najbolje je to pokazati na primjerima. Dakle, prvo \u0107emo pogledati odvojene to\u010dke montiranja: <\/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>\nOvdje je vidljivo da server1 i server2 koriste razli\u010dite to\u010dke montiranja. Kada su putevi odvojeni, konfiguracija \u0107e izgledati ovako:<\/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>\nU ovom slu\u010daju, oba servera koriste istu ta\u010dku montiranja \u00abmount_point\u00bb, ali razli\u010dite putanje. Kada se prvi tajni podatak kreira na serveru server1 na ovoj putanji, server Vault automatski kreira direktorijum \u00abserver1\u00bb. Za server2 je sve isto. Kada obri\u0161ete poslednji tajni podatak u mount_point\/server1 ili mount_point\/server2, server Vault tako\u0111e bri\u0161e te direktorijume. U slu\u010daju da koristite razdvajanje putanja, morate napraviti samo jednu ta\u010dku montiranja i izmeniti konfiguracione datoteke kako bi serveri koristili odvojene putanje. Ta\u010dku montiranja mo\u017eete kreirati putem HTTP zahteva. Ovo je mogu\u0107e uraditi sa CURL-om na slede\u0107i na\u010din:<\/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>\nSva polja (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) odgovaraju parametrima datoteke konfiguracije. Naravno, mo\u017eete koristiti Vault alate za postizanje istog. Ali je tako lak\u0161e automatizovati kreiranje ta\u010dke montiranja. Nadam se da \u0107e vam ove informacije biti korisne, i vidimo se u slede\u0107im \u010dlancima ove serije.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"Enkripcija u MySQL: 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>\u010citajte vi\u0161e:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench i raspodela slu\u010dajnih veli\u010dina<\/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\/hr\/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=\"hr_HR\" \/>\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\/hr\/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 u MySQL: skladi\u0161te klju\u010deva | ProHoster","description":"Uo\u010di po\u010detka novog upisa na kurs \u201eBaze podataka\u201c, pripremili smo za vas prevod korisnog \u010dlanka.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}