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

ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອແນະນຳຜູ້ຮັບຜິດຊອບດ້ານລະບົບຂໍ້ມູນຂ່າວສານ/ຄວາມປອດໄພ ທີ່ຮັບຜິດຊອບການນຳໃຊ້ ແລະ ດຳເນີນງານ AI Agent ໃນບໍລິສັດຍີ່ປຸ່ນ ໂດຍອະທິບາຍຕັ້ງແຕ່ເຫດຜົນທີ່ຈຳເປັນຕ້ອງມີການແຍກສ່ວນ ໄປຈົນເຖິງຂັ້ນຕອນການຈັດຕັ້ງປະຕິບັດໃນ 3 ຂັ້ນຕອນ ຄື: ສະພາບແວດລ້ອມການປະຕິບັດງານ, ເຄືອຂ່າຍ ແລະ ບັນທຶກການກວດສອບ (Audit Log). ເມື່ອອ່ານຈົບ, ທ່ານຈະສາມາດອອກແບບໄດ້ວ່າ "ຄວນປິດກັ້ນຫຍັງ ແລະ ໃນລະດັບໃດ" ສຳລັບ Agent ຂອງບໍລິສັດທ່ານ.

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

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

• ການນຳຂໍ້ມູນອອກໄປຂ້າງນອກ (Data Exfiltration): ເອເຈນອາດສົ່ງເນື້ອໃນຂອງໄຟລ໌ພາຍໃນບໍລິສັດ ຫຼື ຖານຂໍ້ມູນທີ່ຕົນເອງສາມາດເຂົ້າເຖິງໄດ້ ອອກໄປຍັງພາຍນອກ.
• ການລັກຂະໂມຍຂໍ້ມູນການຢືນຢັນຕົວຕົນ: ເອເຈນອາດອ່ານ API Key ຫຼື Token ທີ່ວາງໄວ້ໃນຕົວແປສະພາບແວດລ້ອມ (Environment Variables) ຫຼື ໄຟລ໌ຕັ້ງຄ່າ ແລ້ວສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ລະບົບອື່ນ.
• ການຍົກລະດັບສິດທິ (Privilege Escalation): ໃຊ້ຊ່ອງໂຫວ່ຂອງໂຮສທີ່ໃຊ້ງານ ຫຼື ສິດທິທີ່ເກີນຄວາມຈຳເປັນ ເປັນຈຸດເລີ່ມຕົ້ນໃນການເຂົ້າເຖິງຊັບພະຍາກອນທີ່ບໍ່ຄວນຈະເຂົ້າເຖິງໄດ້.

ສິ່ງທີ່ໜ້າກັງວົນໂດຍສະເພາະແມ່ນ ການໂຈມຕີແບບ Indirect Prompt Injection. ຫາກຂໍ້ມູນພາຍນອກ ຫຼື ໜ້າເວັບໄຊທີ່ເອເຈນອ່ານເຂົ້າມາມີຄຳສັ່ງທີ່ເປັນອັນຕະລາຍແຝງຢູ່, ເອເຈນອາດເຂົ້າໃຈຜິດວ່າສິ່ງນັ້ນເປັນ "ຄຳສັ່ງທີ່ຖືກຕ້ອງ" ແລະ ດຳເນີນການຕາມທີ່ລະບຸໄວ້ຂ້າງເທິງ. OWASP ໄດ້ຈັດລະບຽບຄວາມສ່ຽງສະເພາະຂອງແອັບພລິເຄຊັນ LLM ໄວ້ ເຊິ່ງສາມາດໃຊ້ OWASP LLM Top 10 ໃນການຮຽນຮູ້ດ້ານຄວາມປອດໄພຂອງ AI ເປັນຈຸດເລີ່ມຕົ້ນໃນການວາງມາດຕະການປ້ອງກັນໄດ້.

ມາດຕະການໃນລະດັບແອັບພລິເຄຊັນ ເຊັ່ນ: "ການກຳນົດຂໍ້ຫ້າມໃນ Prompt ຂອງ Agent" ຫຼື "ການຈຳກັດການເຮັດວຽກໃນ Code ຂອງແອັບ" ແມ່ນມີຄວາມຈຳເປັນ, ແຕ່ພຽງເທົ່ານັ້ນຍັງຖືວ່າເປັນການປ້ອງກັນທີ່ບໍ່ແຂງແກ່ນພໍ. ເຫດຜົນແມ່ນງ່າຍດາຍ ເພາະການຄວບຄຸມໃນລະດັບແອັບພລິເຄຊັນສາມາດຖືກທຳລາຍໄດ້ດ້ວຍ Bug ຫຼື ວິທີການຫຼີກລ່ຽງຕ່າງໆ.

