Cifratura in MySQL: Keystore

In anticipazione di l'iniziu di una nova iscrizzione per u corsu "Base di dati" Avemu preparatu una traduzzione di un articulu utile per voi.

Trasparente Data Encryption (TDE) hè apparsu in Percona Server per MySQL è MySQL per un bellu pezzu. Ma avete mai pensatu à cumu si travaglia sottu u cappucciu è chì impattu TDE pò avè in u vostru servitore? In questa serie di articuli, avemu da vede cumu TDE travaglia internamente. Cuminciamu cù l'almacenamiento di chjave, postu chì questu hè necessariu per qualsiasi criptografia per travaglià. Allora avemu da piglià un ochju più vicinu à cumu funziona a criptografia in Percona Server per MySQL / MySQL è quali funzioni supplementari Percona Server per MySQL hà.

Portachiavi MySQL

Keyring sò plugins chì permettenu à u servitore di dumandà, creà è sguassate chjave in un schedariu locale (keyring_file) o in un servitore remotu (cum'è HashiCorp Vault). I chjavi sò sempre in cache in u locu per accelerà a so ricuperazione.

I plugins ponu esse divisi in duie categorie:

• Storage locale. Per esempiu, un schedariu lucale (chjamemu questu un keyring basatu in u schedariu).
• Almacenamiento remota. Per esempiu, Vault Server (chjamemu questu un keyring basatu in u servitore).

Sta separazione hè impurtante perchè i sfarenti tippi di almacenamentu si cumportanu un pocu sfarente, micca solu quandu si guarda è ricuperà e chjave, ma ancu quandu eseguite.

Quandu si usa un archiviu di fugliale, à l'iniziu, u cuntenutu sanu sanu di l'almacenamiento hè caricatu in a cache: ID chjave, utilizatore chjave, tipu di chjave è a chjave stessu.

In u casu di una tenda basata in u servitore (cum'è Vault Server), solu l'identificatore di chjave è l'utilizatore chjave sò caricati à l'iniziu, cusì uttene tutte e chjave ùn rallenta micca l'iniziu. I chjavi sò caricati pigramente. Questu hè, a chjave stessu hè caricata da Vault solu quandu hè veramente necessariu. Una volta scaricata, a chjave hè in cache in memoria per ùn avè micca bisognu di accede à e cunnessione TLS à u Vault Server in u futuru. In seguitu, fighjemu ciò chì infurmazione hè presente in u magazinu chjave.

L'infurmazione chjave cuntene i seguenti:

• ID chjave - identificatore chjave, per esempiu:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• tippu chjave - tipu di chjave basatu annantu à l'algoritmu di criptografia utilizatu, valori pussibuli: "AES", "RSA" o "DSA".
• lunghezza chjave - lunghezza chjave in byte, AES: 16, 24 o 32, RSA 128, 256, 512 è DSA 128, 256 o 384.
• Fammi - pruprietariu di a chjave. Sè a chjave hè sistema, per esempiu, Master Key, allura stu campu hè viotu. Se una chjave hè creata cù keyring_udf, allura stu campu identifica u pruprietariu di a chjave.
• a chjave stessu

A chjave hè identificata unicu da a coppia: key_id, user.

Ci hè ancu sferenze in u almacenamentu è l'eliminazione di e chjave.

U almacenamentu di i schedari hè più veloce. Puderete pensà chì un magazzinu di chjave hè simplicemente scrivendu a chjave in un schedariu una volta, ma no, ci hè più quì. Ogni volta chì una mudificazione di almacenamiento di schedari hè fatta, una copia di salvezza di tuttu u cuntenutu hè prima creata. Dicemu chì u schedariu hè chjamatu my_biggest_secrets, allora a copia di salvezza serà my_biggest_secrets.backup. In seguitu, a cache hè cambiata (i chjavi sò aghjuntu o sguassati) è, se tuttu hè successu, a cache hè resettata à un schedariu. In casi rari, cum'è un fallimentu di u servitore, pudete vede stu schedariu di salvezza. U schedariu di salvezza hè sguassatu a prossima volta chì i chjavi sò caricati (in solitu dopu chì u servitore hè riavviatu).

Quandu salvate o sguassate una chjave in un almacenamentu di u servitore, l'almacenamiento deve cunnette à u servitore MySQL cù i cumandamenti "invià a chjave" / "richiedda l'eliminazione di chjave".

Riturnemu à a velocità di startup di u servitore. In più di u fattu chì a velocità di lanciamentu hè affettata da a volta stessa, ci hè ancu u prublema di quante chjavi da a volta deve esse ricuperate à l'iniziu. Di sicuru, questu hè particularmente impurtante per u almacenamentu di u servitore. À l'iniziu, u servitore verifica quale chjave hè necessaria per tavule / tablespaces criptati è dumanda a chjave da u almacenamiento. In un servitore "pulitu" cù criptografia Master Key, deve esse una Master Key, chì deve esse recuperata da u almacenamentu. In ogni casu, un numeru più grande di chjave pò esse necessariu, per esempiu, quandu u servitore di salvezza restaurà una copia di salvezza da u servitore primariu. In tali casi, a rotazione di a Chjave Maestra deve esse furnita. Questu serà cupertu in più dettagliu in articuli futuri, ancu s'ellu ci vole à nutà chì un servitore chì usa parechje Chjavi Maestri pò piglià un pocu di più per inizià, soprattuttu quandu si usa un magazzinu di chjave di u servitore.

Avà parlemu un pocu più di keyring_file. Quandu aghju sviluppatu keyring_file, era ancu preoccupatu di cumu verificà i cambiamenti di keyring_file mentre u servitore hè in esecuzione. In 5.7, a verificazione hè stata realizata nantu à e statistiche di u schedariu, chì ùn era micca una suluzione ideale, è in 8.0 hè stata rimpiazzata cù un SHA256 checksum.

A prima volta chì eseguite keyring_file, statistiche di u schedariu è un checksum sò calculati, chì sò ricurdati da u servitore, è i cambiamenti sò appiicati solu s'ellu currispondenu. Quandu u schedariu cambia, u checksum hè aghjurnatu.

Avemu digià cupertu parechje dumande nantu à i vaulti chjave. In ogni casu, ci hè un altru tema impurtante chì hè spessu sminticatu o capitu male: sparte e chjave in i servitori.

Chì vogliu dì ? Ogni servitore (per esempiu, Percona Server) in u cluster deve avè un locu separatu nantu à u Vault Server in quale Percona Server deve almacenà e so chjave. Ogni Master Key salvata in u almacenamiento cuntene u GUID di u Percona Server in u so identificatore. Perchè hè impurtante? Imagine chì avete solu un Servitore Vault è tutti i Servitori Percona in u cluster utilizanu quellu Servitore Vault unicu. U prublema pare evidenti. Sì tutti i Servitori Percona anu utilizatu una Chjave Maestra senza identificatori unichi, cum'è id = 1, id = 2, etc., allora tutti i servitori in u cluster utilizanu a stessa Chjave Maestra. Ciò chì u GUID furnisce hè a distinzione trà i servitori. Perchè allora parlà di sparte e chjave trà i servitori se un GUID unicu esiste digià? Ci hè un altru plugin - keyring_udf. Cù stu plugin, u vostru utilizatore di u servitore pò almacenà e so chjave in u servitore Vault. U prublema si trova quandu un utilizatore crea una chjave in u server1, per esempiu, è poi prova di creà una chjave cù u listessu ID in u server2, per esempiu:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

Aspetta. I dui servitori utilizanu u stessu Servitore Vault, a funzione keyring_key_store ùn deve micca falla in server2? Curiosamente, se pruvate à fà u listessu in un servitore, riceverete un errore:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

Hè propiu, ROB_1 esiste digià.

Discutemu u sicondu esempiu prima. Comu avemu dettu prima, keyring_vault o qualsiasi altru plugin di keyring cache tutti l'ID chjave in memoria. Allora, dopu à creà una nova chjave, ROB_1 hè aghjuntu à u servitore1, è in più di mandà sta chjave à Vault, a chjave hè ancu aghjuntu à u cache. Avà, quandu avemu pruvatu à aghjunghje a stessa chjave una seconda volta, keyring_vault verifica se a chjave esiste in a cache è tira un errore.

In u primu casu, a situazione hè diversa. Server1 è server2 anu cache separati. Dopu avè aghjustatu ROB_1 à a cache chjave in u server1 è u servitore Vault, a cache chjave in u server2 hè fora di sincronia. Ùn ci hè micca una chjave ROB_2 in a cache in u server1. Cusì, a chjave ROB_1 hè scritta à u keyring_key_store è à u servitore Vault, chì in realtà overwrites (!) U valore precedente. Avà a chjave ROB_1 nantu à u servitore Vault hè 543210987654321. Curiosamente, u servitore Vault ùn blucca micca tali azzioni è facilmente overwrites u vechju valore.

Avà pudemu vede perchè u particionamentu di u servitore in Vault pò esse impurtante - quandu si usa keyring_udf è vulete almacenà e chjave in Vault. Cumu ottene sta separazione in un servitore Vault?

Ci hè duie manere di particionà in Vault. Pudete creà diversi punti di muntagna per ogni servitore, o utilizate diverse strade in u stessu puntu di muntagna. Questu hè megliu illustratu cù esempi. Allora fighjemu prima i punti di muntagna individuali:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)

Quì pudete vede chì u servitore 1 è u servitore 2 utilizanu diversi punti di muntagna. Quandu si sparte i percorsi, a cunfigurazione sarà cusì:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)

In questu casu, i dui servitori utilizanu u stessu puntu di muntagna "mount_point", ma percorsi differenti. Quandu crea u primu sicretu in u servitore 1 utilizendu sta strada, u servitore Vault crea automaticamente un repertoriu "server1". Per server2 tuttu hè simile. Quandu sguassate l'ultimu sicretu in mount_point/server1 o mount_point/server2, u servitore Vault elimina ancu quelli cartulari. In casu chì aduprate a separazione di caminu, duvete creà solu un puntu di muntagna è cambià i schedarii di cunfigurazione per chì i servitori utilizanu percorsi separati. Un puntu di muntagna pò esse creatu cù una dumanda HTTP. Utilizendu CURL questu pò esse fattu cusì:

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

Tutti i campi (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) currispondenu à i paràmetri di u schedariu di cunfigurazione. Di sicuru, pudete aduprà l'utilità Vault per fà u listessu. Ma hè più faciule per automatizà a creazione di un puntu di muntagna. Spergu chì truvate sta infurmazione utile è vi vedemu in i prossimi articuli in questa serie.

Leghjite più:

• Sysbench è a distribuzione di variabili aleatorii

Source: www.habr.com