Andmete krüpteerimine MySQL-is: võtmehoidjad

Uue kursuse alguse eelõhtul Andmebaasid oleme teie jaoks valmistanud tõlke kasulikust artiklist.

Ahnustatud andmete krüpteerimine (Transparent Data Encryption, TDE) on ilmnenud Percona Server for MySQL ja MySQLis juba üsna kaua aega tagasi. Kuid kas olete kunagi mõelnud, kuidas see töötab ning millist mõju TDE teie serverile avaldab? Selles artiklisarjas vaatame, kuidas TDE töötab sisemiselt. Alustame võtmete salvestamisest, sest see on vajalik igasuguse krüpteerimise toimimiseks. Seejärel vaatame lähemalt, kuidas krüpteerimine töötab Percona Server for MySQLi/MySQLi puhul ja millised lisafunktsioonid on Percona Server for MySQLis.

MySQL Keyring

Keyring on pluginad, mis võimaldavad serveril küsida, luua ja kustutada võtmeid kohalikus failis (keyring_file) või kaugserveris (näiteks HashiCorp Vaultis). Võtmed on alati kohaliku vahemälu, et kiirendada nende kätte saamist.

Pluginaid saab jagada kahte kategooriasse:

• Kohalik salvestus. Näiteks kohalik fail (me nimetame seda failipõhiseks võtmehoidjaks, file-based keyring).
• Kaugsalvestus. Näiteks Vault Server (me nimetame seda serveripõhiseks võtmehoidjaks, server-based keyring).

See jaotus on oluline, kuna erinevad salvestustüübid käituvad veidi erinevalt mitte ainult võtmete salvestamisel ja kätte saamisel, vaid ka käivitamisel.

Kui kasutatakse failipõhist võtmehoidjat, laaditakse käivitamisel vahemällu kogu salvestuse sisu: key id, key user, key type ja ise võtme.

Serveripõhise hoidla (nt Vault server) puhul laaditakse käivitamisel ainult key id ja key user, seega võtmete hankimine ei aeglusta käivitamist. Võtmed laaditakse viivitatud meetodil, st võtme laaditakse Vaultist alles siis, kui see tõeliselt vajalik on. Pärast laadimist kantakse võtme vahemällu, et tulevikus ei oleks vajalik selle hankimiseks TLS-ühenduse kaudu Vault Serveriga. Järgmine arutelu käsitleb, millist teavet võtmehoidlas leidub.

Võtme teave sisaldab järgmist:

• key id — võtme identifikaator, näiteks:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• key type — võtme tüüp, mis põhineb kasutataval krüpteerimisalgoritmil, võimalikud väärtused: «AES», «RSA» või «DSA».
• key length — võtme pikkus baitides, AES: 16, 24 või 32, RSA 128, 256, 512 ja DSA 128, 256 või 384.
• kasutaja — võtme omanik. Kui võtme on süsteemne, näiteks Master Key, on see väli tühi. Kui võti luuakse keyring_udf abil, tähistab see väli võtme omaniku.
• ise võti

Võti on selgelt identifitseeritav paariga: key_id, user.

Samuti on erinevusi võtmete salvestamises ja kustutamises.

Faili salvestamine töötab kiiremini. Eeldada võiks, et võtmete hoidmine on lihtsalt võtme ühekorraline salvestamine faili, kuid ei ole - siin toimub rohkem operatsioone. Iga kord, kui faili salvestust muudetakse, luuakse kogu sisu varukoopia. Oletame, et faili nimi on my_biggest_secrets, siis varukoopia nimi on my_biggest_secrets.backup. Edasi muudetakse vahemälu (lisatakse või kustutatakse võtmed) ja kui kõik on edukalt tehtud, siis vahemälu salvestatakse faili. Harvadel juhtudel, nagu serveri rike, võid näha seda varukoopia faili. Varukoopia faili kustutatakse järgmise võtmete laadimise ajal (tavaliselt pärast serveri taaskäivitamist).

Võtme salvestamise või kustutamise korral serveri hoidlas peab hoidla ühendust võtma MySQL serveriga, kasutades käske 'saada võtme' / 'kustu võtme' ('send the key' / 'request key deletion').

Tagasi minnes serveri käivitamise kiiruseni. Peale selle, et salvestus ise mõjutab käivitamise kiirus, on ka küsimus, kui palju võtmeid peate salvestusest käivitamisel saama. Loomulikult on see eriti oluline serveri hoidlate puhul. Käivitamisel kontrollib server, milline võti on vajalik krüpteeritud tabelite / tabeliruumide jaoks ja nõuab võtme salvestusest. 'Puhas' server, millel on Master Key - krüpteerimisel peab olema üks Master Key, mis tuleb salvestusest välja võtta. Siiski võib olla vajalik ka rohkem võtmeid, kui näiteks varu serveris taastatakse varukoopia peamisest serverist. Sellistel juhtudel tuleks ette näha Master Key rotatsioon. Selle kohta käsitletakse rohkem tulevastes artiklites, kuigi siin tahaksin mainida, et server, mis kasutab mitmeid Master Key, võib käivituda natuke kauem, eriti võtmehoidla kasutamise korral.