ຕົວຢ່າງເຊັ່ນ: ການກຳນົດຂໍ້ຫ້າມໃນ Prompt ອາດຈະຖືກຂຽນທັບດ້ວຍການສັ່ງງານແບບ Prompt Injection ທີ່ຊັບຊ້ອນ. ຖ້າຫາກມີການກວດສອບທີ່ຕົກຫຼົ່ນໃນແອັບພລິເຄຊັນ, Path ຂອງໄຟລ໌ ຫຼື ຄຳສັ່ງທີ່ບໍ່ໄດ້ຄາດຄິດໄວ້ກໍອາດຈະຜ່ານໄປໄດ້. ຖ້າຫາກເປັນໂຄງສ້າງທີ່ Agent ສາມາດປະຕິບັດ Code ໃດໆກໍໄດ້, ຂໍ້ກຳນົດເບື້ອງຕົ້ນຂອງລະດັບແອັບພລິເຄຊັນກໍຈະຖືກຫຼີກລ່ຽງໂດຍກົງ.

ດ້ວຍເຫດນີ້, ນອກເໜືອໄປຈາກການຄວບຄຸມແບບ "ຮ້ອງຂໍ" ໃນລະດັບແອັບພລິເຄຊັນແລ້ວ, ຈຶ່ງມີຄວາມຈຳເປັນຕ້ອງມີການປ້ອງກັນຫຼາຍຊັ້ນ (Defense in Depth) ເພື່ອສ້າງສະພາວະທີ່ "ບໍ່ສາມາດປະຕິບັດງານໄດ້ ຫຼື ບໍ່ສາມາດເຂົ້າເຖິງໄດ້" ຕັ້ງແຕ່ລະດັບ OS ຫຼື Network. ການແຍກສ່ວນດ້ວຍ Sandbox ຖືເປັນປ້ອມປ້ອງກັນດ່ານສຸດທ້າຍນີ້. ຈຸດທີ່ຄວນທຳຄວາມເຂົ້າໃຈຄວບຄູ່ໄປກັບ ຄູ່ມືການນຳໃຊ້ຄວາມປອດໄພ LLM ຄື: ມາດຕະການນີ້ຈະມີຄວາມໝາຍກໍຕໍ່ເມື່ອປະຕິບັດຮ່ວມກັບການວາງລະບົບຄວາມປອດໄພໃນລະດັບແອັບພລິເຄຊັນເທົ່ານັ້ນ.

ການແຍກສ່ວນ Sandbox ສາມາດຈັດລະບຽບໄດ້ງ່າຍໂດຍການພິຈາລະນາຈາກ 4 ຂອບເຂດການປ້ອງກັນ ຄື: "ໄຟລ໌", "ຂະບວນການ", "ເຄືອຂ່າຍ" ແລະ "ນະໂຍບາຍສິດທິ". ໃຫ້ເບິ່ງພາບລວມກ່ອນວ່າແຕ່ລະສ່ວນປົກປ້ອງຫຍັງແດ່ ກ່ອນທີ່ຈະເຂົ້າສູ່ຂັ້ນຕອນການປະຕິບັດງານ.

ໂດເມນທຳອິດແມ່ນການຈຳກັດໄຟລ໌ທີ່ Agent ສາມາດເຂົ້າເຖິງໄດ້ ແລະ ຂະບວນການທີ່ສາມາດປະຕິບັດໄດ້. ໃນສະພາບແວດລ້ອມ Linux, ສິ່ງນີ້ສາມາດເຮັດໃຫ້ສຳເລັດໄດ້ດ້ວຍຟັງຊັນ Kernel ຂອງ OS.

• Landlock: ກົນໄກຄວາມປອດໄພຂອງ Linux ທີ່ຈຳກັດໄຟລ໌ ແລະ ໄດເລກະທໍລີທີ່ສາມາດເຂົ້າເຖິງໄດ້ໃນລະດັບ Process (ນຳໃຊ້ໃນ Kernel 5.13). ຕ່າງຈາກ SELinux ແລະ ອື່ນໆ, ມັນບໍ່ຈຳເປັນຕ້ອງໃຊ້ສິດ root ແລະ ມີຈຸດເດັ່ນຄືເຖິງແມ່ນວ່າຈະເປັນ Process ທີ່ບໍ່ມີສິດພິເສດກໍສາມາດຈຳກັດສິດຂອງຕົນເອງໄດ້. ມັນສາມາດຄວບຄຸມບໍ່ໃຫ້ອ່ານ ຫຼື ຂຽນຂໍ້ມູນນອກເໜືອຈາກໄດເລກະທໍລີການເຮັດວຽກຂອງ Agent ໄດ້.
• seccomp: ກົນໄກໃນການຈຳກັດ System call ທີ່ Process ສາມາດອອກຄຳສັ່ງໄດ້. ມັນຈະບລັອກ System call ທີ່ບໍ່ຈຳເປັນ (ຕົວຢ່າງ: ລະບົບເຄືອຂ່າຍບາງຢ່າງ ຫຼື ລະບົບການຈັດການສິດ) ເພື່ອຫຼຸດຜ່ອນຊ່ອງໂຫວ່ໃນການໂຈມຕີ.

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

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

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

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

