ການຈັດການຕົວຕົນຂອງ AI Agent — ການອອກແບບການຢືນຢັນຕົວຕົນ, ການອະນຸຍາດ ແລະ ການກວດສອບສຳລັບ Non-Human Identity (NHI)

ການຈັດການຕົວຕົນຂອງ AI Agent ແມ່ນຄວາມພະຍາຍາມໃນການຈັດການ, ອອກແບບ ແລະ ດຳເນີນງານດ້ານການຢືນຢັນຕົວຕົນ, ການອະນຸມັດສິດ ແລະ ການກວດສອບ ໂດຍຖືວ່າ AI Agent ເປັນຫົວໜ່ວຍ (Non-human ID) ທີ່ສາມາດລະບຸຕົວຕົນໄດ້ຢ່າງຊັດເຈນວ່າ "ກຳລັງເຄື່ອນໄຫວໃນນາມໃຜ". ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອວິສະວະກອນ ແລະ ຜູ້ຮັບຜິດຊອບດ້ານຄວາມປອດໄພທີ່ກຳລັງດຳເນີນງານ AI Agent ໃນລະບົບຕົວຈິງ, ໂດຍຈະເນັ້ນໃສ່ຫົວຂໍ້ "ຈະຕ້ອງຢືນຢັນຕົວຕົນໃນນາມ ID ໃດ ແລະ ຈະມີການຈັດການວົງຈອນຊີວິດຂອງ ID ນັ້ນແນວໃດ" ເຊິ່ງເປັນຂັ້ນຕອນກ່ອນທີ່ຈະໄປເຖິງເລື່ອງ "Agent ສາມາດເຮັດຫຍັງໄດ້ແດ່" (ການອະນຸມັດສິດ ແລະ ສິດຂັ້ນຕໍ່າສຸດ). ເມື່ອອ່ານຈົບ, ທ່ານຈະໄດ້ຮັບແຜນວາດເພື່ອເລີ່ມຕົ້ນການຈັດຕັ້ງປະຕິບັດໃນສະພາບແວດລ້ອມຂອງທ່ານເອງ ໂດຍມີແນວຄວາມຄິດເລື່ອງ Non-human ID (NHI) ເປັນແກນຫຼັກ ເຊິ່ງກວມເອົາການອອກແບບທີ່ຕໍ່ເນື່ອງກັນຕັ້ງແຕ່ການອອກ ID, Credential ທີ່ມີອາຍຸສັ້ນ, ການມອບໝາຍສິດ, ການຍົກເລີກສິດ ຈົນເຖິງບັນທຶກການກວດສອບ.

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

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

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

ຍິ່ງໄປກວ່ານັ້ນ, ຈຳນວນຂອງ Agent ບໍ່ໄດ້ຖືກຈຳກັດຢູ່ທີ່ຈຳນວນພະນັກງານ. ມັນບໍ່ແມ່ນເລື່ອງແປກທີ່ນັກພັດທະນາຄົນໜຶ່ງຈະສ້າງ Agent ຂຶ້ນມາຫຼາຍຕົວ ແລະ ແຕ່ລະຕົວຮັບຜິດຊອບ Workload ທີ່ແຕກຕ່າງກັນ. ຜົນກໍຄື, ຈຳນວນ ID ທັງໝົດທີ່ຕ້ອງບໍລິຫານຈັດການຈະສູງກວ່າຈຳນວນຄົນໃນອົງກອນຢ່າງຫຼວງຫຼາຍ, ເຮັດໃຫ້ ID ທີ່ບໍ່ແມ່ນຂອງມະນຸດ (Non-human ID) ມີແນວໂນ້ມທີ່ຈະມີຈຳນວນຫຼາຍກວ່າ ID ຂອງມະນຸດ. ບັນຊີລາຍຊື່ ID ແລະ ການດຳເນີນງານດ້ານການກວດສອບທີ່ອອກແບບມາໂດຍອີງໃສ່ຈຳນວນຄົນນັ້ນ ບໍ່ສາມາດຮອງຮັບການເພີ່ມທະວີຂຶ້ນເລື້ອຍໆນີ້ໄດ້. ການທີ່ສົມມຸດຕິຖານພື້ນຖານໃນ 3 ແກນຫຼັກ ຄື: ຄວາມຖີ່, ອາຍຸການໃຊ້ງານ ແລະ ຈຳນວນ ໄດ້ພັງທະລາຍລົງນັ້ນ ຄືເຫດຜົນພື້ນຖານທີ່ວ່າເປັນຫຍັງພວກເຮົາຈຶ່ງບໍ່ສາມາດນຳເອົາ IAM ຂອງມະນຸດມາປັບໃຊ້ກັບກໍລະນີນີ້ໄດ້ໂດຍກົງ.