Nüüd räägime veel natuke keyring_file'ist. Kui töötasin keyring_file'i kallal, muretsesin ka selle üle, kuidas kontrollida keyring_file'i muutumist serveri töö ajal. Versioonis 5.7 toimus kontroll faili statistika põhjal, mis ei olnud ideaalne lahendus, ja versioonis 8.0 asendati see SHA256 kontrollsummaga.

Esimese käivitamise korral arvutatakse keyring_file'i füüsilise faili statistika ja kontrollsumma, mis salvestatakse serverisse, ning muudatused rakendatakse ainult juhul, kui need kattuvad. Faili muutmisel uuendatakse kontrollsummat.

Oleme juba arutanud paljusid võtmehoidla küsimusi. Siiski on veel üks oluline teema, millele sageli ei pöörata tähelepanu või mida mõistetakse valesti — võtmete jagamine serverite kaupa.

Mida ma sellega silmas pean? Igal serveril (näiteks Percona Server) klastris peab olema oma eraldi koht Vault serveris, kuhu Percona Server peab oma võtmed salvestama. Igas võtmehoidlas hoitavas Master Key's sisaldub GUID Percona Serveri serveri identifikaatori sees. Miks see oluline on? Kujutage ette, et teil on ainult üks Vault Server ja kõik Percona Serverid klastris kasutavad seda ühte Vault Serverit. Probleem näib olevat ilmne. Kui kõik Percona Serverid kasutaksid Master Key'd ilma ainulaadsete identifikaatoriteta, näiteks id = 1, id = 2 jne, siis kõik serverid klastris kasutaksid sama Master Key'd. Just seda tagab GUID — eristamine serverite vahel. Miks siis rääkida võtmete jagamisest serverite vahel, kui juba on olemas ainulaadne GUID? On veel üks plugin — keyring_udf. Selle plugina abil saab teie serveri kasutaja hoida oma võtmeid Vault serveris. Probleem tekib siis, kui kasutaja loob võtme, näiteks serveris server1, ja seejärel proovib luua sama identifikaatoriga võtme serveris server2, näiteks:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 tähistab eduka lõpuleviimise
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

Oodake. Mõlemad serverid kasutavad sama Vault Serverit, ei peaks keyring_key_store funktsioon serveris server2 lõppema veaga? Huvitav on see, et kui proovite sama asja teha ühel serveril, saate vea:

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

Õige, ROB_1 on juba olemas.

Arutame kõigepealt teise näite. Nagu me varem mainisime, keyring_vault või mõni muu ladu plugin (keyring) salvestab kõik võtme identifikaatorid mällu. Seega, pärast uue võtme loomist, ROB_1 lisatakse serverisse server1, ja peale selle võtme saatmist Vaulti, lisatakse see ka vahemäesse. Nüüd, kui proovime sama võtme teist korda lisada, kontrollib keyring_vault, kas see võti on vahemälus olemas, ja annab veateate.

Esimeses olukorras on olukord teine. Serverites server1 ja server2 on eraldi vahemälud. Pärast ROB_1 lisamist võtmete vahemällu serveris server1 ja Vault serverisse ei sünkroniseerita võtmete vahemälu serveris server2. Serveris server2 ei ole võtme ROB_1. Seega kirjutatakse võti ROB_1 keyring_key_store'i ja Vault serverisse, mis tegelikult kirjutab (!) eelneva väärtuse üle. Nüüd on Vault serveris võtme ROB_1 väärtus võrdne 543210987654321. Huvitav, et Vault server ei blokeeri selliseid toiminguid ja kirjutab lihtsalt vana väärtuse üle.

Nüüd näeme, miks hajutamine serverite kaupa Vaultis võib olla oluline — kui kasutate keyring_udf ja soovite ladu hoida Vaultis. Kuidas tagada selline hajutamine Vault serveris?

Vaultis on kaks viisi hajutamiseks. Võite luua iga serveri jaoks erinevad mount-punkid või kasutada erinevaid teid ühe mount-punkti sees. Parim on seda näidata näidete abil. Niisiis, vaatame kõigepealt eraldi mount-punkte:

--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 = (...)

Siit on näha, et server1 ja server2 kasutavad erinevaid mount-punkte. Teede hajutamise korral näeb konfigureerimine välja järgmiselt:

--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 = (...)

Antud juhul kasutavad mõlemad serverid sama mount-punkti «mount_point», kuid erinevaid teid. Kui esimese saladuse loomisel serveris server1 sellel teel loob Vault automaatselt katalooge «server1». Serveri server2 puhul on kõik analoogne. Kui kustutate viimase saladuse mount_point/server1 või mount_point/server2-s, kustutab Vault ka need kataloogid. Kui kasutate teede eristamist, peaksite looma ainult ühe mount-punkti ja muutma konfiguratsiooni faile, et serverid kasutaksid eraldi teid. Mount-punkti saab luua HTTP-päringu abil. CURL-i abil saab seda teha järgmiselt:

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

Kõik väljad (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) vastavad konfiguratsioonifaili parameetritele. Loomulikult saab sama teha Vault utiliitide abil. Kuid mount-punkti loomise automatiseerimine on lihtsam. Loodan, et see teave on teile kasulik ja kohtume järgmistes selle seeria artiklites.

Loe edasi:

• Sysbench ja juhuslike väärtuste jaotamine

Allikas: habr.com