ກົດໝາຍ PDPA ຂອງປະເທດໄທ (Personal Data Protection Act B.E. 2562 / 2019) ຮຽກຮ້ອງໃຫ້ຜູ້ປະມວນຜົນຂໍ້ມູນສ່ວນບຸກຄົນມີ "ມາດຕະການປ້ອງກັນທາງດ້ານເຕັກນິກທີ່ເໝາະສົມ", ແຕ່ບໍ່ໄດ້ລະບຸວິທີການເຂົ້າລະຫັດແບບສະເພາະເຈາະຈົງ. AES-256 ເປັນການເຂົ້າລະຫັດແບບສົມມາດ (Symmetric Encryption) ທີ່ໄດ້ຮັບການຮັບຮອງໂດຍລັດຖະບານກາງສະຫະລັດ, FIPS 197 ແລະ ISO/IEC 18033-3, ເຊິ່ງຖືກນຳໃຊ້ຢ່າງກວ້າງຂວາງໃນຖານະເປັນພື້ນຖານຂອງ "ມາດຕະການທີ່ເໝາະສົມ" ໃນທາງປະຕິບັດ. ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອໃຫ້ຂໍ້ມູນແກ່ພະນັກງານໄອທີ ແລະ ນັກພັດທະນາທີ່ດຳເນີນງານດ້ານຜະລິດຕະພັນ AI ໃນບໍລິສັດທ້ອງຖິ່ນທີ່ປະເທດໄທ, ໂດຍຈະສະຫຼຸບຮູບແບບການນຳໃຊ້ AES-256 ເພື່ອໃຫ້ສອດຄ່ອງກັບ PDPA ຢ່າງຄົບວົງຈອນ ຕັ້ງແຕ່ການເລືອກຂໍ້ມູນທີ່ຈະເຂົ້າລະຫັດ, ການຈັດການກຸນແຈ (Key Management) ໄປຈົນເຖິງການກວດສອບ (Audit). ສ່ວນລາຍການກວດສອບ (Checklist) ສຳລັບການປະຕິບັດຕາມ PDPA ຂອງໄທໃນພາບລວມ (ການຂໍຄວາມຍິນຍອມ, ການແຕ່ງຕັ້ງ DPO, ການໂອນຂໍ້ມູນຂ້າມຊາຍແດນ ແລະ ອື່ນໆ) ຈະຖືກກ່າວເຖິງໃນບົດຄວາມອື່ນ, ໂດຍບົດຄວາມນີ້ຈະເນັ້ນສະເພາະໃນສ່ວນຂອງການຈັດຕັ້ງປະຕິບັດທາງດ້ານເຕັກນິກເທົ່ານັ້ນ.

ພາຍໃຕ້ PDPA ຂອງໄທ, ຜູ້ຄວບຄຸມຂໍ້ມູນສ່ວນບຸກຄົນຈຳເປັນຕ້ອງມີມາດຕະການປ້ອງກັນດ້ານເຕັກນິກ ແລະ ການຈັດຕັ້ງທີ່ເໝາະສົມ ເພື່ອປ້ອງກັນການຮົ່ວໄຫຼ, ການເຂົ້າເຖິງ, ການນຳໃຊ້, ການແກ້ໄຂ ຫຼື ການເປີດຕົວ ຫຼື Launch ຂໍ້ມູນສ່ວນບຸກຄົນໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ. ເນື່ອງຈາກບໍ່ມີການລະບຸລະບົບການເຂົ້າລະຫັດ (Encryption algorithm) ທີ່ສະເພາະເຈາະຈົງໄວ້ໃນຕົວບົດກົດໝາຍ, ການນຳໃຊ້ AES-256 ຈຶ່ງຖືເປັນທາງເລືອກທີ່ເໝາະສົມໃນທາງປະຕິບັດ.

ເມື່ອອ່ານຕົວບົດກົດໝາຍ PDPA ຈະພົບເຫັນຂໍ້ຄວາມທີ່ມີລັກສະນະນາມມະທຳຫຼາຍ ເຮັດໃຫ້ຍາກທີ່ຈະຕັດສິນໄດ້ວ່າ "ຕ້ອງປະຕິບັດແນວໃດຈຶ່ງຈະຜ່ານມາດຕະຖານ". ໃນພາກນີ້, ພວກເຮົາຈະມາຈັດລະບຽບກ່ຽວກັບຂໍ້ກຳນົດຂອງ PDPA, ບົດບາດຂອງ AES-256, ແລະ ການແບ່ງໜ້າທີ່ກັບບົດຄວາມກວດສອບຄວາມສອດຄ່ອງຂອງ PDPA ທີ່ມີຢູ່ແລ້ວ.

ມາດຕາ 37(1) ຂອງ PDPA ໄທ ກຳນົດໃຫ້ຜູ້ຄວບຄຸມຂໍ້ມູນ (Data Controller) ຕ້ອງ "ດຳເນີນມາດຕະການຮັກສາຄວາມປອດໄພທາງດ້ານເຕັກນິກ ແລະ ດ້ານການຈັດຕັ້ງທີ່ເໝາະສົມ ເພື່ອປ້ອງກັນການສູນເສຍ, ການເຂົ້າເຖິງໂດຍບໍ່ໄດ້ຮັບອະນຸຍາດ, ການນຳໃຊ້, ການດັດແກ້ ຫຼື ການເປີດຕົວ ຫຼື Launch ຂໍ້ມູນສ່ວນບຸກຄົນ". ໂຄງສ້າງຂອງມາດຕານີ້ແມ່ນຄ້າຍຄືກັນກັບມາດຕາ 32 ຂອງ GDPR ຂອງ EU ເກືອບທັງໝົດ, ແລະ ນັບຕັ້ງແຕ່ມີການບັງຄັບໃຊ້ຢ່າງເຕັມຮູບແບບ, ຄຳແນະນຳທີ່ອອກໂດຍ PDPC (Personal Data Protection Committee) ຂອງໄທ ກໍໄດ້ລະບຸໃຫ້ການເຂົ້າລະຫັດ (Encryption), ການປິດບັງຊື່ (Pseudonymization) ແລະ ການຄວບຄຸມການເຂົ້າເຖິງ ເປັນ "ມາດຕະການທີ່ຄາດຫວັງ" ໄວ້ເຊັ່ນກັນ.

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

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

ໃນທາງປະຕິບັດ, "ມາດຕະການປົກປ້ອງທາງດ້ານເຕັກນິກທີ່ເໝາະສົມ" ໝາຍເຖິງຫຍັງນັ້ນ ແມ່ນຂຶ້ນຢູ່ກັບມາດຕະຖານຂອງອຸດສາຫະກຳ. ໂດຍທົ່ວໄປແລ້ວ ຈະມີການອ້າງອີງເຖິງມາດຕະຖານສາກົນ ເຊັ່ນ: ISO/IEC 27001, ISO/IEC 29100 ຫຼື ການຄວບຄຸມຕາມ NIST SP 800-53, ເຊິ່ງ AES-256 ໄດ້ຖືກຈັດໃຫ້ເປັນອັນກໍລິດ (Algorithm) ທີ່ໄດ້ຮັບການແນະນຳໃນມາດຕະຖານເຫຼົ່ານີ້ທັງໝົດ.

