ການເຂົ້າລະຫັດໃນ MySQL: ການໃຊ້ Master Key

ໃນຄວາມຄາດຫວັງຂອງການເລີ່ມຕົ້ນຂອງການລົງທະບຽນໃຫມ່ສໍາລັບຫຼັກສູດ "ຖານຂໍ້ມູນ" ພວກເຮົາສືບຕໍ່ເຜີຍແຜ່ຊຸດຂອງບົດຄວາມກ່ຽວກັບການເຂົ້າລະຫັດໃນ MySQL.

ໃນບົດຄວາມທີ່ຜ່ານມາໃນຊຸດນີ້ (ການເຂົ້າລະຫັດໃນ MySQL: Keystore) ພວກ​ເຮົາ​ໄດ້​ເວົ້າ​ລົມ​ກ່ຽວ​ກັບ keystores​. ໃນບົດຄວາມນີ້, ພວກເຮົາຈະເບິ່ງວິທີການນໍາໃຊ້ລະຫັດຕົ້ນສະບັບແລະປຶກສາຫາລືຂໍ້ດີແລະຂໍ້ເສຍຂອງການເຂົ້າລະຫັດ envelope. 

ແນວຄວາມຄິດທີ່ຢູ່ເບື້ອງຫລັງການເຂົ້າລະຫັດ envelope ແມ່ນວ່າກະແຈທີ່ໃຊ້ສໍາລັບການເຂົ້າລະຫັດ (ກະແຈຕາຕະລາງ) ຖືກເຂົ້າລະຫັດດ້ວຍກະແຈອື່ນ (ລະຫັດຫຼັກ). ຕົວຈິງແລ້ວກະແຈຊ່ອງຫວ່າງຖືກໃຊ້ເພື່ອເຂົ້າລະຫັດຂໍ້ມູນ. ໃນກາຟິກ, ນີ້ສາມາດຖືກສະແດງດັ່ງຕໍ່ໄປນີ້:

ລະຫັດຫຼັກແມ່ນຢູ່ໃນບ່ອນເກັບຂໍ້ມູນ, ແລະກະແຈຕາຕະລາງຢູ່ໃນສ່ວນຫົວຂອງຕາຕະລາງທີ່ເຂົ້າລະຫັດໄວ້ (ຢູ່ໜ້າ 0 ຂອງພື້ນທີ່ຕາຕະລາງ). 

ໃນຮູບຂ້າງເທິງ:

• ຕາຕະລາງ A ຖືກເຂົ້າລະຫັດດ້ວຍລະຫັດ 1 (ຄີ 1). ລະຫັດ 1 ຖືກເຂົ້າລະຫັດໂດຍໃຊ້ລະຫັດຫຼັກ ແລະຖືກເກັບໄວ້ໃນສ່ວນຫົວຂອງຕາຕະລາງ A.

• ຕາຕະລາງ B ຖືກເຂົ້າລະຫັດດ້ວຍລະຫັດ 2 (ຄີ 2). ລະຫັດ 2 ຖືກເຂົ້າລະຫັດໂດຍໃຊ້ລະຫັດ masker ແລະຖືກເກັບໄວ້ໃນສ່ວນຫົວຂອງຕາຕະລາງ B.

• ແລະອື່ນໆ.

ເມື່ອເຄື່ອງແມ່ຂ່າຍຕ້ອງການຖອດລະຫັດຕາຕະລາງ A, ມັນໄດ້ຮັບລະຫັດຫຼັກຈາກຮ້ານ, ອ່ານລະຫັດທີ່ເຂົ້າລະຫັດ 1 ຈາກສ່ວນຫົວຂອງຕາຕະລາງ A, ແລະຖອດລະຫັດລະຫັດ 1. ລະຫັດທີ່ຖອດລະຫັດ 1 ຖືກເກັບໄວ້ໃນຫນ່ວຍຄວາມຈໍາຂອງເຄື່ອງແມ່ຂ່າຍແລະໃຊ້ເພື່ອຖອດລະຫັດຕາຕະລາງ A. .

InnoDB

ໃນ InnoDB, ການເຂົ້າລະຫັດແລະການຖອດລະຫັດຕົວຈິງແມ່ນເຮັດຢູ່ໃນລະດັບ I/O. ນັ້ນແມ່ນ, ຫນ້າເວັບໄດ້ຖືກເຂົ້າລະຫັດກ່ອນທີ່ມັນຈະ flushed ກັບ disk ແລະ decrypted ທັນທີຫຼັງຈາກການອ່ານຈາກ disk.

