ProHoster > Blogs > Administrācija > Å ifrÄ“Å”ana MySQL: Keystore

ŠifrēŔana MySQL: Keystore

Gaidot jaunas uzņemÅ”anas sākumu kursā "Datu bāze" sagatavoja jums noderÄ«ga raksta tulkojumu.

ŠifrēŔana MySQL: Keystore

gadā parādÄ«jās Transparent Data Encryption (TDE). Percona serveris MySQL un MySQL jau labu laiku. Bet vai esat kādreiz domājis par to, kā tas darbojas zem pārsega un kādu ietekmi TDE var atstāt uz jÅ«su serveri? Å ajā rakstu sērijā mēs apskatÄ«sim, kā TDE darbojas iekŔēji. Sāksim ar atslēgu glabāŔanu, jo tas ir nepiecieÅ”ams, lai darbotos jebkura Å”ifrÄ“Å”ana. Pēc tam mēs sÄ«kāk aplÅ«kosim, kā Å”ifrÄ“Å”ana darbojas Percona Server for MySQL/MySQL un kādas papildu funkcijas ir pieejamas Percona Server for MySQL.

MySQL atslēgu piekariņŔ

Atslēgu piekariņi ir spraudņi, kas ļauj serverim vaicāt, izveidot un dzēst atslēgas lokālā failā (keyring_file) vai attālajā serverī (piemēram, HashiCorp Vault). Atslēgas vienmēr tiek saglabātas lokāli, lai paātrinātu izguvi.

Spraudņus var iedalīt divās kategorijās:

  • Vietējā krātuve. Piemēram, lokālais fails (mēs to saucam par failu atslēgu piekariņu).
  • attālā krātuve. Piemēram, Vault Server (mēs to saucam par servera atslēgu piekariņu).

Å Ä« atdalÄ«Å”ana ir svarÄ«ga, jo dažādi krātuves veidi darbojas nedaudz atŔķirÄ«gi ne tikai saglabājot un izgÅ«stot atslēgas, bet arÄ« palaižot tās.

Lietojot failu krātuvi, startÄ“Å”anas laikā keÅ”atmiņā tiek ielādēts viss krātuves saturs: atslēgas ID, atslēgas lietotājs, atslēgas veids un pati atslēga.

Aizmugurējā veikala (piemēram, Vault servera) gadÄ«jumā startÄ“Å”anas laikā tiek ielādēts tikai atslēgas ID un atslēgas lietotājs, tāpēc visu atslēgu iegÅ«Å”ana nepalēnina startÄ“Å”anu. Atslēgas tiek ielādētas laiski. Tas nozÄ«mē, ka pati atslēga tiek ielādēta no Vault tikai tad, kad tā patieŔām ir nepiecieÅ”ama. Pēc lejupielādes atslēga tiek saglabāta keÅ”atmiņā, lai turpmāk tai nebÅ«tu jāpiekļūst, izmantojot TLS savienojumus ar Vault serveri. Pēc tam apsveriet, kāda informācija atrodas atslēgu krātuvē.

Galvenā informācija satur Ŕādu informāciju:

  • atslēgas id - atslēgas identifikators, piemēram:
    INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
  • atslēgas veids - atslēgas veids, pamatojoties uz izmantoto Å”ifrÄ“Å”anas algoritmu, iespējamās vērtÄ«bas: "AES", "RSA" vai "DSA".
  • atslēgas garums - atslēgas garums baitos, AES: 16, 24 vai 32, RSA 128, 256, 512 un DSA 128, 256 vai 384.
  • lietotājs ir atslēgas Ä«paÅ”nieks. Ja atslēga ir sistēmas atslēga, piemēram, galvenā atslēga, Å”is lauks ir tukÅ”s. Ja atslēga ir izveidota, izmantojot keyring_udf, tad Å”ajā laukā ir norādÄ«ts atslēgas Ä«paÅ”nieks.
  • pati atslēga

Atslēgu unikāli identificē pāris: atslēgas_id, lietotājs.

AtŔķirÄ«bas ir arÄ« atslēgu glabāŔanā un dzÄ“Å”anā.

