{"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\/de\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"Verschl\u00fcsselung in MySQL: Schl\u00fcsselverwaltung","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Kurz vor Beginn des neuen Kurses <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">\u201eDatenbanken\u201c<\/a><\/noindex> Wir haben f\u00fcr Sie die \u00dcbersetzung eines n\u00fctzlichen Artikels vorbereitet.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Verschl\u00fcsselung in MySQL: Schl\u00fcsselverwaltung\" src=\"\/wp-content\/uploads\/2020\/10\/aeca40f53fe6bdf2a9897aa835ff597d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Transparente Datenverschl\u00fcsselung (Transparent Data Encryption, TDE) gibt es seit <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\">Percona Server for MySQL<\/a><\/noindex> und MySQL schon seit geraumer Zeit. Aber haben Sie sich jemals gefragt, wie es funktioniert und welchen Einfluss TDE auf Ihren Server haben kann? In dieser Artikelreihe werden wir untersuchen, wie TDE im Hintergrund funktioniert. Wir beginnen mit der Schl\u00fcsselverwaltung, da diese f\u00fcr jede Verschl\u00fcsselung erforderlich ist. Danach betrachten wir im Detail, wie die Verschl\u00fcsselung in Percona Server f\u00fcr MySQL\/MySQL funktioniert und welche zus\u00e4tzlichen Funktionen Percona Server f\u00fcr MySQL bietet.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring ist ein Plugin, das es dem Server erm\u00f6glicht, Schl\u00fcssel in einer lokalen Datei (keyring_file) oder auf einem Remote-Server (z. B. in HashiCorp Vault) anzufordern, zu erstellen und zu l\u00f6schen. Die Schl\u00fcssel werden immer lokal zwischengespeichert, um ihre Abholung zu beschleunigen. <\/p>\n<p>Die Plugins lassen sich in zwei Kategorien unterteilen:<\/p>\n<ul>\n<li>Lokale Speicherung. Zum Beispiel eine lokale Datei (wir nennen dies schl\u00fcsseldatenbasierte Speicherung, file-based keyring).<\/li>\n<li>Remote Speicherung. Zum Beispiel Vault Server (wir nennen dies serverbasierte Speicherung, server-based keyring).<\/li>\n<\/ul>\n<p>\nDiese Unterscheidung ist wichtig, da sich verschiedene Speicherkategorien bei der Speicherung und Abholung von Schl\u00fcsseln sowie beim Starten etwas unterschiedlich verhalten.<\/p>\n<p>Bei Verwendung der schl\u00fcsseldatenbasierten Speicherung wird beim Starten der gesamte Inhalt des Speichers in den Cache geladen: key id, key user, key type und der Schl\u00fcssel selbst.<\/p>\n<p>Im Fall der serverbasierten Speicherung (z. B. Vault-Server) werden beim Start nur key id und key user geladen, sodass das Abrufen aller Schl\u00fcssel den Start nicht verlangsamt. Die Schl\u00fcssel werden faul geladen. Das bedeutet, der Schl\u00fcssel wird nur von Vault geladen, wenn er tats\u00e4chlich ben\u00f6tigt wird. Nach dem Laden wird der Schl\u00fcssel im Speicher zwischengespeichert, sodass er in Zukunft nicht mehr \u00fcber TLS-Verbindungen zum Vault Server abgerufen werden muss. Schauen wir uns nun an, welche Informationen im Schl\u00fcsseldaten gespeichert sind.<\/p>\n<p>Die Schl\u00fcsselinformation enth\u00e4lt Folgendes:<\/p>\n<ul>\n<li><b>key id<\/b> \u2014 der Schl\u00fcssel-Identifikator, beispielsweise: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>key type<\/b> \u2014 der Schl\u00fcsseltyp, basierend auf dem verwendeten Verschl\u00fcsselungsalgorithmus, m\u00f6gliche Werte: \u201eAES\u201c, \u201eRSA\u201c oder \u201eDSA\u201c.<\/li>\n<li><b>key length<\/b> \u2014 die Schl\u00fcssell\u00e4nge in Bytes, AES: 16, 24 oder 32, RSA 128, 256, 512 und DSA 128, 256 oder 384.<\/li>\n<li><b>Benutzer<\/b> \u2014 der Schl\u00fcsselinhaber. Wenn der Schl\u00fcssel ein Systemschl\u00fcssel ist, wie z. B. der Master Key, ist dieses Feld leer. Wenn der Schl\u00fcssel mit Hilfe von keyring_udf erstellt wird, bezeichnet dieses Feld den Schl\u00fcsselinhaber.<\/li>\n<li><b>der Schl\u00fcssel selbst<\/b><\/li>\n<\/ul>\n<p>\nDer Schl\u00fcssel wird eindeutig durch ein Paar identifiziert: key_id, user.<\/p>\n<p>Es gibt auch Unterschiede beim Speichern und L\u00f6schen von Schl\u00fcsseln.<\/p>\n<p>Der Datei-Speicher arbeitet schneller. Man k\u00f6nnte annehmen, dass das Schl\u00fcsselspeicher einfach eine einmalige Speicherung des Schl\u00fcssels in einer Datei ist, aber das ist nicht der Fall \u2013 hier erfolgen mehr Operationen. Bei jeder Modifikation des Datei-Speichers wird zun\u00e4chst ein Backup des gesamten Inhalts erstellt. Angenommen, die Datei hei\u00dft my_biggest_secrets, dann wird das Backup my_biggest_secrets.backup hei\u00dfen. Anschlie\u00dfend wird der Cache ge\u00e4ndert (Schl\u00fcssel werden hinzugef\u00fcgt oder entfernt) und, wenn alles erfolgreich abgeschlossen ist, wird der Cache in die Datei zur\u00fcckgeschrieben. In seltenen F\u00e4llen, wie z.B. bei einem Serverausfall, k\u00f6nnen Sie diese Backup-Datei sehen. Die Backup-Datei wird beim n\u00e4chsten Laden der Schl\u00fcssel gel\u00f6scht (normalerweise nach einem Serverneustart).<\/p>\n<p>Beim Speichern oder L\u00f6schen eines Schl\u00fcssels im Server-Speicher muss das Speicherger\u00e4t mit dem MySQL-Server \u00fcber die Kommandos \u201eSchl\u00fcssel senden\u201c \/ \u201eAnforderung zur Schl\u00fcsselentfernung\u201c verbunden werden (\"send the key\" \/ \"request key deletion\").<\/p>\n<p>Lassen Sie uns zur Startgeschwindigkeit des Servers zur\u00fcckkehren. Neben dem Einfluss des Speichers auf die Startgeschwindigkeit gibt es auch die Frage, wie viele Schl\u00fcssel aus dem Speicher beim Start ben\u00f6tigt werden. Das ist insbesondere f\u00fcr Serverspeicher wichtig. Beim Start pr\u00fcft der Server, welcher Schl\u00fcssel f\u00fcr die verschl\u00fcsselten Tabellen \/ Tablespaces ben\u00f6tigt wird, und fordert den Schl\u00fcssel aus dem Speicher an. Auf einem \"sauberen\" Server mit Master Key \u2013 Verschl\u00fcsselung sollte es einen Master Key geben, der aus dem Speicher abgerufen werden muss. Es k\u00f6nnen jedoch auch mehr Schl\u00fcssel erforderlich sein, z.B. wenn auf einem Backup-Server ein Backup vom Hauptserver wiederhergestellt wird. In solchen F\u00e4llen sollte eine Rotation des Master Keys eingeplant werden. Dies wird in zuk\u00fcnftigen Artikeln ausf\u00fchrlicher behandelt, aber ich m\u00f6chte hier anmerken, dass ein Server, der mehrere Master Keys verwendet, etwas l\u00e4nger zum Starten ben\u00f6tigen kann, insbesondere bei der Verwendung eines Server-Schl\u00fcsselspeichers.<\/p>\n<p>Lassen Sie uns nun noch etwas \u00fcber keyring_file sprechen. Als ich keyring_file entwickelte, machte ich mir auch Sorgen dar\u00fcber, wie man die \u00c4nderung von keyring_file w\u00e4hrend des Serverbetriebs \u00fcberpr\u00fcfen kann. In 5.7 wurde dies auf Basis der Dateistatistik \u00fcberpr\u00fcft, was keine ideale L\u00f6sung war, und wurde in 8.0 durch eine SHA256-Pr\u00fcfziffer ersetzt.<\/p>\n<p>Beim ersten Start von keyring_file werden die Dateistatistiken und die Pr\u00fcfziffer berechnet, die vom Server gespeichert werden, und \u00c4nderungen werden nur angewendet, wenn sie \u00fcbereinstimmen. Bei \u00c4nderungen der Datei wird die Pr\u00fcfziffer aktualisiert.<\/p>\n<p>Wir haben bereits viele Fragen zu Schl\u00fcsselspeichern behandelt. Dennoch gibt es ein weiteres wichtiges Thema, das oft vergessen oder missverstanden wird \u2013 die Trennung von Schl\u00fcsseln nach Servern. <\/p>\n<p>Was meine ich damit? Jeder Server (z.B. Percona Server) in einem Cluster sollte einen eigenen Platz auf dem Vault-Server haben, wo Percona Server seine Schl\u00fcssel speichern kann. Jeder Master Key, der im Speicher gesichert wird, enth\u00e4lt die GUID des Percona Servers innerhalb seiner Identifikation. Warum ist das wichtig? Stellen Sie sich vor, Sie haben nur einen Vault-Server und alle Percona Server im Cluster nutzen diesen einzigen Vault-Server. Das Problem scheint offensichtlich. Wenn alle Percona Server den Master Key ohne eindeutige Identifikatoren verwenden w\u00fcrden, z.B. id = 1, id = 2 usw., w\u00fcrden alle Server im Cluster denselben Master Key verwenden. Was die GUID erm\u00f6glicht \u2013 die Abgrenzung zwischen den Servern. Warum also \u00fcber die Trennung von Schl\u00fcsseln zwischen den Servern sprechen, wenn bereits eine eindeutige GUID existiert? Es gibt noch ein anderes Plugin \u2013 keyring_udf. Mit diesem Plugin kann der Benutzer Ihres Servers seine Schl\u00fcssel auf dem Vault-Server speichern. Das Problem tritt auf, wenn der Benutzer einen Schl\u00fcssel auf server1 erstellt und dann versucht, einen Schl\u00fcssel mit derselben Identifikation auf server2 zu erstellen, zum Beispiel:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 bedeutet erfolgreicher Abschluss\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\nWarten Sie. Beide Server verwenden denselben Vault-Server, sollte die Funktion keyring_key_store nicht mit einem Fehler auf server2 enden? Interessanterweise erhalten Sie, wenn Sie dasselbe auf demselben Server versuchen, eine Fehlermeldung:<\/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>\nRichtig, ROB_1 existiert bereits.<\/p>\n<p>Lass uns zuerst das zweite Beispiel besprechen. Wie bereits erw\u00e4hnt, speichert keyring_vault oder ein anderer Speicher-Plugin (keyring) alle Schl\u00fcssel-IDs im Speicher. Nach der Erstellung eines neuen Schl\u00fcssels wird ROB_1 auf server1 hinzugef\u00fcgt. Neben dem Senden dieses Schl\u00fcssels an Vault wird der Schl\u00fcssel auch im Cache gespeichert. Wenn wir nun versuchen, denselben Schl\u00fcssel ein zweites Mal hinzuzuf\u00fcgen, \u00fcberpr\u00fcft keyring_vault, ob dieser Schl\u00fcssel im Cache bereits vorhanden ist, und gibt einen Fehler aus. <\/p>\n<p>Im ersten Fall ist die Situation eine andere. Auf den Servern server1 und server2 gibt es separate Caches. Nachdem ROB_1 im Schl\u00fcssel-Cache auf server1 und dem Vault-Server hinzugef\u00fcgt wurde, ist der Schl\u00fcssel-Cache auf server2 nicht synchronisiert. Im Cache auf server2 ist der Schl\u00fcssel ROB_1 nicht vorhanden. Daher wird der Schl\u00fcssel ROB_1 im keyring_key_store und auf dem Vault-Server gespeichert, wodurch der vorherige Wert tats\u00e4chlich \u00fcberschrieben wird (!). Jetzt entspricht der Schl\u00fcssel ROB_1 auf dem Vault-Server 543210987654321. Interessanterweise blockiert der Vault-Server solche Aktionen nicht und \u00fcberschreibt einfach den alten Wert.<\/p>\n<p>Jetzt sehen wir, warum die Trennung nach Servern im Vault wichtig sein kann \u2014 insbesondere wenn Sie keyring_udf verwenden und Schl\u00fcssel im Vault speichern m\u00f6chten. Wie kann man eine solche Trennung auf dem Vault-Server gew\u00e4hrleisten? <\/p>\n<p>Es gibt zwei M\u00f6glichkeiten, eine Trennung im Vault zu erreichen. Man kann f\u00fcr jeden Server unterschiedliche Mount-Punkte erstellen oder unterschiedliche Pfade innerhalb eines Mount-Punkts verwenden. Am besten l\u00e4sst sich das mit Beispielen zeigen. Schauen wir uns zun\u00e4chst die separaten Mount-Punkte an: <\/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 sehen wir, dass server1 und server2 unterschiedliche Mount-Punkte verwenden. Bei der Trennung der Pfade w\u00fcrde die Konfiguration wie folgt aussehen:<\/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 diesem Fall verwenden beide Server denselben Mount-Punkt \u00abmount_point\u00bb, aber unterschiedliche Pfade. Bei der Erstellung des ersten Secrets auf dem Server server1 an diesem Pfad erstellt der Vault-Server automatisch das Verzeichnis \u00abserver1\u00bb. F\u00fcr server2 ist alles \u00e4hnlich. Wenn Sie das letzte Secret in mount_point\/server1 oder mount_point\/server2 l\u00f6schen, entfernt der Vault-Server ebenfalls diese Verzeichnisse. Falls Sie die Pfade trennen, m\u00fcssen Sie nur einen einzigen Mount-Punkt erstellen und die Konfigurationsdateien \u00e4ndern, damit die Server separate Pfade verwenden. Der Mount-Punkt kann durch eine HTTP-Anfrage erstellt werden. Mit CURL geht das wie folgt:<\/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 Felder (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) entsprechen den Parametern der Konfigurationsdatei. Nat\u00fcrlich k\u00f6nnen auch Vault-Utilities verwendet werden, um dasselbe zu tun. Aber so ist es einfacher, die Erstellung des Mount-Punkts zu automatisieren. Ich hoffe, diese Informationen sind f\u00fcr Sie n\u00fctzlich, und wir sehen uns in den n\u00e4chsten Artikeln dieser Serie.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"Verschl\u00fcsselung in MySQL: Schl\u00fcsselverwaltung\" src=\"\/wp-content\/uploads\/2020\/10\/291dcdd68660bfc312021582baa628ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<blockquote>\n<h4>Weiterlesen:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench und Verteilung zuf\u00e4lliger Variablen<\/a><\/noindex><\/li>\n<\/ul>\n<\/blockquote>\n<p>Quelle: <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.1.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\/de\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\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\/de\/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\udd47Verschl\u00fcsselung in MySQL: Schl\u00fcsselspeicher | ProHoster","description":"Im Vorfeld des Starts eines neuen Kurses zu \u00abDatenbanken\u00bb haben wir f\u00fcr Sie die \u00dcbersetzung eines n\u00fctzlichen Artikels vorbereitet.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}