ໃນຖານະທີ່ເປັນໂດເມນທີ 3 ແລະ ທີ 4, ໃຫ້ກຳນົດນະໂຍບາຍສິດອຳນາດແບບ "Declarative" ແລະ ຍຶດຖືແນວຄວາມຄິດໃນການດຳເນີນງານດ້ວຍສິດອຳນາດຂັ້ນຕໍ່າສຸດ. ຄຳວ່າ Declarative ໃນທີ່ນີ້ໝາຍເຖິງການຂຽນກົດລະບຽບການອະນຸຍາດ ຫຼື ຫ້າມໄວ້ຢ່າງຈະແຈ້ງໃນໄຟລ໌ການຕັ້ງຄ່າ ແລະ ອື່ນໆ, ໂດຍບໍ່ຕ້ອງເພິ່ງພາເງື່ອນໄຂການແຍກສາຂາ (Conditional Branching) ທີ່ກະແຈກກະຈາຍຢູ່ທົ່ວໂຄ້ດ.

ຫຼັກການສິດອຳນາດຂັ້ນຕໍ່າສຸດ (Principle of Least Privilege) ໝາຍເຖິງ "ການໃຫ້ສິດອຳນາດທີ່ຈຳເປັນແທ້ໆສຳລັບຕົວແທນ (Agent) ນັ້ນໆ ໃນການປະຕິບັດວຽກງານ". ຕົວຢ່າງເຊັ່ນ: ບໍ່ໃຫ້ສິດໃນການຂຽນຫາກວຽກງານນັ້ນຕ້ອງການພຽງແຕ່ການອ່ານ, ຫຼື ອະນຸຍາດໃຫ້ເຂົ້າເຖິງສະເພາະໄດເລັກທໍຣີທີ່ຈຳເປັນເທົ່ານັ້ນ.

ຂໍ້ດີຂອງການໃຊ້ Declarative Policy ຮ່ວມກັບສິດອຳນາດຂັ້ນຕໍ່າສຸດມີ 2 ປະການ: ປະການທຳອິດແມ່ນສາມາດກວດສອບ ແລະ ດຳເນີນການກວດສອບ (Audit) ໄດ້ງ່າຍ ເນື່ອງຈາກສາມາດເບິ່ງຂອບເຂດການອະນຸຍາດໄດ້ໃນລາຍການດຽວ. ປະການທີສອງແມ່ນການເພີ່ມ ຫຼື ລຶບສິດອຳນາດສາມາດເຮັດໃຫ້ສຳເລັດໄດ້ດ້ວຍການປ່ຽນແປງການຕັ້ງຄ່າ ແລະ ສາມາດຕິດຕາມປະຫວັດການປ່ຽນແປງໄດ້. ສຳລັບການສ້າງໂຄງສ້າງໃນການນຳໄປປະຕິບັດງານໃນລະດັບອົງກອນ, ທ່ານສາມາດອ້າງອີງ AgentOps (ການອອກແບບອົງກອນສຳລັບການດຳເນີນງານ AI Agent) ໄດ້.

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

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

• ໄຟລ໌ ຫຼື ໄດເຣັກທໍຣີໃດທີ່ຕ້ອງອ່ານ ແລະ ຂຽນ
• ບໍລິການພາຍນອກ ຫຼື API ໃດທີ່ຕ້ອງເຊື່ອມຕໍ່
• ຄຳສັ່ງ ຫຼື ເຄື່ອງມືໃດທີ່ຕ້ອງໃຊ້ໃນການປະຕິບັດງານ
• ຂໍ້ມູນທີ່ຈັດການນັ້ນມີຂໍ້ມູນສ່ວນຕົວ ຫຼື ຂໍ້ມູນລັບລວມຢູ່ດ້ວຍຫຼືບໍ່

