{"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\/it\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","title":{"rendered":"Crittografia in MySQL: archivio delle chiavi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>In attesa dell'avvio di un nuovo ciclo di corsi <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\">\u00abBasi di dati\u00bb<\/a><\/noindex> abbiamo preparato per voi la traduzione di un articolo utile.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Crittografia in MySQL: archivio delle chiavi\" src=\"\/wp-content\/uploads\/2020\/10\/aeca40f53fe6bdf2a9897aa835ff597d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>La crittografia trasparente dei dati (Transparent Data Encryption, TDE) \u00e8 disponibile in <noindex><a rel=\"nofollow\" href=\"https:\/\/www.percona.com\/software\/mysql-database\/percona-server\">Percona Server for MySQL<\/a><\/noindex> e MySQL da molto tempo. Ma ti sei mai chiesto come funziona dietro le quinte e quale impatto possa avere TDE sul tuo server? In questa serie di articoli esamineremo come TDE funziona internamente. Iniziamo con l'archiviazione delle chiavi, poich\u00e9 \u00e8 necessaria per qualsiasi tipo di crittografia. Successivamente, esamineremo in dettaglio come funziona la crittografia in Percona Server for MySQL\/MySQL e quali funzionalit\u00e0 aggiuntive offre Percona Server for MySQL.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>MySQL Keyring<\/h3>\n<p>\nKeyring \u00e8 un plugin che consente al server di richiedere, creare ed eliminare chiavi in un file locale (keyring_file) o su un server remoto (ad esempio, in HashiCorp Vault). Le chiavi vengono sempre memorizzate nella cache localmente per accelerare il loro recupero. <\/p>\n<p>I plugin possono essere suddivisi in due categorie:<\/p>\n<ul>\n<li>Archiviazione locale. Ad esempio, un file locale (lo definiamo archivio delle chiavi basato su file, file-based keyring).<\/li>\n<li>Archiviazione remota. Ad esempio, Vault Server (lo definiamo archivio delle chiavi basato su server, server-based keyring).<\/li>\n<\/ul>\n<p>\nQuesta distinzione \u00e8 importante, poich\u00e9 diversi tipi di archiviazione si comportano in modo leggermente diverso non solo durante la memorizzazione e il recupero delle chiavi, ma anche durante l'avvio.<\/p>\n<p>Quando si utilizza un archivio basato su file, al momento dell'avvio viene caricato nella cache l'intero contenuto dell'archivio: id chiave, utente chiave, tipo chiave e la chiave stessa.<\/p>\n<p>Nel caso di un archivio basato su server (ad esempio, un server Vault), al momento dell'avvio vengono caricati solo l'id chiave e l'utente chiave, quindi il recupero di tutte le chiavi non rallenta l'avvio. Le chiavi vengono caricate in modo pigro. Cio\u00e8, la chiave stessa viene caricata da Vault solo quando \u00e8 effettivamente necessaria. Dopo il caricamento, la chiave viene memorizzata nella cache nella memoria, in modo da non doverla richiedere nuovamente tramite connessioni TLS al Vault Server. Successivamente, vedremo quali informazioni sono presenti nell'archivio delle chiavi.<\/p>\n<p>Le informazioni sulla chiave contengono quanto segue:<\/p>\n<ul>\n<li><b>id chiave<\/b> \u2014 identificatore della chiave, ad esempio: <br \/>\n <code>INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1<\/code><\/li>\n<li><b>tipo chiave<\/b> \u2014 tipo di chiave, basato sull'algoritmo di crittografia utilizzato, i valori possibili sono: \u00abAES\u00bb, \u00abRSA\u00bb o \u00abDSA\u00bb.<\/li>\n<li><b>lunghezza chiave<\/b> \u2014 lunghezza della chiave in byte, AES: 16, 24 o 32, RSA 128, 256, 512 e DSA 128, 256 o 384.<\/li>\n<li><b>user<\/b> \u2014 proprietario della chiave. Se la chiave \u00e8 di sistema, ad esempio, Master Key, questo campo \u00e8 vuoto. Se la chiave \u00e8 creata tramite keyring_udf, questo campo indica il proprietario della chiave.<\/li>\n<li><b>la chiave stessa<\/b><\/li>\n<\/ul>\n<p>\nLa chiave \u00e8 univocamente identificata dalla coppia: key_id, user.<\/p>\n<p>Ci sono anche differenze nel salvataggio e nella rimozione delle chiavi.<\/p>\n<p>Il repository file funziona pi\u00f9 velocemente. Si potrebbe presumere che il repository delle chiavi sia una semplice registrazione della chiave in un file, ma non \u00e8 cos\u00ec: ci sono pi\u00f9 operazioni in corso. In caso di qualsiasi modifica al repository file, viene prima creato un backup di tutto il contenuto. Supponiamo che il file si chiami my_biggest_secrets, quindi il backup sar\u00e0 my_biggest_secrets.backup. Successivamente, viene modificata la cache (vengono aggiunte o rimosse chiavi) e, se tutto va a buon fine, la cache viene scritta nel file. In rari casi, come un guasto del server, potresti vedere questo file di backup. Il file di backup viene eliminato al successivo caricamento delle chiavi (di solito dopo il riavvio del server).<\/p>\n<p>Quando si salva o si rimuove una chiave nel repository del server, il repository deve connettersi al server MySQL con i comandi \"inviare chiave\" \/ \"richiedere cancellazione chiave\" (\"send the key\" \/ \"request key deletion\").<\/p>\n<p>Torniamo alla velocit\u00e0 di avvio del server. Oltre al fatto che la velocit\u00e0 di avvio \u00e8 influenzata dal repository stesso, c'\u00e8 anche la questione di quante chiavi dal repository devono essere recuperate all'avvio. Certamente, questo \u00e8 particolarmente importante per i repository server. Durante l'avvio, il server verifica quale chiave \u00e8 necessaria per le tabelle \/ tablespace crittografati e richiede la chiave dal repository. Su un server \"pulito\" con Master Key \u2014 la crittografia deve esserci un'unica Master Key che deve essere estratta dal repository. Tuttavia, potrebbe essere necessaria un numero maggiore di chiavi, ad esempio quando un server di backup ripristina un backup dal server principale. In questi casi, deve essere prevista una rotazione della Master Key. Questo sar\u00e0 approfondito in articoli futuri, anche se qui vorrei sottolineare che un server che utilizza pi\u00f9 Master Key potrebbe avviarsi leggermente pi\u00f9 a lungo, soprattutto quando si utilizza un repository di chiavi server.<\/p>\n<p>Ora parliamo ancora un po' di keyring_file. Quando ho sviluppato keyring_file, mi preoccupava anche come controllare le modifiche a keyring_file durante il funzionamento del server. Nella versione 5.7, il controllo veniva effettuato sulla base delle statistiche del file, il che non era una soluzione ideale, e nella versione 8.0 \u00e8 stato sostituito con un checksum SHA256.<\/p>\n<p>All'avvio di keyring_file, vengono calcolate le statistiche del file e il checksum, che vengono memorizzati dal server, e le modifiche vengono applicate solo se coincidono. Quando il file viene modificato, il checksum viene aggiornato.<\/p>\n<p>Abbiamo gi\u00e0 esaminato molte problematiche relative ai vault delle chiavi. Tuttavia, c'\u00e8 un altro argomento importante che spesso viene dimenticato o frainteso: la separazione delle chiavi tra i server. <\/p>\n<p>Cosa intendo? Ogni server (ad esempio, Percona Server) in un cluster deve avere uno spazio separato sul server Vault, in cui Percona Server deve memorizzare le proprie chiavi. In ogni Master Key memorizzato nel vault \u00e8 contenuto il GUID del server Percona Server all'interno del proprio identificatore. Perch\u00e9 \u00e8 importante? Immagina di avere un solo Server Vault e tutti i Percona Server nel cluster utilizzano quest'unico Server Vault. Il problema sembra ovvio. Se tutti i Percona Server utilizzassero un Master Key senza identificatori unici, ad esempio, id = 1, id = 2 e cos\u00ec via, tutti i server nel cluster utilizzerebbero lo stesso Master Key. Ci\u00f2 che fornisce il GUID \u00e8 la separazione tra i server. Perch\u00e9 allora parlare di separazione delle chiavi tra i server, se esiste gi\u00e0 un GUID unico? C'\u00e8 un altro plugin: keyring_udf. Con questo plugin, l'utente del tuo server pu\u00f2 memorizzare le proprie chiavi sul server Vault. Il problema sorge quando l'utente crea una chiave, ad esempio, sul server server1, e poi cerca di crearne una con lo stesso identificatore su server2, ad esempio:<\/p>\n<pre><code class=\"sql\">--server1:\nselect keyring_key_store('ROB_1','AES',\"123456789012345\");\n1\n--1 indica completamento riuscito\n--server2:\nselect keyring_key_store('ROB_1','AES',\"543210987654321\");\n1<\/code><\/pre>\n<p>\nAspetta. Entrambi i server utilizzano lo stesso Server Vault, non dovrebbe la funzione keyring_key_store terminare con un errore sul server server2? \u00c8 interessante notare che se provi a fare lo stesso su un singolo server, otterrai un errore:<\/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>\nEsatto, ROB_1 esiste gi\u00e0.<\/p>\n<p>Iniziamo discutendo il secondo esempio. Come abbiamo gi\u00e0 detto in precedenza, keyring_vault o qualsiasi altro plugin di archiviazione (keyring) memorizza nella cache tutti gli identificatori delle chiavi in memoria. Pertanto, dopo aver creato una nuova chiave, ROB_1 viene aggiunta a server1 e, oltre all'invio di questa chiave a Vault, la chiave viene anche aggiunta alla cache. Ora, quando proviamo ad aggiungere la stessa chiave per la seconda volta, keyring_vault controlla se questa chiave esiste nella cache e restituisce un errore. <\/p>\n<p>Nel primo caso la situazione \u00e8 diversa. I server server1 e server2 hanno cache separate. Dopo aver aggiunto ROB_1 nella cache delle chiavi sul server server1 e sul server Vault, la cache delle chiavi su server2 non \u00e8 sincronizzata. Nella cache su server2 non c'\u00e8 la chiave ROB_1. Pertanto, la chiave ROB_1 viene scritta in keyring_key_store e nel server Vault, il che effettivamente sovrascrive (!) il valore precedente. Ora la chiave ROB_1 sul server Vault \u00e8 uguale a 543210987654321. \u00c8 interessante notare che il server Vault non blocca tali operazioni e sovrascrive tranquillamente il valore precedente.<\/p>\n<p>Ora vediamo perch\u00e9 la separazione per server su Vault pu\u00f2 essere importante \u2014 quando si utilizza keyring_udf e si desidera memorizzare le chiavi in Vault. Come garantire tale separazione sul server Vault? <\/p>\n<p>Ci sono due modi per separare su Vault. Si possono creare diversi punti di montaggio per ciascun server o utilizzare percorsi diversi all'interno di un unico punto di montaggio. \u00c8 meglio mostrarlo con degli esempi. Quindi, iniziamo a guardare prima i punti di montaggio separati: <\/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>\nQui si pu\u00f2 vedere che server1 e server2 utilizzano punti di montaggio diversi. Quando si separano i percorsi, la configurazione apparir\u00e0 come segue:<\/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>\nIn questo caso, entrambi i server utilizzano lo stesso punto di montaggio \"mount_point\", ma percorsi diversi. Quando si crea il primo segreto sul server server1 tramite questo percorso, il server Vault crea automaticamente la directory \"server1\". Per server2 \u00e8 tutto analogo. Quando si elimina l'ultimo segreto in mount_point\/server1 o mount_point\/server2, il server Vault elimina anche queste directory. Se si utilizza la separazione dei percorsi, \u00e8 necessario creare solo un punto di montaggio e modificare i file di configurazione affinch\u00e9 i server utilizzino percorsi separati. Il punto di montaggio pu\u00f2 essere creato tramite una richiesta HTTP. Con CURL si pu\u00f2 fare in questo modo:<\/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>\nTutti i campi (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) corrispondono ai parametri del file di configurazione. Naturalmente, \u00e8 possibile utilizzare gli strumenti di Vault per fare la stessa cosa. Ma \u00e8 pi\u00f9 semplice automatizzare la creazione del punto di montaggio. Spero che queste informazioni siano utili e ci vediamo nei prossimi articoli di questa serie.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/luFp\/\"><img decoding=\"async\" alt=\"Crittografia in MySQL: archivio delle chiavi\" src=\"\/wp-content\/uploads\/2020\/10\/291dcdd68660bfc312021582baa628ab.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><\/p>\n<blockquote>\n<h4>Leggi anche:<\/h4>\n<p><\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/497466\/\">Sysbench e distribuzione delle variabili casuali<\/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.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\/it\/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=\"it_IT\" \/>\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\/it\/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\udd47Crittografia in MySQL: deposito delle chiavi | ProHoster","description":"In vista dell'inizio di un nuovo ciclo del corso \"Basi di dati\", abbiamo preparato per voi la traduzione di un articolo utile.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/shifrovanie-v-mysql-hranilishhe-klyuchej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/97664","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=97664"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/97664\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/97665"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=97664"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=97664"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=97664"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}