ການນຳໃຊ້ AES-256 ເປັນ "ມາດຕະການທີ່ເໝາະສົມ" ແມ່ນມີພື້ນຖານມາຈາກການຮັບຮອງຂອງໜ່ວຍງານສາທາລະນະຫຼາຍແຫ່ງ. ເນື່ອງຈາກ AES-256 ໄດ້ຮັບການມາດຕະຖານໂດຍ FIPS 197 ຂອງ NIST ແລະ ຍັງຖືກນຳໃຊ້ໃນ CNSA Suite ຂອງ NSA ເປັນອັນກໍລິດທີ່ໃຊ້ສຳລັບການປົກປ້ອງຂໍ້ມູນລະດັບ Top Secret, ຈຶ່ງເຮັດໃຫ້ການນຳໄປໃຊ້ງານຈິງມີຄວາມສະດວກ. ເຖິງຢ່າງໃດກໍຕາມ, ຄວາມເໝາະສົມໃນການກວດສອບ PDPA ຈຳເປັນຕ້ອງໄດ້ອະທິບາຍຢ່າງຮອບດ້ານ ເຊິ່ງລວມເຖິງຮູບແບບໄພຄຸກຄາມ, ການຈັດການກະແຈ, ການຄວບຄຸມການເຂົ້າເຖິງ ແລະ ຫຼັກຖານການກວດສອບ. AES ເປັນການເຂົ້າລະຫັດແບບ Symmetric Block ທີ່ໄດ້ມາດຕະຖານໂດຍ NIST FIPS 197 ແລະ ຍັງຖືກອ້າງອີງຢ່າງກວ້າງຂວາງໃນມາດຕະຖານສາກົນ. ໃນກໍລະນີທີ່ລະບຸຊື່ມາດຕະຖານ, ຄວນກວດສອບສະບັບຂອງມາດຕະຖານ ແລະ ຕຳແໜ່ງທີ່ເປັນທາງການກ່ອນນຳມາລະບຸ.

Cloud KMS ແລະ TLS 1.3 ເປັນກົນໄກທີ່ມີປະໂຫຍດໃນການສະໜັບສະໜູນການດຳເນີນງານດ້ານການເຂົ້າລະຫັດມາດຕະຖານໃນປັດຈຸບັນ. ເຖິງຢ່າງໃດກໍຕາມ, ເນື່ອງຈາກ Cipher Suite ຂອງ TLS 1.3 ແລະ ການຕັ້ງຄ່າເລີ່ມຕົ້ນຂອງແຕ່ລະ Cloud KMS ມີຄວາມແຕກຕ່າງກັນໄປຕາມແຕ່ລະບໍລິການ, ຈຶ່ງຈຳເປັນຕ້ອງກວດສອບ ມາດຕະຖານ ຫຼື Specification ລ່າສຸດຂອງແຕ່ລະ Vendor ເມື່ອເລືອກນຳໃຊ້. ເຖິງແມ່ນວ່າ PDPC ຂອງໄທຈະບໍ່ໄດ້ອອກແນວທາງປະຕິບັດສະເພາະສຳລັບ AES-256, ແຕ່ຖ້າມີຄວາມສອດຄ່ອງກັບມາດຕະຖານສາກົນ ກໍຈະສາມາດອະທິບາຍຕໍ່ການກວດສອບວ່າເປັນ "ການຕັດສິນໃຈທີ່ສົມເຫດສົມຜົນ" ໄດ້ງ່າຍຂຶ້ນ.

ໃນທາງກົງກັນຂ້າມ, ຖ້າຫາກນຳໃຊ້ການເຂົ້າລະຫັດແບບເກົ່າທີ່ບໍ່ແມ່ນ AES (ເຊັ່ນ: DES, 3DES, RC4) ຫຼື ການເຂົ້າລະຫັດທີ່ພັດທະນາຂຶ້ນເອງພາຍໃນບໍລິສັດ, ຈະເຮັດໃຫ້ອຸປະສັກໃນການພິສູດ "ຄວາມເໝາະສົມ" ໃນການກວດສອບເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ຂໍ້ໄດ້ປຽບທາງປະຕິບັດທີ່ໃຫຍ່ທີ່ສຸດຂອງການເລືອກໃຊ້ AES-256 ຄື "ຄວາມຈຳເປັນໃນການອະທິບາຍເຫດຜົນໃນການເລືອກໃຊ້ຈະຫຼຸດໜ້ອຍລົງເຫຼືອໜ້ອຍທີ່ສຸດ".

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

ບົດຄວາມນີ້ຈະເນັ້ນສະເພາະດ້ານການຈັດຕັ້ງປະຕິບັດທາງເຕັກນິກທີ່ບໍ່ໄດ້ກ່າວເຖິງໃນບົດຄວາມກ່ອນໜ້ານີ້, ໂດຍສະເພາະແມ່ນການເຂົ້າລະຫັດ ແລະ ການຈັດການກະແຈ. ບົດຄວາມທັງສອງຖືກອອກແບບມາໃຫ້ໃຊ້ຄູ່ກັນ, ໂດຍແນະນຳໃຫ້ທີມພັດທະນາເລີ່ມຈາກການຈັດຕັ້ງໂຄງສ້າງອົງກອນຜ່ານບົດຄວາມລາຍການກວດສອບ (Checklist) ກ່ອນ, ແລ້ວຈຶ່ງນຳເອົາບົດຄວາມນີ້ມາໃຊ້ໃນຖານະເປັນແນວທາງສຳລັບການຈັດຕັ້ງປະຕິບັດ "ມາດຕະການປົກປ້ອງທາງເຕັກນິກ" ທີ່ຍັງຄົງຄ້າງຢູ່.

ຂັ້ນຕອນການອ່ານທີ່ແນະນຳມີດັ່ງນີ້: ໃນໄລຍະເລີ່ມຕົ້ນຂອງໂຄງການຮັບມືກັບ PDPA, ໃຫ້ອ້າງອີງຈາກບົດຄວາມລາຍການກວດສອບເພື່ອຈັດຕັ້ງ DPO ແລະ ຮ່າງສັນຍາໃຫ້ຮຽບຮ້ອຍ. ຫຼັງຈາກນັ້ນ, ເມື່ອທີມພັດທະນາເຂົ້າສູ່ຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດການເຂົ້າລະຫັດຕົວຈິງ ຈຶ່ງກັບມາອ່ານບົດຄວາມນີ້. ເມື່ອການຈັດຕັ້ງປະຕິບັດທາງເຕັກນິກສຳເລັດລົງໃນລະດັບໜຶ່ງແລ້ວ, ການກັບໄປກວດສອບຄວາມຕໍ່ເນື່ອງຂອງການດຳເນີນງານໃນອົງກອນຜ່ານບົດຄວາມລາຍການກວດສອບອີກຄັ້ງ ຖືເປັນວິທີການທີ່ເໝາະສົມໃນທາງປະຕິບັດ.

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

ຄວາມເຂົ້າໃຈຜິດທີ່ວ່າ "ພຽງແຕ່ສົ່ງຂໍ້ມູນຜ່ານ API ໄປຫາ LLM ພາຍນອກ ເລີຍບໍ່ຈຳເປັນຕ້ອງເຂົ້າລະຫັດໃນຖານຂໍ້ມູນຂອງບໍລິສັດ" ແມ່ນຮູບແບບການລະເມີດ PDPA ທີ່ພົບເຫັນໄດ້ທົ່ວໄປ. ຕໍ່ໄປນີ້ຈະເປັນການຈັດລະບຽບ 4 ຊັ້ນສະເພາະຂອງ AI ໂດຍແບ່ງອອກເປັນ 2 ຫົວຂໍ້ H3 ຕາມຄຸນລັກສະນະຂອງຂໍ້ມູນ.

ໃນລະບົບ AI, ຜູ້ໃຊ້ມັກຈະປ້ອນຂໍ້ມູນສ່ວນຕົວເຂົ້າໄປໃນ Prompt ໂດຍບໍ່ຮູ້ຕົວ. ການປ້ອນຂໍ້ມູນເຊັ່ນ: "ຂ້ອຍຊື່ 〇〇, ເດືອນແລ້ວນີ້ຜົນກວດສຸຂະພາບອອກມາວ່າ △△, ຂໍ້ມູນນີ້ຄວນຕີຄວາມໝາຍແນວໃດ?" ແມ່ນເກີດຂຶ້ນເປັນປະຈຳໃນການໃຊ້ງານ AI. ຖ້າຫາກ Prompt ຖືກບັນທຶກໄວ້ໃນຖານຂໍ້ມູນແບບ Plain text, ຖານຂໍ້ມູນນັ້ນທັງໝົດຈະຕົກຢູ່ພາຍໃຕ້ການຄວບຄຸມຂອງ PDPA.