ຄວາມຖືກຕ້ອງຂອງການກວດສອບນີ້ຈະເປັນຕົວຕັດສິນຄຸນນະພາບຂອງການອອກແບບສິດທິໃນຂັ້ນຕອນຕໍ່ໄປ. ຂໍ້ຜິດພາດທີ່ມັກພົບເຫັນຄື "ການໃຫ້ສິດທິໃນວົງກວ້າງໄວ້ກ່ອນ" ເຊິ່ງເປັນສິ່ງທີ່ກົງກັນຂ້າມກັບຫຼັກການສິດທິຂັ້ນຕໍ່າສຸດ (Least Privilege). ການຕັ້ງຄ່າໃຫ້ຈຳກັດໄວ້ກ່ອນໃນຕອນເລີ່ມຕົ້ນ ແລ້ວຄ່ອຍໆເພີ່ມສິດໃນສ່ວນທີ່ວຽກງານຍັງດຳເນີນການບໍ່ໄດ້ນັ້ນ ຈະເຮັດໃຫ້ໄດ້ໂຄງສ້າງທີ່ປອດໄພກວ່າໃນທີ່ສຸດ. ສຳລັບຄວາມສ່ຽງທີ່ Agent ທີ່ບໍ່ໄດ້ຢູ່ໃນການຄວບຄຸມຈະເພີ່ມທະວີຂຶ້ນເລື້ອຍໆໃນໜ້າວຽກນັ້ນ ຄວນສຶກສາຂໍ້ມູນເພີ່ມເຕີມໄດ້ທີ່ ຄວາມສ່ຽງຂອງ Shadow AI ແລະ ການບໍລິຫານຈັດການ.

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

• ຂໍ້ມູນການຢືນຢັນຕົວຕົນ ເຊັ່ນ: API Key, Token, ລະຫັດຜ່ານ
• ຂໍ້ມູນສ່ວນບຸກຄົນ ເຊັ່ນ: ຂໍ້ມູນລູກຄ້າ, ຂໍ້ມູນພະນັກງານ
• ເອກະສານລັບ ເຊັ່ນ: ເອກະສານອອກແບບ, ສັນຍາ, ຂໍ້ມູນທາງການເງິນ

ໂດຍສະເພາະຂໍ້ມູນການຢືນຢັນຕົວຕົນ, ມັກຈະຖືກວາງໄວ້ໃນຮູບແບບຂໍ້ຄວາມທຳມະດາ (Plain text) ໃນຕົວແປສະພາບແວດລ້ອມ (Environment variables) ຫຼື ໄຟລ໌ການຕັ້ງຄ່າ, ເຊິ່ງຖ້າຫາກວາງໄວ້ໃນຕຳແໜ່ງທີ່ Agent ສາມາດອ່ານໄດ້ ຈະເຮັດໃຫ້ຄວາມສ່ຽງເພີ່ມສູງຂຶ້ນທັນທີ. ຫຼັກການພື້ນຖານຄືການແຍກອອກໄປໄວ້ໃນລະບົບການຈັດການຄວາມລັບ (Secret management) ແລະ ເຮັດໃຫ້ບໍ່ສາມາດເບິ່ງເຫັນໄດ້ຈາກໄດເຣັກທໍຣີການເຮັດວຽກຂອງ Agent. ໃນກໍລະນີຂອງບໍລິສັດຍີ່ປຸ່ນທີ່ດຳເນີນທຸລະກິດໃນບັນດາປະເທດ ASEAN, ການຈັດການຂໍ້ມູນສ່ວນບຸກຄົນຍັງຕົກຢູ່ພາຍໃຕ້ກົດໝາຍປົກປ້ອງຂໍ້ມູນຂອງທ້ອງຖິ່ນນັ້ນໆ. ສຳລັບການຈັດລະບຽບດ້ານທຳມາພິບານ (Governance) ເມື່ອມີການຂະຫຍາຍທຸລະກິດໄປຫຼາຍປະເທດ, ກະລຸນາອ້າງອີງ ການສ້າງລະບົບ AI Governance ສຳລັບບໍລິສັດທີ່ຂະຫຍາຍທຸລະກິດເຂົ້າສູ່ ASEAN.

ໃນຂັ້ນຕອນທີ 1, ໃຫ້ດຳເນີນການ Agent ພາຍໃນ "Sandbox" ທີ່ແຍກອອກຈາກສະພາບແວດລ້ອມການຜະລິດ (Production environment). ໃຫ້ເລືອກລະຫວ່າງ Container ຫຼື MicroVM ແລະ ກຳນົດການຕັ້ງຄ່າຂອບເຂດຂອງ File ແລະ Process.

ການແຍກສະພາບແວດລ້ອມໃນການປະຕິບັດງານ (Execution environment) ໂດຍທົ່ວໄປແມ່ນອີງໃສ່ Container ຫຼື MicroVM. ທັງສອງຢ່າງນີ້ຈະຖືກເລືອກໂດຍອີງໃສ່ ການແລກປ່ຽນ ຫຼື Trade-off ລະຫວ່າງຄວາມແຂງແກ່ນຂອງການແຍກສ່ວນ ແລະ ຕົ້ນທຶນໃນການເລີ່ມຕົ້ນລະບົບ.