ໃນ InnoDB, ການເຂົ້າລະຫັດພຽງແຕ່ເຮັດວຽກຢູ່ໃນລະດັບຕາຕະລາງ. ແລະໂດຍຄ່າເລີ່ມຕົ້ນຕາຕະລາງທັງຫມົດແມ່ນຖືກສ້າງຂຶ້ນໃນຕາຕະລາງແຍກຕ່າງຫາກ (file-per-table tablespace). ໃນຄໍາສັບຕ່າງໆອື່ນໆ, tablespace ໄດ້ຖືກສ້າງຂື້ນທີ່ສາມາດບັນຈຸພຽງແຕ່ຫນຶ່ງຕາຕະລາງ. ເຖິງແມ່ນວ່າທ່ານສາມາດສ້າງຕາຕະລາງຢູ່ໃນຕາຕະລາງຕົ້ນຕໍເຊັ່ນດຽວກັນ (ພື້ນທີ່ໂຕະທົ່ວໄປ). ແຕ່ໃນກໍລະນີໃດກໍ່ຕາມ, ຕາຕະລາງແມ່ນສະເຫມີຢູ່ໃນບາງຕາຕະລາງ. ແລະນັບຕັ້ງແຕ່ການເຂົ້າລະຫັດຖືກເຮັດຢູ່ໃນລະດັບຕາຕະລາງ, ມັນຖືກເຂົ້າລະຫັດຢ່າງເຕັມສ່ວນຫຼືບໍ່. ນັ້ນແມ່ນ, ທ່ານບໍ່ສາມາດເຂົ້າລະຫັດພຽງແຕ່ສ່ວນຫນຶ່ງຂອງຕາຕະລາງໃນພື້ນທີ່ຕາຕະລາງຕົ້ນຕໍ. 

ຖ້າສໍາລັບເຫດຜົນບາງຢ່າງທີ່ທ່ານປິດການໃຊ້ງານໄຟລ໌ຕໍ່ຕາຕາລາງ, ຫຼັງຈາກນັ້ນຕາຕະລາງທັງຫມົດແມ່ນຖືກສ້າງຂຶ້ນພາຍໃນຕາຕະລາງລະບົບ. IN ເຊີບເວີ Percona ສໍາລັບ MySQL ທ່ານສາມາດເຂົ້າລະຫັດຕາຕະລາງຂອງລະບົບໂດຍໃຊ້ຕົວແປ innodbsysໂຕະເຂົ້າລະຫັດຫຼືໃຊ້ຫົວຂໍ້ການເຂົ້າລະຫັດ, ແຕ່ນີ້ຍັງເປັນລັກສະນະທົດລອງ. MySQL ບໍ່ມີອັນນີ້.

ກ່ອນທີ່ຈະກ້າວຕໍ່ໄປ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ພິຈາລະນາໂຄງສ້າງຂອງລະຫັດຕົ້ນສະບັບ. ມັນປະກອບດ້ວຍ UUID, KEYID ແລະຄໍານໍາຫນ້າ "INNODBKey". ມັນເບິ່ງຄືວ່າ: INODBKey-UUID-KEYບັດປະ ຈຳ ຕົວ.

UUID ແມ່ນ uuid ຂອງເຊີບເວີທີ່ມີຕາຕະລາງທີ່ຖືກເຂົ້າລະຫັດ. ກະແຈID ແມ່ນພຽງແຕ່ມູນຄ່າທີ່ເພີ່ມຂຶ້ນຢ່າງຕໍ່ເນື່ອງ. ເມື່ອທ່ານສ້າງຫຼັກຫຼັກ KEY ທໍາອິດID ແມ່ນ 1. ໃນ​ລະ​ຫວ່າງ​ການ​ຫມຸນ​ຂອງ​ກະ​ແຈ​, ໃນ​ເວ​ລາ​ທີ່​ລະ​ຫັດ​ແມ່​ບົດ​ໃຫມ່​ໄດ້​ຖືກ​ສ້າງ​ຕັ້ງ​ຂື້ນ​, KEY​ID = 2 ແລະອື່ນໆ. ພວກເຮົາຈະເວົ້າເພີ່ມເຕີມກ່ຽວກັບການຫມຸນລະຫັດຫຼັກໃນບົດຄວາມຕໍ່ມາໃນຊຸດນີ້.