ໃນຝັ່ງຂອງການຕອບໂຕ້ກໍມີຄວາມເປັນໄປໄດ້ທີ່ຈະສະແດງຂໍ້ມູນສ່ວນຕົວອອກມາເຊັ່ນກັນ. ໃນກໍລະນີທີ່ໃຊ້ RAG (Retrieval-Augmented Generation), ລະບົບຈະສົ່ງຂໍ້ມູນຈາກເອກະສານພາຍໃນ (ການປະເມີນຜົນງານ, ລາຍຊື່ລູກຄ້າ, ບັນທຶກທາງການແພດ ແລະ ອື່ນໆ) ກັບຄືນມາເປັນຜົນການຄົ້ນຫາ, ເຮັດໃຫ້ຂໍ້ຄວາມທີ່ຕອບໂຕ້ອອກມາອາດມີຂໍ້ມູນສ່ວນຕົວລວມຢູ່. ຖ້າຫາກເກັບຮັກສາການຕອບໂຕ້ນັ້ນໄວ້ເປັນປະຫວັດການສົນທະນາ, ສະຖານທີ່ເກັບຮັກສາດັ່ງກ່າວກໍຈະຕ້ອງຖືກເຂົ້າລະຫັດເຊັ່ນກັນ.

ສິ່ງທີ່ມັກຈະຖືກມອງຂ້າມຄືໄຟລ໌ Log. ໃນຫຼາຍກໍລະນີ, ມັກຈະມີການສົ່ງອອກ Prompt ແລະ ການຕອບໂຕ້ໄປຍັງ Log ແບບ Plain text ເພື່ອຈຸດປະສົງໃນການ Debug ແລະ ເກັບຮັກສາໄວ້ເປັນເວລາຫຼາຍເດືອນຫາຫຼາຍປີ. Log ມັກຈະ "ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ໂດຍທີ່ບໍ່ຮູ້ຕົວ ແລະ ນະໂຍບາຍການລຶບຂໍ້ມູນກໍບໍ່ຊັດເຈນ", ເຊິ່ງກາຍເປັນຊ່ອງທາງການຮົ່ວໄຫຼທີ່ພົບເຫັນໄດ້ເລື້ອຍໆເມື່ອເກີດການລະເມີດ PDPA. ຄວນມີການເຂົ້າລະຫັດ Log ຕາມລະດັບຄວາມອ່ອນໄຫວຂອງຂໍ້ມູນ, ກຳນົດນະໂຍບາຍໄລຍະເວລາການເກັບຮັກສາ, ແລະ ລຶບຂໍ້ມູນທີ່ບໍ່ຈຳເປັນອອກຢ່າງເໝາະສົມ. ໄລຍະເວລາການເກັບຮັກສາຈຳເປັນຕ້ອງໄດ້ກຳນົດໃຫ້ສອດຄ່ອງກັບຄວາມຕ້ອງການທາງທຸລະກິດ ແລະ ພັນທະທາງກົດໝາຍໃນການເກັບຮັກສາຂໍ້ມູນ.

ຂໍ້ມູນ Vector Embedding ທີ່ຖືກບັນທຶກໄວ້ໃນ Vector Database (ເຊັ່ນ: Pinecone, Supabase pgvector, Chroma) ມີຄວາມສ່ຽງທີ່ອາດຈະຖືກຄາດເດົາເນື້ອຫາຕົ້ນສະບັບບາງສ່ວນໄດ້, ດັ່ງນັ້ນຫາກມີຂໍ້ມູນທີ່ມີຄວາມລະອຽດອ່ອນ ຈຶ່ງຈຳເປັນຕ້ອງອອກແບບວິທີການຈັດເກັບຢ່າງລະມັດລະວັງ. ຄວນພິຈາລະນາເຖິງ ການແລກປ່ຽນ ຫຼື Trade-off ກັບຄວາມຕ້ອງການໃນການຄົ້ນຫາ, ໂດຍແນະນຳໃຫ້ໃຊ້ການເຂົ້າລະຫັດ, ການຄວບຄຸມການເຂົ້າເຖິງ ແລະ ການຈັດການໄລຍະເວລາໃນການຈັດເກັບຂໍ້ມູນຮ່ວມກັນ.

ປະຫວັດການສົນທະນາ (Chat history) ມີໄລຍະເວລາໃນການຈັດເກັບທີ່ແຕກຕ່າງກັນໄປຕາມແຕ່ລະຜະລິດຕະພັນ ເຊິ່ງມີຕັ້ງແຕ່ສອງສາມຊົ່ວໂມງໄປຈົນເຖິງຫຼາຍປີ, ແຕ່ເພື່ອໃຫ້ສອດຄ່ອງກັບຂໍ້ກຳນົດດ້ານໄລຍະເວລາການຈັດເກັບຂອງ PDPA (ລຶບຂໍ້ມູນຫຼັງຈາກບັນລຸຈຸດປະສົງແລ້ວ), ຈຶ່ງຈຳເປັນຕ້ອງມີການອອກແບບທີ່ຮອງຮັບທັງການເຂົ້າລະຫັດ ແລະ ນະໂຍບາຍການລຶບຂໍ້ມູນ. ຮູບແບບມາດຕະຖານທີ່ນິຍົມໃຊ້ຄື: ການໃຊ້ pgcrypto extension ສຳລັບ Postgres, InnoDB TDE ສຳລັບ MySQL, ຫຼື ການໃຊ້ທາງເລືອກໃນການເຊື່ອມຕໍ່ກັບ KMS ສຳລັບ NoSQL.

ຂໍ້ມູນສຳລັບການຮຽນຮູ້ (Corpus ສຳລັບ Fine-tuning, ເອກະສານສຳລັບ RAG) ແມ່ນເປົ້າໝາຍທີ່ມີຄວາມສ່ຽງສູງທີ່ສຸດ ເນື່ອງຈາກມັກຈະມີຂໍ້ມູນທາງທຸລະກິດຈຳນວນຫຼາຍ. ຂໍ້ມູນການຮຽນຮູ້ຄວນຖືກອອກແບບໃຫ້ "ຖອດລະຫັດສະເພາະໃນເວລາປະມວນຜົນເທົ່ານັ້ນ" ແລະ ຈັດເກັບໃນສະຖານະທີ່ຖືກເຂົ້າລະຫັດໄວ້ໃນເວລາປົກກະຕິ. ໃນກໍລະນີທີ່ມີການຖອດລະຫັດໃນລະຫວ່າງການປະມວນຜົນວຽກ (Job) ການຮຽນຮູ້ເທິງ Cloud, ຄວນກວດສອບລວມເຖິງການທຳຄວາມສະອາດຫຼັງຈາກຈົບວຽກນັ້ນໆ ເພື່ອໃຫ້ແນ່ໃຈວ່າບໍ່ມີຂໍ້ມູນຕົກຄ້າງຢູ່ໃນພື້ນທີ່ຊົ່ວຄາວ (/tmp).

AES-256 ບໍ່ໄດ້ປອດໄພພຽງແຕ່ການ "ເລືອກຊື່ Algorithm" ເທົ່ານັ້ນ. ຄວາມລັບ ແລະ ຄວາມຄົບຖ້ວນຂອງຂໍ້ມູນຈະຖືກຮັບປະກັນກໍຕໍ່ເມື່ອມີການປະສົມປະສານ 3 ອົງປະກອບ ຄື: Mode, Initial Vector (IV), ແລະ Authentication Tag ຢ່າງຖືກຕ້ອງ. ຄວາມຜິດພາດໃນການເລືອກລະຫວ່າງການປະຕິບັດງານ (Implementation) ຈະສົ່ງຜົນໃຫ້ຜົນລັອກທີ່ໄດ້ຮັບບໍ່ຕ່າງຫຍັງກັບຂໍ້ຄວາມທຳມະດາ (Plaintext) ເຖິງວ່າຈະໃຊ້ AES-256 ກໍຕາມ.