ສະຫຼຸບຄື: ຖ້າຫາກຕ້ອງຈັດການກັບໂຄ້ດ ຫຼື ຄຳສັ່ງທີ່ມາຈາກພາຍນອກ ແລະ ຕ້ອງການການແຍກສ່ວນທີ່ແຂງແກ່ນ ໃຫ້ໃຊ້ MicroVM, ແຕ່ຖ້າເປັນການນຳໃຊ້ພາຍໃນບໍລິສັດທີ່ເນັ້ນປະສິດທິພາບໃນການເລີ່ມຕົ້ນລະບົບແມ່ນໃຫ້ໃຊ້ Container ເປັນຫຼັກ. ໃນກໍລະນີທີ່ໃຊ້ Container, ຄວນນຳໃຊ້ການຄວບຄຸມທີ່ເຂັ້ມງວດຮ່ວມດ້ວຍ ເຊັ່ນ: ບໍ່ໃຫ້ເຮັດວຽກດ້ວຍສິດທິ Root, ປິດການໃຊ້ງານຟັງຊັນທີ່ບໍ່ຈຳເປັນ (Capabilities), ແລະ ຕັ້ງຄ່າໃຫ້ລະບົບໄຟລ໌ເປັນແບບອ່ານໄດ້ຢ່າງດຽວ (Read-only) ເປັນພື້ນຖານ. ບໍ່ວ່າຈະເປັນວິທີໃດກໍຕາມ, ການສ້າງສະພາບແວດລ້ອມໃໝ່ສຳລັບທຸກໆໜ້າວຽກ (Task) ແລ້ວທິ້ງໄປຫຼັງຈາກໃຊ້ງານແລ້ວ ແມ່ນວິທີທີ່ປອດໄພ ເພາະຈະບໍ່ມີສິ່ງຕົກຄ້າງຈາກໜ້າວຽກກ່ອນໜ້ານີ້ສົ່ງຜົນກະທົບຕໍ່ໜ້າວຽກຕໍ່ໄປ.

ເມື່ອຈັດກຽມສະພາບແວດລ້ອມແບບແຍກສ່ວນ (Isolated environment) ແລ້ວ ໃຫ້ຈຳກັດຂອບເຂດຂອງໄຟລ໌ ແລະ ຂະບວນການ (Process) ພາຍໃນນັ້ນຕື່ມອີກ ໂດຍໃຊ້ Landlock ແລະ seccomp ທີ່ກ່າວມາຂ້າງຕົ້ນ ແລ້ວຕັ້ງຄ່າດັ່ງນີ້:

• ຂອບເຂດຂອງໄຟລ໌: ອະນຸຍາດໃຫ້ອ່ານ ແລະ ຂຽນໄດ້ສະເພາະໄດເຣັກທໍຣີການເຮັດວຽກຂອງ Agent ເທົ່ານັ້ນ, ສ່ວນອື່ນໆ (ພື້ນທີ່ລະບົບ, ຂໍ້ມູນຂອງຜູ້ໃຊ້ອື່ນ, ສະຖານທີ່ເກັບຂໍ້ມູນການຢືນຢັນຕົວຕົນ) ຈະບໍ່ສາມາດເຂົ້າເຖິງໄດ້.
• ຂອບເຂດຂອງຂະບວນການ: ປິດກັ້ນ System call ທີ່ບໍ່ຈຳເປັນດ້ວຍ seccomp ເພື່ອບໍ່ໃຫ້ສາມາດເປີດຂະບວນການທີ່ບໍ່ຄາດຄິດ ຫຼື ຈັດການສິດທິຕ່າງໆໄດ້.

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

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

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

ປາຍທາງທົ່ວໄປທີ່ຄວນໃສ່ໃນບັນຊີລາຍຊື່ທີ່ອະນຸຍາດມີດັ່ງນີ້:

• ເອັນພອຍ (Endpoint) ຂອງ LLM API ທີ່ນຳໃຊ້
• ບໍລິການພາຍໃນອົງກອນທີ່ Agent ເຊື່ອມຕໍ່
• ແຫຼ່ງຂໍ້ມູນພາຍນອກທີ່ໄດ້ຮັບອະນຸຍາດໃຫ້ດຶງຂໍ້ມູນ

ການອະນຸຍາດຄວນເຮັດໃຫ້ໜ້ອຍທີ່ສຸດ (Minimize) ໂດຍບໍ່ພຽງແຕ່ກຳນົດ "Domain/IP" ເທົ່ານັ້ນ ແຕ່ຕ້ອງລວມເຖິງ "Port" ແລະ "Protocol" ນຳ. ການອະນຸຍາດເປັນຊ່ວງກວ້າງໆໃນຄັ້ງດຽວອາດກາຍເປັນຊ່ອງທາງໃນການຮົ່ວໄຫຼຂອງຂໍ້ມູນໄດ້. ສິ່ງທີ່ຄວນລະວັງຄືການຈັດການກັບ DNS ຫຼື ບໍລິການທີ່ເບິ່ງຄືວ່າບໍ່ມີອັນຕະລາຍ, ເພາະຖ້າອະນຸຍາດໂດຍບໍ່ມີເງື່ອນໄຂ, ສິ່ງເຫຼົ່ານີ້ອາດຖືກນຳໄປໃຊ້ໃນທາງທີ່ຜິດເປັນຊ່ອງທາງໃນການແບ່ງຂໍ້ມູນເປັນສ່ວນຍ່ອຍໆແລ້ວສົ່ງອອກໄປພາຍນອກ. ຄວນມີການກວດສອບບັນຊີລາຍຊື່ທີ່ອະນຸຍາດຢ່າງສະໝໍ່າສະເໝີ ແລະ ດຳເນີນການລຶບປາຍທາງທີ່ບໍ່ໄດ້ນຳໃຊ້ອອກ.