ຕອນນີ້ພວກເຮົາຮູ້ວ່າຕົວລະບຸລະຫັດຫຼັກມີລັກສະນະແນວໃດ, ໃຫ້ເບິ່ງສ່ວນຫົວຂອງຕາຕະລາງທີ່ຖືກເຂົ້າລະຫັດ. ເມື່ອພື້ນທີ່ຕາຕະລາງຖືກເຂົ້າລະຫັດ, ຂໍ້ມູນການເຂົ້າລະຫັດຈະຖືກເພີ່ມໃສ່ສ່ວນຫົວ. ມັນເບິ່ງຄືວ່ານີ້:

KEYID ແມ່ນ KEYID ຈາກລະຫັດຫຼັກຫຼັກທີ່ພວກເຮົາໄດ້ສົນທະນາແລ້ວ. UUID ແມ່ນ uuid ຂອງເຊີບເວີ ແລະຍັງຖືກໃຊ້ໃນຕົວລະບຸຫຼັກຫຼັກ. TABLESPACE KEY - ປຸ່ມຊ່ອງຕາຕະລາງ, ເຊິ່ງປະກອບດ້ວຍ 256 ບິດ, ສ້າງຂຶ້ນໂດຍເຊີບເວີ. vector ການເລີ່ມຕົ້ນ (IV, vector ການເລີ່ມຕົ້ນ) ຍັງປະກອບດ້ວຍ 256 bits ທີ່ສ້າງຂຶ້ນແບບສຸ່ມ (ເຖິງແມ່ນວ່າມັນຄວນຈະເປັນ 128 bits). IV ຖືກນໍາໃຊ້ເພື່ອເລີ່ມຕົ້ນການເຂົ້າລະຫັດແລະຖອດລະຫັດ AES (ອອກຈາກ 256 bits, ພຽງແຕ່ 128 ຖືກນໍາໃຊ້). ໃນຕອນທ້າຍມີການກວດສອບ CRC32 ສໍາລັບ TABLESPACE KEY ແລະ IV.

ຕະຫຼອດເວລານີ້ຂ້າພະເຈົ້າໄດ້ເຮັດໃຫ້ງ່າຍເລັກນ້ອຍໂດຍການບອກວ່າມີລະຫັດຕາຕະລາງທີ່ຖືກເຂົ້າລະຫັດຢູ່ໃນສ່ວນຫົວ. ໃນຄວາມເປັນຈິງ, ກະແຈ tablespace ແລະ vector ການເລີ່ມຕົ້ນແມ່ນຖືກເກັບຮັກສາແລະເຂົ້າລະຫັດຮ່ວມກັນໂດຍໃຊ້ລະຫັດຫຼັກ. ຈົ່ງຈື່ໄວ້ວ່າກ່ອນທີ່ກະແຈ tablespace ແລະ vector ການເລີ່ມຕົ້ນຈະຖືກເຂົ້າລະຫັດ, CRC32 ຈະຖືກຄິດໄລ່ສໍາລັບພວກມັນ.

ເປັນຫຍັງ CRC32 ຈຶ່ງຕ້ອງການ?

ໂດຍຫຍໍ້, ເພື່ອໃຫ້ແນ່ໃຈວ່າກະແຈຫຼັກຖືກຕ້ອງ. ຫຼັງຈາກການຖອດລະຫັດລະຫັດ tablespace ແລະ vector ການເລີ່ມຕົ້ນ, checksum ໄດ້ຖືກຄິດໄລ່ແລະປຽບທຽບກັບ CRC32 ທີ່ເກັບໄວ້ໃນ header. ຖ້າ checksums ກົງກັນ, ພວກເຮົາມີລະຫັດຫຼັກທີ່ຖືກຕ້ອງແລະລະຫັດຕາຕະລາງ. ຖ້າບໍ່ດັ່ງນັ້ນ, ພື້ນທີ່ຕາຕະລາງຈະຖືກໝາຍວ່າຂາດ (ພວກເຮົາຍັງບໍ່ສາມາດຖອດລະຫັດມັນໄດ້).

ເຈົ້າອາດຈະຖາມວ່າ: ການກວດສອບກະແຈທີ່ເຮັດຢູ່ຈຸດໃດ? ຄໍາຕອບແມ່ນເວລາທີ່ເຄື່ອງແມ່ຂ່າຍເລີ່ມຕົ້ນ. ເຊີບເວີທີ່ມີຕາຕະລາງ / tablespaces ທີ່ເຂົ້າລະຫັດອ່ານ UUID, KEY ໃນຕອນເລີ່ມຕົ້ນID ຈາກສ່ວນຫົວ ແລະສ້າງລະຫັດຫຼັກ. ຫຼັງຈາກນັ້ນ, ມັນໄດ້ຮັບລະຫັດຫຼັກທີ່ຕ້ອງການຈາກກະແຈ, ຖອດລະຫັດລະຫັດຕາຕະລາງ, ແລະກວດສອບ checksum. ອີກເທື່ອຫນຶ່ງ, ຖ້າ checksum ກົງກັນ, ຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງແມ່ນຢູ່ໃນຄໍາສັ່ງ, ບໍ່ - tablespace ຖືກຫມາຍວ່າຫາຍໄປ.