ໃນການປະຕິບັດງານຕົວຈິງ, ການເລືອກລະຫວ່າງ GCM ແລະ CBC, ລວມເຖິງຄວາມສອດຄ່ອງໃນລະຫວ່າງການສົ່ງຂໍ້ມູນ ແລະ ການຈັດເກັບຂໍ້ມູນ ແມ່ນສິ່ງທີ່ຖືກຖາມຫາເລື້ອຍໆທີ່ສຸດ. ຫົວຂໍ້ H3 ທັງ 2 ຫົວຂໍ້ຕໍ່ໄປນີ້ຈະເປັນການຈັດລະບຽບແຕ່ລະສ່ວນໃຫ້ຊັດເຈນ.

AES ມີການກຳນົດໂໝດການເຂົ້າລະຫັດແບບບລັອກໄວ້ຫຼາຍຮູບແບບ, ແຕ່ສຳລັບການນຳໃຊ້ໃໝ່ ໂດຍຫຼັກການແລ້ວຄວນເລືອກໃຊ້ໂໝດ AEAD ເຊັ່ນ GCM. ຂຶ້ນກັບສະພາບແວດລ້ອມ, ວິທີການ AEAD ອື່ນໆອາດຈະເໝາະສົມກວ່າ, ດັ່ງນັ້ນຄວນເລືອກໂດຍພິຈາລະນາຈາກຄວາມຕ້ອງການດ້ານປະສິດທິພາບ ແລະ ຄວາມເຂົ້າກັນໄດ້ກັບຊັບສິນທີ່ມີຢູ່. GCM ເປັນວິທີການແບບ AEAD (Authenticated Encryption with Associated Data) ເຊິ່ງຈະສ້າງແທັກການຢືນຢັນຕົວຕົນໄປພ້ອມກັບການເຂົ້າລະຫັດ. ດ້ວຍເຫດນີ້, ຖ້າຫາກຂໍ້ຄວາມທີ່ຖືກເຂົ້າລະຫັດຖືກດັດແກ້, ມັນຈະສາມາດກວດພົບໄດ້ໃນຂັ້ນຕອນການຖອດລະຫັດ.

ໂໝດ CBC (Cipher Block Chaining) ໄດ້ຖືກນຳໃຊ້ຢ່າງກວ້າງຂວາງໃນປະຫວັດສາດ, ແຕ່ເນື່ອງຈາກບໍ່ມີຟັງຊັນການຢືນຢັນຕົວຕົນ, ມັນຈຶ່ງບໍ່ສາມາດກວດພົບການດັດແກ້ໄດ້ເວັ້ນເສຍແຕ່ຈະເພີ່ມ HMAC ເຂົ້າໄປຕ່າງຫາກ. ການໃຊ້ GCM ມີໂອກາດທີ່ຈະເກີດຂໍ້ຜິດພາດໃນການນຳໃຊ້ໜ້ອຍກວ່າການສ້າງລະບົບ CBC + HMAC ດ້ວຍຕົນເອງ. ເວັ້ນເສຍແຕ່ມີຄວາມຈຳເປັນຕ້ອງຮັກສາຄວາມເຂົ້າກັນໄດ້ກັບລະບົບ Legacy ທີ່ມີຢູ່, ເຫດຜົນທີ່ຈະເລືອກໃຊ້ CBC ໃນການນຳໃຊ້ໃໝ່ນັ້ນມີໜ້ອຍຫຼາຍ.

ກັບດັກທີ່ໃຫຍ່ທີ່ສຸດໃນການໃຊ້ GCM ຄືການນຳ IV (Initial Vector, nonce) ກັບມາໃຊ້ຊ້ຳ. ຖ້າຫາກນຳໃຊ້ກະແຈດຽວກັນ ແລະ IV ດຽວກັນໃນການເຂົ້າລະຫັດຂໍ້ຄວາມທຳມະດາ 2 ຂໍ້ຄວາມ, ຈະເກີດຊ່ອງໂຫວ່ທີ່ຮ້າຍແຮງທີ່ສາມາດກູ້ຄືນຂໍ້ຄວາມທຳມະດາໄດ້ຈາກຄວາມສຳພັນແບບ XOR. ໃນການນຳໃຊ້, ຕ້ອງສ້າງ IV ດ້ວຍຕົວເລກສຸ່ມທີ່ມີຄວາມປອດໄພທາງການເຂົ້າລະຫັດສະເໝີ, ພ້ອມທັງຈັດການ Counter ເພື່ອຫຼີກລ່ຽງການນຳໃຊ້ຊ້ຳກັບກະແຈດຽວກັນ ຫຼື ປະຕິບັດຕາມຮູບແບບທີ່ແນະນຳຂອງໄລບຣາຣີສະເພາະ (ຕົວຢ່າງ: Node.js crypto.createCipheriv, Python cryptography.hazmat).

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

ໃນຂະນະສົ່ງຂໍ້ມູນ, ໃຫ້ຍຶດຖື TLS 1.3 ເປັນພື້ນຖານ ແລະ ເລືອກໃຊ້ຊຸດການເຂົ້າລະຫັດ (Cipher Suite) ໂດຍອີງຕາມສະພາບແວດລ້ອມ ແລະ ນະໂຍບາຍການຕັ້ງຄ່າຂອງຜູ້ໃຫ້ບໍລິການ. AES-256-GCM ເປັນໜຶ່ງໃນທາງເລືອກທີ່ມີປະສິດທິພາບ ແຕ່ບໍ່ຄວນຖືວ່າເປັນຄ່າເລີ່ມຕົ້ນຂອງ TLS 1.3 ທັງໝົດ. ຄວນຕັ້ງຄ່າ CDN ຫຼື Reverse Proxy ໃຫ້ອະນຸຍາດສະເພາະ TLS 1.3 + AES-256-GCM ເທົ່ານັ້ນ ແລະ ປິດການໃຊ້ງານ TLS 1.2 ລົງໄປ ຫຼື ການເຂົ້າລະຫັດແບບເກົ່າເຊັ່ນ RC4 ແລະ 3DES.

ໃນຂະນະຈັດເກັບຂໍ້ມູນ, ໃຫ້ໃຊ້ AES-256 ກັບທັງ 3 ຊັ້ນ ຄື: ການເຂົ້າລະຫັດຄໍລຳໃນຖານຂໍ້ມູນ (Postgres pgcrypto, MySQL InnoDB TDE, SQL Server Always Encrypted), ການເຂົ້າລະຫັດໃນ File Storage (AWS S3 SSE-KMS, Google Cloud Storage CMEK, Azure Storage CMK), ແລະ ການເຂົ້າລະຫັດຂໍ້ມູນສຳຮອງ (Snapshot ທີ່ເຊື່ອມຕໍ່ກັບ KMS).

ສິ່ງທີ່ມັກຖືກມອງຂ້າມຄື Log, ໄຟລ໌ຊົ່ວຄາວ (Temporary files) ແລະ ຂໍ້ມູນ Dump ຂອງສະພາບແວດລ້ອມການພັດທະນາ. ເມື່ອມີການສຳເນົາຖານຂໍ້ມູນຈາກລະບົບຈິງ (Production DB) ໄປຍັງສະພາບແວດລ້ອມການພັດທະນາ, ຕ້ອງມີການກວດສອບເປັນໄລຍະວ່າຂໍ້ມູນນັ້ນຖືກຈັດເກັບໂດຍບໍ່ມີການເຂົ້າລະຫັດຫຼືບໍ່. ສິ່ງທີ່ການກວດສອບຕາມ PDPA ຈະຖາມຫາ ບໍ່ແມ່ນ "ການເຂົ້າລະຫັດໃນການອອກແບບ" ແຕ່ແມ່ນ "ການເຂົ້າລະຫັດຍັງຄົງຖືກຮັກສາໄວ້ໃນການດຳເນີນງານຕົວຈິງຫຼືບໍ່".

