{"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\/nl\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"Encryption in MySQL: key storage","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>In de aanloop naar de start van een nieuwe groep voor de cursus <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">Database<\/a><\/noindex> hebben we een vertaling van een nuttig artikel voor u voorbereid.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Encryption in MySQL: key storage\" src=\"\/wp-content\/uploads\/2020\/10\/aeca40f53fe6bdf2a9897aa835ff597d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Transparante gegevensversleuteling (Transparent Data Encryption, TDE) is al een tijd aanwezig in <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\">Percona Server for MySQL<\/a><\/noindex> en MySQL. Maar heb je je ooit afgevraagd hoe het werkt onder de motorkap en welke invloed TDE op je server kan hebben? In deze serie artikelen zullen we bekijken hoe TDE intern werkt. We beginnen met de opslag van sleutels, omdat dit essentieel is voor de werking van elke vorm van versleuteling. Vervolgens kijken we gedetailleerd naar hoe versleuteling werkt in Percona Server for MySQL\/MySQL en welke extra mogelijkheden er zijn in Percona Server for MySQL.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nDe Keyring is een plugin die het de server mogelijk maakt om sleutels aan te vragen, te cre\u00ebren en te verwijderen in een lokaal bestand (keyring_file) of op een externe server (bijvoorbeeld in HashiCorp Vault). Sleutels worden altijd lokaal gecached om hun ophalen te versnellen. <\/p>\n<p>Plugins kunnen in twee categorie\u00ebn worden verdeeld:<\/p>\n<ul>\n<li>Lokaal opslag. Bijvoorbeeld een lokaal bestand (we noemen dit een bestandsopslag voor sleutels, file-based keyring).<\/li>\n<li>Externe opslag. Bijvoorbeeld Vault Server (we noemen dit een serveropslag voor sleutels, server-based keyring).<\/li>\n<\/ul>\n<p>\nDeze scheiding is belangrijk omdat verschillende typen opslag zich iets anders gedragen, niet alleen bij het opslaan en ophalen van sleutels, maar ook bij opstarten.<\/p>\n<p>Bij het gebruik van bestandsopslag wordt bij het opstarten de complete inhoud van de opslag in de cache geladen: key id, key user, key type en de sleutel zelf.<\/p>\n<p>In het geval van serveropslag (bijvoorbeeld een Vault server) wordt bij het opstarten slechts de key id en key user geladen, waardoor het ophalen van alle sleutels de opstart niet vertraagt. Sleutels worden lui geladen; de sleutel wordt alleen met Vault geladen wanneer deze daadwerkelijk nodig is. Nadat de sleutel is geladen, wordt deze in het geheugen gecached, zodat er in de toekomst niet opnieuw via TLS-verbindingen naar de Vault Server hoeft te worden gezocht. Laten we nu eens kijken welke informatie er in de sleutelopslag aanwezig is.<\/p>\n<p>Informatie over de sleutel bevat het volgende:<\/p>\n<ul>\n<li><b>key id<\/b> \u2014 de identificatie van de sleutel, bijvoorbeeld: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>key type<\/b> \u2014 het type sleutel, gebaseerd op het gebruikte versleutelingsalgoritme, mogelijke waarden: 'AES', 'RSA' of 'DSA'.<\/li>\n<li><b>key length<\/b> \u2014 de lengte van de sleutel in bytes, AES: 16, 24 of 32, RSA: 128, 256, 512 en DSA: 128, 256 of 384.<\/li>\n<li><b>gebruiker<\/b> \u2014 de eigenaar van de sleutel. Als de sleutel systeemgebonden is, zoals de Master Key, is dit veld leeg. Als de sleutel is aangemaakt met keyring_udf, dan geeft dit veld de eigenaar van de sleutel aan.<\/li>\n<li><b>de sleutel<\/b><\/li>\n<\/ul>\n<p>\nDe sleutel wordt ondubbelzinnig ge\u00efdentificeerd door een paar: key_id, gebruiker.<\/p>\n<p>Er zijn ook verschillen in het opslaan en verwijderen van sleutels.<\/p>\n<p>De bestandsopslag werkt sneller. Men zou kunnen veronderstellen dat de sleutelopslag een eenvoudige eenmalige registratie van de sleutel in een bestand is, maar dat is niet zo \u2014 er vinden hier meer bewerkingen plaats. Bij elke wijziging in de bestandsopslag wordt eerst een back-up van de volledige inhoud gemaakt. Stel dat het bestand my_biggest_secrets heet, dan is de back-up my_biggest_secrets.backup. Vervolgens wordt de cache gewijzigd (sleutels worden toegevoegd of verwijderd) en, als alles succesvol is uitgevoerd, wordt de cache naar het bestand opgeslagen. In zeldzame gevallen, zoals serverfouten, kunt u dit back-upbestand zien. Het back-upbestand wordt verwijderd bij de volgende laadbeurt van de sleutels (meestal na een herstart van de server).<\/p>\n<p>Bij het opslaan of verwijderen van een sleutel in de serveropslag moet de opslag verbinding maken met de MySQL-server met de opdrachten \"verzend sleutel\" \/ \"verzoek verwijdering sleutel\" (\"send the key\" \/ \"request key deletion\").<\/p>\n<p>Laten we terugkomen op de opstarttijd van de server. Naast het feit dat de opslag zelf de opstarttijd be\u00efnvloedt, is er ook de vraag hoeveel sleutels uit de opslag nodig zijn bij de opstart. Natuurlijk is dit vooral belangrijk voor serveropslag. Bij de opstart controleert de server welke sleutel nodig is voor versleutelde tabellen \/ tabbladen en vraagt de sleutel op uit de opslag. Op een \"schone\" server met Master Key \u2014 versleuteling moet er \u00e9\u00e9n Master Key zijn die uit de opslag moet worden gehaald. Het kan echter ook nodig zijn om meer sleutels te gebruiken, bijvoorbeeld wanneer op de reserve-server een back-up van de hoofdserver wordt hersteld. In dergelijke gevallen moet er rekening worden gehouden met de rotatie van de Master Key. Dit zal verder worden besproken in toekomstige artikelen, hoewel ik hier wil opmerken dat een server die meerdere Master Keys gebruikt iets langer kan opstarten, vooral wanneer gebruik wordt gemaakt van de serveropslag voor sleutels.<\/p>\n<p>Laten we nu nog wat meer praten over keyring_file. Toen ik keyring_file ontwikkelde, maakte ik me ook zorgen over hoe ik de wijziging van keyring_file kon controleren tijdens het draaien van de server. In 5.7 werd de controle uitgevoerd op basis van bestandsstatistieken, wat geen ideale oplossing was, en in 8.0 werd het vervangen door een SHA256-hash.<\/p>\n<p>Bij de eerste start van keyring_file wordt de statistiek van het bestand en de controlewaarde berekend, die door de server worden opgeslagen, en de wijzigingen worden alleen toegepast als ze overeenkomen. Bij wijziging van het bestand wordt de controlewaarde ge\u00fcpdatet.<\/p>\n<p>We hebben al veel vragen over sleutelopslag besproken. Er is echter nog een belangrijk onderwerp dat vaak wordt vergeten of verkeerd begrepen: de scheiding van sleutels per server. <\/p>\n<p>Wat bedoel ik? Elke server (bijvoorbeeld Percona Server) in het cluster moet een aparte plek op de Vault-server hebben waar Percona Server zijn sleutels moet opslaan. In elke Master Key, opgeslagen in de opslag, zit de GUID van de Percona Server in zijn identificatie. Waarom is dit belangrijk? Stel je voor dat je maar \u00e9\u00e9n Vault-server hebt en alle Percona-servers in het cluster deze enige Vault-server gebruiken. Het probleem lijkt voor de hand liggend. Als alle Percona-servers de Master Key zonder unieke identificaties zouden gebruiken, bijvoorbeeld, id = 1, id = 2, enzovoort, dan zouden alle servers in het cluster dezelfde Master Key gebruiken. Dat is wat de GUID biedt \u2014 de scheiding tussen servers. Waarom zou je dan nog praten over het scheiden van sleutels tussen servers, als er al een unieke GUID bestaat? Er is nog een plugin \u2014 keyring_udf. Met deze plugin kan de gebruiker van jouw server zijn sleutels op de Vault-server opslaan. Het probleem ontstaat wanneer de gebruiker een sleutel aanmaakt, bijvoorbeeld op server1, en vervolgens probeert een sleutel met dezelfde identificatie aan te maken op server2, bijvoorbeeld:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 betekent succesvolle voltooiing\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\nWacht even. Beide servers gebruiken dezelfde Vault-server, zou de functie keyring_key_store niet met een fout moeten eindigen op server2? Interessant genoeg, als je hetzelfde op \u00e9\u00e9n server probeert te doen, krijg je een foutmelding:<\/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>\nJuist, ROB_1 bestaat al.<\/p>\n<p>Laten we eerst het tweede voorbeeld bespreken. Zoals eerder vermeld, cachet keyring_vault of een andere opslagplugin (keyring) alle sleutelidentificaties in het geheugen. Nadat een nieuwe sleutel is aangemaakt, wordt ROB_1 toegevoegd op server1, en naast het verzenden van deze sleutel naar Vault, wordt de sleutel ook aan de cache toegevoegd. Nu, wanneer we proberen om dezelfde sleutel voor de tweede keer toe te voegen, controleert keyring_vault of deze sleutel al in de cache bestaat en geeft een foutmelding. <\/p>\n<p>In het eerste geval is de situatie anders. Op de servers server1 en server2 zijn er aparte caches. Na toevoeging van ROB_1 aan de sleutelcache op server1 en de Vault-server, is de sleutelcache op server2 niet gesynchroniseerd. In de cache op server2 is er geen sleutel ROB_1. Daarom wordt sleutel ROB_1 geschreven naar keyring_key_store en naar de Vault-server, wat feitelijk de vorige waarde (!) overschrijft. Nu is sleutel ROB_1 op de Vault-server gelijk aan 543210987654321. Interessant is dat de Vault-server dergelijke acties niet blokkeert en eenvoudig de oude waarde overschrijft.<\/p>\n<p>Nu zien we waarom het scheiden op servers in Vault belangrijk kan zijn \u2014 wanneer je keyring_udf gebruikt en je sleutels in Vault wilt opslaan. Hoe zorg je voor zo'n scheiding op de Vault-server? <\/p>\n<p>Er zijn twee manieren om scheiding in Vault aan te brengen. Je kunt verschillende montagemogelijkheden voor elke server cre\u00ebren of verschillende paden binnen \u00e9\u00e9n montagemogelijkheid gebruiken. Dit kan het beste worden ge\u00efllustreerd aan de hand van voorbeelden. Laten we dus eerst kijken naar afzonderlijke montagemogelijkheden: <\/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>\nHier is te zien dat server1 en server2 verschillende montagemogelijkheden gebruiken. Bij het scheiden van paden zou de configuratie er als volgt uitzien:<\/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>\nIn dit geval gebruiken beide servers hetzelfde mountpoint \"mount_point\", maar met verschillende paden. Wanneer je het eerste geheim aanmaakt op server server1 op dit pad, maakt de Vault-server automatisch de directory \"server1\" aan. Voor server2 is het allemaal hetzelfde. Wanneer je het laatste geheim verwijdert in mount_point\/server1 of mount_point\/server2, verwijdert de Vault-server ook deze directories. Als je padverdeling gebruikt, moet je slechts \u00e9\u00e9n mountpoint aanmaken en de configuratiebestanden aanpassen zodat de servers afzonderlijke paden gebruiken. Een mountpoint kan worden aangemaakt met een HTTP-verzoek. Dit kan met CURL als volgt:<\/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>\nAlle velden (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) komen overeen met de parameters van het configuratiebestand. Natuurlijk kun je de Vault-hulpmiddelen gebruiken om hetzelfde te doen. Maar zo is het makkelijker om de aanmaak van een mountpoint te automatiseren. Ik hoop dat deze informatie nuttig voor je is, en we zien elkaar in de volgende artikelen van deze serie.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"Encryption in MySQL: key storage\" src=\"\/wp-content\/uploads\/2020\/10\/291dcdd68660bfc312021582baa628ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<blockquote>\n<h4>Lees meer:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench en de verdeling van willekeurige variabelen<\/a><\/noindex><\/li>\n<\/ul>\n<\/blockquote>\n<p>Bron: <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.3 - 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\/nl\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\/nl\/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 Encryptie in MySQL: sleutelbeheer | ProHoster","description":"Ter gelegenheid van de lancering van een nieuwe serie voor de cursus \"Databases\" hebben we een vertaling van een nuttig artikel voor je voorbereid.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}