ເມື່ອ導入ນະໂຍບາຍເຄືອຂ່າຍ (ລວມເຖິງນະໂຍບາຍສິດທິອະນຸຍາດໂດຍລວມ), ການບັງຄັບໃຊ້ (enforce) ແບບທັນທີທັນໃດ (ບລັອກການລະເມີດທັງໝົດ) ອາດມີຄວາມສ່ຽງທີ່ຈະເຮັດໃຫ້ການດຳເນີນງານຢຸດສະງັກ. ດັ່ງນັ້ນ, ຈຶ່ງຄວນນຳໃຊ້ໂໝດ audit (ບັນທຶກການລະເມີດແຕ່ຍັງອະນຸຍາດໃຫ້ຜ່ານ) ແລະ ໂໝດ enforce ສະຫຼັບກັນ.

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

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

ຂັ້ນຕອນທີ 3 ແມ່ນການລວມເອົາບັນທຶກການກວດສອບ (Audit log) ເພື່ອຕິດຕາມການເຮັດວຽກຂອງ Agent ຍ້ອນຫຼັງ ແລະ ກົນໄກການອະນຸມັດໂດຍມະນຸດກ່ອນການດຳເນີນການທີ່ມີຄວາມສ່ຽງສູງ. ນີ້ແມ່ນຊັ້ນທີ່ຮັບມືກັບຄວາມສ່ຽງທີ່ຍັງເຫຼືອ ຫຼັງຈາກທີ່ໄດ້ຈຳກັດ "ຂອບເຂດທີ່ສາມາດເຮັດໄດ້" ໂດຍການແຍກອອກຈາກລະບົບຫຼັກ.

ບັນທຶກການກວດສອບ (Audit log) ຈະບັນທຶກວ່າ "Agent ພະຍາຍາມເຮັດຫຍັງ ແລະ ໄດ້ຮັບອະນຸຍາດ ຫຼື ຖືກປະຕິເສດ". ຢ່າງໜ້ອຍຄວນເກັບຂໍ້ມູນຕໍ່ໄປນີ້ໄວ້:

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

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

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

ພື້ນຖານຂອງການອອກແບບແມ່ນການແບ່ງປະເພດການປະຕິບັດງານຕາມຄວາມສ່ຽງ:

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

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

ນີ້ແມ່ນຂໍ້ຜິດພາດທີ່ມັກພົບໃນການນຳໃຊ້ Sandbox isolation ພ້ອມກັບວິທີການຫຼີກລ່ຽງ:

ຂໍ້ຜິດພາດ 1: ການແຍກສ່ວນທີ່ຫ່າງເກີນໄປຈົນບໍ່ມີຄວາມໝາຍ. ເປັນກໍລະນີທີ່ພຽງແຕ່ "ເອົາໃສ່ Container ໄວ້ກ່ອນ" ແຕ່ພາຍໃນຍັງອະນຸຍາດໃຫ້ມີສິດທິສູງ ແລະ ການສື່ສານທີ່ອິດສະຫຼະ. ວິທີຫຼີກລ່ຽງຄື: ຕ້ອງປະຕິບັດຕາມຫຼັກການສິດທິຂັ້ນຕໍ່າສຸດ (Least Privilege) ແລະ ປະຕິເສດການເຂົ້າເຖິງໂດຍຄ່າເລີ່ມຕົ້ນ (Default Deny), ໂດຍອະນຸຍາດໃຫ້ໃຊ້ງານໄດ້ສະເພາະຂອບເຂດທີ່ກຳນົດໄວ້ໃນລາຍການອະນຸຍາດ (Allowlist) ເທົ່ານັ້ນ.

ຂໍ້ຜິດພາດ 2: ເຂັ້ມງວດເກີນໄປຈົນວຽກງານຢຸດສະງັກ. ເປັນກໍລະນີທີ່ປິດກັ້ນແມ້ແຕ່ການສື່ສານ ຫຼື ການເຂົ້າເຖິງໄຟລ໌ທີ່ຈຳເປັນ ຈົນເຮັດໃຫ້ Agent ບໍ່ສາມາດເຮັດວຽກໄດ້. ວິທີຫຼີກລ່ຽງຄື: ໃຫ້ເປີດໃຊ້ງານໃນໂໝດ Audit ເພື່ອທົດສອບການເຮັດວຽກຕົວຈິງ, ລະບຸການອະນຸຍາດທີ່ຈຳເປັນໃຫ້ຄົບຖ້ວນ ກ່ອນທີ່ຈະປ່ຽນໄປໃຊ້ໂໝດ Enforce.