ຄວາມປອດໄພທີ່ມີປະສິດທິຜົນຂອງ AES-256 ແມ່ນຖືກກຳນົດໂດຍການຈັດການກະແຈ (Key Management) ຫຼາຍກວ່າຕົວອັນກໍຣິດຶມ. ໃນທັນທີທີ່ທ່ານວາງກະແຈໄວ້ໃນໂຄ້ດຣີໂພຊິທໍຣີ (Code Repository) ຫຼື ໄຟລ໌ຕັ້ງຄ່າ (Configuration File) ໂດຍບໍ່ມີການເຂົ້າລະຫັດ, ລະຫັດທີ່ແຂງແກ່ນປານໃດກໍບໍ່ມີຄວາມໝາຍ. ການນຳໃຊ້ KMS, HSM ແລະ ການແຍກເທນແນນ (Tenant Isolation) ມາປະສົມປະສານກັນ ແມ່ນມາດຕະຖານພື້ນຖານໃນການປະຕິບັດງານຕົວຈິງໃນຍຸກປັດຈຸບັນ.

ໃນການອອກແບບການຈັດການກະແຈ, ມີ 3 ແກນຫຼັກໃນການຕັດສິນໃຈທີ່ສຳຄັນ ຄື: ຈະໃຊ້ບໍລິການໃດ (KMS / HSM), ຈະມີການໝູນວຽນກະແຈ (Rotation) ແນວໃດ, ແລະ ຈະແຍກສ່ວນໃນຮູບແບບ Multi-tenant ແນວໃດ.

ໃນສະພາບແວດລ້ອມ Cloud, ການເລືອກໃຊ້ບໍລິການຈັດການກຸນແຈ (KMS) ເຊັ່ນ: AWS KMS, Google Cloud KMS, ຫຼື Azure Key Vault ເປັນທາງເລືອກທຳອິດທີ່ຖືເປັນມາດຕະຖານ. KMS ຈະຄວບຄຸມການສ້າງ, ການຈັດເກັບ, ແລະ ການນຳໃຊ້ກຸນແຈຜ່ານ API ເຮັດໃຫ້ສາມາດດຳເນີນການເຂົ້າລະຫັດ ແລະ ຖອດລະຫັດໄດ້ໂດຍທີ່ໂຄ້ດຂອງແອັບພລິເຄຊັນບໍ່ຈຳເປັນຕ້ອງຈັດການກັບກຸນແຈໃນຮູບແບບ Plaintext ເລີຍ. ເນື່ອງຈາກ KMS ມີການຈັດຕັ້ງປະຕິບັດສິ່ງທີ່ເອີ້ນວ່າ "Envelope Encryption" (ໂຄງສ້າງ 2 ຂັ້ນຕອນທີ່ໃຊ້ KEK ເພື່ອເຂົ້າລະຫັດ DEK) ໄວ້ພາຍໃນ, ຈຶ່ງເຮັດໃຫ້ສາມາດຮັກສາທັງປະສິດທິພາບ ແລະ ຄວາມປອດໄພໄປພ້ອມກັນໄດ້.

HSM ແມ່ນກົນໄກທີ່ປົກປ້ອງກຸນແຈໄວ້ພາຍໃນຂອບເຂດຂອງຮາດແວສະເພາະ. ໃນການເລືອກໃຊ້, ຈຳເປັນຕ້ອງກວດສອບແຕ່ລະຜະລິດຕະພັນວ່າສອດຄ່ອງກັບມາດຕະຖານ FIPS 140-2 ຫຼື FIPS 140-3. ໃນກໍລະນີຂອງສະຖາບັນການເງິນ, ສະຖາບັນການແພດ, ແລະ ໂຄງການຂອງລັດຖະບານ, HSM ອາດຈະກາຍເປັນຂໍ້ກຳນົດທາງກົດລະບຽບ, ແຕ່ສຳລັບກົດໝາຍ PDPA ຂອງໄທພຽງຢ່າງດຽວນັ້ນ ການໃຊ້ HSM ບໍ່ແມ່ນຂໍ້ກຳນົດທີ່ຈຳເປັນ.

ສຳລັບການຕັດສິນໃຈໃນທາງປະຕິບັດ, ຜະລິດຕະພັນ AI ທົ່ວໄປແມ່ນໃຊ້ພຽງ KMS ກໍພຽງພໍແລ້ວ, ສ່ວນວຽກງານທີ່ຈັດການກັບຂໍ້ມູນສ່ວນບຸກຄົນທີ່ມີຄວາມລະອຽດອ່ອນ (ເຊັ່ນ: ຂໍ້ມູນສຸຂະພາບ, ຄວາມເຊື່ອ, ຂໍ້ມູນຊີວະມິຕິ) ຫຼື ໃນກໍລະນີທີ່ມີກົດລະບຽບຂອງອຸດສາຫະກຳກ່ຽວຂ້ອງ ເຊັ່ນ: ການເງິນ ຫຼື ການແພດ, ຄວນພິຈາລະນາໃຊ້ HSM. HSM ສາມາດຈັດຫາໄດ້ຜ່ານ AWS CloudHSM ຫຼື Azure Dedicated HSM, ເຊິ່ງມີຕົ້ນທຶນໃນການດຳເນີນງານສູງກວ່າ KMS ປະມານ 1 ຫາ 2 ເທົ່າຕົວ, ດັ່ງນັ້ນຈຶ່ງຄວນຕັດສິນໃຈໂດຍອີງຕາມຄວາມຕ້ອງການທາງທຸລະກິດ.

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

ການແຍກກຸນແຈແມ່ນຫຼັກການອອກແບບໂດຍການໃຊ້ກຸນແຈແຍກຕ່າງຫາກຕາມຈຸດປະສົງ ແລະ ສະພາບແວດລ້ອມ. ຕົວຢ່າງເຊັ່ນ: ການອອກກຸນແຈສຳລັບ "ກຸນແຈເຂົ້າລະຫັດຄໍລຳ DB", "ກຸນແຈເຂົ້າລະຫັດ Log", ແລະ "ກຸນແຈເຂົ້າລະຫັດ API Token" ແຍກອອກຈາກກັນ, ລວມທັງການໃຊ້ກຸນແຈແຍກຕ່າງຫາກໃນສະພາບແວດລ້ອມ Production, Staging ແລະ Development. ການເຮັດແບບນີ້ຈະຊ່ວຍໃຫ້ຂອບເຂດຂອງຜົນກະທົບຖືກຈຳກັດໃນກໍລະນີທີ່ກຸນແຈໃດໜຶ່ງຮົ່ວໄຫຼ.

ອີກໜຶ່ງວິທີການໃນທາງປະຕິບັດຄືການຈັດລຳດັບຊັ້ນຂອງກຸນແຈ. ໂດຍການເກັບຮັກສາ Master Key (KEK) ໄວ້ພາຍໃນ KMS ແລະ ໃຫ້ແອັບພລິເຄຊັນດຶງ Data Encryption Key (DEK) ມາໃຊ້ຊົ່ວຄາວ. ຖ້າສ້າງໂຄງສ້າງທີ່ຈັດການ DEK ຜ່ານ KEK ດ້ວຍ Encrypt/Decrypt API ຂອງ KMS, DEK ຈະບໍ່ຕົກຄ້າງຢູ່ໃນໜ່ວຍຄວາມຈຳເປັນເວລາດົນ, ເຊິ່ງຈະຊ່ວຍຫຼຸດຜ່ອນຄວາມສ່ຽງຕໍ່ການຮົ່ວໄຫຼເຖິງແມ່ນວ່າຈະເກີດ Core dump ຫຼື Memory dump ກໍຕາມ.

