Kursga yangi ro'yxatga olish boshlanishini kutish bilan Biz siz uchun foydali maqolaning tarjimasini tayyorladik.
Shaffof ma'lumotlarni shifrlash (TDE) paydo bo'ldi va MySQL ancha vaqtdan beri. Ammo uning kaput ostida qanday ishlashi va TDE serveringizga qanday ta'sir qilishi haqida hech o'ylab ko'rganmisiz? Ushbu maqolalar turkumida biz TDE qanday ishlashini ko'rib chiqamiz. Kalitni saqlashdan boshlaylik, chunki bu har qanday shifrlashning ishlashi uchun talab qilinadi. Keyin MySQL/MySQL uchun Percona Serverda shifrlash qanday ishlashini va MySQL uchun Percona Server qanday qoβshimcha funksiyalarga ega ekanligini batafsil koβrib chiqamiz.
MySQL kalitlari
Keyring - serverga mahalliy fayldagi (keyring_file) yoki uzoq serverdagi (masalan, HashiCorp Vault) kalitlarni so'rash, yaratish va o'chirish imkonini beruvchi plaginlar. Kalitlarni qidirishni tezlashtirish uchun har doim mahalliy keshda saqlanadi.
Plaginlarni ikki toifaga bo'lish mumkin:
- Mahalliy saqlash. Masalan, mahalliy fayl (biz buni faylga asoslangan kalitlar deb ataymiz).
- Masofaviy saqlash. Masalan, Vault Server (biz buni serverga asoslangan kalitlar deb ataymiz).
Bu ajratish juda muhim, chunki turli xil saqlash turlari faqat kalitlarni saqlash va olishda emas, balki ularni ishga tushirishda ham biroz boshqacha harakat qiladi.
Fayl xotirasidan foydalanganda, ishga tushirilganda, xotiraning butun tarkibi keshga yuklanadi: kalit identifikatori, asosiy foydalanuvchi, kalit turi va kalitning o'zi.
Serverga asoslangan do'konda (masalan, Vault Server) ishga tushirilganda faqat kalit identifikatori va asosiy foydalanuvchi yuklanadi, shuning uchun barcha kalitlarni olish ishga tushirishni sekinlashtirmaydi. Kalitlar dangasalik bilan yuklanadi. Ya'ni, kalitning o'zi Vault'dan faqat kerak bo'lganda yuklanadi. Yuklab olingandan so'ng, kalit xotirada keshlanadi, shunda kelajakda unga Vault serveriga TLS ulanishlari orqali kirish kerak bo'lmaydi. Keyinchalik, kalit do'konida qanday ma'lumotlar mavjudligini ko'rib chiqaylik.
Asosiy ma'lumotlar quyidagilarni o'z ichiga oladi:
- kalit identifikatori β kalit identifikatori, masalan:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - kalit turi β ishlatiladigan shifrlash algoritmiga asoslangan kalit turi, mumkin bo'lgan qiymatlar: "AES", "RSA" yoki "DSA".
- kalit uzunligi β baytdagi kalit uzunligi, AES: 16, 24 yoki 32, RSA 128, 256, 512 va DSA 128, 256 yoki 384.
- foydalanuvchi - kalit egasi. Agar kalit tizim bo'lsa, masalan, Master Key, bu maydon bo'sh. Agar kalit keyring_udf yordamida yaratilsa, bu maydon kalit egasini aniqlaydi.
- kalitning o'zi
Kalit juftlik tomonidan noyob tarzda aniqlanadi: key_id, user.
Kalitlarni saqlash va o'chirishda ham farqlar mavjud.
Faylni saqlash tezroq. Siz kalit do'koni shunchaki faylga kalitni bir marta yozadi deb o'ylashingiz mumkin, lekin yo'q, bu erda yana ko'p narsa bor. Har safar fayl xotirasi o'zgartirilsa, avval barcha tarkibning zaxira nusxasi yaratiladi. Aytaylik, fayl my_biggest_secrets deb ataladi, keyin zaxira nusxasi my_biggest_secrets.backup bo'ladi. Keyinchalik, kesh o'zgartiriladi (kalitlar qo'shiladi yoki o'chiriladi) va agar hamma narsa muvaffaqiyatli bo'lsa, kesh faylga qaytariladi. Kamdan-kam hollarda, masalan, server xatosi, siz ushbu zaxira faylini ko'rishingiz mumkin. Zaxira fayli keyingi safar kalitlar yuklanganda o'chiriladi (odatda server qayta ishga tushirilgandan keyin).
Server xotirasida kalitni saqlash yoki o'chirishda xotira MySQL serveriga "kalitni yuborish" / "kalitni o'chirishni so'rash" buyruqlari bilan ulanishi kerak.
Keling, serverni ishga tushirish tezligiga qaytaylik. Ishga tushirish tezligiga omborning o'zi ta'sir qilishiga qo'shimcha ravishda, ishga tushirish vaqtida ombordan qancha kalitni olish kerakligi masalasi ham mavjud. Albatta, bu serverni saqlash uchun ayniqsa muhimdir. Ishga tushganda server shifrlangan jadvallar/jadvallar uchun qaysi kalit zarurligini tekshiradi va kalitni saqlashdan so'raydi. Asosiy kalit shifrlangan "toza" serverda bitta asosiy kalit bo'lishi kerak, uni saqlashdan olish kerak. Biroq, masalan, zaxira server asosiy serverdan zaxira nusxasini tiklayotganda, ko'proq kalitlar talab qilinishi mumkin. Bunday hollarda asosiy kalitning aylanishi ta'minlanishi kerak. Bu haqda keyingi maqolalarda batafsil yoritiladi, ammo bu yerda shuni ta'kidlashni istardimki, bir nechta asosiy kalitlardan foydalanadigan server ishga tushishi biroz ko'proq vaqt talab qilishi mumkin, ayniqsa server tomonidagi kalitlar do'konidan foydalanilganda.
Endi keyring_file haqida bir oz ko'proq gaplashamiz. Keyring_file-ni ishlab chiqayotganimda, server ishlayotgan vaqtda keyring_file o'zgarishlarini qanday tekshirish haqida ham tashvishlanardim. 5.7 da tekshirish fayl statistikasi asosida amalga oshirildi, bu ideal yechim emas edi va 8.0 da u SHA256 nazorat summasi bilan almashtirildi.
keyring_file-ni birinchi marta ishga tushirganingizda, fayl statistikasi va nazorat summasi hisoblab chiqiladi, ular server tomonidan eslab qolinadi va o'zgarishlar faqat mos keladigan bo'lsa qo'llaniladi. Fayl o'zgarganda nazorat summasi yangilanadi.
Biz allaqachon kalit omborlar haqidagi ko'plab savollarni ko'rib chiqdik. Biroq, ko'pincha unutilgan yoki noto'g'ri tushuniladigan yana bir muhim mavzu bor: serverlar bo'ylab kalitlarni almashish.
Nima demoqchiman? Klasterdagi har bir server (masalan, Percona Server) Percona Server o'z kalitlarini saqlashi kerak bo'lgan Vault Serverda alohida joyga ega bo'lishi kerak. Saqlashda saqlangan har bir asosiy kalit o'z identifikatorida Percona Server GUID-ni o'z ichiga oladi. Nima uchun bu muhim? Tasavvur qiling-a, sizda faqat bitta Vault Server bor va klasterdagi barcha Percona serverlari bitta Vault Serverdan foydalanadi. Muammo aniq ko'rinadi. Agar barcha Percona serverlari id = 1, id = 2 va hokazo kabi noyob identifikatorlarsiz Asosiy kalitdan foydalangan bo'lsa, klasterdagi barcha serverlar bir xil asosiy kalitdan foydalanadilar. GUID serverlar orasidagi farqni taqdim etadi. Agar noyob GUID allaqachon mavjud bo'lsa, nima uchun serverlar o'rtasida kalitlarni almashish haqida gapirish kerak? Yana bir plagin mavjud - keyring_udf. Ushbu plagin yordamida sizning server foydalanuvchingiz o'z kalitlarini Vault serverida saqlashi mumkin. Muammo, masalan, foydalanuvchi server1da kalit yaratganda va keyin server2da bir xil identifikatorga ega kalit yaratishga harakat qilganda yuzaga keladi, masalan:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 Π·Π½Π°ΡΠΈΡ ΡΡΠΏΠ΅ΡΠ½ΠΎΠ΅ Π·Π°Π²Π΅ΡΡΠ΅Π½ΠΈΠ΅
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Kutmoq. Ikkala server ham bir xil Vault serveridan foydalanmoqda, server2 da keyring_key_store funksiyasi ishlamay qolmasligi kerakmi? Qizig'i shundaki, agar siz bitta serverda xuddi shunday qilishga harakat qilsangiz, siz xatoga duch kelasiz:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0ToΚ»gΚ»ri, ROB_1 allaqachon mavjud.
Avval ikkinchi misolni muhokama qilaylik. Yuqorida aytib o'tganimizdek, keyring_vault yoki boshqa kalit plaginlari xotiradagi barcha kalit identifikatorlarini keshlaydi. Shunday qilib, yangi kalit yaratilgandan so'ng, ROB_1 server1ga qo'shiladi va bu kalitni Vault-ga yuborishdan tashqari, kalit keshga ham qo'shiladi. Endi, xuddi shu kalitni ikkinchi marta qo'shishga harakat qilganimizda, keyring_vault kalit keshda mavjudligini tekshiradi va xatoga yo'l qo'yadi.
Birinchi holda, vaziyat boshqacha. Server1 va server2 alohida keshlarga ega. ROB_1-ni server1 va Vault serveridagi kalit keshiga qo'shgandan so'ng, server2-dagi kalit kesh sinxronlashtirilmagan. Server2 keshida ROB_1 kaliti yo'q. Shunday qilib, ROB_1 kaliti keyring_key_store va Vault serveriga yoziladi, u aslida oldingi qiymatni (!) ustiga yozadi. Endi Vault serveridagi ROB_1 kaliti 543210987654321. Qizig'i shundaki, Vault serveri bunday harakatlarni bloklamaydi va eski qiymatni osongina qayta yozadi.
Endi biz Keyring_udf-dan foydalanayotganingizda va kalitlarni Vault-da saqlamoqchi bo'lsangiz, Vault-da server bo'linishi nima uchun muhim bo'lishi mumkinligini bilib olamiz. Vault serverida bu ajratishga qanday erishish mumkin?
Vault-ga bo'linishning ikki yo'li mavjud. Har bir server uchun turli xil ulanish nuqtalarini yaratishingiz yoki bir xil o'rnatish nuqtasi ichida turli yo'llardan foydalanishingiz mumkin. Bu eng yaxshi misollar bilan tasvirlangan. Shunday qilib, avval alohida o'rnatish nuqtalarini ko'rib chiqaylik:
--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 = (...)Bu yerda server1 va server2 turli ulanish nuqtalaridan foydalanayotganini ko'rishingiz mumkin. Yo'llarni bo'lishda konfiguratsiya quyidagicha ko'rinadi:
--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 = (...)Bunday holda, ikkala server ham bir xil o'rnatish nuqtasi "mount_point" dan foydalanadi, ammo turli yo'llar. Ushbu yo'ldan foydalanib server1 da birinchi sirni yaratganingizda, Vault serveri avtomatik ravishda "server1" katalogini yaratadi. Server2 uchun hamma narsa o'xshash. mount_point/server1 yoki mount_point/server2-dagi oxirgi sirni o'chirsangiz, Vault serveri ushbu kataloglarni ham o'chiradi. Agar siz yo'l ajratishdan foydalansangiz, faqat bitta o'rnatish nuqtasini yaratishingiz va serverlar alohida yo'llardan foydalanishi uchun konfiguratsiya fayllarini o'zgartirishingiz kerak. O'rnatish nuqtasi HTTP so'rovi yordamida yaratilishi mumkin. CURL yordamida buni quyidagicha amalga oshirish mumkin:
curl -L -H "X-Vault-Token: TOKEN" βcacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTBarcha maydonlar (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) konfiguratsiya fayli parametrlariga mos keladi. Albatta, xuddi shunday qilish uchun Vault yordam dasturlaridan foydalanishingiz mumkin. Ammo o'rnatish nuqtasini yaratishni avtomatlashtirish osonroq. Umid qilamanki, siz ushbu ma'lumotni foydali deb topasiz va biz sizni ushbu seriyadagi keyingi maqolalarda ko'ramiz.
Ko'proq o'qish:
Manba: www.habr.com