Dina antisipasi mimiti enrollment anyar pikeun kursus Kami parantos nyiapkeun tarjamahan tina tulisan anu mangpaat pikeun anjeun.
Énkripsi Data Transparan (TDE) muncul dina sareng MySQL kanggo sababaraha waktos. Tapi naha anjeun kantos panginten kumaha éta tiasa dianggo dina tiung sareng naon dampak TDE dina server anjeun? Dina runtuyan artikel ieu urang bakal nempo kumaha TDE jalan internal. Hayu urang mimitian ku neundeun konci, sabab ieu dipikabutuh pikeun énkripsi naon waé pikeun jalan. Teras we bakal nyandak katingal ngadeukeutan kumaha enkripsi jalan dina Percona Server pikeun MySQL / MySQL na naon fitur tambahan Percona Server pikeun MySQL boga.
MySQL Keyring
Keyring mangrupikeun plugins anu ngamungkinkeun server naroskeun, nyiptakeun, sareng ngahapus konci dina file lokal (keyring_file) atanapi dina server jauh (sapertos HashiCorp Vault). Konci sok disimpen sacara lokal pikeun nyepetkeun dimeunangkeunana.
Plugins bisa dibagi kana dua kategori:
- Panyimpenan lokal. Contona, file lokal (urang nelepon ieu keyring dumasar-file).
- Panyimpen jauh. Contona, Kolong Server (urang nelepon ieu keyring basis server).
Separation Ieu penting sabab tipena béda gudang kalakuanana rada béda, teu ngan lamun nyimpen jeung retrieving konci, tapi ogé nalika ngajalankeun aranjeunna.
Nalika nganggo panyimpen file, nalika ngamimitian, sadaya eusi gudang dimuat kana cache: id konci, pangguna konci, jinis konci, sareng konci éta sorangan.
Dina kasus toko basis server (sapertos Vault Server), ngan id konci sareng pangguna konci anu dimuat nalika ngamimitian, janten kéngingkeun sadaya konci henteu ngalambatkeun ngamimitian. Konci ditumpakan puguh. Hartina, konci sorangan dimuat ti Kolong ngan lamun eta sabenerna diperlukeun. Saatos diundeur, konci éta disimpen dina mémori supados henteu kedah diaksés ngalangkungan sambungan TLS ka Vault Server ka hareup. Teras, hayu urang tingali inpormasi naon anu aya dina toko konci.
Inpormasi konci ngandung ieu:
- id konci - identifier konci, contona:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - tipe konci - tipe konci dumasar kana algoritma enkripsi dipaké, nilai mungkin: "AES", "RSA" atawa "DSA".
- panjang konci - Panjang konci dina bait, AES: 16, 24 atanapi 32, RSA 128, 256, 512 sareng DSA 128, 256 atanapi 384.
- nu make - boga konci. Upami koncina nyaéta sistem, contona, Master Key, maka lapangan ieu kosong. Lamun konci dijieun maké keyring_udf, mangka widang ieu nangtukeun nu boga konci.
- konci sorangan
Koncina diidentipikasi sacara unik ku pasangan: key_id, pamaké.
Aya ogé béda dina nyimpen sareng mupus konci.
Panyimpenan file langkung gancang. Anjeun panginten panginten yén toko konci ngan saukur nyerat konci kana file sakali, tapi henteu, aya deui anu lumangsung di dieu. Iraha wae modifikasi gudang file dijieun, salinan cadangan sadaya eusi munggaran dijieun. Hayu urang nyebutkeun file disebut my_biggest_secrets, lajeng salinan cadangan bakal my_biggest_secrets.backup. Salajengna, cache nu dirobah (konci ditambahkeun atawa dihapus) jeung, lamun sagalana geus suksés, cache nu ngareset kana file. Dina kasus anu jarang, sapertos gagalna server, anjeun tiasa ningali file cadangan ieu. Payil cadangan dihapus dina waktos salajengna konci dimuat (biasana sanggeus server restarted).
Nalika nyimpen atanapi ngahapus konci dina panyimpenan server, gudang kedah nyambung ka server MySQL kalayan paréntah "ngirim konci" / "nyuhunkeun ngahapus konci".
Hayu urang balik deui ka speed ngamimitian server. Salian kanyataan yén laju peluncuran dipangaruhan ku kolong sorangan, aya ogé masalah sabaraha konci tina kolong anu kedah dipulut nalika ngamimitian. Tangtu, ieu téh hususna penting pikeun neundeun server. Dina ngamimitian, server mariksa konci mana anu dipikabutuh pikeun tabel / rohangan méja énkripsi sareng nyuhunkeun konci tina panyimpenan. Dina server "bersih" sareng enkripsi Master Key, kedah aya hiji Master Key, anu kedah dicandak tina panyimpenan. Tapi, sajumlah konci anu langkung ageung tiasa diperyogikeun, contona, nalika pangladén cadangan mulangkeun cadangan ti pangladén primér. Dina kasus sapertos kitu, rotasi Master Key kedah disayogikeun. Ieu bakal katutupan di leuwih jéntré dina artikel nu bakal datang, najan di dieu Abdi hoyong dicatet yén server ngagunakeun sababaraha Master Keys butuh waktu saeutik deui ngamimitian up, utamana lamun ngagunakeun toko konci sisi server.
Ayeuna hayu urang ngobrol langkung seueur ngeunaan keyring_file. Nalika kuring ngembangkeun keyring_file, kuring ogé prihatin ngeunaan kumaha carana mariksa parobahan keyring_file nalika server dijalankeun. Dina 5.7, pamariksaan dilakukeun dumasar kana statistik file, anu sanés mangrupikeun solusi idéal, sareng dina 8.0 diganti ku checksum SHA256.
Pertama kali anjeun ngajalankeun keyring_file, diitung statistik file na checksum, nu inget ku server, sarta parobahan ngan dilarapkeun lamun cocog. Lamun file robah, checksum nu diropéa.
Kami parantos nutupan seueur patarosan ngeunaan kolong konci. Sanajan kitu, aya topik penting séjén anu mindeng poho atawa salah harti: babagi konci sakuliah server.
Naon maksud kuring? Unggal server (contona, Percona Server) dina kluster kedah gaduh lokasi anu misah dina Kolong Server dimana Percona Server kedah nyimpen konci na. Unggal Master Key disimpen dina gudang ngandung GUID tina Percona Server dina identifier na. Naha éta penting? Bayangkeun yén anjeun ngan ukur gaduh hiji Server Kolong sareng sadaya Percona Server dina kluster nganggo éta Server Kolong tunggal. Masalahna sigana atra. Upami sadayana Percona Server nganggo Master Key tanpa identifier unik, sapertos id = 1, id = 2, jsb, maka sadaya server dina kluster bakal nganggo Master Key anu sami. Anu disayogikeun GUID nyaéta bédana antara server. Naha lajeng ngobrol ngeunaan babagi konci antara server lamun GUID unik geus aya? Aya plugin sejen - keyring_udf. Kalayan plugin ieu, pangguna server anjeun tiasa nyimpen konci na dina server Vault. Masalahna lumangsung nalika pangguna nyiptakeun konci dina server1, contona, teras nyobian ngadamel konci kalayan ID anu sami dina server2, contona:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Antosan. Duanana server ngagunakeun Server Kolong sarua, teu kudu fungsi keyring_key_store gagal dina server2? Narikna, upami anjeun nyobian ngalakukeun hal anu sami dina hiji server, anjeun bakal nampi kasalahan:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Leres, ROB_1 parantos aya.
Hayu urang bahas conto kadua munggaran. Sakumaha anu ceuk urang tadi, keyring_vault atawa plugin keyring séjén cache sadaya ID konci dina mémori. Ku kituna, sanggeus nyieun konci anyar, ROB_1 ditambahkeun kana server1, sarta sajaba ti ngirim konci ieu ka Kolong, konci ogé ditambahkeun kana cache nu. Ayeuna, nalika urang nyobian pikeun nambahkeun konci anu sarua pikeun kadua kalina, keyring_vault pariksa naha konci éta aya dina cache sarta throws kasalahan.
Dina kasus nu pertama, kaayaan béda. Server1 sareng server2 gaduh cache anu misah. Saatos nambihan ROB_1 kana cache konci dina server1 sareng server Vault, cache konci dina server2 teu sinkron. Henteu aya konci ROB_2 dina cache dina server1. Ku kituna, konci ROB_1 ditulis kana keyring_key_store jeung server Kolong, nu sabenerna nimpa (!) Nilai saméméhna. Ayeuna konci ROB_1 dina server Vault nyaéta 543210987654321. Narikna, server Vault henteu meungpeuk tindakan sapertos kitu sareng gampang nimpa nilai anu lami.
Ayeuna urang tiasa ningali naha partisi server di Vault tiasa penting - nalika anjeun nganggo keyring_udf sareng hoyong nyimpen konci dina Vault. Kumaha carana ngahontal separation ieu dina server Vault?
Aya dua cara pikeun ngabagi kana Vault. Anjeun tiasa nyiptakeun titik gunung anu béda pikeun tiap server, atanapi nganggo jalur anu béda dina titik gunung anu sami. Ieu pangalusna digambarkeun ku conto. Ku kituna hayu urang nempo titik gunung individu munggaran:
--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 = (...)Di dieu anjeun tiasa ningali yén server1 sareng server2 nganggo titik gunung anu béda. Nalika ngabagi jalur, konfigurasi bakal katingali sapertos kieu:
--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 = (...)Dina hal ieu, duanana server ngagunakeun titik Gunung sarua "mount_point", tapi jalur béda. Lamun anjeun nyieun rusiah munggaran dina server1 ngagunakeun jalur ieu, server Kolong otomatis nyieun diréktori "server1". Pikeun server2 sagalana sarupa. Lamun anjeun mupus rusiah panungtungan di mount_point / server1 atanapi mount_point / server2, server Kolong ogé mupus directories maranéhanana. Upami anjeun nganggo separation jalur, anjeun kedah nyiptakeun ngan hiji titik gunung sareng ngarobih file konfigurasi supados server nganggo jalur anu misah. Hiji titik Gunung bisa dijieun maké pamundut HTTP. Ngagunakeun CURL ieu tiasa dilakukeun sapertos kieu:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTSadaya widang (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) pakait jeung parameter tina file konfigurasi. Tangtosna, anjeun tiasa nganggo utilitas Vault pikeun ngalakukeun anu sami. Tapi leuwih gampang pikeun ngajadikeun otomatis nyieun hiji titik Gunung. Abdi ngarepkeun anjeun mendakan inpormasi ieu mangpaat sareng urang bakal ningali anjeun dina tulisan salajengna dina séri ieu.
Maca deui:
sumber: www.habr.com