ຖ້າທ່ານອ່ານບົດຄວາມສຸດທ້າຍໃນຊຸດນີ້ (ການເຂົ້າລະຫັດໃນ MySQL: Keystore), ຫຼັງຈາກນັ້ນບາງທີອາດຈື່ໄວ້ວ່າໃນເວລາທີ່ການນໍາໃຊ້ເກັບຮັກສາລະຫັດເຊີຟເວີ, ເຄື່ອງແມ່ຂ່າຍພຽງແຕ່ໄດ້ຮັບບັນຊີລາຍຊື່ຂອງຕົວກໍານົດທີ່ສໍາຄັນໃນຕອນເລີ່ມຕົ້ນ, ຊັດເຈນກວ່າ, ລະຫັດລະຫັດແລະ ID ຜູ້ໃຊ້, ນັບຕັ້ງແຕ່ຄູ່ນີ້ກໍານົດລະຫັດເປັນເອກະລັກ. ສິ່ງທີ່ຂ້ອຍເວົ້າຕອນນີ້ແມ່ນວ່າເຄື່ອງແມ່ຂ່າຍ, ໃນຕອນເລີ່ມຕົ້ນ, ໄດ້ຮັບກະແຈທັງຫມົດທີ່ມັນຕ້ອງການເພື່ອກວດເບິ່ງວ່າກະແຈຕາຕະລາງສາມາດຖືກຖອດລະຫັດໄດ້. ດັ່ງນັ້ນ, ເປັນຫຍັງ, ເມື່ອເລີ່ມຕົ້ນ, ໃນກໍລະນີຂອງການເກັບຮັກສາເຊີຟເວີ, ມີພຽງແຕ່ລະຫັດທີ່ຖືກໂຫລດid ແລະຜູ້ໃຊ້id ແລະບໍ່ແມ່ນກະແຈທັງໝົດບໍ? ເພາະວ່າເຈົ້າອາດຈະບໍ່ຕ້ອງການກະແຈທັງໝົດ. ອັນນີ້ສ່ວນໃຫຍ່ແມ່ນຍ້ອນການຫມຸນຂອງກະແຈຫຼັກ. ເມື່ອລະຫັດຫຼັກຖືກໝຸນຢູ່ໃນຫ້ອງໂຖງ, ລະບົບຈະສ້າງລະຫັດຫຼັກໃໝ່, ແຕ່ກະແຈເກົ່າບໍ່ໄດ້ຖືກລຶບຖິ້ມ. ດັ່ງນັ້ນ, ທ່ານອາດຈະມີກະແຈຫຼາຍອັນໃນ keystore ຂອງເຄື່ອງແມ່ຂ່າຍທີ່ບໍ່ຈໍາເປັນໂດຍເຄື່ອງແມ່ຂ່າຍແລະດັ່ງນັ້ນຈິ່ງບໍ່ໄດ້ດຶງຄືນເມື່ອເຄື່ອງແມ່ຂ່າຍເລີ່ມຕົ້ນ.

ມັນເປັນເວລາທີ່ຈະເວົ້າເລັກນ້ອຍກ່ຽວກັບຂໍ້ດີແລະຂໍ້ເສຍຂອງການເຂົ້າລະຫັດໂດຍໃຊ້ລະຫັດຫຼັກ. ປະໂຫຍດທີ່ໃຫຍ່ທີ່ສຸດແມ່ນທ່ານຕ້ອງການລະຫັດການເຂົ້າລະຫັດອັນດຽວ (ລະຫັດຫຼັກ), ເຊິ່ງຈະຖືກເກັບໄວ້ແຍກຕ່າງຫາກຈາກຂໍ້ມູນທີ່ເຂົ້າລະຫັດຂອງທ່ານ. ນີ້ເຮັດໃຫ້ການເລີ່ມຕົ້ນຂອງເຄື່ອງແມ່ຂ່າຍໄວແລະການເກັບຮັກສາຂະຫນາດນ້ອຍ, ເຮັດໃຫ້ມັນງ່າຍຕໍ່ການຈັດການ. ແລະ​ຍັງ​ພຽງ​ແຕ່​ຕົ້ນ​ສະ​ບັບ​ທີ່​ງ່າຍ​ທີ່​ຈະ​ຟື້ນ​ຟູ​.