ການອອກແບບໃຫ້ຫຼາຍ Agent ໃຊ້ API Key ຫຼື Service Account ດຽວກັນອາດເບິ່ງຄືວ່າງ່າຍໃນໄລຍະເລີ່ມຕົ້ນຂອງການດຳເນີນງານ ເພາະໃຊ້ພຽງ Credential ດຽວ ແລະ ການຕັ້ງຄ່າກໍບໍ່ຊັບຊ້ອນ. ແຕ່ຄວາມງ່າຍນີ້ຈະສົ່ງຜົນກັບມາໃນພາຍຫຼັງ ໃນຮູບແບບຂອງການບໍ່ສາມາດຕິດຕາມໄດ້ ແລະ ຄວາມເສຍຫາຍທີ່ຂະຫຍາຍວົງກວ້າງເມື່ອເກີດການຮົ່ວໄຫຼ.

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

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

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

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

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

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

Non-Human Identity (NHI) ແມ່ນຄຳສັບລວມທີ່ໃຊ້ເອີ້ນ ID ທີ່ຖືກກຳນົດໃຫ້ກັບຫົວໜ່ວຍທີ່ບໍ່ແມ່ນມະນຸດ ເຊັ່ນ: AI Agent, ບໍລິການ, ຫຼື Workload ເພື່ອໃຊ້ໃນການຢືນຢັນຕົວຕົນ, ການໃຫ້ສິດທິ, ແລະ ການກວດສອບ. ມັນເປັນແນວຄວາມຄິດທີ່ນຳເອົາສິ່ງທີ່ເຄີຍຖືກເອີ້ນແຍກກັນວ່າ "Service Account" ຫຼື "API Key" ມາພິຈາລະນາໃໝ່ໃນຖານະໝວດໝູ່ດຽວກັນຈາກມຸມມອງດ້ານການກຳກັບດູແລ (Governance). ໃນບົດນີ້, ພວກເຮົາຈະມາຈັດລະບຽບໃຫ້ເຫັນວ່າ NHI ກວມເອົາຫຍັງແດ່, ມີຄວາມແຕກຕ່າງຈາກ ID ຂອງມະນຸດແນວໃດ, ມີສິ່ງທ້າທາຍໃດໃນການຈັດການ, ແລະ ເປັນຫຍັງມັນຈຶ່ງໄດ້ຮັບຄວາມສົນໃຈໃນປັດຈຸບັນ.

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

ຕໍ່ມາຄື Service Account ເຊິ່ງເປັນບັນຊີສະເພາະທີ່ບໍ່ໄດ້ຜູກມັດກັບມະນຸດ ທີ່ແອັບພລິເຄຊັນໜຶ່ງໃຊ້ເພື່ອເຂົ້າເຖິງອີກລະບົບໜຶ່ງ. ມັນຖືກນຳໃຊ້ຢ່າງກວ້າງຂວາງໃນການປະມວນຜົນແບບ Batch, ການຕັ້ງເວລາປະຕິບັດງານ (Scheduled Execution) ແລະ ການເຊື່ອມຕໍ່ລະຫວ່າງລະບົບ. ໃນສະພາບແວດລ້ອມ Cloud, ການກຳນົດ ID ໃຫ້ກັບ Workload ໂດຍກົງ ເຊັ່ນ: Serverless Function ຫຼື Container ແລະ ການໃຫ້ເຂົ້າເຖິງບໍລິການອື່ນຜ່ານ ID Federation ກໍກາຍເປັນໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ທົ່ວໄປ.

