{"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\/pt\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"Criptografia no MySQL: armazenamento de chaves","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Com a proximidade do in\u00edcio de um novo ciclo de inscri\u00e7\u00f5es para o curso <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">\u00abBancos de Dados\u00bb<\/a><\/noindex> preparamos para voc\u00ea a tradu\u00e7\u00e3o de um artigo \u00fatil.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Criptografia no MySQL: armazenamento de chaves\" src=\"\/wp-content\/uploads\/2020\/10\/aeca40f53fe6bdf2a9897aa835ff597d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>A criptografia transparente de dados (Transparent Data Encryption, TDE) surgiu no <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\">Percona Server for MySQL<\/a><\/noindex> e MySQL h\u00e1 bastante tempo. Mas voc\u00ea j\u00e1 se perguntou como isso funciona por tr\u00e1s das cenas e qual \u00e9 o impacto que o TDE pode ter no seu servidor? Nesta s\u00e9rie de artigos, vamos examinar como o TDE funciona internamente. Come\u00e7aremos pelo armazenamento de chaves, que \u00e9 necess\u00e1rio para a opera\u00e7\u00e3o de qualquer criptografia. Depois, iremos detalhar como a criptografia funciona no Percona Server for MySQL\/MySQL e quais recursos adicionais existem no Percona Server for MySQL.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring \u2014 s\u00e3o plugins que permitem ao servidor solicitar, criar e excluir chaves em um arquivo local (keyring_file) ou em um servidor remoto (como o HashiCorp Vault). As chaves s\u00e3o sempre armazenadas em cache localmente para acelerar sua recupera\u00e7\u00e3o. <\/p>\n<p>Os plugins podem ser divididos em duas categorias:<\/p>\n<ul>\n<li>Armazenamento local. Por exemplo, um arquivo local (chamamos isso de armazenamento de chaves baseado em arquivos, file-based keyring).<\/li>\n<li>Armazenamento remoto. Por exemplo, um Vault Server (chamamos isso de armazenamento de chaves baseado em servidor, server-based keyring).<\/li>\n<\/ul>\n<p>\nEssa divis\u00e3o \u00e9 importante, pois diferentes tipos de armazenamento se comportam um pouco de maneira diferente tanto ao armazenar e recuperar chaves quanto durante a inicializa\u00e7\u00e3o.<\/p>\n<p>Quando se utiliza um armazenamento baseado em arquivos, ao iniciar, todo o conte\u00fado do armazenamento \u00e9 carregado em cache: key id, key user, key type e a pr\u00f3pria chave.<\/p>\n<p>No caso de armazenamento baseado em servidores (como um servidor Vault), ao iniciar, apenas key id e key user s\u00e3o carregados, portanto, a recupera\u00e7\u00e3o de todas as chaves n\u00e3o desacelera a inicializa\u00e7\u00e3o. As chaves s\u00e3o carregadas de forma pregui\u00e7osa. Ou seja, a chave em si \u00e9 carregada do Vault somente quando realmente necess\u00e1rio. Ap\u00f3s o carregamento, a chave \u00e9 armazenada em cache na mem\u00f3ria, para que no futuro n\u00e3o seja necess\u00e1rio acess\u00e1-la atrav\u00e9s de conex\u00f5es TLS com o Vault Server. A seguir, vamos ver quais informa\u00e7\u00f5es est\u00e3o presentes no armazenamento de chaves.<\/p>\n<p>As informa\u00e7\u00f5es da chave cont\u00eam o seguinte:<\/p>\n<ul>\n<li><b>key id<\/b> \u2014 identificador da chave, por exemplo: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>key type<\/b> \u2014 tipo da chave, baseado no algoritmo de criptografia utilizado, os valores poss\u00edveis s\u00e3o: \u00abAES\u00bb, \u00abRSA\u00bb ou \u00abDSA\u00bb.<\/li>\n<li><b>key length<\/b> \u2014 comprimento da chave em bytes, AES: 16, 24 ou 32, RSA 128, 256, 512 e DSA 128, 256 ou 384.<\/li>\n<li><b>user<\/b> \u2014 propriet\u00e1rio da chave. Se a chave for uma chave de sistema, como a Master Key, este campo ficar\u00e1 vazio. Se a chave for criada usando keyring_udf, este campo indica o propriet\u00e1rio da chave.<\/li>\n<li><b>a chave<\/b><\/li>\n<\/ul>\n<p>\nA chave \u00e9 identificada de forma \u00fanica pelo par: key_id, user.<\/p>\n<p>Tamb\u00e9m existem diferen\u00e7as no armazenamento e na exclus\u00e3o de chaves.<\/p>\n<p>O armazenamento em arquivo funciona mais r\u00e1pido. Pode-se supor que o armazenamento de chaves \u00e9 uma simples grava\u00e7\u00e3o \u00fanica da chave em um arquivo, mas n\u00e3o \u2014 aqui ocorrem mais opera\u00e7\u00f5es. Ao modificar o armazenamento em arquivo, uma c\u00f3pia de seguran\u00e7a de todo o conte\u00fado \u00e9 criada primeiro. Suponha que o arquivo se chama my_biggest_secrets, ent\u00e3o a c\u00f3pia de seguran\u00e7a ser\u00e1 my_biggest_secrets.backup. Depois, o cache \u00e9 modificado (chaves s\u00e3o adicionadas ou removidas) e, se tudo for bem-sucedido, o cache \u00e9 gravado no arquivo. Em casos raros, como falha do servidor, voc\u00ea pode ver este arquivo de c\u00f3pia de seguran\u00e7a. O arquivo de c\u00f3pia de seguran\u00e7a \u00e9 exclu\u00eddo na pr\u00f3xima carga das chaves (geralmente ap\u00f3s a reinicializa\u00e7\u00e3o do servidor).<\/p>\n<p>Ao salvar ou excluir uma chave no armazenamento do servidor, o armazenamento deve se conectar ao servidor MySQL com os comandos \u2018enviar chave\u2019 \/ \u2018solicitar exclus\u00e3o de chave\u2019 (\u2018send the key\u2019 \/ \u2018request key deletion\u2019).<\/p>\n<p>Vamos voltar \u00e0 velocidade de inicializa\u00e7\u00e3o do servidor. Al\u00e9m do fato de que a pr\u00f3pria armazenagem afeta a velocidade de inicializa\u00e7\u00e3o, h\u00e1 tamb\u00e9m a quest\u00e3o de quantas chaves do armazenamento precisam ser obtidas na inicializa\u00e7\u00e3o. Claro, isso \u00e9 especialmente importante para armazenamentos de servidor. Na inicializa\u00e7\u00e3o, o servidor verifica qual chave \u00e9 necess\u00e1ria para as tabelas criptografadas \/ espa\u00e7os de tabela e solicita a chave do armazenamento. Em um servidor \u2018limpo\u2019 com Master Key \u2014 a criptografia deve ter uma \u00fanica Master Key, que deve ser extra\u00edda do armazenamento. No entanto, pode ser necess\u00e1ria uma quantidade maior de chaves, por exemplo, quando um servidor de backup est\u00e1 restaurando uma c\u00f3pia de seguran\u00e7a de um servidor principal. Nesses casos, deve-se considerar a rota\u00e7\u00e3o da Master Key. Mais detalhes ser\u00e3o discutidos em futuros artigos, embora eu queira ressaltar aqui que um servidor que utiliza v\u00e1rias Master Keys pode iniciar um pouco mais devagar, especialmente ao usar armazenamento de chaves do servidor.<\/p>\n<p>Agora vamos falar um pouco mais sobre o keyring_file. Quando desenvolvi o keyring_file, eu tamb\u00e9m me preocupava com como checar a altera\u00e7\u00e3o do keyring_file durante a opera\u00e7\u00e3o do servidor. Na vers\u00e3o 5.7, a verifica\u00e7\u00e3o era feita com base nas estat\u00edsticas do arquivo, o que n\u00e3o era uma solu\u00e7\u00e3o ideal, e na 8.0 foi substitu\u00edda por um hash SHA256.<\/p>\n<p>Na primeira execu\u00e7\u00e3o, as estat\u00edsticas do arquivo e o hash s\u00e3o calculados e armazenados pelo servidor, e as altera\u00e7\u00f5es s\u00e3o aplicadas apenas se coincidirem. Ao alterar o arquivo, o hash \u00e9 atualizado.<\/p>\n<p>J\u00e1 discutimos v\u00e1rias quest\u00f5es sobre reposit\u00f3rios de chaves. No entanto, h\u00e1 um outro t\u00f3pico importante, frequentemente esquecido ou mal interpretado \u2014 a separa\u00e7\u00e3o de chaves entre servidores. <\/p>\n<p>O que quero dizer? Cada servidor (por exemplo, Percona Server) em um cluster deve ter um local separado no servidor Vault, onde o Percona Server deve armazenar suas chaves. Em cada Master Key armazenada, cont\u00e9m-se o GUID do servidor Percona Server dentro de seu identificador. Por que isso \u00e9 importante? Imagine que voc\u00ea tem apenas um servidor Vault e todos os Percona Servers no cluster usam esse \u00fanico servidor Vault. O problema parece \u00f3bvio. Se todos os Percona Servers usassem uma Master Key sem identificadores \u00fanicos, por exemplo, id = 1, id = 2, etc., todos os servidores no cluster usariam a mesma Master Key. O que o GUID fornece \u2014 \u00e9 uma delimita\u00e7\u00e3o entre servidores. Ent\u00e3o, por que falar sobre a separa\u00e7\u00e3o de chaves entre servidores, se j\u00e1 existe um GUID \u00fanico? H\u00e1 um outro plugin \u2014 keyring_udf. Com este plugin, um usu\u00e1rio do seu servidor pode armazenar suas chaves no servidor Vault. O problema surge quando o usu\u00e1rio cria uma chave, por exemplo, no servidor server1, e depois tenta criar uma chave com o mesmo identificador no server2, por exemplo:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 significa conclus\u00e3o bem-sucedida\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\nEspere. Ambos os servidores usam o mesmo servidor Vault, a fun\u00e7\u00e3o keyring_key_store n\u00e3o deveria resultar em erro no servidor server2? Curiosamente, se voc\u00ea tentar fazer a mesma coisa em um \u00fanico servidor, receber\u00e1 um erro:<\/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>\nCorreto, ROB_1 j\u00e1 existe.<\/p>\n<p>Vamos primeiro discutir o segundo exemplo. Como mencionamos anteriormente, o keyring_vault ou qualquer outro plugin de armazenamento (keyring) armazena em cache todos os identificadores de chave na mem\u00f3ria. Assim, ap\u00f3s a cria\u00e7\u00e3o de uma nova chave, o ROB_1 \u00e9 adicionado ao server1 e, al\u00e9m de enviar essa chave para o Vault, a chave tamb\u00e9m \u00e9 adicionada ao cache. Agora, quando tentamos adicionar a mesma chave pela segunda vez, o keyring_vault verifica se essa chave j\u00e1 existe no cache e gera um erro. <\/p>\n<p>No primeiro caso, a situa\u00e7\u00e3o \u00e9 diferente. Nos servidores server1 e server2, h\u00e1 caches separados. Ap\u00f3s adicionar o ROB_1 ao cache de chaves no servidor server1 e no servidor Vault, o cache de chaves no server2 n\u00e3o est\u00e1 sincronizado. O cache no server2 n\u00e3o cont\u00e9m a chave ROB_1. Assim, a chave ROB_1 \u00e9 gravada no keyring_key_store e no servidor Vault, que efetivamente sobrescreve (!) o valor anterior. Agora a chave ROB_1 no servidor Vault \u00e9 igual a 543210987654321. Curiosamente, o servidor Vault n\u00e3o bloqueia tais a\u00e7\u00f5es e simplesmente sobrescreve o valor antigo.<\/p>\n<p>Agora vemos por que a divis\u00e3o por servidores no Vault pode ser importante \u2014 quando voc\u00ea usa o keyring_udf e deseja armazenar chaves no Vault. Como assegurar essa divis\u00e3o no servidor Vault? <\/p>\n<p>Existem duas maneiras de dividir no Vault. Voc\u00ea pode criar diferentes pontos de montagem para cada servidor ou usar diferentes caminhos dentro de um \u00fanico ponto de montagem. Vamos mostrar isso com exemplos. Ent\u00e3o, vamos primeiro olhar para os pontos de montagem 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 = server2_mount\ntoken = (...)\nvault_ca = (...)<\/code><\/pre>\n<p>\nAqui vemos que server1 e server2 usam pontos de montagem diferentes. Ao dividir caminhos, a configura\u00e7\u00e3o ser\u00e1 a seguinte:<\/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>\nNeste caso, ambos os servidores usam o mesmo ponto de montagem \"mount_point\", mas caminhos diferentes. Ao criar o primeiro segredo no servidor server1 nesse caminho, o servidor Vault cria automaticamente o diret\u00f3rio \"server1\". O mesmo acontece para server2. Quando voc\u00ea exclui o \u00faltimo segredo em mount_point\/server1 ou mount_point\/server2, o servidor Vault tamb\u00e9m remove esses diret\u00f3rios. Se voc\u00ea estiver usando a separa\u00e7\u00e3o de caminhos, deve criar apenas um ponto de montagem e alterar os arquivos de configura\u00e7\u00e3o para que os servidores usem caminhos separados. O ponto de montagem pode ser criado com uma solicita\u00e7\u00e3o HTTP. Com CURL, isso pode ser feito da seguinte forma:<\/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 os campos (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) correspondem aos par\u00e2metros do arquivo de configura\u00e7\u00e3o. Claro, voc\u00ea pode usar as utilidades Vault para fazer o mesmo. Mas assim \u00e9 mais f\u00e1cil automatizar a cria\u00e7\u00e3o do ponto de montagem. Espero que esta informa\u00e7\u00e3o seja \u00fatil para voc\u00ea, e nos vemos nos pr\u00f3ximos artigos desta s\u00e9rie.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"Criptografia no MySQL: armazenamento de chaves\" src=\"\/wp-content\/uploads\/2020\/10\/291dcdd68660bfc312021582baa628ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<blockquote>\n<h4>Leia mais:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench e a distribui\u00e7\u00e3o de vari\u00e1veis aleat\u00f3rias<\/a><\/noindex><\/li>\n<\/ul>\n<\/blockquote>\n<p>Fonte: <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\/pt\/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=\"pt_PT\" \/>\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\/pt\/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\udd47Criptografia no MySQL: armazenamento de chaves | ProHoster","description":"\u00c0 medida que se aproxima o in\u00edcio de uma nova turma do curso \"Bancos de Dados\", preparamos para voc\u00ea a tradu\u00e7\u00e3o de um artigo \u00fatil.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}