ຂໍ້ຜິດພາດ 3: ຂໍ້ມູນການຢືນຢັນຕົວຕົນສາມາດເບິ່ງເຫັນໄດ້ຈາກ Agent. ເປັນກໍລະນີທີ່ມີການວາງ Key ທີ່ເປັນຂໍ້ຄວາມທຳມະດາ (Plaintext) ໄວ້ໃນຕົວແປສະພາບແວດລ້ອມ (Environment Variables) ຫຼື ໄຟລ໌ຕັ້ງຄ່າ ເຊິ່ງເຮັດໃຫ້ສາມາດອ່ານໄດ້ຈາກພາຍໃນສະພາບແວດລ້ອມທີ່ແຍກອອກມາ. ວິທີຫຼີກລ່ຽງຄື: ແຍກ Secret ໄປໄວ້ໃນກົນໄກການຈັດການສະເພາະ ແລະ ເຮັດໃຫ້ມັນບໍ່ສາມາດເບິ່ງເຫັນໄດ້ຈາກໄດເລກະທໍລີທີ່ເຮັດວຽກ.

ຂໍ້ຜິດພາດ 4: ບໍ່ມີການບັນທຶກ Log ຫຼື ສາມາດແກ້ໄຂ Log ໄດ້. ເປັນກໍລະນີທີ່ບໍ່ສາມາດຕິດຕາມໄດ້ວ່າເກີດຫຍັງຂຶ້ນເມື່ອມີອຸບັດຕິເຫດ ຫຼື ຕົວ Agent ເອງສາມາດແກ້ໄຂ Log ໄດ້. ວິທີຫຼີກລ່ຽງຄື: ລວບລວມ Audit Log ໄວ້ພາຍນອກ ແລະ ຕັ້ງຄ່າໃຫ້ບໍ່ສາມາດແກ້ໄຂໄດ້.

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

Q1. ການນຳໃສ່ Container ພຽງພໍແລ້ວບໍ? ການເຮັດ Containerization ເປັນພຽງຈຸດເລີ່ມຕົ້ນ ແລະ ຫຼາຍຄັ້ງກໍຍັງບໍ່ພຽງພໍ. ຖ້າຍັງມີການອະນຸຍາດໃຫ້ໃຊ້ສິດ Root, ມີຄວາມສາມາດ (Capabilities) ຫຼາຍເກີນຄວາມຈຳເປັນ, ຫຼື ມີການສື່ສານກັບພາຍນອກຢ່າງເສລີ, ຄວາມເສຍຫາຍກໍສາມາດເກີດຂຶ້ນພາຍໃນ Container ໄດ້. ຕ້ອງລວມເຖິງການຕັ້ງຄ່າສິດຂັ້ນຕ່ຳ (Least Privilege), ການປະຕິເສດໂດຍຄ່າເລີ່ມຕົ້ນ (Default Deny), ແລະ ການກຳນົດຂອບເຂດຂອງໄຟລ໌/ຂະບວນການ ຈຶ່ງຈະສາມາດເອີ້ນໄດ້ວ່າເປັນ "ການແຍກສ່ວນ (Isolation)".

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

Q3. ຖ້າໃຊ້ Managed Service ຂອງ Cloud ແລ້ວ ບໍ່ຈຳເປັນຕ້ອງແຍກສ່ວນແມ່ນບໍ? ເຖິງແມ່ນວ່າຈະຢູ່ໃນສະພາບແວດລ້ອມແບບ Managed, ການອອກແບບສິດທີ່ມອບໃຫ້ Agent, ຂອບເຂດການສື່ສານ, ແລະ ການເຂົ້າເຖິງຂໍ້ມູນ ກໍຍັງເປັນຄວາມຮັບຜິດຊອບຂອງຜູ້ໃຊ້ງານ. ຄວນແຍກໃຫ້ອອກລະຫວ່າງຄວາມແຂງແກ່ນຂອງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ກັບການອອກແບບສິດທີ່ບໍລິສັດຂອງທ່ານສ້າງຂຶ້ນເອງ, ແລະ ຄວນດຳເນີນການຈັດລະບຽບເງື່ອນໄຂເບື້ອງຕົ້ນ ແລະ ການອອກແບບນະໂຍບາຍຕາມບົດຄວາມນີ້.

