Ing nunggu wiwitan enrollment anyar kanggo mesthi Kita wis nyiapake terjemahan artikel sing migunani kanggo sampeyan.
Enkripsi Data Transparan (TDE) muncul ing lan MySQL kanggo sawetara wektu. Nanging apa sampeyan wis tau mikir babagan cara kerjane lan apa pengaruh TDE ing server sampeyan? Ing seri artikel iki kita bakal nliti cara kerja TDE sacara internal. Ayo dadi miwiti karo panyimpenan tombol, amarga iki dibutuhake supaya enkripsi bisa digunakake. Banjur kita bakal nliti kanthi luwih rinci babagan cara enkripsi ing Percona Server kanggo MySQL/MySQL lan fitur tambahan apa Percona Server kanggo MySQL.
MySQL Keyring
Keyring minangka plugin sing ngidini server takon, nggawe, lan mbusak kunci ing file lokal (keyring_file) utawa ing server remot (kayata HashiCorp Vault). Tombol tansah di-cache sacara lokal kanggo nyepetake pengangkatan.
Plugins bisa dipΓ©rang dadi rong kategori:
- Panyimpenan lokal. Contone, file lokal (kita nyebut iki keyring basis file).
- Panyimpenan adoh. Contone, Vault Server (kita nyebut iki keyring basis server).
Pemisahan iki penting amarga macem-macem jinis panyimpenan tumindak rada beda, ora mung nalika nyimpen lan njupuk tombol, nanging uga nalika mbukak.
Nalika nggunakake panyimpenan file, nalika wiwitan, kabeh isi panyimpenan dimuat menyang cache: key id, key user, key type, lan key dhewe.
Ing kasus toko sisih server (kayata Vault Server), mung id kunci lan pangguna kunci sing dimuat nalika wiwitan, mula njupuk kabeh tombol ora bakal alon-alon wiwitan. Keys dimuat kesed. Tegese, tombol kasebut dimuat saka Vault mung nalika dibutuhake. Sawise diundhuh, kunci kasebut disimpen ing memori supaya ora perlu diakses liwat sambungan TLS menyang Server Vault ing mangsa ngarep. Sabanjure, ayo goleki informasi apa sing ana ing toko kunci.
Informasi kunci ngemot ing ngisor iki:
- kunci id - pengenal kunci, contone:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - jinis tombol - jinis tombol adhedhasar algoritma enkripsi digunakake, nilai bisa: "AES", "RSA" utawa "DSA".
- dawa tombol - dawa tombol ing bita, AES: 16, 24 utawa 32, RSA 128, 256, 512 lan DSA 128, 256 utawa 384.
- user - sing duwe kunci. Yen tombol iku sistem, contone, Master Key, banjur kolom iki kosong. Yen kunci digawe nggunakake keyring_udf, banjur kolom iki ngenali pemilik kunci kasebut.
- tombol dhewe
Tombol kasebut diidentifikasi kanthi unik dening pasangan: key_id, pangguna.
Ana uga beda ing nyimpen lan mbusak tombol.
Panyimpenan file luwih cepet. Sampeyan bisa uga mikir yen toko kunci mung nulis kunci file sapisan, nanging ora, ana liyane sing kedadeyan ing kene. Kapan modifikasi panyimpenan file digawe, salinan serep kabeh isi pisanan digawe. Ayo dadi ngomong file disebut my_biggest_secrets, banjur salinan serep bakal my_biggest_secrets.backup. Sabanjure, cache diganti (tombol ditambahake utawa dibusak) lan, yen kabeh sukses, cache direset menyang file. Ing kasus sing jarang, kayata kegagalan server, sampeyan bisa ndeleng file serep iki. File serep bakal dibusak ing wektu sabanjure tombol dimuat (biasane sawise server diwiwiti maneh).
Nalika nyimpen utawa mbusak kunci ing panyimpenan server, panyimpenan kudu nyambung menyang server MySQL kanthi printah "ngirim tombol" / "nyuwun pambusakan kunci".
Ayo bali menyang kacepetan wiwitan server. Saliyane kasunyatan manawa kacepetan peluncuran dipengaruhi dening kubah kasebut, uga ana masalah babagan pirang-pirang kunci saka kubah sing kudu dijupuk nalika wiwitan. Mesthine, iki penting banget kanggo panyimpenan server. Nalika wiwitan, server mriksa kunci sing dibutuhake kanggo tabel / ruang meja sing dienkripsi lan njaluk kunci saka panyimpenan. Ing server "resik" kanthi enkripsi Master Key, kudu ana siji Master Key, sing kudu dijupuk saka panyimpenan. Nanging, jumlah kunci sing luwih akeh bisa uga dibutuhake, contone, nalika server serep mulihake serep saka server utama. Ing kasus kasebut, rotasi Master Key kudu diwenehake. Iki bakal dibahas kanthi luwih rinci ing artikel sing bakal teka, sanajan ing kene aku pengin nyathet manawa server sing nggunakake macem-macem Master Keys bisa uga butuh wektu luwih suwe kanggo miwiti, utamane nalika nggunakake toko kunci sisih server.
Saiki ayo ngomong luwih akeh babagan keyring_file. Nalika aku ngembangake keyring_file, aku uga prihatin babagan carane mriksa owah-owahan keyring_file nalika server mlaku. Ing 5.7, mriksa ditindakake adhedhasar statistik file, sing dudu solusi sing cocog, lan ing 8.0 diganti karo checksum SHA256.
Nalika sapisanan mbukak keyring_file, statistik file lan checksum diwilang, kang eling dening server, lan owah-owahan mung ditrapake yen padha cocog. Nalika file diganti, checksum dianyari.
Kita wis ngrampungake akeh pitakonan babagan kubah kunci. Nanging, ana topik penting liyane sing asring dilalekake utawa disalahake: nuduhake kunci ing server.
Maksudku opo? Saben server (contone, Percona Server) ing kluster kudu duwe lokasi sing kapisah ing Vault Server ing ngendi Percona Server kudu nyimpen kunci. Saben Master Key sing disimpen ing panyimpenan ngemot GUID saka Percona Server ing pengenal. Apa sebabe penting? Mbayangno sing duwe mung siji Vault Server lan kabeh Percona Server ing kluster nggunakake Vault Server siji. Masalah katon jelas. Yen kabeh Server Percona nggunakake Master Key tanpa pengenal unik, kayata id = 1, id = 2, lan sapiturute, kabeh server ing kluster bakal nggunakake Master Key sing padha. Apa sing diwenehake GUID yaiku bedane antarane server. Napa banjur ngomong babagan nuduhake kunci ing antarane server yen GUID unik wis ana? Ana plugin liyane - keyring_udf. Kanthi plugin iki, pangguna server sampeyan bisa nyimpen kunci ing server Vault. Masalah kasebut kedadeyan nalika pangguna nggawe kunci ing server1, umpamane, banjur nyoba nggawe kunci kanthi ID sing padha ing server2, contone:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 Π·Π½Π°ΡΠΈΡ ΡΡΠΏΠ΅ΡΠ½ΠΎΠ΅ Π·Π°Π²Π΅ΡΡΠ΅Π½ΠΈΠ΅
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Ngenteni. Loro-lorone server nggunakake Server Vault sing padha, apa fungsi keyring_key_store ora kudu gagal ing server2? Apike, yen sampeyan nyoba nindakake sing padha ing siji server, sampeyan bakal entuk kesalahan:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Bener, ROB_1 wis ana.
Ayo padha ngrembug conto kapindho pisanan. Kaya sing wis dingerteni sadurunge, keyring_vault utawa plugin keyring liyane nyimpen kabeh ID kunci ing memori. Dadi, sawise nggawe kunci anyar, ROB_1 ditambahake menyang server1, lan saliyane ngirim kunci iki menyang Vault, kunci kasebut uga ditambahake ing cache. Saiki, nalika kita nyoba kanggo nambah tombol padha kaping pindho, keyring_vault mriksa apa tombol ana ing cache lan mbalang kesalahan.
Ing kasus pisanan, kahanan beda. Server1 lan server2 duwe cache sing kapisah. Sawise nambahake ROB_1 menyang cache tombol ing server1 lan server Vault, cache tombol ing server2 ora sinkron. Ora ana tombol ROB_2 ing cache ing server1. Mangkono, tombol ROB_1 ditulis ing keyring_key_store lan kanggo server Vault, kang bener nimpa (!) Nilai sadurungΓ©. Saiki tombol ROB_1 ing server Vault yaiku 543210987654321. Apike, server Vault ora ngalangi tumindak kasebut lan gampang nimpa nilai lawas.
Saiki kita bisa ndeleng kenapa partisi server ing Vault bisa dadi penting - nalika sampeyan nggunakake keyring_udf lan pengin nyimpen kunci ing Vault. Carane entuk pamisahan iki ing server Vault?
Ana rong cara kanggo partisi menyang Vault. Sampeyan bisa nggawe titik gunung beda kanggo saben server, utawa nggunakake dalan beda ing titik gunung padha. Iki paling apik digambarake karo conto. Dadi ayo goleki titik mount individu dhisik:
--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 = (...)Ing kene sampeyan bisa ndeleng manawa server1 lan server2 nggunakake titik gunung sing beda. Nalika misahake path, konfigurasi bakal katon kaya iki:
--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 = (...)Ing kasus iki, loro server nggunakake titik gunung padha "mount_point", nanging dalan beda. Nalika sampeyan nggawe rahasia pisanan ing server1 nggunakake dalan iki, server Vault kanthi otomatis nggawe direktori "server1". Kanggo server2 kabeh padha. Nalika sampeyan mbusak rahasia pungkasan ing mount_point/server1 utawa mount_point/server2, server Vault uga mbusak direktori kasebut. Yen sampeyan nggunakake pemisahan jalur, sampeyan kudu nggawe mung siji titik gunung lan ngganti file konfigurasi supaya server nggunakake jalur sing kapisah. Titik gunung bisa digawe nggunakake panjalukan HTTP. Nggunakake CURL iki bisa ditindakake kaya mangkene:
curl -L -H "X-Vault-Token: TOKEN" βcacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTKabeh kolom (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) cocog karo paramèter file konfigurasi. Mesthi, sampeyan bisa nggunakake keperluan Vault kanggo nindakake sing padha. Nanging luwih gampang ngotomatisasi nggawe titik gunung. Muga-muga informasi iki migunani lan kita bakal ketemu sampeyan ing artikel sabanjure ing seri iki.
Waca liyane:
Source: www.habr.com