Failu glabāŔana ir ātrāka. Varētu domāt, ka atslēgu krātuve ir tikai vienreizēja faila atslēgas ierakstÄ«Å”ana, taču tā nav ā€” Å”eit notiek vairāk. Ikreiz, kad tiek mainÄ«ta failu krātuve, viss saturs vispirms tiek dublēts. Pieņemsim, ka failu sauc my_biggest_secrets, tad dublējums bÅ«s my_biggest_secrets.backup. Pēc tam keÅ”atmiņa tiek mainÄ«ta (atslēgas tiek pievienotas vai noņemtas) un, ja viss ir veiksmÄ«gs, keÅ”atmiņa tiek izmesta failā. Retos gadÄ«jumos, piemēram, servera avārijas gadÄ«jumā, jÅ«s varat redzēt Å”o dublējuma failu. Dublējuma fails tiek dzēsts nākamreiz, kad tiek ielādētas atslēgas (parasti pēc servera restartÄ“Å”anas).

Saglabājot vai dzÄ“Å”ot atslēgu servera veikalā, veikalam ir jāpieslēdzas MySQL serverim ar komandām "nosÅ«tÄ«t atslēgu" / "pieprasÄ«t atslēgas dzÄ“Å”anu".

AtgriezÄ«simies pie servera startÄ“Å”anas ātruma. Papildus tam, ka pati glabātuve ietekmē palaiÅ”anas ātrumu, ir arÄ« jautājums par to, cik atslēgu no glabātuves ir jāiegÅ«st startÄ“Å”anas laikā. Protams, tas ir Ä«paÅ”i svarÄ«gi serveru krātuvēm. Startējot, serveris pārbauda, ā€‹ā€‹kura atslēga ir nepiecieÅ”ama Å”ifrētajām tabulām/tabulu vietām, un pieprasa atslēgu no krātuves. "TÄ«rā" serverÄ« ar galveno atslēgu - Å”ifrÄ“Å”anai ir jābÅ«t vienai galvenajai atslēgai, kas jāizgÅ«st no krātuves. Tomēr var bÅ«t nepiecieÅ”ams vairāk atslēgu, piemēram, ja rezerves serverÄ« tiek atjaunota rezerves kopija no primārā servera. Šādos gadÄ«jumos ir jānodroÅ”ina galvenā atslēgas rotācija. Tas tiks sÄ«kāk apspriests nākamajos rakstos, lai gan Å”eit es vēlos atzÄ«mēt, ka servera, kas izmanto vairākas galvenās atslēgas, startÄ“Å”ana var aizņemt nedaudz ilgāku laiku, it Ä«paÅ”i, ja tiek izmantots servera atslēgu krātuvis.

Tagad parunāsim nedaudz vairāk par keyring_file. Izstrādājot atslēgu piekariņa_failu, man bija bažas arī par to, kā pārbaudīt atslēgas gredzena_faila izmaiņas, kamēr serveris darbojas. Programmā 5.7 pārbaude tika veikta, pamatojoties uz failu statistiku, kas nebija ideāla, un 8.0 versijā tā tika aizstāta ar SHA256 kontrolsummu.

Pirmo reizi palaižot keyring_file, serveris aprēķina un atceras faila statistiku un kontrolsummu, un izmaiņas tiek lietotas tikai tad, ja tās atbilst. Kad fails mainās, kontrolsumma tiek atjaunināta.

Mēs jau esam apskatÄ«juÅ”i daudzus jautājumus par atslēgu krātuvēm. Tomēr ir vēl viena svarÄ«ga tēma, kas bieži tiek aizmirsta vai pārprasta ā€“ atslēgu koplietoÅ”ana starp serveriem.

Ko es domāju? Katram klastera serverim (piemēram, Percona Server) Vault serverÄ« ir jābÅ«t atseviŔķai vietai, kurā Percona Server jāglabā savas atslēgas. Katra krātuvē saglabātā galvenā atslēga savā ID satur Percona Server GUID. Kāpēc tas ir svarÄ«gi? Iedomājieties, ka jums ir tikai viens Vault serveris un visi klastera Percona serveri izmanto Å”o vienu Vault serveri. Problēma Ŕķiet acÄ«mredzama. Ja visi Percona serveri izmantotu galveno atslēgu bez unikāliem identifikatoriem, piemēram, id = 1, id = 2 utt., tad visi klastera serveri izmantotu vienu un to paÅ”u galveno atslēgu. Tas ir tas, ko nodroÅ”ina GUID ā€” atŔķirÄ«ba starp serveriem. Kāpēc tad runāt par atslēgu koplietoÅ”anu starp serveriem, ja jau ir unikāls GUID? Ir vēl viens spraudnis - keyring_udf. Izmantojot Å”o spraudni, jÅ«su servera lietotājs var saglabāt savas atslēgas Vault serverÄ«. Problēma rodas, ja lietotājs izveido atslēgu, piemēram, serverÄ«1, un pēc tam mēģina izveidot atslēgu ar tādu paÅ”u ID serverÄ«2, piemēram:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 Š·Š½Š°Ń‡Šøт усŠæŠµŃˆŠ½Š¾Šµ Š·Š°Š²ŠµŃ€ŃˆŠµŠ½ŠøŠµ
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