Q4. ການແຍກສ່ວນຈະເຮັດໃຫ້ປະສິດທິພາບຂອງ Agent ຫຼຸດລົງບໍ? ຖ້າອອກແບບຢ່າງເໝາະສົມ, ການເຂົ້າເຖິງທີ່ຈຳເປັນຕໍ່ການເຮັດວຽກຈະໄດ້ຮັບການອະນຸຍາດ, ສະນັ້ນປະສິດທິພາບໃນການເຮັດວຽກຕົວຈິງຈະຍັງຄົງຢູ່ເກືອບທັງໝົດ. ສິ່ງທີ່ເປັນບັນຫາບໍ່ແມ່ນປະສິດທິພາບ ແຕ່ແມ່ນ "ການອະນຸຍາດທີ່ຫຼາຍ ຫຼື ໜ້ອຍເກີນໄປ", ດັ່ງນັ້ນການກວດສອບການເຂົ້າເຖິງທີ່ຈຳເປັນໃນໂໝດ Audit ກ່ອນທີ່ຈະປ່ຽນໄປໃຊ້ໂໝດ Enforce ຈຶ່ງເປັນວິທີທີ່ເໝາະສົມໃນທາງປະຕິບັດ.

ການແຍກ Sandbox ຂອງ AI Agent ແມ່ນພື້ນຖານໃນການປົກປ້ອງຂໍ້ມູນພາຍໃນ ແລະ ຂໍ້ມູນການຢືນຢັນຕົວຕົນ ຈາກ Agent ທີ່ເຮັດວຽກແບບອັດຕະໂນມັດ. ເນື່ອງຈາກການຄວບຄຸມໃນລະດັບ Prompt ແລະ App Layer ສາມາດຖືກເຈາະໄດ້, ການປ້ອງກັນແບບຫຼາຍຊັ້ນ (Defense-in-depth) ທີ່ສ້າງສະພາວະ "ບໍ່ສາມາດປະຕິບັດງານ ຫຼື ເຂົ້າເຖິງໄດ້ຕັ້ງແຕ່ຕົ້ນ" ໃນລະດັບ OS, Network ແລະ ນະໂຍບາຍສິດທິການເຂົ້າເຖິງ ຈຶ່ງເປັນສິ່ງທີ່ຂາດບໍ່ໄດ້.

ການຈັດຕັ້ງປະຕິບັດສາມາດແບ່ງອອກເປັນ 3 ຂັ້ນຕອນ: ແຍກສະພາບແວດລ້ອມການເຮັດວຽກດ້ວຍ Container/MicroVM ແລະ ຈຳກັດຂອບເຂດຂອງໄຟລ໌ ແລະ ຂະບວນການ (ຂັ້ນຕອນທີ 1). ຄວບຄຸມເຄືອຂ່າຍດ້ວຍການປະຕິເສດໂດຍຄ່າເລີ່ມຕົ້ນ (Default Deny) ແລະ ບັນຊີລາຍຊື່ທີ່ອະນຸຍາດ (Allowlist) (ຂັ້ນຕອນທີ 2). ລວມເອົາບັນທຶກການກວດສອບ (Audit Log) ແລະ ການອະນຸມັດໂດຍມະນຸດສຳລັບການປະຕິບັດງານທີ່ມີຄວາມສ່ຽງສູງ (ຂັ້ນຕອນທີ 3). ທັງໝົດນີ້ຕັ້ງຢູ່ເທິງຫຼັກການພື້ນຖານດຽວກັນ ຄື: ສິດທິຂັ້ນຕໍ່າສຸດ (Least Privilege), ການປະຕິເສດໂດຍຄ່າເລີ່ມຕົ້ນ (Default Deny), ແລະ ການປ່ຽນຜ່ານຈາກການກວດສອບ (Audit) ໄປສູ່ການບັງຄັບໃຊ້ (Enforce).

ສຳລັບບໍລິສັດຍີ່ປຸ່ນທີ່ດຳເນີນທຸລະກິດໃນບັນດາປະເທດ ASEAN, ການອອກແບບທີ່ຄຳນຶງເຖິງກົດໝາຍປົກປ້ອງຂໍ້ມູນຂອງທ້ອງຖິ່ນແມ່ນມີຄວາມຈຳເປັນ. ບໍລິສັດຂອງພວກເຮົາໃຫ້ການສະໜັບສະໜູນການນຳໃຊ້ AI Agent ຢ່າງປອດໄພ ແລະ ການຈັດຕັ້ງລະບົບ Governance. ຫາກທ່ານຕ້ອງການອອກແບບຮ່ວມກັນວ່າ "ຄວນປິດກັ້ນຫຍັງ ໃນລະດັບໃດ" ສຳລັບ Agent ຂອງບໍລິສັດທ່ານ, ກະລຸນາປຶກສາຫາລືກັບພວກເຮົາໄດ້ທຸກເມື່ອ.