ນອກຈາກນີ້, CI/CD ຂະບວນການ ຫຼື Pipeline, Token ສຳລັບເຊື່ອມຕໍ່ກັບ SaaS ພາຍນອກ, ແລະ ອຸປະກອນ IoT ຕ່າງໆ ກໍຖືເປັນຫົວໜ່ວຍທີ່ບໍ່ແມ່ນມະນຸດ ເຊິ່ງຕ້ອງໄດ້ຮັບການຢືນຢັນຕົວຕົນ ແລະ ການອະນຸມັດສິດ. ທີ່ຜ່ານມາ, ສິ່ງເຫຼົ່ານີ້ຖືກຈັດການແຍກກັນຕາມບໍລິບົດຂອງໃຜລາວ ເຊັ່ນ: API Key, OAuth Client, Service Account, ແລະ ໃບຢັ້ງຢືນ (Certificate).

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

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

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

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

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

ເບື້ອງຫຼັງການທີ່ແນວຄິດການບໍລິຫານຈັດການແບບ NHI ໄດ້ຮັບຄວາມສົນໃຈນັ້ນ ມີການປ່ຽນແປງທາງໂຄງສ້າງຢູ່ຫຼາຍປະການ. ສິ່ງທີ່ສຳຄັນທີ່ສຸດຄື ການແຜ່ຂະຫຍາຍຂອງຮູບແບບການພັດທະນາແບບ Cloud-native. ເມື່ອການປ່ຽນໄປສູ່ Microservices ມີຄວາມຄືບໜ້າ ແລະ ລະບົບຖືກແບ່ງອອກເປັນສ່ວນປະກອບນ້ອຍໆຈຳນວນຫຼາຍ, ຈຶ່ງເກີດຄວາມຈຳເປັນທີ່ແຕ່ລະສ່ວນຕ້ອງມີ ການຢືນຢັນຕົວຕົນ ເຊິ່ງກັນແລະກັນ. ທຸກຄັ້ງທີ່ມີການສື່ສານລະຫວ່າງບໍລິການ (Service) ຈຳເປັນຕ້ອງມີ ID, ເຮັດໃຫ້ຈຳນວນຂອງ "ໜ່ວຍງານທີ່ບໍ່ແມ່ນມະນຸດ" (Non-human entities) ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ.

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

ນອກຈາກນັ້ນ, ການທີ່ການຮົ່ວໄຫຼຂອງ Credential ກາຍເປັນໄພຄຸກຄາມທີ່ເຫັນໄດ້ຊັດເຈນ ກໍເປັນອີກໜຶ່ງເບື້ອງຫຼັງ. API Key ທີ່ຖືກຂຽນລົງໃນ Code repository ຫຼື Log ໂດຍບໍ່ຕັ້ງໃຈ, ລວມເຖິງ Key ຂອງ Service account ທີ່ຖືກ ຄົງຄ່າໄວ້ ໂດຍບໍ່ມີການໝູນວຽນ (Rotation) ເປັນເວລາດົນນານ, ມັກຈະກາຍເປັນຈຸດເລີ່ມຕົ້ນຂອງການໂຈມຕີ. ຍິ່ງມີ "ໜ່ວຍງານທີ່ບໍ່ແມ່ນມະນຸດ" ເພີ່ມຂຶ້ນເທົ່າໃດ, ປະລິມານລວມຂອງ Credential ທີ່ບໍ່ໄດ້ຮັບການຄຸ້ມຄອງເຫຼົ່ານີ້ກໍຍິ່ງເພີ່ມຂຶ້ນ ແລະ ເຮັດໃຫ້ພື້ນທີ່ການໂຈມຕີຂະຫຍາຍຕົວອອກໄປ.

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

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

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

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

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

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