ເມື່ອອອກແບບລະບົບເພື່ອຮອງຮັບ PDPA ຢ່າງຈິງຈັງໃນ Multi-tenant SaaS, ຂໍແນະນຳໃຫ້ໃຊ້ "ການຈັດການກະແຈແຍກຕາມແຕ່ລະ Tenant" ເຊິ່ງຈະເຮັດໃຫ້ແຕ່ລະ Tenant ມີກະແຈເປັນຂອງຕົນເອງ. ວິທີນີ້ຈະຊ່ວຍຫຼີກລ່ຽງສະຖານະການທີ່ຮ້າຍແຮງທີ່ສຸດຄື "ຖ້າກະແຈດຽວຮົ່ວໄຫຼ ກໍຈະເຮັດໃຫ້ຂໍ້ມູນຂອງທຸກ Tenant ຖືກເປີດຕົວ ຫຼື Launch".

ໃນ AWS KMS, ການອອກແບບໂດຍໃຊ້ Customer Managed Key (CMK) ແຍກຕ່າງຫາກສຳລັບແຕ່ລະ Tenant ແມ່ນວິທີທີ່ມີປະສິດທິພາບ. ຄວນຕັດສິນໃຈເລືອກລະຫວ່າງການໃຊ້ກະແຈດຽວ, ກະແຈແຍກຕາມສະພາບແວດລ້ອມ, ຫຼື ກະແຈແຍກຕາມ Tenant ໂດຍພິຈາລະນາຈາກຕົ້ນທຶນ ແລະ ພາລະໃນການດຳເນີນງານ.

ແຖວຂໍ້ມູນໃນຖານຂໍ້ມູນ (DB) ຂອງແຕ່ລະ Tenant ຈະຖືກເຂົ້າລະຫັດດ້ວຍ DEK ເຊິ່ງຖືກເຂົ້າລະຫັດແບບ Envelope Encryption ດ້ວຍ CMK ຂອງ Tenant ນັ້ນໆ. ຖ້າໂຄ້ດທີ່ພະຍາຍາມຖອດລະຫັດຂໍ້ມູນຂອງ Tenant A ເຂົ້າເຖິງຂໍ້ມູນຂອງ Tenant B ໂດຍຜິດພາດ, ມັນກໍຈະບໍ່ສາມາດຖອດລະຫັດໄດ້ ເນື່ອງຈາກບໍ່ສາມາດເອີ້ນໃຊ້ CMK ທີ່ຖືກຕ້ອງໄດ້.

ສຳລັບໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງ Multi-tenant ທີ່ອີງໃສ່ PostgreSQL, ການອອກແບບທີ່ລວມເອົາ RLS ແລະ ການເຂົ້າລະຫັດເຂົ້າດ້ວຍກັນຖືເປັນວິທີທີ່ມີປະສິດທິພາບ. ໃນກໍລະນີທີ່ໃຊ້ Supabase, ຈຳເປັນຕ້ອງກວດສອບຮູບແບບສິດທິ (Permission Model) ໃນປັດຈຸບັນ ແລະ ທາງເລືອກໃນການເຂົ້າລະຫັດກ່ອນເລີ່ມອອກແບບ. ເຖິງແມ່ນວ່າຕົ້ນທຶນໃນການຈັດຕັ້ງປະຕິບັດຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ ເມື່ອທຽບກັບການໃຊ້ພຽງແຕ່ RLS ປົກກະຕິ, ແຕ່ມັນກໍເປັນຫຼັກຖານທີ່ໜັກແໜ້ນໃນການອະທິບາຍເຖິງ "ຄວາມເໝາະສົມຂອງມາດຕະການປ້ອງກັນທາງເຕັກນິກ" ຕາມຂໍ້ກຳນົດຂອງ PDPA.

ໃນໂຄງການທີ່ນຳໃຊ້ AES-256, ຄວາມຜິດພາດທີ່ມັກຖືກກວດພົບໃນລະຫວ່າງການກວດສອບ PDPA ຈະບໍ່ໄດ້ສຸມໃສ່ການເລືອກອະລະກໍລິດ (Algorithm) ແຕ່ຈະສຸມໃສ່ "ຊ່ອງໂຫວ່ໃນການດຳເນີນງານ" ເປັນຫຼັກ. ໂດຍສະເພາະ 3 ຮູບແບບຫຼັກຄື: ການສຳຮອງຂໍ້ມູນແບບບໍ່ໄດ້ເຂົ້າລະຫັດ (Plaintext backup), ການຮົ່ວໄຫຼຜ່ານ SaaS ຂອງພາກສ່ວນທີສາມ, ແລະ ບັນທຶກການກວດສອບ (Audit log) ທີ່ບໍ່ຄົບຖ້ວນ.

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

ເຖິງແມ່ນວ່າຖານຂໍ້ມູນການຜະລິດ (Production DB) ຈະຖືກເຂົ້າລະຫັດດ້ວຍ AES-256 ແລ້ວ, ແຕ່ກໍຍັງມີຫຼາຍກໍລະນີທີ່ເສັ້ນທາງການສຳຮອງຂໍ້ມູນຍັງເປັນຂໍ້ຄວາມທຳມະດາ (Plaintext) ເຊິ່ງເປັນເລື່ອງທີ່ໜ້າຕົກໃຈ. ບໍ່ວ່າຈະເປັນໄຟລ໌ SQL ທີ່ສົ່ງອອກມາດ້ວຍ pg_dump, ການສົ່ງອອກໄຟລ໌ CSV ທີ່ເກັບໄວ້ໃນເຄື່ອງທຸກໆອາທິດ, ຫຼື Snapshot ທີ່ສຳເນົາໄປຍັງສະພາບແວດລ້ອມການພັດທະນາເພື່ອການກວດສອບ QA — ຖ້າ "ຂໍ້ມູນທີ່ແຕກແຍກອອກມາ" (Derived data) ເຫຼົ່ານີ້ບໍ່ໄດ້ຖືກເຂົ້າລະຫັດ, ການເຂົ້າລະຫັດໃນຖານຂໍ້ມູນການຜະລິດກໍຈະສູນເສຍຄວາມໝາຍໄປເຄິ່ງໜຶ່ງ. ຄວນໃຊ້ຟັງຊັນ Snapshot ທີ່ເຊື່ອມຕໍ່ກັບ KMS ແລະຕ້ອງເຂົ້າລະຫັດໄຟລ໌ Dump ດ້ວຍ AES-256 ສະເໝີ.

ການຮົ່ວໄຫຼຜ່ານ SaaS ຂອງພາກສ່ວນທີສາມກໍເປັນຈຸດບອດທີ່ພົບເຫັນໄດ້ທົ່ວໄປ. ໃນການຕິດຕາມຂໍ້ຜິດພາດ (Sentry), APM (Datadog, New Relic), ຫຼື ການວິເຄາະຜະລິດຕະພັນ (Mixpanel, Amplitude) ມັກຈະມີກໍລະນີທີ່ Prompt ຫຼື ການຕອບກັບໄຫຼໄປໃນຮູບແບບຂໍ້ຄວາມທຳມະດາ. ເຖິງແມ່ນວ່າບໍລິການເຫຼົ່ານີ້ຈະມີການເຂົ້າລະຫັດດ້ວຍຕົນເອງ, ແຕ່ "ໃຜເປັນຜູ້ຖືຄີ (Key)" ນັ້ນແມ່ນສິ່ງທີ່ສຳຄັນ. ນອກຈາກ SSE (Server-Side Encryption) ແລ້ວ, ຄວນພິຈາລະນາໃຊ້ CSE (Client-Side Encryption) ແລະ ຮູບແບບທີ່ປອດໄພທີ່ສຸດຄືການ Masking ຫຼື Hashing ຂໍ້ມູນ PII ຢູ່ຝັ່ງແອັບພລິເຄຊັນກ່ອນສົ່ງຂໍ້ມູນ.

ການສ້າງຂະບວນການ "ລຶບ PII ອອກກ່ອນສົ່ງໄປຍັງ SaaS ພາຍນອກ" ໃຫ້ເປັນ Library ກາງ ແລະ ສ້າງກົນໄກໃຫ້ທຸກການສົ່ງ Telemetry ຕ້ອງຜ່ານຂະບວນການດັ່ງກ່າວ, ຈະຊ່ວຍປ້ອງກັນການຮົ່ວໄຫຼໄດ້ໂດຍທີ່ນັກພັດທະນາບໍ່ຈຳເປັນຕ້ອງຄອຍລະວັງດ້ວຍຕົນເອງ.

