Kursga yangi ro'yxatga olish boshlanishini kutish bilan biz MySQL-da shifrlash haqida bir qator maqolalarni nashr etishda davom etamiz.
Ushbu turkumdagi oldingi maqolada () biz kalit do'konlar haqida gaplashdik. Ushbu maqolada biz asosiy kalitdan qanday foydalanishni ko'rib chiqamiz va konvertni shifrlashning afzalliklari va kamchiliklarini muhokama qilamiz.
Konvertni shifrlash g'oyasi shundan iboratki, shifrlash uchun ishlatiladigan kalitlar (jadval maydoni kalitlari) boshqa kalit (bosh kalit) bilan shifrlangan. Tablespace kalitlari aslida ma'lumotlarni shifrlash uchun ishlatiladi. Grafik jihatdan buni quyidagicha ifodalash mumkin:
Asosiy kalit kalitlar do'konida, jadval maydoni kalitlari esa shifrlangan jadval maydonlarining sarlavhalarida (jadval maydonining 0-betida).
Yuqoridagi rasmda:
A jadvali 1-kalit (1-kalit) bilan shifrlangan. 1-kalit asosiy kalit yordamida shifrlanadi va A jadvalining sarlavhasida shifrlangan holda saqlanadi.
B jadvali 2-kalit bilan shifrlangan (2-kalit). 2-kalit masker kaliti yordamida shifrlanadi va B jadvalining sarlavhasida shifrlangan holda saqlanadi.
Va shunga o'xshash.
Server A jadvalining shifrini ochishi kerak bo'lganda, u do'kondan asosiy kalitni oladi, A jadvalining sarlavhasidan shifrlangan kalit 1ni o'qiydi va 1-kalit shifrini ochadi. Shifrlangan kalit 1 server xotirasida keshlanadi va A jadvalining shifrini ochish uchun ishlatiladi. .
InnoDB
InnoDB da haqiqiy shifrlash va shifrni ochish I/U darajasida amalga oshiriladi. Ya'ni, sahifa diskka o'tkazilishidan oldin shifrlanadi va diskdan o'qilgandan so'ng darhol shifrlanadi.
InnoDB da shifrlash faqat jadval maydoni darajasida ishlaydi. Va sukut bo'yicha barcha jadvallar alohida jadval maydonlarida yaratilgan (). Boshqacha qilib aytganda, faqat bitta jadvalni o'z ichiga olishi mumkin bo'lgan jadval maydoni yaratiladi. Siz asosiy jadval maydonida ham jadvallar yaratishingiz mumkin (). Lekin har qanday holatda ham, jadval har doim qandaydir jadval maydonida bo'ladi. Va shifrlash jadval maydoni darajasida amalga oshirilganligi sababli, u to'liq shifrlangan yoki shifrlanmagan. Ya'ni, siz asosiy jadval maydonidagi jadvallarning faqat bir qismini shifrlay olmaysiz.
Agar biron sababga ko'ra sizda har bir jadval uchun fayl o'chirilgan bo'lsa, barcha jadvallar tizim jadval maydonida yaratiladi. IN innodb o'zgaruvchisi yordamida tizim jadval maydonini shifrlashingiz mumkintizimstol maydonishifrlash yoki shifrlash iplarini ishlatish, lekin bu hali ham eksperimental xususiyatdir. MySQL-da bu yo'q.
Davom etishdan oldin biz asosiy kalit identifikatorining tuzilishini ko'rib chiqishimiz kerak. U UUID, KEY dan iboratID va "INNODBKey" prefiksi. Bu shunday ko'rinadi: INNODBKey-UUID-KEYID.
UUID - shifrlangan jadval maydoniga ega serverning uuidi. kalitID - bu tobora ortib borayotgan qiymat. Birinchi marta asosiy kalit KEY ni yaratganingizdaID 1. Kalitni aylantirish vaqtida, yangi asosiy kalit yaratilganda, KEYID = 2 va boshqalar. Asosiy kalitlarni aylantirish haqida biz ushbu turkumning keyingi maqolalarida ko'proq gaplashamiz.
Endi biz asosiy kalit identifikatori qanday ko'rinishini bilganimizdan so'ng, shifrlangan jadval maydonining sarlavhasini ko'rib chiqamiz. Jadval maydoni shifrlanganda, shifrlash ma'lumotlari sarlavhaga qo'shiladi. Bu shunday ko'rinadi:
KEYID - KEYBiz allaqachon muhokama qilgan asosiy kalit identifikatoridan olingan identifikator. UUID serverning uuidi hisoblanadi va asosiy kalit identifikatorida ham ishlatiladi. TABLESPACE KEY - server tomonidan tasodifiy hosil qilingan 256 bitdan iborat jadval maydoni kaliti. Initsializatsiya vektori (IV, ishga tushirish vektori) ham tasodifiy yaratilgan 256 bitdan iborat (garchi u 128 bit bo'lishi kerak). IV AES shifrlash va dekodlashni ishga tushirish uchun ishlatiladi (256 bitdan faqat 128 tasi ishlatiladi). Oxirida TABLESPACE KEY va IV uchun CRC32 nazorat summasi mavjud.
Bu vaqt davomida men sarlavhada shifrlangan jadval maydoni kaliti borligini aytib, biroz soddalashtirdim. Aslida, jadval maydoni kaliti va ishga tushirish vektori asosiy kalit yordamida birga saqlanadi va shifrlanadi. Esda tutingki, jadval maydoni kaliti va ishga tushirish vektori shifrlanishidan oldin ular uchun CRC32 hisoblab chiqiladi.
Nima uchun CRC32 kerak?
Xulosa qilib aytganda, asosiy kalitning haqiqiyligini tekshirish uchun. Jadval maydoni kaliti va ishga tushirish vektori shifrlangandan so'ng nazorat summasi hisoblanadi va sarlavhada saqlangan CRC32 bilan solishtiriladi. Agar nazorat summalari mos kelsa, bizda to'g'ri asosiy kalit va jadval maydoni kaliti mavjud. Aks holda, jadval maydoni etishmayotgan deb belgilanadi (biz uni haligacha parolini hal qila olmaymiz).
Siz so'rashingiz mumkin: kalitlarni tekshirish qaysi nuqtada amalga oshiriladi? Javob server ishga tushganda. Shifrlangan jadvallar/jadval maydonlari bo'lgan server ishga tushirilganda UUID, KEY ni o'qiydiSarlavhadagi identifikator va asosiy kalit identifikatorini yaratadi. Shundan so'ng u kalitlardan kerakli asosiy kalitni oladi, jadval maydoni kalitini parolini ochadi va nazorat summasini tekshiradi. Yana bir bor, agar nazorat summasi mos keladigan bo'lsa, unda hamma narsa tartibda, yo'q - jadval maydoni etishmayotgan deb belgilangan.
Agar siz ushbu turkumdagi oxirgi maqolani o'qisangiz (), keyin, ehtimol esda tutingki, server kalitlari do'konidan foydalanganda, server ishga tushirilganda faqat kalit identifikatorlari ro'yxatini oladi, aniqrog'i, kalit identifikatori va foydalanuvchi identifikatori, chunki bu juftlik kalitni noyob tarzda aniqlaydi. Men hozir aytmoqchi bo'lgan narsa shundaki, server ishga tushganda, jadval maydoni kalitlari shifrini ochish mumkinligini tekshirish uchun barcha kalitlarni oladi. Xo'sh, nima uchun ishga tushirilganda, serverni saqlash holatida faqat kalit yuklanadiid va foydalanuvchiid va barcha kalitlar emasmi? Chunki sizga barcha kalitlar kerak bo'lmasligi mumkin. Bu, asosan, asosiy kalitning aylanishi bilan bog'liq. Kassada asosiy kalit aylantirilganda, yangi asosiy kalit yaratiladi, lekin eski kalitlar o'chirilmaydi. Shunday qilib, server kalit do'konida serverga kerak bo'lmagan va shuning uchun server ishga tushganda olinmaydigan ko'plab kalitlarga ega bo'lishingiz mumkin.
Asosiy kalit yordamida shifrlashning afzalliklari va kamchiliklari haqida bir oz gapirish vaqti keldi. Eng katta afzallik shundaki, sizga faqat bitta shifrlash kaliti (bosh kalit) kerak bo'ladi, u shifrlangan ma'lumotlaringizdan alohida saqlanadi. Bu serverni tez ishga tushirish va saqlashni kichik qiladi, bu esa boshqarishni osonlashtiradi. Va shuningdek, yagona asosiy kalitni qayta tiklash oson.
Biroq, asosiy kalitni shifrlashning bitta katta kamchiligi bor: jadval maydoni tablespace_key bilan shifrlangandan so'ng, u har doim bir xil kalit bilan shifrlangan bo'lib qoladi. Asosiy kalitni aylantirish bu erda yordam bermaydi. Nima uchun bu kamchilik? Bilamizki, MySQL-da uning ishdan chiqishiga va asosiy faylni yaratishiga olib keladigan xatolar bor. Asosiy fayl server xotirasi dumpini o'z ichiga olganligi sababli, dumpda shifrlangan jadval maydoni kaliti bo'lishi mumkin. Bundan ham yomoni, shifrlangan jadval maydoni kalitlari xotirada saqlanadi, ularni diskka almashtirish mumkin. Aytish mumkinki, bu kamchilik emas, chunki ushbu fayllarga va almashtirish bo'limiga kirish uchun sizga root ruxsatnomalari kerak. Ha. Ammo ildiz faqat bir muddat kerak bo'ladi. Kimdir shifrlangan jadval maydoni kalitiga kirish huquqiga ega bo'lgandan so'ng, u ildizdan foydalanmasdan ham ma'lumotlarni shifrlash uchun foydalanishda davom etishi mumkin. Bundan tashqari, diskni o'g'irlash mumkin va uchinchi tomon vositalari yordamida almashtirish / asosiy fayllarni o'qish mumkin. TDE ning maqsadi disk o'g'irlangan taqdirda ham uni o'qib bo'lmaydigan qilishdir. IN yangi yaratilgan kalitlar bilan jadval maydonini qayta shifrlash mumkin. Bu xususiyat shifrlash iplari deb ataladi va bu yozish paytida hali ham eksperimental hisoblanadi.
Ko'proq o'qish:
Manba: www.habr.com