Credential ແບບອາຍຸສັ້ນມັກຈະຖືກນຳມາໃຊ້ໃນຮູບແບບຂອງການຂໍ Token ທີ່ມີວັນໝົດອາຍຸໃນທຸກຄັ້ງທີ່ຕ້ອງການໃຊ້ງານ ແລະ ເມື່ອໝົດອາຍຸກໍຈະຂໍ Token ໃໝ່ ເຊັ່ນດຽວກັບ Access Token ຂອງ OAuth2.0. ນອກຈາກນີ້ ຍັງມີກົນໄກຢ່າງ Workload ID Federation ທີ່ໃຊ້ສະພາບແວດລ້ອມທີ່ Agent ຕັ້ງຢູ່ເປັນຈຸດເລີ່ມຕົ້ນຂອງຄວາມເຊື່ອຖື (Trust) ເພື່ອໃຫ້ໄດ້ມາເຊິ່ງຂໍ້ມູນການຢືນຢັນຕົວຕົນແບບອາຍຸສັ້ນ ໂດຍບໍ່ຈຳເປັນຕ້ອງເກັບຮັກສາຄີໄລຍະຍາວໄວ້. ທັງສອງວິທີນີ້ມີຈຸດປະສົງດຽວກັນຄື "ບໍ່ເກັບຮັກສາຄວາມລັບໄວ້ເປັນເວລາດົນ".

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

ທັງ Credential ແບບອາຍຸສັ້ນ ແລະ ການເຮັດ Rotation ມີແນວຄິດຮ່ວມກັນຄື "ການຕັ້ງໃຈເຮັດໃຫ້ໄລຍະເວລາທີ່ຄວາມລັບຍັງມີຜົນບັງຄັບໃຊ້ສັ້ນລົງ". ການອອກແບບໂດຍບໍ່ຂຽນຄີລົງໃນ Code ຫຼື ໄຟລ໌ຕັ້ງຄ່າໂດຍກົງ ແຕ່ໃຫ້ດຶງຂໍ້ມູນມາໃຊ້ໃນຂະນະທີ່ເຮັດວຽກ (Runtime) ແລະ ໃຊ້ພຽງໄລຍະເວລາສັ້ນໆ ຈະຊ່ວຍໃຫ້ຈຳກັດຄວາມເສຍຫາຍໄດ້ງ່າຍຂຶ້ນຫາກເກີດການຮົ່ວໄຫຼ.

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

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

ໃນການປ້ອງກັນການສວມຮອຍ, ກຸນແຈສຳຄັນຄືການສາມາດກວດສອບໄດ້ໃນຂັ້ນຕອນການຢືນຢັນຕົວຕົນວ່າ "ໃຜກຳລັງເຄື່ອນໄຫວໃນນາມຂອງໃຜ". ຝ່າຍທີ່ຮັບ Token ຕ້ອງສາມາດກວດສອບໄດ້ວ່າ Token ທີ່ Agent ນຳສະເໜີນັ້ນ ຖືກອອກໃຫ້ເພື່ອຕົວ Agent ເອງແທ້ໆ ຫຼື ຖືກອອກໃຫ້ເພື່ອເປັນຕົວແທນຂອງບຸກຄົນໃດ. ມາດຕະຖານເຊັ່ນ OAuth2.0 ແລະ OpenID Connect ໄດ້ສະໜອງໂຄງຮ່າງທີ່ຮອງຮັບການກວດສອບເຫຼົ່ານີ້ ໂດຍການບັນຈຸເປົ້າໝາຍການອອກ Token ແລະ ຈຸດປະສົງການໃຊ້ງານໄວ້ໃນ Token ນັ້ນ.

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

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

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

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

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

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

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

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

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

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