ສິ່ງທີ່ຖືກກວດສອບໃນການກວດສອບ PDPA ບໍ່ແມ່ນພຽງແຕ່ "ຂໍ້ມູນໄດ້ຮັບການເຂົ້າລະຫັດແລ້ວຫຼືບໍ່" ເທົ່ານັ້ນ, ແຕ່ຍັງລວມເຖິງ "ການດຳເນີນງານດ້ານການເຂົ້າລະຫັດໄດ້ຖືກຮັກສາໄວ້ຢ່າງຕໍ່ເນື່ອງຫຼືບໍ່" ອີກດ້ວຍ. ພື້ນຖານສຳລັບສິ່ງດັ່ງກ່າວແມ່ນບັນທຶກການກວດສອບ (Audit logs) ແລະ ການທົບທວນຄືນເປັນໄລຍະ.

ບັນທຶກການໃຊ້ງານຂອງ KMS ຈະຖືກບັນທຶກໄວ້ໃນ AWS CloudTrail ຫຼື Google Cloud Audit Logs. ຄວນຕັ້ງຄ່າການແຈ້ງເຕືອນສຳລັບຄວາມຖີ່ໃນການໃຊ້ກະແຈ, ການເຂົ້າເຖິງໃນຊ່ວງເວລາທີ່ຜິດປົກກະຕິ, ແລະ ການຮຽກໃຊ້ຈາກ IAM role ທີ່ແຕກຕ່າງຈາກປົກກະຕິ. ໃນຜະລິດຕະພັນ AI, ທີມພັດທະນາມັກຈະຕົກຢູ່ໃນຮູບແບບທີ່ບໍ່ເໝາະສົມ (Anti-pattern) ເຊັ່ນ: "ການສົ່ງກະແຈຜ່ານຕົວແປສະພາບແວດລ້ອມ (Environment variables) ແທນທີ່ຈະຜ່ານ KMS" ເປັນການຊົ່ວຄາວ, ເຊິ່ງການທົບທວນຄືນຮ່ອງຮອຍເຫຼົ່ານັ້ນຈາກບັນທຶກຢ່າງສະໝໍ່າສະເໝີຈະຊ່ວຍປ້ອງກັນບັນຫາໄດ້.

ສຳລັບລາຍການທົບທວນຄືນທີ່ຄວນດຳເນີນການໃນຮອບ 10 ປີ (ໝາຍເຫດ: ຕາມບໍລິບົດຄວນເປັນລາຍປີ) ຄວນກຳນົດຢ່າງໜ້ອຍ 5 ຫົວຂໍ້ຄື: ການກວດສອບຂໍ້ມູນທີ່ຕ້ອງເຂົ້າລະຫັດ, ປະຫວັດການໝູນວຽນຂອງກະແຈ (Key rotation), ສະຖານະການເຂົ້າລະຫັດຂອງເສັ້ນທາງສຳຮອງຂໍ້ມູນ (Backup pipeline), ການອັບເດດນະໂຍບາຍການເຂົ້າລະຫັດຂອງ SaaS ພາກສ່ວນທີສາມ, ແລະ ການຕິດຕາມການອັບເດດແນວທາງປະຕິບັດຈາກ PDPC. ນອກຈາກນີ້, ບັນທຶກການດຳເນີນງານເມື່ອຕອບສະໜອງຕໍ່ສິດຂອງເຈົ້າຂອງຂໍ້ມູນຕາມ PDPA (ການຮ້ອງຂໍເປີດຕົວ ຫຼື Launch ແລະ ການຮ້ອງຂໍລຶບຂໍ້ມູນ) ຄວນຖືກຈັດເກັບໄວ້ໃນລະດັບດຽວກັນກັບຂໍ້ມູນທີ່ເຂົ້າລະຫັດ. ໃນກໍລະນີສ່ວນໃຫຍ່, ການກວດສອບຈະຜ່ານໄປໄດ້ຖ້າມີຫຼັກຖານຮ່ອງຮອຍ, ແລະ ຕົວຫຼັກຖານເຫຼົ່ານັ້ນເອງກໍຄືການເຮັດໃຫ້ການປະຕິບັດຕາມ PDPA ສາມາດເບິ່ງເຫັນໄດ້ຢ່າງຊັດເຈນ.

ສະຫຼຸບຄຳຖາມທີ່ພົບເລື້ອຍໃນການພັດທະນາລະບົບກ່ຽວກັບ AES-256 ແລະ ການປະຕິບັດຕາມ PDPA. ທຸກຫົວຂໍ້ລ້ວນເປັນປະເດັນທີ່ "ຖ້າບໍ່ຮູ້ຈະເຮັດໃຫ້ເກີດການແກ້ໄຂງານຄືນໃໝ່ຢ່າງມະຫາສານ".

Q1: ຖ້າຫາກນຳໃຊ້ AES-256 ແລ້ວ ຈະສາມາດຕອບໂຈດມາດຕະການປ້ອງກັນທາງເຕັກນິກຂອງ PDPA ໄດ້ຢ່າງຄົບຖ້ວນເລີຍຫຼືບໍ່? ຍັງບໍ່ຄົບຖ້ວນ. AES-256 ເປັນພຽງພື້ນຖານຂອງການເຂົ້າລະຫັດເທົ່ານັ້ນ, ການຈະເປັນ "ມາດຕະການທີ່ເໝາະສົມ" ໄດ້ນັ້ນ ຕ້ອງມີການປະສົມປະສານກັບຊັ້ນອື່ນໆ ເຊັ່ນ: ການຄວບຄຸມການເຂົ້າເຖິງ (RBAC/IAM), ບັນທຶກການກວດສອບ (Audit Log), ການຈັດປະເພດຂໍ້ມູນ, ນະໂຍບາຍການລຶບຂໍ້ມູນ ແລະ ການຝຶກອົບຮົມພະນັກງານ. PDPA ບໍ່ໄດ້ຮຽກຮ້ອງພຽງແຕ່ການເຂົ້າລະຫັດເທົ່ານັ້ນ ແຕ່ຍັງຮຽກຮ້ອງໃຫ້ມີກົນໄກການປົກປ້ອງຂໍ້ມູນໂດຍລວມຢ່າງຄົບຖ້ວນ.

Q2: AES-128 ຖືວ່າບໍ່ພຽງພໍສຳລັບຂໍ້ກຳນົດຂອງ PDPA ແມ່ນຫຼືບໍ່? AES-128 ກໍເປັນລະບົບອັນກໍຣິດຶມທີ່ໄດ້ຮັບການຮັບຮອງຈາກ FIPS 197 ແລະ ໄດ້ຮັບການຍອມຮັບໃນຫຼາຍກົດລະບຽບ. ຄວາມແຕກຕ່າງກັບ AES-256 ແມ່ນ AES-256 ຈະມີຄວາມໄດ້ປຽບໃນດ້ານ "ຄວາມທົນທານຕໍ່ການວິເຄາະລະຫັດໃນອະນາຄົດ", ແຕ່ໃນປັດຈຸບັນທີ່ຕ້ອງປະຕິບັດຕາມ PDPA ນັ້ນ ທັງສອງແບບມີໂອກາດສູງທີ່ຈະຖືກຕັດສິນວ່າເປັນ "ມາດຕະການທີ່ເໝາະສົມ". ຖ້າລະບົບເດີມໃຊ້ AES-128 ຢູ່ ແລະ ມີຕົ້ນທຶນໃນການປ່ຽນແທນສູງ ການນຳໃຊ້ຕໍ່ໄປກໍຖືວ່າມີເຫດຜົນ. ແຕ່ສຳລັບການຈັດຕັ້ງປະຕິບັດໃໝ່ ການເລືອກ AES-256 ຈະປອດໄພກວ່າ.

