{"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\/da\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"Kryptering i MySQL: n\u00f8glelagring","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>I forklaringen af den nye optagelse til kurset <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">\u00abDatabaser\u00bb<\/a><\/noindex> vi har forberedt en overs\u00e6ttelse af en nyttig artikel til dig.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Kryptering i MySQL: n\u00f8glelagring\" src=\"\/wp-content\/uploads\/2020\/10\/aeca40f53fe6bdf2a9897aa835ff597d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Transparent datakryptering (Transparent Data Encryption, TDE) er blevet introduceret i <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\">Percona Server for MySQL<\/a><\/noindex> og MySQL for l\u00e6nge siden. Men har du nogensinde t\u00e6nkt over, hvordan det fungerer under overfladen, og hvilken indvirkning TDE kan have p\u00e5 din server? I denne artikelserie vil vi se p\u00e5, hvordan TDE fungerer internt. Vi starter med n\u00f8glelagring, da det er n\u00f8dvendigt for al kryptering. Derefter vil vi unders\u00f8ge, hvordan kryptering fungerer i Percona Server for MySQL\/MySQL og hvilke ekstra funktioner der er i Percona Server for MySQL.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring er plugins, der tillader serveren at anmode om, oprette og slette n\u00f8gler i en lokal fil (keyring_file) eller p\u00e5 en fjernserver (f.eks. i HashiCorp Vault). N\u00f8glerne caches altid lokalt for at fremskynde adgangen. <\/p>\n<p>Plugins kan opdeles i to kategorier:<\/p>\n<ul>\n<li>Lokalt lager. For eksempel en lokal fil (vi kalder dette filbaseret n\u00f8glelager, file-based keyring).<\/li>\n<li>Fjernlager. For eksempel Vault Server (vi kalder dette serverbaseret n\u00f8glelager, server-based keyring).<\/li>\n<\/ul>\n<p>\nDenne opdeling er vigtig, fordi forskellige typer lagre opf\u00f8rer sig lidt forskelligt, ikke kun ved opbevaring og hentning af n\u00f8gler, men ogs\u00e5 ved opstart.<\/p>\n<p>N\u00e5r der anvendes et filbaseret lager, indl\u00e6ses alt indholdet af lageret i cachen ved opstart: n\u00f8gle-id, n\u00f8glebruger, n\u00f8gletype og selve n\u00f8glen.<\/p>\n<p>I tilf\u00e6lde af et serverbaseret lager (f.eks. Vault server) indl\u00e6ses kun n\u00f8gle-id og n\u00f8glebruger ved opstart, s\u00e5 hentning af alle n\u00f8gler ikke forsinker opstarten. N\u00f8glerne indl\u00e6ses 'lazy'. Det vil sige, at selve n\u00f8glen kun indl\u00e6ses fra Vault, n\u00e5r den faktisk er n\u00f8dvendig. Efter indl\u00e6sning caches n\u00f8glen i hukommelsen for at undg\u00e5 fremtidige TLS-forbindelser til Vault Server. Lad os se, hvilken information der er til stede i n\u00f8glelageret.<\/p>\n<p>Oplysningerne om n\u00f8glen indeholder f\u00f8lgende:<\/p>\n<ul>\n<li><b>n\u00f8gle-id<\/b> \u2014 identifikator for n\u00f8glen, f.eks.: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>n\u00f8gletype<\/b> \u2014 typen af n\u00f8glen, baseret p\u00e5 den anvendte krypteringsalgoritme, mulige v\u00e6rdier: \"AES\", \"RSA\" eller \"DSA\".<\/li>\n<li><b>n\u00f8glel\u00e6ngde<\/b> \u2014 l\u00e6ngden af n\u00f8glen i bytes, AES: 16, 24 eller 32, RSA 128, 256, 512 og DSA 128, 256 eller 384.<\/li>\n<li><b>user<\/b> \u2014 ejer af n\u00f8glen. Hvis n\u00f8glen er en systemn\u00f8gle, f.eks. Master Key, er dette felt tomt. Hvis n\u00f8glen oprettes ved hj\u00e6lp af keyring_udf, angiver dette felt ejer af n\u00f8glen.<\/li>\n<li><b>selve n\u00f8glen<\/b><\/li>\n<\/ul>\n<p>\nN\u00f8glen identificeres entydigt af et par: key_id, user.<\/p>\n<p>Der er ogs\u00e5 forskelle i opbevaring og sletning af n\u00f8gler.<\/p>\n<p>Filopbevaringen fungerer hurtigere. Man kunne antage, at n\u00f8gleopbevaringen er en simpel engangsindskrivning af n\u00f8glen i filen, men det er ikke tilf\u00e6ldet \u2014 der sker flere operationer her. Ved enhver \u00e6ndring af filopbevaringen oprettes f\u00f8rst en sikkerhedskopi af alt indholdet. Lad os sige, at filen hedder my_biggest_secrets, s\u00e5 vil sikkerhedskopien hedde my_biggest_secrets.backup. Derefter \u00e6ndres cachen (n\u00f8gler f\u00f8jes til eller fjernes fra) og, hvis alt g\u00e5r godt, nulstilles cachen til filen. I sj\u00e6ldne tilf\u00e6lde, s\u00e5som serverfejl, kan du se denne sikkerhedskopsfil. Sikkerhedskopsfilen slettes ved n\u00e6ste indl\u00e6sning af n\u00f8glerne (normalt efter genstart af serveren).<\/p>\n<p>N\u00e5r en n\u00f8gle gemmes eller slettes i serveropbevaringen, skal opbevaringen oprette forbindelse til MySQL-serveren med kommandoerne \"send n\u00f8gle\" \/ \"anmod om sletning af n\u00f8gle\".<\/p>\n<p>Lad os vende tilbage til serverens opstartshastighed. Udover at selve opbevaringen p\u00e5virker opstartshastigheden, er der ogs\u00e5 sp\u00f8rgsm\u00e5let om, hvor mange n\u00f8gler fra opbevaringen der skal hentes ved opstart. Det er selvf\u00f8lgelig is\u00e6r vigtigt for serveropbevaringer. Ved opstart kontrollerer serveren, hvilken n\u00f8gle der er n\u00f8dvendig for de krypterede tabeller \/ tabelrum, og anmoder om n\u00f8glen fra opbevaringen. P\u00e5 en \"ren\" server med Master Key - kryptering skal der v\u00e6re en Master Key, der skal hentes fra opbevaringen. Dog kan der v\u00e6re behov for flere n\u00f8gler, for eksempel n\u00e5r en sikkerhedskopi fra hovedserveren genoprettes p\u00e5 en reserve server. I s\u00e5danne tilf\u00e6lde b\u00f8r der overvejes rotation af Master Key. Dette vil blive behandlet mere i fremtidige artikler, men her vil jeg gerne p\u00e5pege, at en server, der bruger flere Master Keys, kan starte lidt l\u00e6ngere tid, is\u00e6r n\u00e5r man bruger serveropbevaringen til n\u00f8gler.<\/p>\n<p>Lad os nu tale lidt mere om keyring_file. Da jeg udviklede keyring_file, var jeg ogs\u00e5 bekymret for, hvordan man skulle tjekke \u00e6ndringerne af keyring_file, mens serveren k\u00f8rte. I 5.7 blev kontrollen udf\u00f8rt baseret p\u00e5 filens statistik, hvilket ikke var en perfekt l\u00f8sning, og i 8.0 blev det \u00e6ndret til en SHA256-kontrollsum.<\/p>\n<p>Ved f\u00f8rste opstart beregner keyring_file filens statistik og kontrolsum, som gemmes af serveren, og \u00e6ndringer anvendes kun, hvis de stemmer overens. Ved \u00e6ndring af filen opdateres kontrolsummen.<\/p>\n<p>Vi har allerede dr\u00f8ftet mange emner omkring n\u00f8glelagre. Men der er et vigtigt emne, som ofte glemmes eller misforst\u00e5s \u2014 opdelingen af n\u00f8gler mellem serverne. <\/p>\n<p>Hvad mener jeg med det? Hver server (f.eks. Percona Server) i klyngen skal have sit eget omr\u00e5de p\u00e5 Vault-serveren, hvor Percona Server skal opbevare sine n\u00f8gler. Hver Master Key gemt i lageret indeholder GUID'en for Percona Server inden for sin identifikator. Hvorfor er det vigtigt? Forestil dig, at du kun har \u00e9n Vault-server, og alle Percona Server i klyngen bruger denne ene Vault-server. Problemet virker \u00e5benlyst. Hvis alle Percona Server brugte Master Key uden unikke identifikatorer, f.eks. id = 1, id = 2 osv., ville alle servere i klyngen bruge den samme Master Key. Det, som GUID'en muligg\u00f8r \u2014 adskillelse mellem servere. Hvorfor tale om at opdele n\u00f8gler mellem serverne, n\u00e5r der allerede findes en unik GUID? Der er en anden plugin \u2014 keyring_udf. Med denne plugin kan brugeren af din server gemme sine n\u00f8gler p\u00e5 Vault-serveren. Problemet opst\u00e5r, n\u00e5r brugeren opretter en n\u00f8gle, f.eks. p\u00e5 server1, og derefter fors\u00f8ger at oprette en n\u00f8gle med den samme identifikator p\u00e5 server2, f.eks.:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 betyder vellykket afslutning\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\nVent lige. Begge servere bruger den samme Vault-server, skulle funktionen keyring_key_store ikke afslutte med en fejl p\u00e5 server2? Interessant, at hvis du pr\u00f8ver at g\u00f8re det samme p\u00e5 \u00e9n server, vil du f\u00e5 en fejl:<\/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>\nKorrekt, ROB_1 eksisterer allerede.<\/p>\n<p>Lad os f\u00f8rst diskutere det andet eksempel. Som vi allerede har n\u00e6vnt, cacher keyring_vault eller enhver anden lagringsplugin (keyring) alle n\u00f8gle-ID'er i hukommelsen. S\u00e5 efter oprettelse af en ny n\u00f8gle, tilf\u00f8jes ROB_1 til server1, og ud over at sende denne n\u00f8gle til Vault, tilf\u00f8jes n\u00f8gle ogs\u00e5 til cachen. Nu, n\u00e5r vi fors\u00f8ger at tilf\u00f8je den samme n\u00f8gle igen, kontrollerer keyring_vault, om denne n\u00f8gle findes i cachen, og giver en fejlmeddelelse. <\/p>\n<p>I det f\u00f8rste tilf\u00e6lde er situationen en anden. P\u00e5 serverne server1 og server2 er der separate cacher. Efter at have tilf\u00f8jet ROB_1 til cache n\u00f8glerne p\u00e5 server1 og server Vault, er cache n\u00f8glerne p\u00e5 server2 ikke synkroniseret. Der er ingen n\u00f8gle ROB_1 i cachen p\u00e5 server2. Derfor skrives n\u00f8gle ROB_1 til keyring_key_store og til server Vault, som faktisk overskriver (!) den tidligere v\u00e6rdi. Nu er n\u00f8gle ROB_1 p\u00e5 server Vault lig med 543210987654321. Det er interessant, at server Vault ikke blokerer s\u00e5danne handlinger og blot overskriver den gamle v\u00e6rdi.<\/p>\n<p>Nu ser vi, hvorfor opdeling efter servere p\u00e5 Vault kan v\u00e6re vigtigt \u2014 n\u00e5r du bruger keyring_udf og \u00f8nsker at gemme n\u00f8gler i Vault. Hvordan sikrer man en s\u00e5dan opdeling p\u00e5 server Vault? <\/p>\n<p>Der er to m\u00e5der at opdele p\u00e5 Vault. Du kan oprette forskellige monteringspunkter for hver server eller bruge forskellige stier inden for et monteringspunkt. Det bedste er at vise det med eksempler. S\u00e5 lad os f\u00f8rst se p\u00e5 separate monteringspunkter: <\/p>\n<pre><code class=\"sql\">--server1:\nvault_url = http:\/\/127.0.0.1:8200\nsecret_mount_point = server1_mount\ntoken = (...)\nvault_ca = (...)\n\n--server2:\nvault_url = http:\/\/127.0.0.1:8200\nsecret_mount_point = sever2_mount\ntoken = (...)\nvault_ca = (...)<\/code><\/pre>\n<p>\nHer kan vi se, at server1 og server2 bruger forskellige monteringspunkter. Ved opdeling af stier vil konfigurationen se s\u00e5ledes ud:<\/p>\n<pre><code class=\"sql\">--server1:\nvault_url = http:\/\/127.0.0.1:8200\nsecret_mount_point = mount_point\/server1\ntoken = (...)\nvault_ca = (...)\n--server2:\nvault_url = http:\/\/127.0.0.1:8200\nsecret_mount_point = mount_point\/sever2\ntoken = (...)\nvault_ca = (...)<\/code><\/pre>\n<p>\nI dette tilf\u00e6lde bruger begge servere det samme monteringspunkt \u00abmount_point\u00bb, men forskellige stier. N\u00e5r den f\u00f8rste hemmelighed oprettes p\u00e5 serveren server1 p\u00e5 denne sti, opretter Vault-serveren automatisk en mappe \u00abserver1\u00bb. For server2 er alt det samme. N\u00e5r du sletter den sidste hemmelighed i mount_point\/server1 eller mount_point\/server2, sletter Vault-serveren ogs\u00e5 disse mapper. Hvis du anvender stiadskillelse, skal du kun oprette \u00e9n monteringspunkt og \u00e6ndre konfigurationsfilerne, s\u00e5 serverne bruger separate stier. Monteringspunktet kan oprettes ved hj\u00e6lp af en HTTP-anmodning. Med CURL kan det g\u00f8res p\u00e5 f\u00f8lgende m\u00e5de:<\/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 felter (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) svarer til parametrene i konfigurationsfilen. Selvf\u00f8lgelig kan man bruge Vault-v\u00e6rkt\u00f8jer til at g\u00f8re det samme. Men det er lettere at automatisere oprettelsen af monteringspunktet. Jeg h\u00e5ber, denne information vil v\u00e6re nyttig for dig, og vi ses i de n\u00e6ste artikler i denne serie.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"Kryptering i MySQL: n\u00f8glelagring\" src=\"\/wp-content\/uploads\/2020\/10\/291dcdd68660bfc312021582baa628ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<blockquote>\n<h4>L\u00e6s mere:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench og fordeling af tilf\u00e6ldige st\u00f8rrelser<\/a><\/noindex><\/li>\n<\/ul>\n<\/blockquote>\n<p>Kilde: <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\/da\/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=\"da_DK\" \/>\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\/da\/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\udd47Kryptering i MySQL: n\u00f8glelager | ProHoster","description":"I takt med at vi forbereder os p\u00e5 at starte et nyt hold p\u00e5 kurset 'Databaser', har vi forberedt en overs\u00e6ttelse af en nyttig artikel til dig.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}