ຂັ້ນຕອນທຳອິດແມ່ນການອອກ ID ສະເພາະໃຫ້ແກ່ແຕ່ລະ Agent ເຊິ່ງນີ້ຄື ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການອອກແບບ NHI. ຖ້າຫາກທ່ານກຳລັງໃຊ້ງານດ້ວຍ Shared Key, ໃຫ້ຕັ້ງເປົ້າໝາຍໃນການປ່ຽນຜ່ານໄປສູ່ສະຖານະ "1 Agent 1 ID" ກ່ອນ. ໃຫ້ກຳນົດຊື່ ຫຼື ID ທີ່ສາມາດລະບຸຕົວຕົນຂອງແຕ່ລະ Agent ໄດ້ຢ່າງຊັດເຈນ ແລະ ບັນທຶກ Metadata ໄວ້ວ່າ Agent ນັ້ນເຮັດວຽກເພື່ອຈຸດປະສົງໃດ ແລະ ໃຜເປັນຜູ້ຮັບຜິດຊອບ.

ສຳລັບວິທີການດຳເນີນການຢ່າງເປັນຮູບປະທຳ, ຕົວຢ່າງເຊັ່ນ: ການຈັດລະບຽບຂໍ້ມູນຕໍ່ໄປນີ້ໃຫ້ແກ່ແຕ່ລະ ID:

• ຊື່ ID (ຊື່ທີ່ໃຊ້ລະບຸຕົວຕົນຂອງ Agent ຢ່າງຊັດເຈນ)
• ເຈົ້າຂອງ (ບຸກຄົນ ຫຼື ທີມງານທີ່ມີຄວາມຮັບຜິດຊອບ)
• ຈຸດປະສົງ (Agent ນີ້ເຮັດວຽກໄປເພື່ອຫຍັງ)
• ອາຍຸການໃຊ້ງານທີ່ຄາດໄວ້ (ເປັນແບບຖາວອນ ຫຼື ຊົ່ວຄາວ)

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

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

ຂັ້ນຕອນທີສອງ ແມ່ນການປ່ຽນຂໍ້ມູນການຢືນຢັນຕົວຕົນທີ່ສົ່ງໃຫ້ Agent ໄປເປັນ Token ທີ່ມີອາຍຸການໃຊ້ງານສັ້ນ ເພື່ອຫຼຸດຜ່ອນສິດທິໃນດ້ານເວລາໃຫ້ໜ້ອຍທີ່ສຸດ. ຫຼັງຈາກສ້າງ ID ສະເພາະໃນຂັ້ນຕອນທີ 1 ແລ້ວ, ແທນທີ່ຈະຜູກມັດ Long-term key ໃສ່ກັບ ID ນັ້ນໂດຍກົງ, ໃຫ້ປ່ຽນມາເປັນການອອກ Token ທີ່ມີວັນໝົດອາຍຸສັ້ນໆມາໃຊ້ງານເມື່ອຈຳເປັນແທນ.

ສຳລັບແນວທາງການດຳເນີນການ, ເລີ່ມຈາກການກວດສອບ Long-term key ຫຼື ຂໍ້ມູນການຢືນຢັນຕົວຕົນທີ່ຖືກ Hard-code ໄວ້ໃນປັດຈຸບັນທີ່ Agent ກຳລັງໃຊ້ງານຢູ່. ຈາກນັ້ນ, ໃຫ້ພິຈາລະນາວ່າສາມາດປ່ຽນແທນສິ່ງເຫຼົ່ານັ້ນດ້ວຍການຢືນຢັນຕົວຕົນແບບໃຊ້ Token ໄດ້ຫຼືບໍ່. ຕົວຢ່າງເຊັ່ນ: ການໃຊ້ Access Token ຂອງ OAuth 2.0 ໂດຍການຂໍ Token ທີ່ມີວັນໝົດອາຍຸໃນແຕ່ລະຄັ້ງ ແລະ ຂໍໃໝ່ທຸກຄັ້ງທີ່ Token ໝົດອາຍຸ. ຖ້າເປັນສະພາບແວດລ້ອມ Cloud, ການໃຊ້ Workload ID Federation ເພື່ອໃຫ້ສະພາບແວດລ້ອມການເຮັດວຽກຂອງ Agent ເປັນຈຸດເລີ່ມຕົ້ນຂອງຄວາມເຊື່ອໝັ້ນໃນການໄດ້ຮັບຂໍ້ມູນການຢືນຢັນຕົວຕົນທີ່ມີອາຍຸສັ້ນ ກໍເປັນທາງເລືອກໜຶ່ງເຊັ່ນກັນ.

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

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

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