Q3: ຖ້າຖານຂໍ້ມູນເດີມເປີດໃຊ້ TDE (Transparent Data Encryption) ໄວ້ແລ້ວ ຈຳເປັນຕ້ອງເພີ່ມການຈັດຕັ້ງປະຕິບັດອື່ນອີກຫຼືບໍ່? TDE ມີປະສິດທິພາບໃນການ "ປ້ອງກັນເມື່ອມີການລັກຂະໂມຍດິສກ໌", ແຕ່ເນື່ອງຈາກມັນຈະຖອດລະຫັດແບບໂປ່ງໃສສຳລັບຜູ້ໃຊ້ທີ່ມີສິດເຂົ້າເຖິງ SQL, ມັນຈຶ່ງບໍ່ສາມາດປ້ອງກັນການທຸຈະລິດພາຍໃນ ຫຼື ການຮົ່ວໄຫຼຜ່ານ SQL Injection ໄດ້. ສຳລັບຄໍລຳທີ່ມີຂໍ້ມູນລະອຽດອ່ອນ, ການເພີ່ມການເຂົ້າລະຫັດໃນລະດັບຄໍລຳ (ເຊັ່ນ: pgcrypto ຫຼື ການເຂົ້າລະຫັດໃນຊັ້ນແອັບພລິເຄຊັນ) ເຂົ້າໄປນຳ TDE ຈະເປັນການຈັດຕັ້ງປະຕິບັດທີ່ອະທິບາຍໄດ້ງ່າຍກວ່າໃນການກວດສອບ PDPA.

Q4: ຄວນໃຫ້ຄວາມສຳຄັນກັບການເຂົ້າລະຫັດທີ່ທົນທານຕໍ່ຄວອນຕັມ (Quantum-Resistant Cryptography) ໃນຕອນນີ້ເລີຍຫຼືບໍ່? ການໂຈມຕີ AES-256 ດ້ວຍຄອມພິວເຕີຄວອນຕັມໃນທາງປະຕິບັດຍັງບໍ່ທັນເກີດຂຶ້ນ. ເຖິງແມ່ນວ່າ NIST ຈະປະກາດມາດຕະຖານການເຂົ້າລະຫັດທີ່ທົນທານຕໍ່ຄວອນຕັມ (ML-KEM, ML-DSA) ແລ້ວກໍຕາມ, ແຕ່ຈຸດສຸມຫຼັກແມ່ນການປ່ຽນແທນການເຂົ້າລະຫັດແບບກະແຈສາທາລະນະ (RSA, ECDH) ສ່ວນ AES ເຊິ່ງເປັນການເຂົ້າລະຫັດແບບສົມມາດນັ້ນ ຍັງຖືວ່າປອດໄພໃນໄລຍະນີ້ ໂດຍການຮັກສາຄວາມຍາວຂອງກະແຈໄວ້ທີ່ 256 ບິດ. ໃຫ້ພິຈາລະນາແຜນການເຂົ້າລະຫັດໃໝ່ໃນອະນາຄົດສະເພາະກໍລະນີທີ່ຈັດການກັບຂໍ້ມູນທີ່ຕ້ອງເກັບຮັກສາໄວ້ໃນໄລຍະຍາວ (ຮອບ 10 ປີ ຂຶ້ນໄປ) ເທົ່ານັ້ນ.

ເພື່ອໃຫ້ບັນລຸ "ມາດຕະຖານ ຫຼື Specification" ດ້ານການປົກປ້ອງທາງເຕັກນິກທີ່ເໝາະສົມຕາມ PDPA ຂອງໄທ, AES-256 ແມ່ນທາງເລືອກທີ່ອະທິບາຍໄດ້ງ່າຍທີ່ສຸດໃນທາງປະຕິບັດ. ຢ່າງໃດກໍຕາມ, ການພຽງແຕ່ "ໃຊ້ AES-256" ບໍ່ໄດ້ໝາຍຄວາມວ່າຈະຜ່ານການກວດສອບໄດ້. ການອອກແບບສິ່ງທີ່ຕ້ອງເຂົ້າລະຫັດ (4 ຊັ້ນ: Prompt, Response, Vector, ແລະ Training Data), ການເລືອກໂໝດ (GCM ເປັນທາງເລືອກທຳອິດ), ການຈັດການກະແຈ (KMS, Tenant Isolation, Rotation), ມາດຕະການປ້ອງກັນການຮົ່ວໄຫຼຜ່ານ Backup ແລະ SaaS, ລວມເຖິງບັນທຶກການກວດສອບ (Audit Log) ແລະ ການທົບທວນຢ່າງຕໍ່ເນື່ອງ — ສິ່ງເຫຼົ່ານີ້ຕ້ອງຖືກອອກແບບໃຫ້ເປັນອັນໜຶ່ງອັນດຽວກັນ ຈຶ່ງຈະກາຍເປັນ "ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure" ທາງເຕັກນິກທີ່ສອດຄ່ອງກັບ PDPA.

ບົດຄວາມນີ້ເນັ້ນໃສ່ຊັ້ນການຈັດຕັ້ງປະຕິບັດທາງເຕັກນິກໂດຍສະເພາະ, ແຕ່ການຮອງຮັບ PDPA ຈຳເປັນຕ້ອງດຳເນີນໄປຄຽງຄູ່ກັບດ້ານອົງກອນ. ສຳລັບດ້ານອົງກອນ ແລະ ສັນຍາ ເຊັ່ນ: ການຂໍຄວາມຍິນຍອມ, ການແຕ່ງຕັ້ງ DPO, ສັນຍາການໂອນຂໍ້ມູນຂ້າມແດນ, ແລະ ການຕອບສະໜອງຕໍ່ຄຳຮ້ອງຂໍຈາກເຈົ້າຂອງຂໍ້ມູນນັ້ນ, ພວກເຮົາໄດ້ຮວບຮວມໄວ້ໃນ "ລາຍການກວດສອບການປະຕິບັດຕາມກົດໝາຍເພື່ອຄວາມສົມດຸນລະຫວ່າງການຮອງຮັບ PDPA ຂອງໄທ ແລະ ການນຳໃຊ້ AI" ຂອງບໍລິສັດເຮົາ. ນອກຈາກນີ້, ການອອກແບບທຳນຽມການປົກຄອງ (Governance) ຂອງລະບົບ AI ທັງໝົດແມ່ນໄດ້ກ່າວເຖິງໃນ "AI Governance ແມ່ນຫຍັງ? ຄູ່ມືພາກປະຕິບັດຕັ້ງແຕ່ການຮອງຮັບ EU AI Act ຈົນເຖິງການຈັດຕັ້ງກົດລະບຽບພາຍໃນ", ແລະຄວາມສ່ຽງດ້ານຄວາມປອດໄພໂດຍລວມແມ່ນໄດ້ກ່າວເຖິງໃນ "ທ່າອ່ຽງຫຼ້າສຸດຂອງຄວາມປອດໄພທາງໄຊເບີສຳລັບ AI", ເຊິ່ງທ່ານສາມາດອ້າງອີງເພີ່ມເຕີມໄດ້.

ຂັ້ນຕອນຕໍ່ໄປແມ່ນການກວດສອບຂໍ້ມູນທີ່ໃຊ້ໃນຜະລິດຕະພັນ AI ຂອງບໍລິສັດທ່ານໂດຍແບ່ງອອກເປັນ 4 ຊັ້ນ (Prompt, Response, Vector, Training Data) ແລະ ເຮັດ Mapping ສະຖານະການເຂົ້າລະຫັດໃນປັດຈຸບັນຂອງແຕ່ລະຊັ້ນ. ເມື່ອເຫັນຊ່ອງຫວ່າງທີ່ຊັດເຈນແລ້ວ, ລຳດັບຄວາມສຳຄັນໃນການຈັດຕັ້ງປະຕິບັດກໍຈະປາກົດຂຶ້ນມາເອງ.