{"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\/sk\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"\u0160ifrovanie v MySQL: \u00falo\u017eisko k\u013e\u00fa\u010dov","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Pred spusten\u00edm nov\u00e9ho kurzu <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">\u201eDatab\u00e1zy\u201c<\/a><\/noindex> pripravili sme pre v\u00e1s preklad u\u017eito\u010dn\u00e9ho \u010dl\u00e1nku.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"\u0160ifrovanie v MySQL: \u00falo\u017eisko k\u013e\u00fa\u010dov\" src=\"\/wp-content\/uploads\/2020\/10\/aeca40f53fe6bdf2a9897aa835ff597d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Transparentn\u00e9 \u0161ifrovanie \u00fadajov (Transparent Data Encryption, TDE) sa objavilo v <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\">Percona Server for MySQL<\/a><\/noindex> a MySQL u\u017e dos\u0165 d\u00e1vno. Ale zamysleli ste sa niekedy nad t\u00fdm, ako funguje pod pokrievkou a ak\u00fd vplyv m\u00f4\u017ee ma\u0165 TDE na v\u00e1\u0161 server? V tejto s\u00e9rii \u010dl\u00e1nkov si podrobne rozoberieme, ako TDE funguje vo vn\u00fatri. Za\u010dneme so skladovan\u00edm k\u013e\u00fa\u010dov, preto\u017ee je potrebn\u00e9 na ak\u00e9ko\u013evek \u0161ifrovanie. N\u00e1sledne sa podrobne pozrieme na to, ako funguje \u0161ifrovanie v Percona Server for MySQL\/MySQL a ak\u00e9 \u010fal\u0161ie mo\u017enosti pon\u00faka Percona Server for MySQL.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring \u2014 to s\u00fa pluginy, ktor\u00e9 umo\u017e\u0148uj\u00fa serveru \u017eiada\u0165, vytv\u00e1ra\u0165 a odstra\u0148ova\u0165 k\u013e\u00fa\u010de v lok\u00e1lnom s\u00fabore (keyring_file) alebo na vzdialenom serveri (napr\u00edklad v HashiCorp Vault). K\u013e\u00fa\u010de sa v\u017edy ukladaj\u00fa do cache lok\u00e1lne, aby sa ur\u00fdchlil ich pr\u00edstup. <\/p>\n<p>Pluginy m\u00f4\u017eeme rozdeli\u0165 do dvoch kateg\u00f3ri\u00ed:<\/p>\n<ul>\n<li>Lok\u00e1lne \u00falo\u017eisko. Napr\u00edklad lok\u00e1lny s\u00fabor (naz\u00fdvame to s\u00faborov\u00e9 \u00falo\u017eisko k\u013e\u00fa\u010dov, file-based keyring).<\/li>\n<li>Vzdialen\u00e9 \u00falo\u017eisko. Napr\u00edklad Vault Server (naz\u00fdvame to serverov\u00e9 \u00falo\u017eisko k\u013e\u00fa\u010dov, server-based keyring).<\/li>\n<\/ul>\n<p>\nToto rozdelenie je d\u00f4le\u017eit\u00e9, preto\u017ee r\u00f4zne typy \u00falo\u017e\u00edsk sa spr\u00e1vaj\u00fa trochu inak nielen pri ukladan\u00ed a z\u00edskavan\u00ed k\u013e\u00fa\u010dov, ale aj pri spusten\u00ed.<\/p>\n<p>Pri pou\u017eit\u00ed s\u00faborov\u00e9ho \u00falo\u017eiska sa pri spusten\u00ed do cache na\u010d\u00edta cel\u00fd obsah \u00falo\u017eiska: key id, key user, key type a samotn\u00fd k\u013e\u00fa\u010d.<\/p>\n<p>V pr\u00edpade serverov\u00e9ho \u00falo\u017eiska (napr\u00edklad server Vault) sa pri spusten\u00ed na\u010d\u00edta len key id a key user, preto z\u00edskanie v\u0161etk\u00fdch k\u013e\u00fa\u010dov nezdr\u017euje spustenie. K\u013e\u00fa\u010de sa na\u010d\u00edtavaj\u00fa len vtedy, ke\u010f s\u00fa skuto\u010dne potrebn\u00e9. Po na\u010d\u00edtan\u00ed sa k\u013e\u00fa\u010d uklad\u00e1 do cache v pam\u00e4ti, aby v bud\u00facnosti nebolo potrebn\u00e9 po\u017eiada\u0165 o\u0148 cez TLS pripojenia na Vault Server. Teraz si pozrieme, ak\u00e9 inform\u00e1cie s\u00fa k dispoz\u00edcii v \u00falo\u017eisku k\u013e\u00fa\u010dov.<\/p>\n<p>Inform\u00e1cie o k\u013e\u00fa\u010di obsahuj\u00fa nasleduj\u00face:<\/p>\n<ul>\n<li><b>key id<\/b> \u2014 identifik\u00e1tor k\u013e\u00fa\u010da, napr\u00edklad: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>key type<\/b> \u2014 typ k\u013e\u00fa\u010da, ktor\u00fd je zalo\u017een\u00fd na pou\u017eitom algoritme \u0161ifrovania, mo\u017en\u00e9 hodnoty: \u201eAES\u201c, \u201eRSA\u201c alebo \u201eDSA\u201c.<\/li>\n<li><b>key length<\/b> \u2014 d\u013a\u017eka k\u013e\u00fa\u010da v bajtoch, AES: 16, 24 alebo 32, RSA 128, 256, 512 a DSA 128, 256 alebo 384.<\/li>\n<li><b>user<\/b> \u2014 vlastn\u00edk k\u013e\u00fa\u010da. Ak je k\u013e\u00fa\u010d syst\u00e9mov\u00fd, napr\u00edklad Master Key, toto pole zost\u00e1va pr\u00e1zdne. Ak je k\u013e\u00fa\u010d vytvoren\u00fd pomocou keyring_udf, toto pole ozna\u010duje vlastn\u00edka k\u013e\u00fa\u010da.<\/li>\n<li><b>samotn\u00fd k\u013e\u00fa\u010d<\/b><\/li>\n<\/ul>\n<p>\nK\u013e\u00fa\u010d sa jednozna\u010dne identifikuje dvojicou: key_id, user.<\/p>\n<p>Existuj\u00fa aj rozdiely v ulo\u017een\u00ed a odstra\u0148ovan\u00ed k\u013e\u00fa\u010dov.<\/p>\n<p>S\u00faborov\u00e9 \u00falo\u017eisko funguje r\u00fdchlej\u0161ie. Je mo\u017en\u00e9 predpoklada\u0165, \u017ee \u00falo\u017eisko k\u013e\u00fa\u010dov je len jednoduch\u00e9 jednorazov\u00e9 zap\u00edsanie k\u013e\u00fa\u010da do s\u00faboru, ale nie \u2014 tu prebieha viac oper\u00e1ci\u00ed. Pri akejko\u013evek modifik\u00e1cii s\u00faborov\u00e9ho \u00falo\u017eiska sa najsk\u00f4r vytvor\u00ed z\u00e1loha cel\u00e9ho obsahu. Predpokladajme, \u017ee s\u00fabor sa naz\u00fdva my_biggest_secrets, z\u00e1loha teda bude my_biggest_secrets.backup. Potom sa zmen\u00ed cache (pridaj\u00fa alebo odstr\u00e1nia k\u013e\u00fa\u010de) a ak je v\u0161etko \u00faspe\u0161ne vykonan\u00e9, cache sa vyma\u017ee do s\u00faboru. V zriedkav\u00fdch pr\u00edpadoch, ako je zlyhanie servera, m\u00f4\u017eete vidie\u0165 tento z\u00e1lo\u017en\u00fd s\u00fabor. S\u00fabor z\u00e1lohy sa odstra\u0148uje pri nasleduj\u00facom na\u010d\u00edtan\u00ed k\u013e\u00fa\u010dov (zvy\u010dajne po re\u0161tarte servera).<\/p>\n<p>Pri ulo\u017een\u00ed alebo odstr\u00e1nen\u00ed k\u013e\u00fa\u010da v serverovom \u00falo\u017eisku sa \u00falo\u017eisko mus\u00ed pripoji\u0165 k serveru MySQL s pr\u00edkazmi \u201eodo\u0161li k\u013e\u00fa\u010d\u201c \/ \u201epo\u017eiadanie o odstr\u00e1nenie k\u013e\u00fa\u010da\u201c (\u201esend the key\u201c \/ \u201erequest key deletion\u201c).<\/p>\n<p>Teraz sa vr\u00e1\u0165me k r\u00fdchlosti spustenia servera. Okrem toho, \u017ee na r\u00fdchlos\u0165 spustenia vpl\u00fdva samotn\u00e9 \u00falo\u017eisko, je tu aj ot\u00e1zka, ko\u013eko k\u013e\u00fa\u010dov z \u00falo\u017eiska je potrebn\u00e9 z\u00edska\u0165 pri spusten\u00ed. Samozrejme, to je obzvl\u00e1\u0161\u0165 d\u00f4le\u017eit\u00e9 pre serverov\u00e9 \u00falo\u017eisk\u00e1. Pri spusten\u00ed server kontroluje, ktor\u00fd k\u013e\u00fa\u010d je potrebn\u00fd pre \u0161ifrovan\u00e9 tabu\u013eky \/ tabu\u013ekov\u00e9 priestory a po\u017eaduje k\u013e\u00fa\u010d z \u00falo\u017eiska. Na \u201e\u010distom\u201c serveri so \u0161ifrovan\u00edm Master Key by mal by\u0165 iba jeden Master Key, ktor\u00fd je potrebn\u00e9 vytiahnu\u0165 z \u00falo\u017eiska. M\u00f4\u017ee v\u0161ak by\u0165 potrebn\u00e9 aj viac k\u013e\u00fa\u010dov, napr\u00edklad pri obnove z\u00e1lohy na z\u00e1lo\u017enom serveri z hlavn\u00e9ho servera. V tak\u00fdchto pr\u00edpadoch by sa mal predpoklada\u0165 cyklus rot\u00e1cie Master Key. Podrobnej\u0161ie sa t\u00fdm budeme zaobera\u0165 v bud\u00facich \u010dl\u00e1nkoch, hoci tu by som r\u00e1d poznamenal, \u017ee server pou\u017e\u00edvaj\u00faci nieko\u013eko Master Key m\u00f4\u017ee sp\u00fa\u0161\u0165a\u0165 o nie\u010do dlh\u0161ie, najm\u00e4 pri pou\u017eit\u00ed serverov\u00e9ho \u00falo\u017eiska k\u013e\u00fa\u010dov.<\/p>\n<p>Teraz sa e\u0161te trochu porozpr\u00e1vajme o keyring_file. Ke\u010f som vyv\u00edjal keyring_file, tie\u017e ma zauj\u00edmalo, ako kontrolova\u0165 zmeny v keyring_file po\u010das prev\u00e1dzky servera. V 5.7 sa kontrola vykon\u00e1vala na z\u00e1klade \u0161tatistiky s\u00faboru, \u010do nebolo ide\u00e1lne rie\u0161enie, a v 8.0 bolo nahraden\u00e9 kontroln\u00fdm s\u00fa\u010dtom SHA256.<\/p>\n<p>Pri prvom spusten\u00ed sa vypo\u010d\u00edta \u0161tatistika s\u00faboru a kontroln\u00e1 suma pre keyring_file, ktor\u00e9 server ulo\u017e\u00ed, a zmeny sa aplikuj\u00fa iba v pr\u00edpade, \u017ee sa zhoduj\u00fa. Pri zmene s\u00faboru sa kontroln\u00e1 suma aktualizuje.<\/p>\n<p>U\u017e sme prebrali mnoh\u00e9 ot\u00e1zky t\u00fdkaj\u00face sa \u00falo\u017e\u00edsk k\u013e\u00fa\u010dov. Existuje v\u0161ak e\u0161te jedna d\u00f4le\u017eit\u00e1 t\u00e9ma, na ktor\u00fa sa \u010dasto zab\u00fada alebo sa nespr\u00e1vne ch\u00e1pe \u2013 rozdelenie k\u013e\u00fa\u010dov pod\u013ea serverov. <\/p>\n<p>\u010co m\u00e1m na mysli? Ka\u017ed\u00fd server (napr\u00edklad Percona Server) v klastri mus\u00ed ma\u0165 samostatn\u00e9 miesto na serveri Vault, kde mus\u00ed Percona Server uchov\u00e1va\u0165 svoje k\u013e\u00fa\u010de. Ka\u017ed\u00fd Master Key ulo\u017een\u00fd v \u00falo\u017eisku obsahuje GUID servera Percona Server vo svojom identifik\u00e1tore. Pre\u010do je to d\u00f4le\u017eit\u00e9? Predstavte si, \u017ee m\u00e1te iba jeden Vault Server a v\u0161etky Percona Servery v klastri pou\u017e\u00edvaj\u00fa tento jedin\u00fd Vault Server. Probl\u00e9m sa zd\u00e1 by\u0165 o\u010dividn\u00fd. Keby v\u0161etky Percona Servery pou\u017e\u00edvali Master Key bez jedine\u010dn\u00fdch identifik\u00e1torov, napr\u00edklad id = 1, id = 2 a pod., v\u0161etky servery v klastri by pou\u017e\u00edvali ten ist\u00fd Master Key. GUID zabezpe\u010duje rozdelenie medzi servermi. Pre\u010do teda hovori\u0165 o rozdelen\u00ed k\u013e\u00fa\u010dov medzi servermi, ak u\u017e existuje jedine\u010dn\u00fd GUID? Existuje e\u0161te jeden plugin \u2013 keyring_udf. S pomocou tohto pluginu m\u00f4\u017ee pou\u017e\u00edvate\u013e v\u00e1\u0161ho servera uchov\u00e1va\u0165 svoje k\u013e\u00fa\u010de na serveri Vault. Probl\u00e9m nast\u00e1va, ke\u010f pou\u017e\u00edvate\u013e vytvor\u00ed k\u013e\u00fa\u010d napr\u00edklad na serveri server1 a potom sa pok\u00fasi vytvori\u0165 k\u013e\u00fa\u010d s t\u00fdm ist\u00fdm identifik\u00e1torom na serveri server2, napr\u00edklad:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 znamen\u00e1 \u00faspe\u0161n\u00e9 dokon\u010denie\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\nPo\u010dkajte. Oba servery pou\u017e\u00edvaj\u00fa rovnak\u00fd Vault Server, nemala by funkcia keyring_key_store skon\u010di\u0165 s chybou na serveri server2? Zauj\u00edmav\u00e9 je, \u017ee ak sa pok\u00fasite urobi\u0165 to ist\u00e9 na jednom serveri, dostanete chybu:<\/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>\nSpr\u00e1vne, ROB_1 u\u017e existuje.<\/p>\n<p>Po\u010fme sa najsk\u00f4r podrobne zaobera\u0165 druh\u00fdm pr\u00edkladom. Ako sme u\u017e spomenuli, keyring_vault, alebo ak\u00fdko\u013evek in\u00fd plugin \u00falo\u017eiska (keyring), cache v\u0161etky identifik\u00e1tory k\u013e\u00fa\u010dov v pam\u00e4ti. Tak\u017ee, po vytvoren\u00ed nov\u00e9ho k\u013e\u00fa\u010da, ROB_1 sa prid\u00e1va na server1, a okrem odoslania tohto k\u013e\u00fa\u010da do Vault sa k\u013e\u00fa\u010d tie\u017e prid\u00e1va do cache. Teraz, ke\u010f sa pok\u00fa\u0161ame prida\u0165 rovnak\u00fd k\u013e\u00fa\u010d po druh\u00fd raz, keyring_vault kontroluje, \u010di tento k\u013e\u00fa\u010d existuje v cache a vr\u00e1ti chybu. <\/p>\n<p>V prvom pr\u00edpade je situ\u00e1cia in\u00e1. Na serveroch server1 a server2 s\u00fa samostatn\u00e9 cache. Po pridan\u00ed ROB_1 do cache k\u013e\u00fa\u010dov na serveri server1 a server Vault, cache k\u013e\u00fa\u010dov na serveri server2 nie je synchronizovan\u00e1. V cache na serveri server2 nie je k\u013e\u00fa\u010d ROB_1. Tak\u017ee, k\u013e\u00fa\u010d ROB_1 je zap\u00edsan\u00fd do keyring_key_store a na server Vault, ktor\u00fd vlastne prep\u00ed\u0161e (!) predch\u00e1dzaj\u00facu hodnotu. Teraz je k\u013e\u00fa\u010d ROB_1 na serveri Vault rovn\u00fd 543210987654321. Zauj\u00edmav\u00e9 je, \u017ee server Vault tak\u00e9to akcie neblokuje a bez probl\u00e9mov prep\u00ed\u0161e star\u00fa hodnotu.<\/p>\n<p>Teraz vid\u00edme, pre\u010do m\u00f4\u017ee by\u0165 d\u00f4le\u017eit\u00e9 rozdelenie pod\u013ea serverov na Vault \u2014 ke\u010f pou\u017e\u00edvate keyring_udf a chcete uklada\u0165 k\u013e\u00fa\u010de v Vault. Ako zabezpe\u010di\u0165 tak\u00e9to rozdelenie na serveri Vault? <\/p>\n<p>Existuj\u00fa dva sp\u00f4soby, ako vykona\u0165 rozdelenie na Vault. M\u00f4\u017eete vytvori\u0165 r\u00f4zne monta\u017en\u00e9 body pre ka\u017ed\u00fd server alebo pou\u017ei\u0165 r\u00f4zne cesty v r\u00e1mci jedn\u00e9ho monta\u017en\u00e9ho bodu. Najlep\u0161ie to uk\u00e1za\u0165 na pr\u00edkladoch. Tak\u017ee, pozrime sa najprv na samostatn\u00e9 monta\u017en\u00e9 body: <\/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 = server2_mount\ntoken = (...)\nvault_ca = (...)<\/code><\/pre>\n<p>\nTu je zrejm\u00e9, \u017ee server1 a server2 pou\u017e\u00edvaj\u00fa r\u00f4zne monta\u017en\u00e9 body. Pri delen\u00ed ciest bude konfigur\u00e1cia vyzera\u0165 nasledovne:<\/p>\n<pre><code class=\"sql\">--server1:\nvault_url = http:\/\/127.0.0.1:8200\nsecret_mount_point = mount_point\/server1\ntoken = (...)\nvault_ca = (...)\n--server2:\nvault_url = http:\/\/127.0.0.1:8200\nsecret_mount_point = mount_point\/server2\ntoken = (...)\nvault_ca = (...)<\/code><\/pre>\n<p>\nV tomto pr\u00edpade oba servery pou\u017e\u00edvaj\u00fa rovnak\u00fd bod pripojenia \u201emount_point\u201c, ale r\u00f4zne cesty. Pri vytv\u00e1ran\u00ed prv\u00e9ho tajn\u00e9ho k\u013e\u00fa\u010da na serveri server1 na tejto ceste server Vault automaticky vytv\u00e1ra adres\u00e1r \u201eserver1\u201c. Pre server2 plat\u00ed to ist\u00e9. Ke\u010f odstr\u00e1nite posledn\u00fd tajn\u00fd k\u013e\u00fa\u010d v mount_point\/server1 alebo mount_point\/server2, server Vault tie\u017e odstr\u00e1ni tieto adres\u00e1re. V pr\u00edpade, \u017ee pou\u017e\u00edvate oddelenie ciest, mus\u00edte vytvori\u0165 iba jeden bod pripojenia a zmeni\u0165 konfigura\u010dn\u00e9 s\u00fabory, aby servery pou\u017e\u00edvali samostatn\u00e9 cesty. Bod pripojenia mo\u017eno vytvori\u0165 prostredn\u00edctvom HTTP po\u017eiadavky. Pomocou CURL to mo\u017eno urobi\u0165 nasleduj\u00facim sp\u00f4sobom:<\/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>\nV\u0161etky polia (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) zodpovedaj\u00fa parametroch konfigura\u010dn\u00e9ho s\u00faboru. Samozrejme, m\u00f4\u017eete vyu\u017ei\u0165 utilitky Vault, aby ste dosiahli to ist\u00e9. Ale takto je jednoduch\u0161ie automatizova\u0165 vytvorenie bodu pripojenia. D\u00fafam, \u017ee tieto inform\u00e1cie bud\u00fa pre v\u00e1s u\u017eito\u010dn\u00e9 a stretneme sa v nasleduj\u00facich \u010dl\u00e1nkoch tejto s\u00e9rie.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"\u0160ifrovanie v MySQL: \u00falo\u017eisko k\u013e\u00fa\u010dov\" src=\"\/wp-content\/uploads\/2020\/10\/291dcdd68660bfc312021582baa628ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<blockquote>\n<h4>\u010c\u00edta\u0165 \u010falej:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench a rozdelenie n\u00e1hodn\u00fdch hodn\u00f4t<\/a><\/noindex><\/li>\n<\/ul>\n<\/blockquote>\n<p>Zdroj: <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\/sk\/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=\"sk_SK\" \/>\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\/sk\/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\u0160ifrovanie v MySQL: \u00falo\u017eisko k\u013e\u00fa\u010dov | ProHoster","description":"V predve\u010der za\u010datia nov\u00e9ho cyklu na kurze \u201eDatab\u00e1zy\u201c sme pre v\u00e1s pripravili preklad u\u017eito\u010dn\u00e9ho \u010dl\u00e1nku.","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","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\/sk\/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\/sk\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}