ການຈັດລະບຽບການດຳເນີນງານທີ່ຕ້ອງການເຮັດໃຫ້ເປັນອັດຕະໂນມັດ ມີດັ່ງນີ້:

• ການຍົກເລີກສິດອັດຕະໂນມັດເມື່ອໝົດອາຍຸ (ການເຮັດໃຫ້ ID ຫຼື Token ທີ່ໝົດອາຍຸຕາມທີ່ກຳນົດໄວ້ຕອນອອກບັດ ໃຊ້ງານບໍ່ໄດ້ໂດຍອັດຕະໂນມັດ)
• ການໝູນວຽນ Secret ເປັນໄລຍະ (ໃນກໍລະນີທີ່ຈຳເປັນຕ້ອງໃຊ້ຂໍ້ມູນລັບໃນໄລຍະຍາວ ໃຫ້ມີການອັບເດດໂດຍອັດຕະໂນມັດຕາມໄລຍະເວລາທີ່ກຳນົດ)
• ການຍົກເລີກສິດ ID ຂອງ Agent ທີ່ຖືກຍົກເລີກ (ການເຮັດໃຫ້ ID ຂອງ Agent ທີ່ໝົດໜ້າທີ່ແລ້ວ ໃຊ້ງານບໍ່ໄດ້ໂດຍເຊື່ອມໂຍງກັບຂະບວນການຍົກເລີກ)

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

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

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

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

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

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

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

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

ອີກໜຶ່ງຈຸດສຳຄັນ ຫຼື ແກນຫຼັກທີ່ມັກພາດກັນຄື NHI Sprawl ເຊິ່ງເປັນສະພາວະທີ່ NHI ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆຈົນບໍ່ສາມາດຄວບຄຸມໄດ້ ແລະ ບໍ່ສາມາດກວດສອບໄດ້. ເອເຈນ (Agents) ຫຼື ບັນຊີບໍລິການ (Service Accounts) ຈະຖືກສ້າງຂຶ້ນຢ່າງງ່າຍດາຍທຸກຄັ້ງທີ່ມີການ Deploy ໂຄ້ດ ຫຼື ທົດສອບເລັກໆນ້ອຍໆ ໂດຍບໍ່ຜ່ານຂັ້ນຕອນການກວດສອບຄືກັບຂະບວນການຮັບພະນັກງານ. ເຖິງແມ່ນວ່າການຕັດສິນໃຈໃນແຕ່ລະຄັ້ງຈະເປັນເລື່ອງນ້ອຍໆ ແຕ່ເມື່ອສະສົມກັນໄປ ກໍຈະກາຍເປັນກອງ ID ທີ່ບໍ່ມີໃຜສາມາດເຂົ້າໃຈພາບລວມໄດ້.

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

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