Pagaidiet. Abi serveri izmanto vienu un to paÅ”u Vault serveri. Vai serverÄ«2 nevajadzētu darboties keyring_key_store funkcijai? Interesanti, ka, mēģinot darÄ«t to paÅ”u tajā paŔā serverÄ«, jÅ«s saņemsit kļūdu:

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

TieŔi tā, ROB_1 jau pastāv.

Vispirms apspriedÄ«sim otro piemēru. Kā jau teicām iepriekÅ”, keyring_vault vai jebkurÅ” cits glabātuves spraudnis (keyring) saglabā atmiņā visus atslēgu ID. Tātad, pēc jaunas atslēgas izveidoÅ”anas ROB_1 tiek pievienots serverim1, un papildus Ŕīs atslēgas nosÅ«tÄ«Å”anai uz Vault, atslēga tiek pievienota arÄ« keÅ”atmiņai. Tagad, mēģinot pievienot to paÅ”u atslēgu otrreiz, keyring_vault pārbauda, ā€‹ā€‹vai atslēga pastāv keÅ”atmiņā, un rada kļūdu.

Pirmajā gadÄ«jumā situācija ir atŔķirÄ«ga. Server1 un serverim2 ir atseviŔķas keÅ”atmiņas. Pēc ROB_1 pievienoÅ”anas atslēgu keÅ”atmiņai serverÄ«1 un Vault serverÄ«, servera2 atslēgas keÅ”atmiņa nav sinhronizēta. Server2 keÅ”atmiņā nav ROB_1 atslēgas. Tādējādi atslēga ROB_1 tiek ierakstÄ«ta keyring_key_store un Vault serverÄ«, kas faktiski pārraksta (!) iepriekŔējo vērtÄ«bu. Tagad Vault servera atslēga ROB_1 ir 543210987654321. Interesanti, ka Vault serveris nebloķē Ŕādas darbÄ«bas un viegli pārraksta veco vērtÄ«bu.

Tagad mēs redzam, kāpēc segregācija pēc servera pakalpojumā Vault var bÅ«t svarÄ«ga, ja izmantojat keyring_udf un vēlaties saglabāt atslēgas pakalpojumā Vault. Kā nodroÅ”ināt Ŕādu atdalÄ«Å”anu Vault serverÄ«?

Ir divi veidi, kā sadalÄ«t Vault. Katram serverim varat izveidot dažādus stiprinājuma punktus vai izmantot dažādus ceļus vienā un tajā paŔā stiprinājuma punktā. Labākais veids, kā to parādÄ«t, ir ar piemēriem. Vispirms apskatÄ«sim atseviŔķus stiprinājuma punktus: 

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

Å eit jÅ«s varat redzēt, ka serveris1 un serveris2 izmanto dažādus stiprinājuma punktus. Izmantojot ceļu atdalÄ«Å”anu, konfigurācija izskatÄ«sies Ŕādi:

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

Å ajā gadÄ«jumā abi serveri izmanto vienu un to paÅ”u pievienoÅ”anas punktu "mount_point", bet atŔķirÄ«gus ceļus. Kad izveidojat pirmo noslēpumu serverÄ«1, izmantojot Å”o ceļu, Vault serveris automātiski izveido direktoriju "server1". Server2 viss ir vienāds. DzÄ“Å”ot pēdējo noslēpumu mount_point/server1 vai mount_point/server2, Vault serveris dzÄ“Å” arÄ« Å”os direktorijus. Ja izmantojat sadalÄ«tos ceļus, jums ir jāizveido tikai viens stiprinājuma punkts un jāmaina konfigurācijas faili, lai serveri izmantotu atseviŔķus ceļus. Montāžas punktu var izveidot ar HTTP pieprasÄ«jumu. Ar CURL to var izdarÄ«t Ŕādi:

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

Visi lauki (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) atbilst konfigurācijas faila parametriem. Protams, varat izmantot Vault utilÄ«tas, lai veiktu to paÅ”u. Bet montāžas punkta izveidi ir vieglāk automatizēt. Ceru, ka Ŕī informācija jums noderēs un tiekamies nākamajos Ŕīs sērijas rakstos.

ŠifrēŔana MySQL: Keystore

Lasīt vairāk:

Avots: www.habr.com

Pievieno komentāru