{"id":97667,"date":"2020-10-20T08:42:25","date_gmt":"2020-10-20T06:42:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/shifrovanie-v-mysql-ispolzovanie-master-key"},"modified":"2020-10-20T08:42:25","modified_gmt":"2020-10-20T06:42:25","slug":"shifrovanie-v-mysql-ispolzovanie-master-key","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/shifrovanie-v-mysql-ispolzovanie-master-key","title":{"rendered":"\u0160ifriranje u MySQL-u: kori\u0161tenje glavnog klju\u010da","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h2><\/h2>\n<p><strong><em>Uo\u010di po\u010detka novog upisa na te\u010daj&nbsp;<\/em><\/strong><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/wMyj\/\"><strong><em>\u00abBaze podataka\u00bb<\/em><\/strong><\/a><\/noindex><strong><em>&nbsp;nastavljamo s objavljivanjem serije \u010dlanaka o \u0161ifriranju u MySQL-u.<\/em><\/strong><\/p>\n<p><img decoding=\"async\" alt=\"\u0160ifriranje u MySQL-u: kori\u0161tenje glavnog klju\u010da\" src=\"\/wp-content\/uploads\/2020\/10\/762866d2c321acd726e30606c9108122.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>U prethodnom \u010dlanku ove serije (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/522092\/\"><u>Enkripcija u MySQL: skladi\u0161te klju\u010deva<\/u><\/a><\/noindex>) razgovarali smo o skladi\u0161tima klju\u010deva. U ovom \u010dlanku razmotrit \u0107emo kako se koristi glavni klju\u010d, kao i raspraviti prednosti i nedostatke \u0161ifriranja metodom omota (envelope encryption).&nbsp;<\/p>\n<p>Ideja \u0161ifriranja omota je da se klju\u010devi kori\u0161teni za \u0161ifriranje (klju\u010devi tabli\u010dnih prostora) \u0161ifriraju drugim klju\u010dem (glavnim klju\u010dem). Klju\u010devi tabli\u010dnih prostora se zapravo koriste za \u0161ifriranje podataka. Grafi\u010dki se to mo\u017ee prikazati ovako:<\/p>\n<p><img decoding=\"async\" alt=\"\u0160ifriranje u MySQL-u: kori\u0161tenje glavnog klju\u010da\" src=\"\/wp-content\/uploads\/2020\/10\/385afda0eff739f4720f59799c35b51f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Glavni klju\u010d (master key) nalazi se u skladi\u0161tu klju\u010deva (keyring), a klju\u010devi tabli\u010dnih prostora su u zaglavljima enkriptiranih tabli\u010dnih prostora (na stranici 0 tabli\u010dnog prostora).&nbsp;<\/p>\n<p>Na slici iznad:<\/p>\n<ul>\n<li>\n<p>Tablica A je \u0161ifrirana klju\u010dem 1. Klju\u010d 1 se \u0161ifrira pomo\u0107u glavnog klju\u010da i pohranjuje u \u0161ifriranom obliku u zaglavlju tablice A.<\/p>\n<\/li>\n<li>\n<p>Tablica B je \u0161ifrirana klju\u010dem 2. Klju\u010d 2 se \u0161ifrira pomo\u0107u glavnog klju\u010da i pohranjuje u \u0161ifriranom obliku u zaglavlju tablice B.<\/p>\n<\/li>\n<li>\n<p>I tako dalje.<\/p>\n<\/li>\n<\/ul>\n<p>Kada serveru zatreba de\u0161ifriranje tablice A, on dobiva glavni klju\u010d iz skladi\u0161ta, \u010dita \u0161ifrirani klju\u010d 1 iz zaglavlja tablice A i de\u0161ifrira klju\u010d 1. De\u0161ifrirani klju\u010d 1 se pohranjuje u ke\u0161u servera i koristi za de\u0161ifriranje tablice A.<\/p>\n<h3>InnoDB<\/h3>\n<p>U InnoDB, stvarno \u0161ifriranje i de\u0161ifriranje odvijaju se na razini ulaza-izlaza. To zna\u010di da se stranica \u0161ifrira neposredno prije nego \u0161to se isprazni na disk i de\u0161ifrira odmah nakon \u010ditanja s diska.<\/p>\n<p>U InnoDB, \u0161ifriranje djeluje samo na razini tabli\u010dnih prostora. I po defaultu, sve tablice se stvaraju u posebnim tabli\u010dnim prostorima (<noindex><a rel=\"nofollow\" href=\"https:\/\/dev.mysql.com\/doc\/refman\/8.0\/en\/innodb-file-per-table-tablespaces.html\"><u>file-per-table tablespace<\/u><\/a><\/noindex>). Drugim rije\u010dima, stvara se tabli\u010dni prostor koji mo\u017ee sadr\u017eavati samo jednu tablicu. Iako mo\u017eete stvarati tablice i u glavnom tabli\u010dnom prostoru (<noindex><a rel=\"nofollow\" href=\"https:\/\/dev.mysql.com\/doc\/refman\/8.0\/en\/general-tablespaces.html\"><u>general tablespace<\/u><\/a><\/noindex>). No, u svakom slu\u010daju, tablica se uvijek nalazi u nekom tabli\u010dnom prostoru. A budu\u0107i da se \u0161ifriranje vr\u0161i na razini tabli\u010dnog prostora, ono je ili potpuno \u0161ifrirano ili nije. To jest, nije mogu\u0107e u glavnom tabli\u010dnom prostoru \u0161ifrirati samo dio tablica.&nbsp;<\/p>\n<p>Ako je iz nekog razloga isklju\u010den file-per-table, sve tablice se stvaraju unutar sistemskog tabli\u010dnog prostora (system tablespace). U <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\"><u>Percona Server for MySQL<\/u><\/a><\/noindex> mo\u017eete enkriptirati sistemski tabli\u010dni prostor pomo\u0107u varijable innodb<em>sys<\/em>tablespace<em>encrypt ili koriste\u0107i tokove enkripcije (encryption threads), ali to je jo\u0161 uvijek eksperimentalna funkcija. U MySQL-u toga nema.<\/em><\/p>\n<p><em>Prije nego \u0161to krenemo dalje, trebamo razmotriti strukturu identifikatora glavnog klju\u010da (master key ID). Sastoji se od UUID-a, KEY<\/em>ID i prefiks \u00abINNODBKey\u00bb. Izgleda ovako: INNODBKey-UUID-KEY<em>ID.<\/em><\/p>\n<p><em>UUID \u2014 to je uuid servera s enkriptiranim tabli\u010dnim prostorom. KEY<\/em>ID \u2014 to je samo stalno rastu\u0107a vrijednost. Prilikom prvotnog stvaranja glavnog klju\u010da KEY<em>ID je jednak 1. Prilikom rotacije klju\u010da, kada se stvara novi glavni klju\u010d, KEY<\/em>ID = 2 i tako dalje. O rotaciji glavnih klju\u010deva razgovarat \u0107emo u sljede\u0107im \u010dlancima ove serije.<\/p>\n<p>Sada, kada znamo kako izgleda identifikator glavnog klju\u010da, pogledajmo zaglavlje enkriptiranog tabli\u010dnog prostora. Kada se tabli\u010dni prostor enkriptira, informacije o enkripciji dodaju se u zaglavlje. Izgleda ovako:<\/p>\n<p><img decoding=\"async\" alt=\"\u0160ifriranje u MySQL-u: kori\u0161tenje glavnog klju\u010da\" src=\"\/wp-content\/uploads\/2020\/10\/0703933a85f0a106c07c0dbd6b7f4186.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>KEY ID \u2014 to je KEY<em>ID iz identifikatora glavnog klju\u010da koji smo ve\u0107 raspravili. UUID \u2014 to je uuid servera, koji se tako\u0111er koristi u identifikatoru glavnog klju\u010da. TABLESPACE KEY \u2014 klju\u010d tabli\u010dnog prostora koji se sastoji od 256 bitova, nasumi\u010dno generiranih od strane servera. Vektor inicijalizacije (IV, initialization vector) tako\u0111er se sastoji od 256 nasumi\u010dno generiranih bitova (iako bi trebao biti 128 bitova). IV se koristi za inicijalizaciju enkripcije i dekripcije AES-a (od 256 bitova koristi se samo 128). Na kraju se nalazi kontrolna suma CRC32 za TABLESPACE KEY i IV.<\/em><\/p>\n<p><em>Sve to vrijeme malo sam pojednostavio, govore\u0107i da u zaglavlju postoji enkriptirani klju\u010d tabli\u010dnog prostora. U stvarnosti, klju\u010d tabli\u010dnog prostora i vektor inicijalizacije pohranjuju se i enkriptiraju zajedno s pomo\u0107u glavnog klju\u010da. Zapamtite, prije enkripcije klju\u010da tabli\u010dnog prostora i vektora inicijalizacije, za njih se izra\u010dunava CRC32.<\/em><\/p>\n<h3>Za\u0161to je CRC32 potreban?<\/h3>\n<p><em>Ukratko, kako biste se uvjerili u valjanost glavnog klju\u010da. Nakon de\u0161ifriranja klju\u010da tabelarnog prostora i vektora inicijalizacije, izra\u010dunava se kontrolna suma i uspore\u0111uje s CRC32, pohranjenom u zaglavlju. Ako se kontrolne sume podudaraju, imamo ispravni glavni klju\u010d i klju\u010d tabelarnog prostora. U suprotnom, tabelarni prostor se ozna\u010dava kao nedostupan (ne\u0107emo ga mo\u0107i de\u0161ifrirati).<\/em><\/p>\n<p><em>Mo\u017eete se pitati: u kojem trenutku se provodi provjera klju\u010deva? Odgovor \u2014 pri pokretanju servera. Server s enkriptiranim tablicama\/tabli\u010dnim prostorima pri pokretanju \u010dita UUID, KEY<\/em>ID iz zaglavlja i generira identifikator glavnog klju\u010da. Zatim dobiva potrebni glavni klju\u010d iz skladi\u0161ta (keyring), de\u0161ifrira klju\u010d tabli\u010dnog prostora i provjerava kontrolnu sumu. Jo\u0161 jednom, ako se kontrolna suma podudara, onda je sve u redu; ako ne \u2014 tabli\u010dni prostor se ozna\u010dava kao nedostupan.<\/p>\n<p>Ako ste \u010ditali prethodni \u010dlanak ove serije (<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/522092\/\"><u>Enkripcija u MySQL: skladi\u0161te klju\u010deva<\/u><\/a><\/noindex>), mogli biste se sjetiti da prilikom kori\u0161tenja serverskog spremi\u0161ta klju\u010deva, server pri pokretanju dobiva samo popis identifikatora klju\u010deva, odnosno key id i user id, jer se ovaj par jednozna\u010dno identificira kao klju\u010d. A sada ka\u017eem da server pri pokretanju dobiva sve klju\u010deve potrebne za provjeru mogu\u0107nosti de\u0161ifriranja klju\u010deva tabelarnih prostora. Za\u0161to se pri inicijalizaciji, u slu\u010daju serverskog spremi\u0161ta, u\u010ditavaju samo key<em>id i user<\/em>id, a ne svi klju\u010devi? Zato \u0161to vam mo\u017eda nisu potrebni svi klju\u010devi. Uglavnom se to odnosi na rotaciju glavnog klju\u010da. Pri rotaciji glavnog klju\u010da u spremi\u0161tu se stvara novi glavni klju\u010d, ali stari klju\u010devi se ne bri\u0161u. Tako u serverskom spremi\u0161tu klju\u010deva mo\u017ee biti mnogo klju\u010deva koji nisu potrebni serveru i stoga se ne izvla\u010de prilikom pokretanja servera.<\/p>\n<p>Do\u0161lo je vrijeme da malo razgovaramo o prednostima i nedostacima \u0161ifriranja pomo\u0107u glavnog klju\u010da. Najve\u0107a prednost je \u0161to vam je potreban samo jedan klju\u010dno \u0161ifriranje (glavni klju\u010d), koji \u0107e se \u010duvati odvojeno od va\u0161ih \u0161ifriranih podataka. To ubrzava pokretanje poslu\u017eitelja, a skladi\u0161te ostaje malo, \u0161to olak\u0161ava upravljanje. Tako\u0111er, jedini glavni klju\u010d se lako mo\u017ee ponovo generirati.<\/p>\n<p>Me\u0111utim, \u0161ifriranje pomo\u0107u glavnog klju\u010da ima jednu veliku manu: nakon \u0161to je prostor tablice \u0161ifriran pomo\u0107u tablespace_key, uvijek ostaje \u0161ifriran istim klju\u010dem. Rotacija glavnog klju\u010da ovdje ne poma\u017ee. Za\u0161to je to mana? Znamo da u MySQL-u postoje gre\u0161ke koje mogu dovesti do iznenadnog kvara i stvaranja core datoteke. Budu\u0107i da core datoteka sadr\u017ei snimak memorije poslu\u017eitelja, mo\u017ee se dogoditi da u snimku bude de\u0161ifrirani klju\u010d prostora tablice. \u0160to je jo\u0161 gore, de\u0161ifrirani klju\u010devi prostora tablice pohranjuju se u memoriji koja se mo\u017ee zamijeniti na disku. Mo\u017eda \u0107ete re\u0107i da to nije mana, jer su vam potrebne root privilegije za pristup tim datotekama i swap particiji. Da. Ali root je potreban samo na trenutak. Nakon \u0161to netko dobije pristup de\u0161ifriranom klju\u010du prostora tablice, on\/ona \u0107e mo\u0107i dalje koristiti taj klju\u010d za de\u0161ifriranje podataka, \u010dak i bez root privilegija. Osim toga, disk se mo\u017ee ukrasti, a swap particija\/core datoteke se mogu pro\u010ditati pomo\u0107u vanjskih alata. Cilj TDE-a je u\u010diniti ih ne\u010ditljivima, \u010dak i ako se disk ukrade. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\"><u>Percona Server for MySQL<\/u><\/a><\/noindex> postoji mogu\u0107nost ponovnog \u0161ifriranja prostora tablice s novim generiranim klju\u010devima. Ova funkcija se naziva tokovi \u0161ifriranja (encryption threads) i u trenutku pisanja ovog \u010dlanka jo\u0161 uvijek je eksperimentalna.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/wMyj\/\"><strong>Saznajte vi\u0161e o te\u010daju<\/strong><\/a><\/noindex><\/p>\n<h3>\u010citajte vi\u0161e:<\/h3>\n<ul>\n<li>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/522092\/\">Enkripcija u MySQL: skladi\u0161te klju\u010deva<\/a><\/noindex><\/p>\n<\/li>\n<\/ul>\n<p>Izvor: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/524050\/\">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&nbsp;\u00ab\u0411\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445\u00bb&nbsp;\u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u0442\u044c \u0441\u0435\u0440\u0438\u044e \u0441\u0442\u0430\u0442\u0435\u0439 \u043f\u0440\u043e \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0432 MySQL. \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u044d\u0442\u043e\u0439 \u0441\u0435\u0440\u0438\u0438 (\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) \u043c\u044b \u0433\u043e\u0432\u043e\u0440\u0438\u043b\u0438 \u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430\u0445 \u043a\u043b\u044e\u0447\u0435\u0439. \u0412 \u044d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c, \u043a\u0430\u043a \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442\u0441\u044f \u0433\u043b\u0430\u0432\u043d\u044b\u0439 \u043a\u043b\u044e\u0447 (master key), \u0430 \u0442\u0430\u043a\u0436\u0435 \u043e\u0431\u0441\u0443\u0434\u0438\u043c \u0434\u043e\u0441\u0442\u043e\u0438\u043d\u0441\u0442\u0432\u0430 \u0438 \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043a\u0438 \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043c\u0435\u0442\u043e\u0434\u043e\u043c \u043a\u043e\u043d\u0432\u0435\u0440\u0442\u043e\u0432 (envelope encryption).&nbsp; \u0418\u0434\u0435\u044f \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043a\u043e\u043d\u0432\u0435\u0440\u0442\u043e\u0432 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97668,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97667","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\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c.\" \/>\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-ispolzovanie-master-key\" \/>\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: \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 Master Key | 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\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/shifrovanie-v-mysql-ispolzovanie-master-key\" \/>\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:25+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-10-20T06:42:25+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-u: kori\u0161tenje Master Key-a | ProHoster","description":"Uo\u010di po\u010detka novog ciklusa te\u010daja 'Baze podataka' nastavljamo.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/shifrovanie-v-mysql-ispolzovanie-master-key","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: \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0435 Master Key | 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\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c.","og:url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/shifrovanie-v-mysql-ispolzovanie-master-key","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:25+00:00","article:modified_time":"2020-10-20T06:42:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97667","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:51","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\/97667","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=97667"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/97667\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/97668"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=97667"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=97667"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=97667"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}