ສິ່ງທີ່ມີປະສິດທິພາບຍິ່ງກວ່ານັ້ນຄື ການນຳໄປໃຊ້ຮ່ວມກັບການເຮັດໃຫ້ການໝົດອາຍຸເປັນແບບອັດຕະໂນມັດທີ່ໄດ້ກ່າວເຖິງໃນບົດກ່ອນ. ຖ້າມີກົນໄກທີ່ກຳນົດອາຍຸການໃຊ້ງານໄວ້ຕັ້ງແຕ່ຕອນອອກ ID ແລະ ໃຫ້ມັນໝົດອາຍຸໂດຍອັດຕະໂນມັດເມື່ອຮອດກຳນົດ ກໍຈະສາມາດຫຼຸດຈຳນວນ ID ທີ່ຖືກປ່ອຍປະລະເລີຍໄດ້. Sprawl ເກີດມາຈາກຄວາມບໍ່ສົມດຸນທີ່ວ່າ "ການອອກ ID ແມ່ນງ່າຍ ແຕ່ການຍົກເລີກຕ້ອງເຮັດດ້ວຍມື" ດັ່ງນັ້ນ ການອອກແບບໃຫ້ທັງສອງຢ່າງນີ້ສົມດຸນກັນຈຶ່ງເປັນວິທີການປ້ອງກັນທີ່ດີທີ່ສຸດ.

Q: ຕົວຕົນທີ່ບໍ່ແມ່ນມະນຸດ (NHI) ກັບບັນຊີບໍລິການ (Service Account) ແບບດັ້ງເດີມມີຄວາມແຕກຕ່າງກັນແນວໃດ? A: ເຖິງວ່າສິ່ງທີ່ກ່ຽວຂ້ອງຈະມີສ່ວນຊ້ອນທັບກັນ ແຕ່ການຕີຄວາມໝາຍນັ້ນແຕກຕ່າງກັນ. ບັນຊີບໍລິການເປັນຊື່ຂອງກົນໄກສະເພາະ ໃນຂະນະທີ່ NHI ເປັນແນວຄິດລະດັບສູງທີ່ລວມເອົາ "ຫົວໜ່ວຍທີ່ບໍ່ແມ່ນມະນຸດ ເຊິ່ງເປັນເປົ້າໝາຍຂອງການຢືນຢັນຕົວຕົນ, ການອະນຸມັດ ແລະ ການກວດສອບ" ເຂົ້າໄວ້ດ້ວຍກັນ ເຊັ່ນ: ບັນຊີບໍລິການ, API Key, ແລະ Workload ID. ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງ NHI ຄືແນວຄິດທີ່ຕ້ອງການຄວບຄຸມການບໍລິຫານຈັດການ (Governance) ຫົວໜ່ວຍທີ່ບໍ່ແມ່ນມະນຸດ ເຊິ່ງເຄີຍຖືກຈັດການແບບແຍກສ່ວນ ໃຫ້ມາຢູ່ພາຍໃຕ້ແກນກາງດຽວກັນ ຄື: ເຈົ້າຂອງ, ອາຍຸການໃຊ້ງານ ແລະ ສິດທິ.

Q: ຖ້າຂະໜາດນ້ອຍ ແລະ ມີຕົວແທນ (Agent) ພຽງ 1 ຫຼື 2 ຕົວ, ຍັງຈຳເປັນຕ້ອງມີກົນໄກ NHI ບໍ? A: ໃນຂະນະທີ່ຂະໜາດຍັງນ້ອຍ ການຮອງຮັບແບບໜ້ອຍທີ່ສຸດກໍມັກຈະພຽງພໍ ແຕ່ການນຳເອົາແນວຄິດນີ້ມາໃຊ້ໄວຈະຊ່ວຍໃຫ້ການເຮັດວຽກໃນພາຍຫຼັງງ່າຍຂຶ້ນ. ຢ່າງໜ້ອຍທີ່ສຸດ, ການບໍ່ນຳບັນຊີຂອງມະນຸດມາໃຊ້ງານແທນ ແລະ ການອອກ ID ສະເພາະສຳລັບ Agent ລວມເຖິງການຫຼີກລ່ຽງການຂຽນ Key ໄລຍະຍາວລົງໃນ Code ໂດຍກົງ ແມ່ນສິ່ງທີ່ມີຄຸນຄ່າຄວນປະຕິບັດເຖິງແມ່ນວ່າຈະມີຈຳນວນໜ້ອຍກໍຕາມ. ເນື່ອງຈາກ Agent ມີໂອກາດທີ່ຈະ ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ, ການດຳເນີນງານດ້ວຍ ID ສະເພາະຕັ້ງແຕ່ຕົ້ນຈະຊ່ວຍຫຼີກລ່ຽງການກັບມາແກ້ໄຂໃໝ່ໃນພາຍຫຼັງເມື່ອມີຈຳນວນເພີ່ມຂຶ້ນ.

