{"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\/et\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"Andmete kr\u00fcpteerimine MySQL-is: v\u00f5tmehoidjad","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Uue kursuse alguse eel\u00f5htul <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">Andmebaasid<\/a><\/noindex> oleme teie jaoks valmistanud t\u00f5lke kasulikust artiklist.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Andmete kr\u00fcpteerimine MySQL-is: v\u00f5tmehoidjad\" src=\"\/wp-content\/uploads\/2020\/10\/aeca40f53fe6bdf2a9897aa835ff597d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Ahnustatud andmete kr\u00fcpteerimine (Transparent Data Encryption, TDE) on ilmnenud <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\">Percona Server for MySQL<\/a><\/noindex> ja MySQLis juba \u00fcsna kaua aega tagasi. Kuid kas olete kunagi m\u00f5elnud, kuidas see t\u00f6\u00f6tab ning millist m\u00f5ju TDE teie serverile avaldab? Selles artiklisarjas vaatame, kuidas TDE t\u00f6\u00f6tab sisemiselt. Alustame v\u00f5tmete salvestamisest, sest see on vajalik igasuguse kr\u00fcpteerimise toimimiseks. Seej\u00e4rel vaatame l\u00e4hemalt, kuidas kr\u00fcpteerimine t\u00f6\u00f6tab Percona Server for MySQLi\/MySQLi puhul ja millised lisafunktsioonid on Percona Server for MySQLis.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring on pluginad, mis v\u00f5imaldavad serveril k\u00fcsida, luua ja kustutada v\u00f5tmeid kohalikus failis (keyring_file) v\u00f5i kaugserveris (n\u00e4iteks HashiCorp Vaultis). V\u00f5tmed on alati kohaliku vahem\u00e4lu, et kiirendada nende k\u00e4tte saamist. <\/p>\n<p>Pluginaid saab jagada kahte kategooriasse:<\/p>\n<ul>\n<li>Kohalik salvestus. N\u00e4iteks kohalik fail (me nimetame seda failip\u00f5hiseks v\u00f5tmehoidjaks, file-based keyring).<\/li>\n<li>Kaugsalvestus. N\u00e4iteks Vault Server (me nimetame seda serverip\u00f5hiseks v\u00f5tmehoidjaks, server-based keyring).<\/li>\n<\/ul>\n<p>\nSee jaotus on oluline, kuna erinevad salvestust\u00fc\u00fcbid k\u00e4ituvad veidi erinevalt mitte ainult v\u00f5tmete salvestamisel ja k\u00e4tte saamisel, vaid ka k\u00e4ivitamisel.<\/p>\n<p>Kui kasutatakse failip\u00f5hist v\u00f5tmehoidjat, laaditakse k\u00e4ivitamisel vahem\u00e4llu kogu salvestuse sisu: key id, key user, key type ja ise v\u00f5tme.<\/p>\n<p>Serverip\u00f5hise hoidla (nt Vault server) puhul laaditakse k\u00e4ivitamisel ainult key id ja key user, seega v\u00f5tmete hankimine ei aeglusta k\u00e4ivitamist. V\u00f5tmed laaditakse viivitatud meetodil, st v\u00f5tme laaditakse Vaultist alles siis, kui see t\u00f5eliselt vajalik on. P\u00e4rast laadimist kantakse v\u00f5tme vahem\u00e4llu, et tulevikus ei oleks vajalik selle hankimiseks TLS-\u00fchenduse kaudu Vault Serveriga. J\u00e4rgmine arutelu k\u00e4sitleb, millist teavet v\u00f5tmehoidlas leidub.<\/p>\n<p>V\u00f5tme teave sisaldab j\u00e4rgmist:<\/p>\n<ul>\n<li><b>key id<\/b> \u2014 v\u00f5tme identifikaator, n\u00e4iteks: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>key type<\/b> \u2014 v\u00f5tme t\u00fc\u00fcp, mis p\u00f5hineb kasutataval kr\u00fcpteerimisalgoritmil, v\u00f5imalikud v\u00e4\u00e4rtused: \u00abAES\u00bb, \u00abRSA\u00bb v\u00f5i \u00abDSA\u00bb.<\/li>\n<li><b>key length<\/b> \u2014 v\u00f5tme pikkus baitides, AES: 16, 24 v\u00f5i 32, RSA 128, 256, 512 ja DSA 128, 256 v\u00f5i 384.<\/li>\n<li><b>kasutaja<\/b> \u2014 v\u00f5tme omanik. Kui v\u00f5tme on s\u00fcsteemne, n\u00e4iteks Master Key, on see v\u00e4li t\u00fchi. Kui v\u00f5ti luuakse keyring_udf abil, t\u00e4histab see v\u00e4li v\u00f5tme omaniku.<\/li>\n<li><b>ise v\u00f5ti<\/b><\/li>\n<\/ul>\n<p>\nV\u00f5ti on selgelt identifitseeritav paariga: key_id, user.<\/p>\n<p>Samuti on erinevusi v\u00f5tmete salvestamises ja kustutamises.<\/p>\n<p>Faili salvestamine t\u00f6\u00f6tab kiiremini. Eeldada v\u00f5iks, et v\u00f5tmete hoidmine on lihtsalt v\u00f5tme \u00fchekorraline salvestamine faili, kuid ei ole - siin toimub rohkem operatsioone. Iga kord, kui faili salvestust muudetakse, luuakse kogu sisu varukoopia. Oletame, et faili nimi on my_biggest_secrets, siis varukoopia nimi on my_biggest_secrets.backup. Edasi muudetakse vahem\u00e4lu (lisatakse v\u00f5i kustutatakse v\u00f5tmed) ja kui k\u00f5ik on edukalt tehtud, siis vahem\u00e4lu salvestatakse faili. Harvadel juhtudel, nagu serveri rike, v\u00f5id n\u00e4ha seda varukoopia faili. Varukoopia faili kustutatakse j\u00e4rgmise v\u00f5tmete laadimise ajal (tavaliselt p\u00e4rast serveri taask\u00e4ivitamist).<\/p>\n<p>V\u00f5tme salvestamise v\u00f5i kustutamise korral serveri hoidlas peab hoidla \u00fchendust v\u00f5tma MySQL serveriga, kasutades k\u00e4ske 'saada v\u00f5tme' \/ 'kustu v\u00f5tme' ('send the key' \/ 'request key deletion').<\/p>\n<p>Tagasi minnes serveri k\u00e4ivitamise kiiruseni. Peale selle, et salvestus ise m\u00f5jutab k\u00e4ivitamise kiirus, on ka k\u00fcsimus, kui palju v\u00f5tmeid peate salvestusest k\u00e4ivitamisel saama. Loomulikult on see eriti oluline serveri hoidlate puhul. K\u00e4ivitamisel kontrollib server, milline v\u00f5ti on vajalik kr\u00fcpteeritud tabelite \/ tabeliruumide jaoks ja n\u00f5uab v\u00f5tme salvestusest. 'Puhas' server, millel on Master Key - kr\u00fcpteerimisel peab olema \u00fcks Master Key, mis tuleb salvestusest v\u00e4lja v\u00f5tta. Siiski v\u00f5ib olla vajalik ka rohkem v\u00f5tmeid, kui n\u00e4iteks varu serveris taastatakse varukoopia peamisest serverist. Sellistel juhtudel tuleks ette n\u00e4ha Master Key rotatsioon. Selle kohta k\u00e4sitletakse rohkem tulevastes artiklites, kuigi siin tahaksin mainida, et server, mis kasutab mitmeid Master Key, v\u00f5ib k\u00e4ivituda natuke kauem, eriti v\u00f5tmehoidla kasutamise korral.<\/p>\n<p>N\u00fc\u00fcd r\u00e4\u00e4gime veel natuke keyring_file'ist. Kui t\u00f6\u00f6tasin keyring_file'i kallal, muretsesin ka selle \u00fcle, kuidas kontrollida keyring_file'i muutumist serveri t\u00f6\u00f6 ajal. Versioonis 5.7 toimus kontroll faili statistika p\u00f5hjal, mis ei olnud ideaalne lahendus, ja versioonis 8.0 asendati see SHA256 kontrollsummaga.<\/p>\n<p>Esimese k\u00e4ivitamise korral arvutatakse keyring_file'i f\u00fc\u00fcsilise faili statistika ja kontrollsumma, mis salvestatakse serverisse, ning muudatused rakendatakse ainult juhul, kui need kattuvad. Faili muutmisel uuendatakse kontrollsummat.<\/p>\n<p>Oleme juba arutanud paljusid v\u00f5tmehoidla k\u00fcsimusi. Siiski on veel \u00fcks oluline teema, millele sageli ei p\u00f6\u00f6rata t\u00e4helepanu v\u00f5i mida m\u00f5istetakse valesti \u2014 v\u00f5tmete jagamine serverite kaupa. <\/p>\n<p>Mida ma sellega silmas pean? Igal serveril (n\u00e4iteks Percona Server) klastris peab olema oma eraldi koht Vault serveris, kuhu Percona Server peab oma v\u00f5tmed salvestama. Igas v\u00f5tmehoidlas hoitavas Master Key's sisaldub GUID Percona Serveri serveri identifikaatori sees. Miks see oluline on? Kujutage ette, et teil on ainult \u00fcks Vault Server ja k\u00f5ik Percona Serverid klastris kasutavad seda \u00fchte Vault Serverit. Probleem n\u00e4ib olevat ilmne. Kui k\u00f5ik Percona Serverid kasutaksid Master Key'd ilma ainulaadsete identifikaatoriteta, n\u00e4iteks id = 1, id = 2 jne, siis k\u00f5ik serverid klastris kasutaksid sama Master Key'd. Just seda tagab GUID \u2014 eristamine serverite vahel. Miks siis r\u00e4\u00e4kida v\u00f5tmete jagamisest serverite vahel, kui juba on olemas ainulaadne GUID? On veel \u00fcks plugin \u2014 keyring_udf. Selle plugina abil saab teie serveri kasutaja hoida oma v\u00f5tmeid Vault serveris. Probleem tekib siis, kui kasutaja loob v\u00f5tme, n\u00e4iteks serveris server1, ja seej\u00e4rel proovib luua sama identifikaatoriga v\u00f5tme serveris server2, n\u00e4iteks:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 t\u00e4hendab edukat l\u00f5puleviimist\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\nOodake. M\u00f5lemad serverid kasutavad sama Vault Serverit, ei peaks keyring_key_store funktsioon serveris server2 l\u00f5ppema veaga? Huvitav on see, et kui proovite sama asja teha \u00fchel serveril, saate vea:<\/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>\n\u00d5ige, ROB_1 on juba olemas.<\/p>\n<p>Arutame k\u00f5igepealt teise n\u00e4ite. Nagu me varem mainisime, keyring_vault v\u00f5i m\u00f5ni muu ladu plugin (keyring) salvestab k\u00f5ik v\u00f5tme identifikaatorid m\u00e4llu. Seega, p\u00e4rast uue v\u00f5tme loomist, ROB_1 lisatakse serverisse server1, ja peale selle v\u00f5tme saatmist Vaulti, lisatakse see ka vahem\u00e4esse. N\u00fc\u00fcd, kui proovime sama v\u00f5tme teist korda lisada, kontrollib keyring_vault, kas see v\u00f5ti on vahem\u00e4lus olemas, ja annab veateate. <\/p>\n<p>Esimeses olukorras on olukord teine. Serverites server1 ja server2 on eraldi vahem\u00e4lud. P\u00e4rast ROB_1 lisamist v\u00f5tmete vahem\u00e4llu serveris server1 ja Vault serverisse ei s\u00fcnkroniseerita v\u00f5tmete vahem\u00e4lu serveris server2. Serveris server2 ei ole v\u00f5tme ROB_1. Seega kirjutatakse v\u00f5ti ROB_1 keyring_key_store'i ja Vault serverisse, mis tegelikult kirjutab (!) eelneva v\u00e4\u00e4rtuse \u00fcle. N\u00fc\u00fcd on Vault serveris v\u00f5tme ROB_1 v\u00e4\u00e4rtus v\u00f5rdne 543210987654321. Huvitav, et Vault server ei blokeeri selliseid toiminguid ja kirjutab lihtsalt vana v\u00e4\u00e4rtuse \u00fcle.<\/p>\n<p>N\u00fc\u00fcd n\u00e4eme, miks hajutamine serverite kaupa Vaultis v\u00f5ib olla oluline \u2014 kui kasutate keyring_udf ja soovite ladu hoida Vaultis. Kuidas tagada selline hajutamine Vault serveris? <\/p>\n<p>Vaultis on kaks viisi hajutamiseks. V\u00f5ite luua iga serveri jaoks erinevad mount-punkid v\u00f5i kasutada erinevaid teid \u00fche mount-punkti sees. Parim on seda n\u00e4idata n\u00e4idete abil. Niisiis, vaatame k\u00f5igepealt eraldi mount-punkte: <\/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>\nSiit on n\u00e4ha, et server1 ja server2 kasutavad erinevaid mount-punkte. Teede hajutamise korral n\u00e4eb konfigureerimine v\u00e4lja j\u00e4rgmiselt:<\/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>\nAntud juhul kasutavad m\u00f5lemad serverid sama mount-punkti \u00abmount_point\u00bb, kuid erinevaid teid. Kui esimese saladuse loomisel serveris server1 sellel teel loob Vault automaatselt katalooge \u00abserver1\u00bb. Serveri server2 puhul on k\u00f5ik analoogne. Kui kustutate viimase saladuse mount_point\/server1 v\u00f5i mount_point\/server2-s, kustutab Vault ka need kataloogid. Kui kasutate teede eristamist, peaksite looma ainult \u00fche mount-punkti ja muutma konfiguratsiooni faile, et serverid kasutaksid eraldi teid. Mount-punkti saab luua HTTP-p\u00e4ringu abil. CURL-i abil saab seda teha j\u00e4rgmiselt:<\/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>\nK\u00f5ik v\u00e4ljad (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) vastavad konfiguratsioonifaili parameetritele. Loomulikult saab sama teha Vault utiliitide abil. Kuid mount-punkti loomise automatiseerimine on lihtsam. Loodan, et see teave on teile kasulik ja kohtume j\u00e4rgmistes selle seeria artiklites.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"Andmete kr\u00fcpteerimine MySQL-is: v\u00f5tmehoidjad\" src=\"\/wp-content\/uploads\/2020\/10\/291dcdd68660bfc312021582baa628ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<blockquote>\n<h4>Loe edasi:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench ja juhuslike v\u00e4\u00e4rtuste jaotamine<\/a><\/noindex><\/li>\n<\/ul>\n<\/blockquote>\n<p>Allikas: <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.1.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\/et\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"et_EE\" \/>\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\/et\/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\udd47Kr\u00fcpteerimine MySQL-is: v\u00f5tmehoidla | ProHoster","description":"Uue gruppi alustamise eel valmistame teie jaoks t\u00f5lke kasulikust artiklist kursusele \u201eAndmebaasid\u201d.","canonical_url":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"et_EE","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\/et\/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\/et\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/et\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}