{"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\/ro\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"Criptarea \u00een MySQL: stocarea cheilor","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>\u00cenainte de \u00eenceperea unui nou grup pentru curs <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">\u201eBaze de date\u201d<\/a><\/noindex> am preg\u0103tit pentru tine un traducere a unui articol util.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Criptarea \u00een MySQL: stocarea cheilor\" src=\"\/wp-content\/uploads\/2020\/10\/aeca40f53fe6bdf2a9897aa835ff597d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Criptarea transparent\u0103 a datelor (Transparent Data Encryption, TDE) a ap\u0103rut \u00een <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\">Percona Server for MySQL<\/a><\/noindex> \u0219i MySQL de ceva vreme. Dar te-ai \u00eentrebat vreodat\u0103 cum func\u021bioneaz\u0103 sub capot\u0103 \u0219i ce influen\u021b\u0103 poate avea TDE asupra serverului t\u0103u? \u00cen aceast\u0103 serie de articole, vom explora cum func\u021bioneaz\u0103 TDE \u00een interior. Vom \u00eencepe cu stocarea cheilor, deoarece aceasta este necesar\u0103 pentru func\u021bionarea oric\u0103rei cript\u0103ri. Apoi vom analiza \u00een detaliu cum func\u021bioneaz\u0103 criptarea \u00een Percona Server for MySQL\/MySQL \u0219i ce func\u021bionalit\u0103\u021bi suplimentare exist\u0103 \u00een Percona Server for MySQL.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring este un plugin care permite serverului s\u0103 solicite, s\u0103 creeze \u0219i s\u0103 elimine chei \u00eentr-un fi\u0219ier local (keyring_file) sau pe un server extern (de exemplu, \u00een HashiCorp Vault). Cheile sunt \u00eentotdeauna cache-uite local, pentru a accelera ob\u021binerea acestora. <\/p>\n<p>Pluginurile pot fi \u00eemp\u0103r\u021bite \u00een dou\u0103 categorii:<\/p>\n<ul>\n<li>Stocare local\u0103. De exemplu, un fi\u0219ier local (numim aceasta stocare bazat\u0103 pe fi\u0219iere, file-based keyring).<\/li>\n<li>Stocare la distan\u021b\u0103. De exemplu, Vault Server (numim aceasta stocare bazat\u0103 pe servere, server-based keyring).<\/li>\n<\/ul>\n<p>\nAceast\u0103 \u00eemp\u0103r\u021bire este important\u0103, deoarece diferite tipuri de stoc\u0103ri se comport\u0103 u\u0219or diferit nu doar la stocarea \u0219i ob\u021binerea cheilor, ci \u0219i la pornire.<\/p>\n<p>Atunci c\u00e2nd utilizezi o stocare bazat\u0103 pe fi\u0219iere, la pornire se \u00eencarc\u0103 tot con\u021binutul stoc\u0103rii \u00een cache: key id, key user, key type \u0219i cheia \u00een sine.<\/p>\n<p>\u00cen cazul unei stoc\u0103ri bazate pe server (de exemplu, serverul Vault), la pornire se \u00eencarc\u0103 doar key id \u0219i key user, astfel \u00eenc\u00e2t ob\u021binerea tuturor cheilor nu \u00eencetine\u0219te pornirea. Cheile sunt \u00eenc\u0103rcate oarecum lazy. Adic\u0103 cheia \u00een sine este \u0219tears\u0103 din Vault doar atunci c\u00e2nd este necesar\u0103 efectiv. Dup\u0103 ce a fost \u00eenc\u0103rcat\u0103, cheia este cache-uit\u0103 \u00een memorie, pentru a nu mai necesita accesul prin conexiuni TLS la Vault Server. S\u0103 mai vedem ce informa\u021bii se g\u0103sesc \u00een stocarea cheilor.<\/p>\n<p>Informa\u021biile despre cheie con\u021bin urm\u0103toarele:<\/p>\n<ul>\n<li><b>key id<\/b> \u2014 identificatorul cheii, de exemplu: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>key type<\/b> \u2014 tipul cheii, bazat pe algoritmul de criptare utilizat, valorile posibile sunt: \u201eAES\u201d, \u201eRSA\u201d sau \u201eDSA\u201d.<\/li>\n<li><b>key length<\/b> \u2014 lungimea cheii \u00een octe\u021bi, AES: 16, 24 sau 32, RSA 128, 256, 512 \u0219i DSA 128, 256 sau 384.<\/li>\n<li><b>utilizator<\/b> \u2014 de\u021bin\u0103torul cheii. Dac\u0103 cheia este sistemic\u0103, de exemplu, Master Key, atunci acest c\u00e2mp este gol. Dac\u0103 cheia este creat\u0103 folosind keyring_udf, atunci acest c\u00e2mp indic\u0103 de\u021bin\u0103torul cheii.<\/li>\n<li><b>cheia \u00een sine<\/b><\/li>\n<\/ul>\n<p>\nCheia este identificat\u0103 \u00een mod clar de perechea: key_id, user.<\/p>\n<p>Exist\u0103 de asemenea diferen\u021be \u00een stocarea \u0219i \u0219tergerea cheilor.<\/p>\n<p>Stocarea pe fi\u0219iere func\u021bioneaz\u0103 mai rapid. Se poate presupune c\u0103 stocarea cheilor este o simpl\u0103 \u00eenregistrare unic\u0103 a cheii \u00eentr-un fi\u0219ier, dar nu este a\u0219a \u2014 aici au loc mai multe opera\u021biuni. La orice modificare a stoc\u0103rii pe fi\u0219iere, mai \u00eent\u00e2i se creeaz\u0103 o copie de rezerv\u0103 a \u00eentregului con\u021binut. S\u0103 presupunem c\u0103 fi\u0219ierul se nume\u0219te my_biggest_secrets, atunci copia de rezerv\u0103 va fi my_biggest_secrets.backup. Apoi, se modific\u0103 memoria cache (se adaug\u0103 sau se \u0219terg chei) \u0219i, dac\u0103 totul decurge cu succes, memoria cache este rescris\u0103 \u00een fi\u0219ier. \u00cen cazuri rare, cum ar fi o defec\u021biune a serverului, este posibil s\u0103 vezi acest fi\u0219ier de rezerv\u0103. Fi\u0219ierul de rezerv\u0103 este \u0219ters la urm\u0103toarea \u00eenc\u0103rcare a cheilor (de obicei dup\u0103 repornirea serverului).<\/p>\n<p>Atunci c\u00e2nd salvezi sau \u0219teri o cheie \u00een stocarea serverului, stocarea trebuie s\u0103 se conecteze la serverul MySQL cu comenzile \u201etrimite cheie\u201d \/ \u201esolicit\u0103 \u0219tergerea cheii\u201d (\u201esend the key\u201d \/ \u201erequest key deletion\u201d).<\/p>\n<p>S\u0103 ne \u00eentoarcem la viteza de pornire a serverului. Pe l\u00e2ng\u0103 faptul c\u0103 viteza de pornire este influen\u021bat\u0103 de stocare \u00een sine, exist\u0103 \u0219i \u00eentrebarea c\u00e2te chei din stocare trebuie s\u0103 fie ob\u021binute la pornire. Desigur, acest lucru este deosebit de important pentru stoc\u0103rile serverului. La pornire, serverul verific\u0103 ce cheie este necesar\u0103 pentru tabelele criptate \/ spa\u021biile de tabele \u0219i solicit\u0103 cheia din stocare. Pe un server \u201ecurat\u201d cu criptare Master Key \u2014 trebuie s\u0103 existe o singur\u0103 Master Key, care trebuie extras\u0103 din stocare. Cu toate acestea, poate fi necesar un num\u0103r mai mare de chei, de exemplu, atunci c\u00e2nd pe un server de rezerv\u0103 se restaureaz\u0103 o copie de rezerv\u0103 de pe serverul principal. \u00cen astfel de cazuri, ar trebui prev\u0103zut\u0103 rota\u021bia Master Key. Acest aspect va fi discutat \u00een articolele viitoare, de\u0219i aici a\u0219 dori s\u0103 subliniez c\u0103 un server care utilizeaz\u0103 mai multe Master Key poate porni pu\u021bin mai lent, \u00een special atunci c\u00e2nd folose\u0219te stocarea cheilor serverului.<\/p>\n<p>Acum s\u0103 discut\u0103m pu\u021bin despre keyring_file. C\u00e2nd am dezvoltat keyring_file, m-a preocupat, de asemenea, modul de verificare a modific\u0103rii keyring_file \u00een timpul func\u021bion\u0103rii serverului. \u00cen versiunea 5.7, verificarea se realiza pe baza statisticilor fi\u0219ierului, ceea ce nu era o solu\u021bie ideal\u0103, iar \u00een versiunea 8.0 aceasta a fost \u00eenlocuit\u0103 cu suma de control SHA256.<\/p>\n<p>La prima rulare, keyring_file calculeaz\u0103 statisticile fi\u0219ierului \u0219i suma de control, care sunt memorate de server, iar modific\u0103rile sunt aplicate doar dac\u0103 acestea coincid. La modificarea fi\u0219ierului, suma de control este actualizat\u0103.<\/p>\n<p>Am discutat deja multe aspecte despre magazinul de chei. Totu\u0219i, exist\u0103 o tem\u0103 important\u0103 pe care mul\u021bi o uit\u0103 sau o \u00een\u021beleg gre\u0219it - separarea cheilor pe servere. <\/p>\n<p>Ce vreau s\u0103 spun? Fiecare server (de exemplu, Percona Server) din cluster trebuie s\u0103 aib\u0103 un loc separat pe serverul Vault, unde Percona Server \u00ee\u0219i va stoca cheile. Fiecare Master Key salvat \u00een magazin con\u021bine GUID-ul serverului Percona Server \u00een interiorul identificatorului s\u0103u. De ce este important? Imagineaz\u0103-\u021bi c\u0103 ai un singur Vault Server \u0219i toate Percona Server din cluster folosesc acest singur Vault Server. Problema pare evident\u0103. Dac\u0103 toate Percona Server ar folosi Master Key f\u0103r\u0103 identificatori unici, de exemplu, id = 1, id = 2 etc., atunci toate serverele din cluster ar folosi aceea\u0219i Master Key. Iar asta este ceea ce asigur\u0103 GUID-ul - delimitarea \u00eentre servere. De ce, atunci, s\u0103 discut\u0103m despre separarea cheilor \u00eentre servere, dac\u0103 deja exist\u0103 un GUID unic? Exist\u0103 un alt plugin - keyring_udf. Cu ajutorul acestui plugin, utilizatorul serverului t\u0103u poate stoca cheile pe serverul Vault. Problema apare atunci c\u00e2nd utilizatorul creeaz\u0103 o cheie, de exemplu, pe serverul server1, \u0219i apoi \u00eencearc\u0103 s\u0103 creeze o cheie cu acela\u0219i identificator pe serverul server2, de exemplu:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 \u00eenseamn\u0103 finalizare de succes\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\nA\u0219teapt\u0103. Ambele servere folosesc acela\u0219i Vault Server, nu ar trebui ca func\u021bia keyring_key_store s\u0103 se \u00eencheie cu o eroare pe serverul server2? Este interesant, c\u0103 dac\u0103 \u00eencerci s\u0103 faci acela\u0219i lucru pe un singur server, vei ob\u021bine o eroare:<\/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>\nCorect, ROB_1 exist\u0103 deja.<\/p>\n<p>S\u0103 discut\u0103m mai \u00eent\u00e2i al doilea exemplu. A\u0219a cum am men\u021bionat anterior, keyring_vault sau orice alt plugin de stocare (keyring) cache-uie\u0219te toate identificatoarele cheilor \u00een memorie. Astfel, dup\u0103 crearea unei noi chei, ROB_1 este ad\u0103ugat pe serverul server1, iar, pe l\u00e2ng\u0103 trimiterea acestei chei \u00een Vault, cheia este, de asemenea, ad\u0103ugat\u0103 \u00een cache. Acum, c\u00e2nd \u00eencerc\u0103m s\u0103 ad\u0103ug\u0103m aceea\u0219i cheie a doua oar\u0103, keyring_vault verific\u0103 dac\u0103 aceast\u0103 cheie exist\u0103 \u00een cache \u0219i returneaz\u0103 o eroare. <\/p>\n<p>\u00cen primul caz, situa\u021bia este diferit\u0103. Pe serverele server1 \u0219i server2 exist\u0103 cache-uri separate. Dup\u0103 ad\u0103ugarea ROB_1 \u00een cache-ul cheilor de pe serverul server1 \u0219i serverul Vault, cache-ul cheilor pe serverul server2 nu este sincronizat. \u00cen cache-ul de pe server2 nu exist\u0103 cheia ROB_1. Astfel, cheia ROB_1 este scris\u0103 \u00een keyring_key_store \u0219i pe serverul Vault, care de fapt suprascrie (!) valoarea anterioar\u0103. Acum, cheia ROB_1 de pe serverul Vault este egal\u0103 cu 543210987654321. Este interesant c\u0103 serverul Vault nu blocheaz\u0103 astfel de ac\u021biuni \u0219i pur \u0219i simplu suprascrie vechea valoare.<\/p>\n<p>Acum vedem de ce separarea pe servere \u00een Vault poate fi important\u0103 \u2014 c\u00e2nd folosi\u021bi keyring_udf \u0219i dori\u021bi s\u0103 stoca\u021bi cheile \u00een Vault. Cum asigura\u021bi o astfel de separare pe serverul Vault? <\/p>\n<p>Exist\u0103 dou\u0103 modalit\u0103\u021bi de a separa \u00een Vault. Pute\u021bi crea diferite puncte de montare pentru fiecare server sau utiliza diferite c\u0103i \u00een interiorul unui singur punct de montare. Cel mai bine este s\u0103 ar\u0103t\u0103m acest lucru prin exemple. A\u0219adar, s\u0103 ne uit\u0103m mai \u00eent\u00e2i la puncte de montare separate: <\/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>\nAici se poate observa c\u0103 serverul server1 \u0219i serverul server2 folosesc puncte de montare diferite. C\u00e2nd separa\u021bi c\u0103ile, configura\u021bia va ar\u0103ta astfel:<\/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>\n\u00cen acest caz, ambele servere folosesc acela\u0219i punct de montare \u201emount_point\u201d, dar c\u0103i diferite. Atunci c\u00e2nd se creeaz\u0103 primul secret pe serverul server1 la aceast\u0103 cale, serverul Vault creeaz\u0103 automat directorul \u201eserver1\u201d. Pentru server2, totul este similar. C\u00e2nd \u0219terge\u021bi ultimul secret din mount_point\/server1 sau mount_point\/server2, serverul Vault \u0219terge de asemenea aceste directoare. \u00cen cazul \u00een care folosi\u021bi separarea c\u0103ilor, trebuie s\u0103 crea\u021bi un singur punct de montare \u0219i s\u0103 modifica\u021bi fi\u0219ierele de configurare, astfel \u00eenc\u00e2t serverele s\u0103 foloseasc\u0103 c\u0103i separate. Punctul de montare poate fi creat printr-o solicitare HTTP. Cu CURL, se poate face astfel:<\/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>\nToate c\u00e2mpurile (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) corespund parametrilor din fi\u0219ierul de configurare. Desigur, se pot utiliza utilitarele Vault pentru a realiza aceea\u0219i opera\u021biune. Dar este mai simplu s\u0103 automatiza\u021bi crearea punctului de montare. Sper c\u0103 aceste informa\u021bii v\u0103 vor fi utile \u0219i ne vom vedea \u00een urm\u0103toarele articole din aceast\u0103 serie.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"Criptarea \u00een MySQL: stocarea cheilor\" src=\"\/wp-content\/uploads\/2020\/10\/291dcdd68660bfc312021582baa628ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<blockquote>\n<h4>Cite\u0219te mai mult:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench \u0219i distribu\u021bia variabilelor aleatoare<\/a><\/noindex><\/li>\n<\/ul>\n<\/blockquote>\n<p>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/522092\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u043e\u0433\u043e \u043d\u0430\u0431\u043e\u0440\u0430 \u043d\u0430 \u043a\u0443\u0440\u0441 \u00ab\u0411\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445\u00bb \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438. \u041f\u0440\u043e\u0437\u0440\u0430\u0447\u043d\u043e\u0435 \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 (Transparent Data Encryption, TDE) \u043f\u043e\u044f\u0432\u0438\u043b\u043e\u0441\u044c \u0432 Percona Server for MySQL \u0438 MySQL \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0434\u0430\u0432\u043d\u043e. \u041d\u043e \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u043b\u0438\u0441\u044c \u043b\u0438 \u0432\u044b \u043a\u043e\u0433\u0434\u0430-\u043d\u0438\u0431\u0443\u0434\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442\u043e\u043c \u0438 \u043a\u0430\u043a\u043e\u0435 \u0432\u043b\u0438\u044f\u043d\u0438\u0435 TDE \u043c\u043e\u0436\u0435\u0442 \u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043d\u0430 \u0432\u0430\u0448 \u0441\u0435\u0440\u0432\u0435\u0440? \u0412 \u044d\u0442\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97665,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97664","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u043e\u0433\u043e \u043d\u0430\u0431\u043e\u0440\u0430 \u043d\u0430 \u043a\u0443\u0440\u0441 \u00ab\u0411\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445\u00bb \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\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\/ro\/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\udd47Criptarea \u00een MySQL: depozitul cheilor | ProHoster","description":"\u00cen a\u0219teptarea \u00eenceperii unei noi sesiuni pentru cursul \u201eBaze de date\u201d, am preg\u0103tit pentru dumneavoastr\u0103 traducerea unui articol util.","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}