Q: ການຢືນຢັນຕົວຕົນ (Authentication - ເຮັດວຽກໃນນາມໃຜ) ແລະ ການອະນຸມັດ (Authorization - ເຮັດຫຍັງໄດ້ແດ່) ຄວນອອກແບບອັນໃດກ່ອນ? A: ລຳດັບທີ່ເປັນທຳມະຊາດຄື ການຢືນຢັນຕົວຕົນເພື່ອລະບຸຫົວໜ່ວຍໃຫ້ຊັດເຈນກ່ອນ ແລ້ວຈຶ່ງວາງການອະນຸມັດໄວ້ເທິງພື້ນຖານນັ້ນ. ເນື່ອງຈາກຖ້າບໍ່ສາມາດລະບຸໄດ້ວ່າໃຜເປັນຜູ້ສົ່ງຄຳຮ້ອງຂໍ ກໍຈະບໍ່ສາມາດກຳນົດຜູ້ທີ່ຈະໄດ້ຮັບສິດທິຂັ້ນຕໍ່າສຸດໄດ້. ບົດຄວາມນີ້ເນັ້ນໃສ່ການຢືນຢັນຕົວຕົນ ແລະ ວົງຈອນຊີວິດຂອງຕົວຕົນ (Identity Lifecycle), ສ່ວນການອອກແບບການອະນຸມັດຢ່າງລະອຽດ ເຊັ່ນ: ສິດທິຂັ້ນຕໍ່າສຸດ (Least Privilege) ແມ່ນຖືກຈັດເປັນຫົວຂໍ້ໃນອີກຊັ້ນໜຶ່ງ.

Q: ການນຳໃຊ້ Token ທີ່ມີອາຍຸສັ້ນ (Short-lived token) ຈະເຮັດໃຫ້ຂະບວນການຊັບຊ້ອນຂຶ້ນຍ້ອນຕ້ອງມີການຂໍ Token ໃໝ່ບໍ? A: ໃນຫຼາຍກໍລະນີ, ມາດຕະຖານ ຫຼື ກົນໄກທີ່ມີຢູ່ແລ້ວ ເຊັ່ນ: OAuth2.0 ຫຼື Workload ID Federation ຈະຮັບຜິດຊອບໃນການຂໍ ແລະ ອັບເດດ Token ເຮັດໃຫ້ຝັ່ງ Application ບໍ່ຈຳເປັນຕ້ອງພັດທະນາກົນໄກທີ່ຊັບຊ້ອນດ້ວຍຕົນເອງ. ໃນທາງກົງກັນຂ້າມ, ການດຳເນີນງານທີ່ຂຽນ Key ໄລຍະຍາວລົງໃນ Code ຫຼື ການຕັ້ງຄ່າໂດຍກົງ ຈະສ້າງຕົ້ນທຶນໃນພາຍຫຼັງໃນຮູບແບບຂອງການຈັດການເມື່ອເກີດຂໍ້ມູນຮົ່ວໄຫຼ ແລະ ຄວາມຫຍຸ້ງຍາກໃນການໝູນວຽນ Key (Rotation). Token ທີ່ມີອາຍຸສັ້ນແມ່ນການອອກແບບທີ່ຂໍ້ດີດ້ານຄວາມປອດໄພ ເຊິ່ງຊ່ວຍຫຼຸດໄລຍະເວລາທີ່ອາດເກີດຄວາມເສຍຫາຍເມື່ອມີການຮົ່ວໄຫຼນັ້ນ ມີຄ່າຫຼາຍກວ່າຄວາມຫຍຸ້ງຍາກໃນການນຳມາໃຊ້ງານ.