{"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\/es\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"Cifrado en MySQL: almacenamiento de claves","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Con la pr\u00f3xima apertura del nuevo ciclo del curso <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">\u00abBases de Datos\u00bb<\/a><\/noindex> hemos preparado para ustedes la traducci\u00f3n de un art\u00edculo \u00fatil.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Cifrado en MySQL: almacenamiento de claves\" src=\"\/wp-content\/uploads\/2020\/10\/aeca40f53fe6bdf2a9897aa835ff597d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>El cifrado transparente de datos (Transparent Data Encryption, TDE) se introdujo en <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\">Percona Server for MySQL<\/a><\/noindex> y MySQL hace bastante tiempo. Pero, \u00bfalguna vez se han preguntado c\u00f3mo funciona internamente y qu\u00e9 impacto puede tener TDE en su servidor? En esta serie de art\u00edculos exploraremos c\u00f3mo funciona TDE por dentro. Comenzaremos con el almacenamiento de claves, ya que es necesario para cualquier cifrado. Luego examinaremos en detalle c\u00f3mo funciona el cifrado en Percona Server for MySQL\/MySQL y qu\u00e9 funcionalidades adicionales ofrece Percona Server for MySQL.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring son complementos que permiten al servidor solicitar, crear y eliminar claves en un archivo local (keyring_file) o en un servidor remoto (por ejemplo, en HashiCorp Vault). Las claves siempre se almacenan en cach\u00e9 localmente para acelerar su recuperaci\u00f3n. <\/p>\n<p>Los complementos se pueden dividir en dos categor\u00edas:<\/p>\n<ul>\n<li>Almacenamiento local. Por ejemplo, un archivo local (lo llamamos almacenamiento de claves basado en archivos, file-based keyring).<\/li>\n<li>Almacenamiento remoto. Por ejemplo, un servidor Vault (lo llamamos almacenamiento de claves basado en servidor, server-based keyring).<\/li>\n<\/ul>\n<p>\nEsta divisi\u00f3n es importante porque diferentes tipos de almacenamiento se comportan un poco de manera diferente no solo al almacenar y recuperar claves, sino tambi\u00e9n al iniciar.<\/p>\n<p>Al usar el almacenamiento basado en archivos, el contenido completo del almacenamiento se carga en la cach\u00e9 al iniciar: id de clave, usuario de clave, tipo de clave y la propia clave.<\/p>\n<p>En el caso del almacenamiento basado en servidor (por ejemplo, el servidor Vault), al iniciar solo se cargan el id de clave y el usuario de clave, por lo que la obtenci\u00f3n de todas las claves no ralentiza el inicio. Las claves se cargan de manera perezosa, es decir, la clave en s\u00ed se carga desde Vault solo cuando realmente se necesita. Despu\u00e9s de la carga, la clave se almacena en la memoria para que no sea necesario volver a acceder a ella a trav\u00e9s de conexiones TLS al servidor Vault. A continuaci\u00f3n, veamos qu\u00e9 informaci\u00f3n contiene el almacenamiento de claves.<\/p>\n<p>La informaci\u00f3n sobre la clave contiene lo siguiente:<\/p>\n<ul>\n<li><b>id de clave<\/b> \u2014 el identificador de la clave, por ejemplo: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>tipo de clave<\/b> \u2014 el tipo de clave, basado en el algoritmo de cifrado utilizado, posibles valores: \u00abAES\u00bb, \u00abRSA\u00bb o \u00abDSA\u00bb.<\/li>\n<li><b>longitud de clave<\/b> \u2014 la longitud de la clave en bytes, AES: 16, 24 o 32, RSA 128, 256, 512 y DSA 128, 256 o 384.<\/li>\n<li><b>usuario<\/b> \u2014 propietario de la clave. Si la clave es del sistema, como la Master Key, este campo estar\u00e1 vac\u00edo. Si la clave se crea usando keyring_udf, este campo indica el propietario de la clave.<\/li>\n<li><b>la propia clave<\/b><\/li>\n<\/ul>\n<p>\nLa clave se identifica de manera inequ\u00edvoca por un par: key_id, user.<\/p>\n<p>Tambi\u00e9n hay diferencias en el almacenamiento y eliminaci\u00f3n de claves.<\/p>\n<p>El almacenamiento de archivos es m\u00e1s r\u00e1pido. Se podr\u00eda suponer que el almacenamiento de claves es simplemente una grabaci\u00f3n \u00fanica de la clave en un archivo, pero no es as\u00ed: aqu\u00ed se realizan m\u00e1s operaciones. Ante cualquier modificaci\u00f3n del almacenamiento de archivos, primero se crea una copia de seguridad de todo el contenido. Supongamos que el archivo se llama my_biggest_secrets, entonces la copia de seguridad ser\u00e1 my_biggest_secrets.backup. A continuaci\u00f3n, se modifica la cach\u00e9 (se agregan o eliminan claves) y, si todo se realiza con \u00e9xito, la cach\u00e9 se restablece en el archivo. En raras ocasiones, como en un fallo del servidor, puede que veas este archivo de copia de seguridad. El archivo de copia de seguridad se elimina en la siguiente carga de claves (generalmente despu\u00e9s de reiniciar el servidor).<\/p>\n<p>Al guardar o eliminar una clave en el almacenamiento del servidor, el almacenamiento debe conectarse al servidor MySQL con los comandos 'enviar clave' \/ 'solicitar eliminaci\u00f3n de clave'.<\/p>\n<p>Regresando a la velocidad de inicio del servidor. Adem\u00e1s de que el almacenamiento en s\u00ed afecta la velocidad de inicio, tambi\u00e9n existe la cuesti\u00f3n de cu\u00e1ntas claves del almacenamiento es necesario obtener al iniciar. Por supuesto, esto es especialmente importante para los almacenamientos de servidores. Al iniciarse, el servidor verifica qu\u00e9 clave es necesaria para las tablas cifradas \/ espacios de tablas y solicita la clave del almacenamiento. En un servidor 'limpio' con cifrado de Master Key, debe haber una sola Master Key que se debe extraer del almacenamiento. Sin embargo, puede ser necesaria una mayor cantidad de claves, por ejemplo, cuando en un servidor de respaldo se restaura una copia de seguridad del servidor principal. En tales casos, se debe considerar la rotaci\u00f3n de la Master Key. Esto se abordar\u00e1 con m\u00e1s detalle en art\u00edculos futuros, aunque aqu\u00ed quisiera se\u00f1alar que un servidor que utiliza m\u00faltiples Master Keys puede tardar un poco m\u00e1s en arrancar, especialmente cuando se utiliza el almacenamiento de claves del servidor.<\/p>\n<p>Ahora hablemos un poco m\u00e1s sobre keyring_file. Cuando desarroll\u00e9 keyring_file, tambi\u00e9n me preocupaba c\u00f3mo verificar los cambios en keyring_file durante el funcionamiento del servidor. En 5.7, la verificaci\u00f3n se realizaba sobre la base de estad\u00edsticas del archivo, lo cual no era una soluci\u00f3n ideal, y en 8.0 fue reemplazada por un hash SHA256.<\/p>\n<p>En el primer inicio, se calcula la estad\u00edstica y el hash del archivo keyring_file, que son almacenados por el servidor, y los cambios se aplican solo si coinciden. Al modificar el archivo, se actualiza el hash.<\/p>\n<p>Ya hemos tratado muchos temas sobre los almacenes de claves. Sin embargo, hay un tema importante que a menudo se olvida o se entiende mal: la separaci\u00f3n de claves entre servidores. <\/p>\n<p>\u00bfA qu\u00e9 me refiero? Cada servidor (por ejemplo, Percona Server) en un cl\u00faster debe tener su propio lugar en el servidor Vault, donde Percona Server debe almacenar sus claves. Cada Master Key almacenado en el dep\u00f3sito contiene el GUID del servidor Percona Server dentro de su identificador. \u00bfPor qu\u00e9 es importante? Imagina que tienes solo un servidor Vault y todos los Percona Server en el cl\u00faster utilizan ese \u00fanico servidor Vault. El problema parece obvio. Si todos los Percona Server utilizaran un Master Key sin identificadores \u00fanicos, por ejemplo, id = 1, id = 2, etc., entonces todos los servidores en el cl\u00faster usar\u00edan el mismo Master Key. Lo que proporciona el GUID es la separaci\u00f3n entre servidores. \u00bfPor qu\u00e9 hablar entonces de la separaci\u00f3n de claves entre servidores si ya existe un GUID \u00fanico? Hay otro complemento: keyring_udf. Con este complemento, un usuario de tu servidor puede almacenar sus claves en el servidor Vault. El problema surge cuando el usuario crea una clave, por ejemplo, en el servidor server1, y luego intenta crear una clave con el mismo identificador en server2, por ejemplo:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 significa finalizaci\u00f3n exitosa\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\nEspera. Ambos servidores utilizan el mismo servidor Vault, \u00bfno deber\u00eda la funci\u00f3n keyring_key_store terminar con un error en el servidor server2? Curiosamente, si intentas hacer lo mismo en un solo servidor, recibir\u00e1s un error:<\/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>\nCorrecto, ROB_1 ya existe.<\/p>\n<p>Primero, discutamos el segundo ejemplo. Como mencionamos anteriormente, keyring_vault o cualquier otro complemento de almacenamiento (keyring) almacena en cach\u00e9 todos los identificadores de claves en memoria. As\u00ed, despu\u00e9s de crear una nueva clave, ROB_1 se a\u00f1ade en server1, y adem\u00e1s de enviar esta clave a Vault, la clave tambi\u00e9n se agrega a la cach\u00e9. Ahora, cuando intentamos agregar la misma clave por segunda vez, keyring_vault verifica si esta clave existe en la cach\u00e9 y genera un error. <\/p>\n<p>En el primer caso, la situaci\u00f3n es diferente. Los servidores server1 y server2 tienen cach\u00e9s separados. Despu\u00e9s de agregar ROB_1 a la cach\u00e9 de claves en server1 y en el servidor Vault, la cach\u00e9 de claves en server2 no est\u00e1 sincronizada. En la cach\u00e9 de server2 no hay clave ROB_1. Por lo tanto, la clave ROB_1 se almacena en keyring_key_store y en el servidor Vault, que efectivamente sobrescribe (!) el valor anterior. Ahora la clave ROB_1 en el servidor Vault es igual a 543210987654321. Curiosamente, el servidor Vault no bloquea tales acciones y reescribe f\u00e1cilmente el valor antiguo.<\/p>\n<p>Ahora vemos por qu\u00e9 la separaci\u00f3n en servidores en Vault puede ser importante, cuando se utiliza keyring_udf y se desea almacenar claves en Vault. \u00bfC\u00f3mo asegurar tal separaci\u00f3n en el servidor Vault? <\/p>\n<p>Hay dos m\u00e9todos para la separaci\u00f3n en Vault. Se pueden crear diferentes puntos de montaje para cada servidor o usar diferentes rutas dentro de un mismo punto de montaje. Esto se puede mostrar mejor con ejemplos. As\u00ed que empecemos primero con puntos de montaje separados: <\/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>\nAqu\u00ed se puede ver que server1 y server2 utilizan diferentes puntos de montaje. Al separar las rutas, la configuraci\u00f3n se ver\u00e1 de la siguiente manera:<\/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>\nEn este caso, ambos servidores utilizan el mismo punto de montaje \u00abmount_point\u00bb, pero diferentes rutas. Al crear el primer secreto en el servidor server1 en esta ruta, el servidor Vault crea autom\u00e1ticamente el directorio \u00abserver1\u00bb. Lo mismo sucede con server2. Cuando eliminas el \u00faltimo secreto en mount_point\/server1 o mount_point\/server2, el servidor Vault tambi\u00e9n elimina estos directorios. Si utilizas la separaci\u00f3n de rutas, debes crear solo un punto de montaje y modificar los archivos de configuraci\u00f3n para que los servidores usen rutas separadas. El punto de montaje se puede crear mediante una solicitud HTTP. Con CURL, se puede hacer de la siguiente manera:<\/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>\nTodos los campos (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) corresponden a los par\u00e1metros del archivo de configuraci\u00f3n. Por supuesto, se pueden utilizar utilidades de Vault para hacer lo mismo. Pero es m\u00e1s sencillo automatizar la creaci\u00f3n del punto de montaje. Espero que esta informaci\u00f3n te resulte \u00fatil y nos vemos en los pr\u00f3ximos art\u00edculos de esta serie.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"Cifrado en MySQL: almacenamiento de claves\" src=\"\/wp-content\/uploads\/2020\/10\/291dcdd68660bfc312021582baa628ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<blockquote>\n<h4>Leer m\u00e1s:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench y distribuci\u00f3n de variables aleatorias<\/a><\/noindex><\/li>\n<\/ul>\n<\/blockquote>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/522092\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u043e\u0433\u043e \u043d\u0430\u0431\u043e\u0440\u0430 \u043d\u0430 \u043a\u0443\u0440\u0441 \u00ab\u0411\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445\u00bb \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u0438\u043b\u0438 \u0434\u043b\u044f \u0432\u0430\u0441 \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043f\u043e\u043b\u0435\u0437\u043d\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0438. \u041f\u0440\u043e\u0437\u0440\u0430\u0447\u043d\u043e\u0435 \u0448\u0438\u0444\u0440\u043e\u0432\u0430\u043d\u0438\u0435 \u0434\u0430\u043d\u043d\u044b\u0445 (Transparent Data Encryption, TDE) \u043f\u043e\u044f\u0432\u0438\u043b\u043e\u0441\u044c \u0432 Percona Server for MySQL \u0438 MySQL \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0434\u0430\u0432\u043d\u043e. \u041d\u043e \u0437\u0430\u0434\u0443\u043c\u044b\u0432\u0430\u043b\u0438\u0441\u044c \u043b\u0438 \u0432\u044b \u043a\u043e\u0433\u0434\u0430-\u043d\u0438\u0431\u0443\u0434\u044c \u043e \u0442\u043e\u043c, \u043a\u0430\u043a \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 \u043f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442\u043e\u043c \u0438 \u043a\u0430\u043a\u043e\u0435 \u0432\u043b\u0438\u044f\u043d\u0438\u0435 TDE \u043c\u043e\u0436\u0435\u0442 \u043e\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043d\u0430 \u0432\u0430\u0448 \u0441\u0435\u0440\u0432\u0435\u0440? \u0412 \u044d\u0442\u043e\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97665,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97664","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - 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\/es\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\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\/es\/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\udd47Cifrado en MySQL: almacenamiento de claves | ProHoster","description":"En la antesala del inicio de un nuevo ciclo para el curso \u00abBases de datos\u00bb, hemos preparado para ti la traducci\u00f3n de un art\u00edculo \u00fatil.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}