ແນວໃດກໍ່ຕາມ, ການເຂົ້າລະຫັດຫຼັກຫຼັກມີຂໍ້ເສຍອັນໃຫຍ່ອັນໜຶ່ງ: ເມື່ອພື້ນທີ່ຕາຕະລາງຖືກເຂົ້າລະຫັດດ້ວຍ tablespace_key, ມັນຍັງຄົງຖືກເຂົ້າລະຫັດດ້ວຍລະຫັດດຽວກັນສະເໝີ. ການໝຸນຂອງຫຼັກຫຼັກບໍ່ໄດ້ຊ່ວຍຢູ່ທີ່ນີ້. ເປັນຫຍັງອັນນີ້ຈຶ່ງເປັນຂໍ້ເສຍ? ພວກເຮົາຮູ້ວ່າ MySQL ມີຂໍ້ບົກຜ່ອງທີ່ສາມາດເຮັດໃຫ້ມັນຂັດຂ້ອງແລະສ້າງໄຟລ໌ຫຼັກ. ເນື່ອງຈາກໄຟລ໌ຫຼັກປະກອບດ້ວຍການ dump ຫນ່ວຍຄວາມຈໍາຂອງເຄື່ອງແມ່ຂ່າຍ, ມັນສາມາດເກີດຂຶ້ນໄດ້ທີ່ dump ມີລະຫັດຕາຕະລາງ decrypted. ຮ້າຍແຮງໄປກວ່ານັ້ນ, ກະແຈ tablespace ທີ່ຖືກຖອດລະຫັດຖືກເກັບໄວ້ໃນຫນ່ວຍຄວາມຈໍາ, ເຊິ່ງສາມາດແລກປ່ຽນກັບແຜ່ນ. ທ່ານ​ສາ​ມາດ​ບອກ​ໄດ້​ວ່າ​ນີ້​ບໍ່​ແມ່ນ​ຂໍ້​ເສຍ​ເນື່ອງ​ຈາກ​ວ່າ​ທ່ານ​ຕ້ອງ​ການ​ການ​ອະ​ນຸ​ຍາດ​ຮາກ​ໃນ​ການ​ເຂົ້າ​ເຖິງ​ໄຟລ​໌​ເຫຼົ່າ​ນີ້​ແລະ swap partition​. ແມ່ນແລ້ວ. ແຕ່ຮາກແມ່ນຕ້ອງການພຽງແຕ່ສໍາລັບໃນຂະນະທີ່. ເມື່ອໃຜຜູ້ຫນຶ່ງສາມາດເຂົ້າເຖິງກະແຈຕາຕະລາງ decrypted, ລາວສາມາດສືບຕໍ່ໃຊ້ມັນເພື່ອຖອດລະຫັດຂໍ້ມູນ, ເຖິງແມ່ນວ່າບໍ່ມີການເຂົ້າເຖິງຮາກ. ນອກຈາກນັ້ນ, ແຜ່ນສາມາດຖືກລັກ, ແລະໄຟລ໌ swap / core ສາມາດອ່ານໄດ້ໂດຍໃຊ້ເຄື່ອງມືຂອງພາກສ່ວນທີສາມ. ເປົ້າຫມາຍຂອງ TDE ແມ່ນເພື່ອເຮັດໃຫ້ມັນບໍ່ສາມາດອ່ານໄດ້ເຖິງແມ່ນວ່າ disk ຈະຖືກລັກ. IN ເຊີບເວີ Percona ສໍາລັບ MySQL ມັນເປັນໄປໄດ້ທີ່ຈະເຂົ້າລະຫັດພື້ນທີ່ຕາຕະລາງຄືນໃໝ່ດ້ວຍກະແຈທີ່ສ້າງຂຶ້ນໃໝ່. ຄຸນນະສົມບັດນີ້ເອີ້ນວ່າຫົວຂໍ້ການເຂົ້າລະຫັດແລະຍັງທົດລອງຢູ່ໃນເວລາຂອງການຂຽນນີ້.

ຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບຫຼັກສູດ

ອ່ານ​ຕື່ມ:

• ການເຂົ້າລະຫັດໃນ MySQL: Keystore

ແຫຼ່ງຂໍ້ມູນ: www.habr.com