การจัดการอัตลักษณ์ของ AI Agent — การออกแบบการยืนยันตัวตน การอนุญาต และการตรวจสอบสำหรับ Non-Human Identity (NHI)

การจัดการอัตลักษณ์ของ AI Agent (AI Agent Identity Management) คือแนวทางในการปฏิบัติงานที่มองว่า AI Agent เป็นตัวตนที่สามารถระบุได้อย่างชัดเจน (Non-human ID) ว่า "กำลังทำงานในฐานะใคร" โดยมีการออกแบบและดำเนินการด้านการพิสูจน์ตัวตน (Authentication) การให้สิทธิ์ (Authorization) และการตรวจสอบ (Audit) อย่างสอดคล้องกัน บทความนี้มุ่งเน้นไปที่วิศวกรและผู้ดูแลความปลอดภัยที่ต้องนำ AI Agent ไปใช้งานจริง โดยจะเน้นไปที่หัวข้อ "จะพิสูจน์ตัวตนในฐานะ ID ใด และจะจัดการวงจรชีวิตของ ID นั้นอย่างไร" ซึ่งเป็นขั้นตอนที่อยู่ก่อนหน้าการกำหนดว่า Agent สามารถทำอะไรได้บ้าง (การให้สิทธิ์และหลักการสิทธิ์ขั้นต่ำ) เมื่ออ่านจบ คุณจะเข้าใจแนวคิดเรื่อง Non-human ID (NHI) ในฐานะแกนหลัก และเห็นภาพรวมของการออกแบบที่ครอบคลุมตั้งแต่การออก ID, การใช้ Credential ระยะสั้น, การมอบอำนาจ (Delegation), การเพิกถอนสิทธิ์ ไปจนถึงบันทึกการตรวจสอบ เพื่อให้คุณสามารถนำไปประยุกต์ใช้ในสภาพแวดล้อมของคุณเองได้

กล่าวโดยสรุปคือ AI Agent เป็นสิ่งที่ "แสดงพฤติกรรมเหมือนมนุษย์ แต่ไม่เป็นไปตามเงื่อนไขของ IAM สำหรับมนุษย์" ซึ่งส่งผลให้การจัดการ ID แบบเดิมไม่สามารถใช้งานได้ใน 3 ประเด็น ได้แก่ ความถี่ อายุการใช้งาน และความสามารถในการตรวจสอบ (Traceability) ID สำหรับมนุษย์ถูกออกแบบภายใต้สมมติฐานที่ว่า "หนึ่งคนใช้หนึ่งบัญชีเป็นระยะเวลานาน และมีการล็อกอินเพียงวันละไม่กี่ครั้ง" ในขณะที่ Agent จะส่งคำขอจำนวนมหาศาลด้วยความเร็วสูง และอาจถูกสร้างขึ้นหรือทำลายทิ้งภายในเวลาเพียงไม่กี่วินาที ในบทนี้จะสรุปเหตุผลว่าทำไมการนำ IAM สำหรับมนุษย์มาปรับใช้โดยตรงจึงล้มเหลว โดยพิจารณาจาก 3 มุมมอง ได้แก่ ลักษณะเฉพาะของการเข้าถึง (Access Characteristics), ข้อมูลประจำตัวที่ใช้ร่วมกัน (Shared Credentials) และข้อจำกัดของการให้สิทธิ์ (Authorization)

มนุษย์และ AI Agent มีความถี่ในการเข้าถึงและอายุการใช้งานที่แตกต่างกันอย่างสิ้นเชิง ผู้ใช้งานที่เป็นมนุษย์จะล็อกอินวันละไม่กี่ครั้ง โดยมีเซสชันที่ยาวนานตั้งแต่ไม่กี่ชั่วโมงไปจนถึงหลายวัน และพฤติกรรมค่อนข้างคาดเดาได้ง่าย ในทางตรงกันข้าม Agent อาจทำการเรียก API จำนวนมากติดต่อกันในระยะเวลาอันสั้นเพื่อทำภารกิจให้สำเร็จ ซึ่งความหนาแน่นของทราฟฟิกนั้นไม่สามารถนำมาเปรียบเทียบกับมนุษย์ได้เลย

ในด้านอายุการใช้งานก็มีความแตกต่างอย่างมากเช่นกัน ตัวอย่างเช่น Agent ที่ทำงานในสภาพแวดล้อมแบบ Serverless หรือ Container อาจมีลักษณะการทำงานที่สั้น โดยจะเริ่มทำงานเมื่อมีคำขอและหายไปเมื่อประมวลผลเสร็จสิ้น โมเดลแบบ "ใช้ข้อมูลยืนยันตัวตนเดิมต่อเนื่องเป็นเวลาหลายเดือนหรือหลายปี" เหมือนกับ ID ของมนุษย์ จึงไม่เหมาะกับเวิร์กโหลดที่มีลักษณะใช้แล้วทิ้งเช่นนี้ การกำหนด Credential แบบถาวรที่มีอายุการใช้งานยาวนานให้กับ Agent ที่มีอายุสั้น จะทำให้ Credential เหล่านั้นยังคงอยู่แม้ตัว Agent จะหายไปแล้ว ซึ่งมักจะหลุดจากการตรวจสอบและถูกปล่อยทิ้งไว้โดยไม่มีการจัดการ

นอกจากนี้ จำนวนของ Agent ยังไม่ได้ถูกจำกัดอยู่แค่จำนวนพนักงานที่เป็นมนุษย์ ไม่ใช่เรื่องแปลกที่นักพัฒนาหนึ่งคนจะเปิดใช้งาน Agent หลายตัว โดยแต่ละตัวรับผิดชอบเวิร์กโหลดที่แตกต่างกัน ส่งผลให้จำนวน ID ทั้งหมดที่ต้องจัดการมีมากกว่าจำนวนคนในองค์กรอย่างมาก และมีแนวโน้มที่ Non-human ID จะมีจำนวนมากกว่า Human ID ซึ่งระบบทะเบียน ID และการตรวจสอบที่ออกแบบมาโดยอิงจากจำนวนคนจะไม่สามารถรองรับอัตราการเพิ่มขึ้นนี้ได้ การที่สมมติฐานพื้นฐานทั้ง 3 ด้าน ได้แก่ ความถี่ อายุการใช้งาน และจำนวน เปลี่ยนไป คือเหตุผลสำคัญที่ทำให้ไม่สามารถนำระบบ IAM ของมนุษย์มาปรับใช้โดยตรงได้

การออกแบบให้เอเจนต์หลายตัวใช้ API Key หรือ Service Account ร่วมกันอาจดูสะดวกในขั้นตอนเริ่มต้นของการดำเนินงาน เพราะใช้ Credential เพียงชุดเดียวและตั้งค่าได้ง่าย อย่างไรก็ตาม ความสะดวกนี้จะย้อนกลับมาสร้างปัญหาในภายหลัง ทั้งในแง่ของการไม่สามารถตรวจสอบย้อนกลับได้ และความเสียหายที่ขยายวงกว้างเมื่อเกิดการรั่วไหล

ตัวอย่างเช่น หากเอเจนต์ 5 ตัวใช้คีย์ร่วมกันเพื่อเข้าถึงฐานข้อมูล บันทึกการตรวจสอบ (Audit Log) จะระบุเพียงว่า "คีย์นั้นเป็นผู้เข้าถึง" แต่ไม่สามารถแยกแยะได้ว่า "เอเจนต์ตัวใด" เป็นผู้ดำเนินการดังกล่าว เมื่อพบการทำงานที่ผิดปกติ จึงไม่สามารถระบุเอเจนต์ที่เป็นต้นเหตุได้ ทำให้การสืบสวนมักจะถึงทางตัน การที่ไม่สามารถติดตามได้ว่าใครทำอะไรส่งผลโดยตรงต่อความล่าช้าในการตอบสนองต่อเหตุการณ์ (Incident Response)

ในด้านความเสี่ยงจากการรั่วไหล Credential ที่ใช้ร่วมกันยังขยายขอบเขตผลกระทบโดยไม่จำเป็น หากคีย์หนึ่งหลุดออกไปภายนอก สิทธิ์ของเอเจนต์ทั้งหมดที่ใช้คีย์นั้นจะตกไปอยู่ในมือของผู้โจมตีทันที หากใช้หลักการ 1 เอเจนต์ต่อ 1 ID เราสามารถเพิกถอนสิทธิ์เฉพาะ ID ที่รั่วไหลได้ แต่ในการออกแบบที่ใช้ร่วมกัน การประเมินว่าผลกระทบจะลุกลามไปถึงจุดใดและการควบคุมความเสียหายต้องใช้เวลานาน

นอกจากนี้ Credential ที่ใช้ร่วมกันยังทำให้การตัดสินใจเพิกถอนสิทธิ์ทำได้ยาก หากต้องการยกเลิกการใช้งานเอเจนต์ตัวหนึ่ง แต่เอเจนต์ตัวอื่นยังคงใช้คีย์เดียวกันอยู่ ก็จะไม่สามารถปิดใช้งานคีย์นั้นได้ ส่งผลให้สิทธิ์ที่ไม่จำเป็นยังคงค้างอยู่ การที่การตรวจสอบย้อนกลับ การควบคุมความเสียหาย และการเพิกถอนสิทธิ์ทำได้ยากขึ้นจากการใช้ทรัพยากรร่วมกัน จึงเป็นเหตุผลว่าทำไมเราควรออก ID เฉพาะสำหรับเอเจนต์แต่ละตัว

เมื่อพูดถึงการควบคุมการเข้าถึง (Access Control) ของ AI Agent ความสนใจมักจะพุ่งไปที่การอนุญาต (Authorization) ซึ่งกำหนดว่า "ทำอะไรได้บ้าง" โดยเฉพาะการออกแบบสิทธิ์ขั้นต่ำ (Least Privilege) แม้ว่าการจำกัดสิทธิ์จะเป็นเรื่องสำคัญ แต่การอนุญาตเพียงอย่างเดียวไม่สามารถรับประกันความปลอดภัยได้ เพราะการอนุญาตเป็นเพียงกฎที่กำหนดว่า "อนุญาตให้ ID ใดทำปฏิบัติการใดได้บ้าง" ซึ่งจะไม่มีความหมายเลยหากปราศจากการยืนยันตัวตน (Authentication) ที่ตรวจสอบว่า "คำขอนั้นมาจาก ID นั้นจริงหรือไม่"

ตัวอย่างเช่น หากเราตั้งค่าสิทธิ์ขั้นต่ำ "อนุญาตให้อ่านได้อย่างเดียว" ให้กับ Agent ตัวหนึ่งไว้อย่างดีแล้ว แต่ถ้าข้อมูลการยืนยันตัวตนของ Agent นั้นถูกแชร์กับ Agent ตัวอื่น หรือมีการออกแบบที่เปิดช่องให้เกิดการสวมรอยได้ ก็จะทำให้ไม่ชัดเจนว่าใครเป็นผู้ใช้สิทธิ์นั้น ต่อให้จำกัดขอบเขตของสิทธิ์ไว้อย่างถูกต้อง แต่หากไม่สามารถระบุตัวตนของผู้ใช้สิทธิ์นั้นได้อย่างชัดเจน ก็จะไม่สามารถรับประกันได้ว่า "มีการมอบสิทธิ์ที่เหมาะสมให้กับคู่สนทนาที่เหมาะสม"

เหตุผลที่บทความนี้ไม่ได้ลงลึกเรื่องการอนุญาตหรือสิทธิ์ขั้นต่ำโดยตรง เป็นเพราะเรื่องเหล่านั้นเป็นคนละเลเยอร์กัน สิทธิ์ขั้นต่ำคือการออกแบบในขั้นตอน "การผูกสิทธิ์เข้ากับ ID" แต่บทความนี้จะกล่าวถึงขั้นตอนก่อนหน้านั้น คือ "การยืนยันตัวตนในฐานะ ID ใด และจะออกหรือจัดการ ID นั้นอย่างไร" หากเราตระหนักถึงลำดับขั้นตอนที่ว่าต้องสร้างตัวตนให้ชัดเจนด้วยการยืนยันตัวตนก่อน แล้วจึงค่อยวางการอนุญาตไว้ด้านบน ความรับผิดชอบของทั้งสองส่วนก็จะถูกจัดระเบียบให้ชัดเจนขึ้น การออกแบบสิทธิ์ขั้นต่ำอย่างเป็นรูปธรรมจะถูกยกให้เป็นหัวข้อที่เกี่ยวข้อง แต่ในที่นี้เราจะมุ่งเน้นไปที่วงจรชีวิตของ ID (ID Lifecycle) เป็นหลัก

Non-Human Identity (NHI) คือคำรวมที่ใช้เรียกอัตลักษณ์ที่ต้องผ่านการตรวจสอบสิทธิ์ (Authentication) การอนุญาต (Authorization) และการตรวจสอบ (Audit) ซึ่งกำหนดให้กับเอนทิตีที่ไม่ใช่มนุษย์ เช่น AI agent, บริการ (Service) และเวิร์กโหลด (Workload) เป็นแนวคิดที่นำสิ่งที่เคยเรียกแยกกันว่า "Service Account" หรือ "API Key" มาจัดกลุ่มใหม่ภายใต้หมวดหมู่เดียวกันในมุมมองของการกำกับดูแล (Governance) ในบทนี้จะสรุปให้เห็นว่า NHI ครอบคลุมถึงอะไรบ้าง แตกต่างจากอัตลักษณ์ของมนุษย์อย่างไร มีความท้าทายในการจัดการอย่างไร และเหตุใดจึงได้รับความสนใจในขณะนี้

NHI ไม่ได้มุ่งเน้นไปที่มนุษย์ที่อยู่หลังหน้าจอเข้าสู่ระบบ แต่เป็นตัวตน (entities) ที่ทำงานอย่างอิสระภายในระบบ ตัวอย่างที่ชัดเจนที่สุดคือ AI Agent ซึ่งหมายถึงเวิร์กโหลดในลักษณะเอเจนต์ที่รับคำสั่งจากผู้ใช้เพื่อเรียกใช้ API ภายนอก หรือดึงข้อมูลและประมวลผลข้อมูล

ถัดมาคือ Service Account ซึ่งเป็นบัญชีเฉพาะที่ไม่ได้ผูกกับมนุษย์ โดยแอปพลิเคชันใช้เพื่อเข้าถึงระบบอื่น ซึ่งมีการใช้งานอย่างแพร่หลายในงานประมวลผลแบบแบตช์ (batch processing), การตั้งเวลาทำงาน (scheduled execution) และการเชื่อมต่อระหว่างระบบ ในสภาพแวดล้อมคลาวด์ การกำหนด ID ให้กับเวิร์กโหลดโดยตรง เช่น Serverless functions หรือ Containers เพื่อให้เข้าถึงบริการอื่นผ่าน ID Federation ก็เป็นโครงสร้างที่พบเห็นได้ทั่วไป

นอกจากนี้ CI/CD pipeline, โทเค็นสำหรับการเชื่อมต่อกับ SaaS ภายนอก และอุปกรณ์ IoT ต่างก็ถือเป็นตัวตนที่ไม่ใช่มนุษย์ที่ต้องได้รับการพิสูจน์ตัวตน (Authentication) และการอนุญาต (Authorization) ซึ่งที่ผ่านมาสิ่งเหล่านี้ถูกจัดการแยกกันตามบริบท เช่น API keys, OAuth clients, Service accounts หรือใบรับรอง (Certificates)

หัวใจสำคัญของแนวคิด NHI คือการไม่จัดการสิ่งเหล่านี้แยกจากกัน แต่ให้มองรวมกันภายใต้หมวดหมู่เดียวกันคือ "ตัวตนที่ไม่ใช่มนุษย์ที่ควรได้รับการพิสูจน์ตัวตน" ด้วยการแพร่หลายของ AI Agent ทำให้ตัวตนที่ไม่ใช่มนุษย์เหล่านี้เพิ่มขึ้นอย่างรวดเร็ว จนการจัดการแบบแยกส่วนไม่สามารถทำให้เห็นภาพรวมได้อีกต่อไป ด้วยเหตุนี้ จึงจำเป็นต้องมีแนวคิดในการรวบรวมเป้าหมายเหล่านี้ไว้ภายใต้แนวคิดเดียวเพื่อจัดการอย่างเป็นเอกภาพ

ความแตกต่างที่สำคัญที่สุดระหว่าง NHI และ ID ของมนุษย์ คือ "ใคร" เป็นผู้กระตุ้นและ "กระตุ้นอย่างไร" ในวงจรชีวิตของ ID โดย ID ของมนุษย์จะถูกออก เปลี่ยนแปลง หรือลบตามเหตุการณ์ทางทรัพยากรบุคคล เช่น การเข้าทำงาน การย้ายตำแหน่ง หรือการลาออก ช่วงเวลาในการตรวจสอบสิทธิ์ก็ค่อนข้างชัดเจน ทำให้ง่ายต่อการรวมเข้าเป็นส่วนหนึ่งของการตรวจสอบสิทธิ์เข้าถึง (Access Review) ตามรอบเวลา ในขณะที่ NHI จะเกิดขึ้นจากเหตุการณ์ทางเทคนิค เช่น การปรับใช้โค้ด (Code Deployment) หรือการเริ่มการทำงานของเอเจนต์ตัวใหม่ ซึ่งไม่มีจุดเปลี่ยนที่แน่นอนเหมือนกระบวนการทางทรัพยากรบุคคล ทำให้ความชัดเจนว่าใครคือ "เจ้าของ" ID นั้นมักจะคลุมเครือ

ความท้าทายในการจัดการเกิดจากความคลุมเครือนี้ ประการแรก คือมักเกิด ID ที่ไม่มีเจ้าของ เช่น กรณีที่วิศวกรสร้างบัญชีบริการ (Service Account) ขึ้นมาใช้งานชั่วคราว แต่เมื่อเจ้าตัวย้ายตำแหน่งไปแล้ว บัญชีนั้นกลับไม่มีใครรับช่วงต่อและยังคงทำงานอยู่เรื่อยๆ ID ที่ไม่ทราบว่าใครเป็นผู้รับผิดชอบจะถูกปล่อยทิ้งไว้โดยไม่สามารถตัดสินใจได้ว่าจะยกเลิกหรือไม่

ประการที่สอง คือการตรวจสอบสิทธิ์ทำได้ยาก หากเป็น ID ของมนุษย์ เราสามารถตรวจสอบเทียบกับ "รายชื่อพนักงานที่ยังปฏิบัติงานอยู่" เพื่อค้นหา ID ที่ไม่จำเป็นได้ แต่สำหรับ NHI มักจะไม่มี "รายชื่อที่ถูกต้อง" (Source of Truth) มาให้เทียบ ทำให้ขาดข้อมูลในการตัดสินใจว่า ID ใดที่ยังจำเป็นและ ID ใดที่ไม่จำเป็นแล้ว

ประการที่สาม คือความหลากหลายของวิธีการยืนยันตัวตน ID ของมนุษย์มักได้รับการปกป้องด้วยวิธีการที่ค่อนข้างเป็นมาตรฐาน เช่น รหัสผ่านหรือการยืนยันตัวตนหลายชั้น (MFA) แต่ NHI กลับมีวิธีการที่หลากหลายปะปนกัน ทั้ง API Key, ใบรับรอง (Certificate) และ Token ซึ่งระดับการป้องกันมักจะแตกต่างกันไป หากนำวิธีการจัดการ ID ของมนุษย์มาปรับใช้โดยไม่คำนึงถึงความแตกต่างเหล่านี้ จะทำให้เกิด ID ที่หลุดรอดจากการควบคุม ดังนั้น NHI จึงจำเป็นต้องมีระบบกำกับดูแล (Governance) เฉพาะที่ระบุเจ้าของและอายุการใช้งานโดยอ้างอิงจากเหตุการณ์ทางเทคนิคเป็นหลัก

เบื้องหลังแนวคิดด้านธรรมาภิบาลที่เรียกว่า NHI (Non-Human Identity) ที่ได้รับความสนใจมากขึ้นนั้น มาจากการเปลี่ยนแปลงเชิงโครงสร้างหลายประการ สิ่งที่สำคัญที่สุดคือการแพร่หลายของรูปแบบการพัฒนาแบบ Cloud-native เมื่อมีการเปลี่ยนไปใช้ Microservices และระบบถูกแบ่งออกเป็นส่วนประกอบย่อยจำนวนมาก จึงเกิดความจำเป็นที่แต่ละส่วนต้องตรวจสอบสิทธิ์ซึ่งกันและกัน ทำให้ต้องใช้ ID ในการสื่อสารระหว่างบริการทุกครั้ง ส่งผลให้จำนวนตัวตนที่ไม่ใช่มนุษย์ (Non-human entities) เพิ่มขึ้นอย่างรวดเร็ว

ปัจจัยต่อมาคือการแพร่หลายของ AI Agent เนื่องจาก Agent สามารถเข้าถึง API หรือแหล่งข้อมูลภายนอกได้อย่างอิสระ การติดตั้งเพียงหนึ่งตัวจึงเท่ากับการเพิ่มตัวตนที่ต้องตรวจสอบสิทธิ์ขึ้นมาใหม่ และในโครงสร้างที่ให้ Agent หลายตัวทำงานร่วมกัน จำนวนดังกล่าวก็จะยิ่งเพิ่มมากขึ้น แนวโน้มที่ ID เพิ่มขึ้นโดยไม่สัมพันธ์กับจำนวนพนักงานที่เป็นมนุษย์นี้ กำลังเข้าสู่ระดับที่บัญชีรายชื่อ ID แบบเดิมหรือการตรวจสอบด้วยมือไม่สามารถติดตามได้ทัน

นอกจากนี้ การที่การรั่วไหลของข้อมูลรับรอง (Credential) กลายเป็นภัยคุกคามที่เกิดขึ้นจริงก็เป็นอีกหนึ่งปัจจัยสำคัญ API Key ที่ถูกเขียนลงใน Code repository หรือ Log โดยไม่ได้ตั้งใจ รวมถึง Key ของ Service account ที่ถูกทิ้งไว้โดยไม่มีการหมุนเวียนใช้งานเป็นเวลานาน มักกลายเป็นช่องทางให้ผู้โจมตีใช้เป็นจุดเริ่มต้น ยิ่งตัวตนที่ไม่ใช่มนุษย์มีจำนวนมากเท่าใด ปริมาณของข้อมูลรับรองที่ไม่มีการจัดการเหล่านี้ก็จะยิ่งเพิ่มขึ้น ส่งผลให้พื้นที่การโจมตี (Attack surface) ขยายกว้างขึ้น

ผลจากการเปลี่ยนแปลงเหล่านี้ทำให้แนวคิด NHI ที่มุ่งเน้นการทำให้ "ตัวตนที่ไม่ใช่มนุษย์" เป็นสิ่งที่มองเห็นได้ชัดเจนในฐานะหมวดหมู่หนึ่ง แทนที่จะแยกจัดการเป็นรายตัว และมุ่งเน้นการจัดการเจ้าของ อายุการใช้งาน และสิทธิ์อย่างเป็นระบบ กลายเป็นความจำเป็นที่จับต้องได้ กล่าวได้ว่านี่คือการเคลื่อนไหวเพื่อขยายขอบเขตของการจัดการ ID จากเดิมที่เน้นมนุษย์เป็นศูนย์กลาง ให้ครอบคลุมทั้งมนุษย์และสิ่งที่ไม่ใช่มนุษย์ไปพร้อมกัน

การจัดการข้อมูลรับรอง (Credentials) สำหรับเอเจนต์จะใช้การตัดสินใจเชิงออกแบบ 3 ประการ ได้แก่ "การออก ID เฉพาะ, การใช้งานด้วยข้อมูลรับรองที่มีอายุสั้น และการควบคุมการมอบสิทธิ์และการสวมรอย" หัวใจสำคัญคือแนวคิดในการส่งมอบข้อมูลรับรองที่มีอายุสั้นเท่าที่จำเป็นและในขอบเขตที่ต้องการ แทนการแจกจ่ายคีย์ถาวรที่มีอายุการใช้งานยาวนาน ในบทนี้จะเจาะลึกถึงวิธีการให้ข้อมูลรับรองแก่เอเจนต์ โดยพิจารณาจากวงจรชีวิตตั้งแต่การออก ID ไปจนถึงการเพิกถอน, ข้อมูลรับรองที่มีอายุสั้นและการหมุนเวียน (Rotation) รวมถึงมาตรการป้องกันการมอบสิทธิ์และการสวมรอย

การจัดการ ID ของเอเจนต์สามารถทำได้ง่ายขึ้นหากพิจารณาผ่าน 3 ระยะ ได้แก่ การออก (Issuance) การมอบอำนาจ (Delegation) และการเพิกถอน (Revocation) เริ่มต้นที่การออก ID เมื่อมีการสร้างเอเจนต์ใหม่ จุดเริ่มต้นคือการผูก ID ที่สามารถระบุตัวตนได้อย่างเฉพาะเจาะจง ID นี้จะเป็นจุดอ้างอิงในการติดตามว่า "ใครทำอะไร" ในภายหลัง ดังนั้นจึงควรเป็น ID ที่ไม่ซ้ำกันสำหรับเอเจนต์แต่ละตัว และควรระบุเจ้าของ (บุคคลหรือทีมที่รับผิดชอบ) ให้ชัดเจน การบันทึกวัตถุประสงค์ อายุการใช้งานที่คาดการณ์ไว้ และขอบเขตของสิทธิ์ที่จำเป็นไว้เป็นข้อมูลเมตา (Metadata) ณ เวลาที่ออก จะช่วยให้การตรวจสอบ (Inventory) ในภายหลังทำได้ง่ายขึ้นมาก

ถัดมาคือการมอบอำนาจ ในกรณีที่เอเจนต์ไม่ได้ทำงานโดยลำพัง แต่ทำหน้าที่แทนผู้ใช้หรือบริการอื่น จำเป็นต้องระบุให้ชัดเจนว่า "ทำหน้าที่แทนใคร และมีขอบเขตเพียงใด" การจำกัดขอบเขตของการมอบอำนาจให้แคบไว้ จะช่วยให้สามารถออกแบบระบบได้ว่า หากเอเจนต์นั้นถูกบุกรุก ความเสียหายจะจำกัดอยู่เพียงแค่ในขอบเขตที่ได้รับมอบอำนาจเท่านั้น แม้การมอบอำนาจจะสะดวก แต่หากขอบเขตไม่ชัดเจนก็อาจเกิดความเสี่ยงที่สิทธิ์จะขยายตัวเป็นลูกโซ่ ดังนั้นความชัดเจนจึงเป็นสิ่งสำคัญ

สุดท้ายคือการเพิกถอน เมื่อเอเจนต์หมดหน้าที่หรือถูกยกเลิก ต้องมั่นใจว่าสามารถเพิกถอน ID และข้อมูลประจำตัว (Credential) ที่เกี่ยวข้องได้อย่างสมบูรณ์ หากลืมเพิกถอน ID ที่ควรจะหยุดทำงานไปแล้วจะยังคงมีสิทธิ์ค้างอยู่และกลายเป็นเป้าหมายของการโจมตีได้ การกำหนดอายุการใช้งานไว้ตั้งแต่ตอนออก และใช้กลไกที่เพิกถอนโดยอัตโนมัติเมื่อครบกำหนด จะช่วยลดความเสี่ยงจากการลืมเพิกถอนด้วยตนเองได้ การออกแบบให้การออก การมอบอำนาจ และการเพิกถอนเป็นวงจรชีวิต (Lifecycle) ที่ต่อเนื่องกันนั้น เป็นสิ่งที่ขาดไม่ได้ในการป้องกันไม่ให้เกิด ID ที่ถูกทิ้งร้างไว้โดยไม่มีการดูแล

การใช้งานโดยให้ Agent ถือ Long-term key แบบถาวรนั้น จะทำให้ต้องแบกรับความเสี่ยงในระยะยาวหากเกิดการรั่วไหล เพราะหากคีย์หลุดออกไป ผู้โจมตีจะสามารถใช้งานต่อไปได้เรื่อยๆ ตราบเท่าที่คีย์นั้นยังคงมีผลอยู่ แนวคิดพื้นฐานในการหลีกเลี่ยงปัญหานี้คือการใช้ Short-lived credential โดยการออกโทเค็นที่มีอายุการใช้งานสั้นสำหรับการเข้าถึงแต่ละครั้ง และทำให้โทเค็นนั้นหมดอายุโดยอัตโนมัติเมื่อครบกำหนด ซึ่งจะช่วยจำกัดช่วงเวลาที่ผู้โจมตีสามารถนำโทเค็นที่รั่วไหลไปใช้ในทางที่ผิดได้

Short-lived credential มักถูกนำมาใช้ในรูปแบบของการขอโทเค็นที่มีวันหมดอายุทุกครั้งที่ใช้งาน เช่น Access token ของ OAuth 2.0 และเมื่อโทเค็นหมดอายุก็จะทำการขอโทเค็นใหม่ นอกจากนี้ยังมีกลไกอย่าง Workload Identity Federation ที่ใช้สภาพแวดล้อมที่ Agent ติดตั้งอยู่เป็นจุดเริ่มต้นของความเชื่อถือ (Trust) เพื่อรับข้อมูลรับรองที่มีอายุสั้นโดยไม่ต้องจัดเก็บ Long-term key ไว้ ซึ่งทั้งหมดนี้มีเป้าหมายร่วมกันคือ "การไม่จัดเก็บความลับไว้นานเกินไป"

อย่างไรก็ตาม ยังคงมีสถานการณ์ที่จำเป็นต้องใช้ความลับในระยะยาว ในกรณีนี้ สิ่งสำคัญคือการทำ Secret rotation หรือการหมุนเวียนข้อมูลรับรองให้เป็นของใหม่ตามระยะเวลาที่กำหนด ตัวอย่างเช่น หากใช้เครื่องมือจัดการความลับ (โดยทั่วไปคือกลไกอย่าง Vault) เพื่อให้ Agent ดึงข้อมูลความลับเมื่อจำเป็นและอัปเดตโดยอัตโนมัติในช่วงเวลาที่กำหนด จะช่วยลดความเสี่ยงจากการใช้ความลับเดิมซ้ำเป็นเวลานานได้

ทั้ง Short-lived credential และ Rotation ต่างมีแนวคิดร่วมกันคือ "การจำกัดระยะเวลาที่ความลับมีผลบังคับใช้อย่างตั้งใจ" การออกแบบโดยเน้นไปที่การดึงข้อมูลมาใช้ขณะรันไทม์และใช้เพียงช่วงเวลาสั้นๆ แทนการเขียนคีย์ลงในโค้ดหรือไฟล์ตั้งค่าโดยตรง จะช่วยให้จำกัดความเสียหายได้ง่ายขึ้นหากเกิดการรั่วไหลขึ้นจริง

การมอบอำนาจและการสวมรอย (impersonation) หมายถึงสถานการณ์ที่เอเจนต์ "ดำเนินการโดยใช้สิทธิ์ของเอนทิตีอื่นที่ไม่ใช่ตนเอง" เช่น กรณีที่เอเจนต์เรียกใช้ API ในนามของผู้ใช้ หรือทำหน้าที่เสมือนเป็นบริการอื่น แม้ว่าสิ่งนี้จะเป็นฟังก์ชันที่ถูกต้องตามกฎหมาย แต่หากออกแบบผิดพลาด อาจกลายเป็นช่องโหว่ที่ทำให้เอเจนต์ใช้อำนาจเกินขอบเขตที่ได้รับอนุญาตได้

สิ่งที่อันตรายคือรูปแบบการส่งมอบสิทธิ์ในวงกว้างโดยที่ขอบเขตของการมอบอำนาจยังไม่ชัดเจน ตัวอย่างเช่น เมื่อเอเจนต์ทำงานในนามของผู้ใช้ หากปล่อยให้สถานะเป็น "สามารถทำทุกอย่างที่ผู้ใช้คนนี้ทำได้" เมื่อเอเจนต์ถูกบุกรุก สิทธิ์ทั้งหมดของผู้ใช้จะตกไปอยู่ในมือของผู้โจมตีทันที การจำกัดการดำเนินการที่สามารถทำแทนได้ให้อยู่ในขอบเขตที่จำเป็น และระบุไว้อย่างชัดเจนในโทเค็นว่ากำลังทำหน้าที่แทนในเรื่องใด จะช่วยลดการลุกลามของความเสียหายได้ง่ายขึ้น

กุญแจสำคัญในการป้องกันการสวมรอยคือการตรวจสอบให้ได้ว่า "ใครกำลังทำหน้าที่เป็นใคร" ในขั้นตอนการยืนยันตัวตน ฝั่งผู้รับจำเป็นต้องตรวจสอบได้ว่าโทเค็นที่เอเจนต์นำเสนอมานั้น ออกให้สำหรับเอเจนต์นั้นจริงๆ หรือออกให้ในฐานะตัวแทนของเอนทิตีใด มาตรฐานอย่าง OAuth2.0 และ OpenID Connect ได้จัดเตรียมกรอบการทำงานที่รองรับการตรวจสอบดังกล่าว โดยการรวมข้อมูลผู้รับและวัตถุประสงค์ไว้ในโทเค็น

สำหรับแนวทางในการนำไปใช้งาน ประการแรกคือการรักษาห่วงโซ่ของการมอบอำนาจให้สั้นที่สุดเท่าที่จะเป็นไปได้ หากเอเจนต์มีการมอบอำนาจต่อไปยังเอเจนต์อื่นอีก ท้ายที่สุดแล้วจะไม่สามารถติดตามได้ว่าเกิดอะไรขึ้นและเป็นสิทธิ์ของใคร ประการต่อมาคือการกำหนดวันหมดอายุที่สั้นสำหรับโทเค็นที่ได้รับมอบอำนาจ และสุดท้าย ในบันทึกการตรวจสอบ (audit log) ควรบันทึกทั้ง "เอเจนต์ที่เป็นตัวตนจริง" และ "เอนทิตีที่ถูกมอบอำนาจ" เพื่อให้สามารถติดตามความรับผิดชอบย้อนหลังได้

อัตลักษณ์ (Identity) จะมีความหมายก็ต่อเมื่อทำหน้าที่เป็นผู้รับสิทธิ์ตามหลักการให้สิทธิ์ขั้นต่ำ (Principle of Least Privilege) และเป็นประธานของบันทึกการตรวจสอบ (Audit Log) เท่านั้น แม้จะมีการออกรหัสประจำตัว (Unique ID) แต่หากรหัสนั้นไม่ได้เชื่อมโยงกับหน่วยของสิทธิ์หรือหน่วยของการบันทึกข้อมูล ความสามารถในการระบุตัวตนที่มีอยู่ก็จะไม่เกิดประโยชน์ ในบทนี้จะกล่าวถึงวิธีการเชื่อมโยง ID ที่ได้จากการยืนยันตัวตนเข้ากับสิทธิ์ขั้นต่ำ (ซึ่งเป็นเรื่องของอีกเลเยอร์หนึ่ง) และวิธีการออกแบบบันทึกการตรวจสอบเพื่อเก็บข้อมูลว่า "ใคร ทำอะไร เมื่อไหร่" โดยจะมุ่งเน้นไปที่จุดเชื่อมต่อเป็นหลัก แทนที่จะลงลึกในรายละเอียดของกระบวนการให้สิทธิ์ (Authorization) เอง

หลักการสิทธิ์ขั้นต่ำ (Least Privilege) คือหลักการที่ให้สิทธิ์แก่แต่ละ ID เฉพาะเท่าที่จำเป็นต่อการปฏิบัติงานเท่านั้น ซึ่งเป็นการออกแบบคนละเลเยอร์กับการยืนยันตัวตน (Authentication) ที่เป็นหัวข้อหลักของบทความนี้ สิ่งสำคัญที่ต้องเน้นย้ำคือ การที่หลักการสิทธิ์ขั้นต่ำจะเกิดขึ้นได้นั้น "ผู้ที่ได้รับมอบหมายสิทธิ์" จะต้องถูกระบุตัวตนอย่างชัดเจนและเป็นเอกลักษณ์ หากมีการออก ID เฉพาะสำหรับแต่ละเอเจนต์ (Agent) ก็จะสามารถจำกัดสิทธิ์โดยใช้ ID นั้นเป็นหน่วยวัดได้ ในทางกลับกัน หากเอเจนต์หลายตัวใช้ ID ร่วมกัน สิทธิ์ที่จำเป็นสำหรับเอเจนต์ตัวหนึ่งก็จะถูกมอบให้เอเจนต์อีกตัวโดยอัตโนมัติ ทำให้ไม่สามารถรักษาหลักการสิทธิ์ขั้นต่ำไว้ได้

กล่าวคือ การระบุตัวตนผ่านการยืนยันตัวตนถือเป็นเงื่อนไขเบื้องต้นในการบรรลุหลักการสิทธิ์ขั้นต่ำ ตัวอย่างเช่น หากมีเอเจนต์ที่ทำหน้าที่อ่านข้อมูลเพียงอย่างเดียว และเอเจนต์ที่ทำหน้าที่เขียนข้อมูลด้วย หากทั้งสองได้รับ ID แยกกัน ก็จะสามารถแบ่งสิทธิ์ได้ว่าตัวแรกมีสิทธิ์แค่อ่าน ส่วนตัวหลังมีสิทธิ์ทั้งอ่านและเขียน การที่ ID แยกจากกันจึงเป็นจุดเริ่มต้นที่ทำให้สามารถแบ่งสิทธิ์ได้อย่างเหมาะสม

เหตุผลที่บทความนี้ไม่ได้ลงลึกถึงการออกแบบสิทธิ์ขั้นต่ำอย่างเป็นรูปธรรม (เช่น วิธีการกำหนดบทบาทหรือการเขียนนโยบาย) เป็นเพราะเรื่องดังกล่าวเป็นหัวข้อเฉพาะของเลเยอร์การอนุญาต (Authorization) สิ่งที่ควรทำความเข้าใจในที่นี้คือ แนวคิดเรื่องการเชื่อมโยงที่ไม่ใช่แค่ "ออก ID แล้วจบไป" แต่เป็นการนำ ID นั้นไปเชื่อมต่อกับกลไกการอนุญาตในฐานะหน่วยของการมอบสิทธิ์ การมีรากฐานเป็น ID เฉพาะตัวเท่านั้นที่จะทำให้โครงสร้างส่วนบนอย่างสิทธิ์ขั้นต่ำตั้งอยู่ได้อย่างมั่นคง แม้การยืนยันตัวตนและการอนุญาตจะมีหน้าที่ต่างกัน แต่การใช้ ID เป็นแกนกลางร่วมกันจะทำให้ทั้งสองส่วนทำงานประสานกันได้อย่างลงตัว

บันทึกการตรวจสอบ (Audit Log) คือบันทึกที่ช่วยให้สามารถสร้างเหตุการณ์ย้อนหลังได้ว่า "ใคร ทำอะไร เมื่อไหร่" และยังเป็นวิธีการตรวจสอบว่าการออกแบบ NHI นั้นใช้งานได้จริงหรือไม่ ประโยชน์เชิงปฏิบัติที่สำคัญที่สุดอย่างหนึ่งของการออก ID เฉพาะสำหรับเอเจนต์แต่ละตัว คือการทำให้สามารถระบุประธานของบันทึกการตรวจสอบนี้ในระดับเอเจนต์ได้ หากยังใช้ ID ร่วมกัน จะทราบเพียงว่า "ID นั้นเป็นผู้ดำเนินการ" แต่หากเป็น ID เฉพาะ จะสามารถระบุได้ว่า "เอเจนต์ตัวใดเป็นผู้ดำเนินการ"

เมื่อจัดระเบียบองค์ประกอบที่ควรมีในบันทึกการตรวจสอบ อย่างแรกคือตัวผู้กระทำ กล่าวคือ ID ของเอเจนต์ตัวใดที่เป็นผู้ดำเนินการ ในกรณีที่มีการมอบอำนาจ การบันทึกทั้งตัวเอเจนต์ที่เป็นผู้ปฏิบัติงานจริงและตัวการเดิมที่มอบอำนาจไว้จะช่วยให้ติดตามความรับผิดชอบได้ง่ายขึ้น ต่อมาคือเวลา คือวันและเวลาที่ดำเนินการ นอกจากนี้ยังรวมถึงเป้าหมายและเนื้อหาของการดำเนินการ กล่าวคือดำเนินการใด (อ่าน เขียน ลบ ฯลฯ) กับทรัพยากรใด และผลลัพธ์ว่าการดำเนินการนั้นสำเร็จหรือล้มเหลวก็เป็นเบาะแสสำหรับการตรวจจับความผิดปกติได้เช่นกัน

ข้อควรระวังในการบันทึกข้อมูลเหล่านี้คือการปกป้องตัวบันทึกเอง หากบันทึกการตรวจสอบอยู่ในสถานะที่แก้ไขได้ง่าย ก็จะไม่สามารถใช้เป็นหลักฐานที่น่าเชื่อถือเมื่อเกิดเหตุการณ์ไม่พึงประสงค์ได้ ควรจัดเก็บบันทึกในรูปแบบที่เพิ่มข้อมูลได้เท่านั้นและแก้ไขได้ยาก และควรแยกสิทธิ์ไม่ให้ตัวเอเจนต์เองสามารถลบหรือแก้ไขบันทึกนั้นได้

บันทึกการตรวจสอบจะแสดงคุณค่าได้ก็ต่อเมื่อใช้งานร่วมกับการออกแบบวงจรชีวิตของ ID ไม่ใช่แค่เพียงลำพัง ด้วยกลไกอย่างการออก ID เฉพาะ, ข้อมูลรับรองที่มีอายุสั้น (Short-lived credentials) และการเพิกถอนสิทธิ์ บันทึกที่เหลืออยู่จึงจะเชื่อมโยงกับตัวตนที่สอดคล้องกัน และทำให้สามารถระบุได้อย่างน่าเชื่อถือว่า "เกิดอะไรขึ้นและใครเป็นผู้รับผิดชอบ"

การนำ NHI ไปใช้งานจะดำเนินการเป็นขั้นตอน 3 ขั้น ได้แก่ "การออก ID เฉพาะ → การจำกัดสิทธิ์ด้วยโทเค็นที่มีอายุสั้น → การทำให้การเพิกถอนและการหมุนเวียนเป็นไปโดยอัตโนมัติ" ไม่จำเป็นต้องตั้งเป้าหมายไปที่กลไกที่สมบูรณ์แบบในทันที แต่การค่อยๆ สร้างขึ้นอย่างมั่นคงตามลำดับ โดยเริ่มจากการแยก ID จากนั้นทำให้ความลับ (secrets) มีอายุสั้นลง และสุดท้ายคือการทำระบบปฏิบัติการให้เป็นอัตโนมัติ ถือเป็นแนวทางที่ทำได้จริง ในบทนี้จะอธิบายถึงสิ่งที่ต้องทำในแต่ละขั้นตอน พร้อมทั้งจุดประสงค์ของแต่ละขั้นตอนอย่างเป็นรูปธรรม

ขั้นตอนแรกคือการออก ID เฉพาะให้กับเอเจนต์แต่ละตัว ซึ่งถือเป็นรากฐานของการออกแบบ NHI หากปัจจุบันยังใช้งานโดยใช้คีย์ร่วม (Shared Key) เป้าหมายแรกที่ควรทำคือการเปลี่ยนไปสู่สถานะ "1 เอเจนต์ต่อ 1 ID" โดยกำหนดชื่อหรือ ID ที่สามารถระบุตัวตนของเอเจนต์แต่ละตัวได้อย่างเฉพาะเจาะจง พร้อมบันทึกข้อมูลเมตา (Metadata) ไว้ว่าเอเจนต์นั้นทำงานเพื่อวัตถุประสงค์ใดและอยู่ภายใต้ความรับผิดชอบของใคร

สำหรับวิธีการดำเนินการที่เป็นรูปธรรม ให้จัดระเบียบข้อมูลตาม ID ดังนี้:

• ชื่อ ID (ชื่อที่ใช้ระบุตัวตนของเอเจนต์อย่างเฉพาะเจาะจง)
• เจ้าของ (บุคคลหรือทีมที่รับผิดชอบ)
• วัตถุประสงค์ (เอเจนต์นี้ทำงานไปเพื่ออะไร)
• อายุการใช้งานที่คาดการณ์ (แบบถาวร หรือแบบชั่วคราว)

การจัดทำข้อมูลเหล่านี้เป็นบัญชีรายชื่อ (Ledger) จะกลายเป็นฐานข้อมูลสำหรับการตรวจสอบและการตัดสินใจเพิกถอนสิทธิ์ในภายหลัง หากมี ID เฉพาะ จะสามารถบันทึกข้อมูลในบันทึกการตรวจสอบ (Audit Log) แยกตามรายเอเจนต์ได้ ทำให้สามารถติดตามได้ว่า "ใครทำอะไร" ในทางกลับกัน หากข้ามขั้นตอนนี้ไปและยังคงใช้ ID ร่วมกันต่อไป ก็จะไม่สามารถติดตามการทำงานได้

สิ่งที่ควรตระหนักในขั้นตอนนี้ไม่ใช่แค่การออก ID เท่านั้น แต่คือการสร้างนิสัยในการปฏิบัติงานที่ว่า "ต้องผูก ID นั้นเข้ากับผู้รับผิดชอบและวัตถุประสงค์เสมอ" การไม่สร้าง ID ที่ไม่มีเจ้าของถือเป็นปราการด่านแรกในการป้องกันปัญหา NHI Sprawl (การเพิ่มจำนวนของ NHI จนไม่สามารถจัดการได้) ในอนาคต ตัวอย่างเช่น หากรวมขั้นตอน "การลงทะเบียน ID และระบุเจ้าของ" เข้าไปในขั้นตอนการสร้างเอเจนต์ใหม่ ก็จะช่วยลดโอกาสที่จะเกิดการลืมออก ID หรือการมี ID ที่ไม่ทราบผู้รับผิดชอบได้

ขั้นตอนที่สองคือการเปลี่ยนข้อมูลรับรอง (credentials) ที่ส่งให้กับเอเจนต์ให้เป็นโทเค็นที่มีอายุการใช้งานสั้น เพื่อลดสิทธิ์ในด้านเวลาให้เหลือน้อยที่สุด เมื่อกำหนด ID เฉพาะตัวในขั้นตอนที่ 1 แล้ว แทนที่จะผูกคีย์ระยะยาวเข้ากับ ID นั้นโดยตรง ให้เปลี่ยนไปใช้วิธีออกโทเค็นที่มีอายุการใช้งานสั้นเมื่อจำเป็นแทน

แนวทางการดำเนินการคือ เริ่มจากการตรวจสอบคีย์ระยะยาวหรือข้อมูลรับรองที่ถูกฮาร์ดโค้ด (hard-coded) ซึ่งเอเจนต์ใช้งานอยู่ในปัจจุบัน จากนั้นพิจารณาว่าสามารถเปลี่ยนไปใช้การยืนยันตัวตนแบบใช้โทเค็นแทนได้หรือไม่ เช่น การใช้วิธีรับโทเค็นที่มีวันหมดอายุมาใช้งานเป็นครั้งคราวเหมือนกับ Access Token ของ OAuth 2.0 และขอใหม่ทุกครั้งที่โทเค็นหมดอายุ หากเป็นสภาพแวดล้อมบนคลาวด์ อาจเลือกใช้การกำหนดค่าอย่าง Workload Identity Federation ซึ่งใช้สภาพแวดล้อมการทำงานของเอเจนต์เป็นจุดเริ่มต้นของความเชื่อถือเพื่อรับข้อมูลรับรองที่มีอายุการใช้งานสั้นได้เช่นกัน

เป้าหมายของขั้นตอนนี้มี 2 ประการ ประการแรกคือการลดระยะเวลาที่อาจเกิดความเสียหายหากข้อมูลรั่วไหล หากโทเค็นมีอายุการใช้งานสั้น ช่องทางที่ผู้ไม่หวังดีจะนำไปใช้ในทางที่ผิดก็จะจำกัดลง ประการที่สองคือการเปลี่ยนผ่านไปสู่วัฒนธรรมที่ไม่เขียนข้อมูลลับลงในโค้ดหรือการตั้งค่าโดยตรง การออกแบบให้มีการรับโทเค็นในขณะรันไทม์ (runtime) จะช่วยลดความเสี่ยงที่คีย์จะหลงเหลืออยู่ในที่เก็บข้อมูล (repository) หรือบันทึก (log) ได้

ทั้งนี้ สิ่งที่กล่าวถึงในที่นี้เป็นเพียงการลดสิทธิ์ในเชิงเวลาที่เน้นไปที่การยืนยันตัวตน (authentication) ว่า "สามารถใช้งานได้นานแค่ไหนและด้วยข้อมูลรับรองใด" ซึ่งเป็นคนละเลเยอร์กับการให้สิทธิ์ขั้นต่ำ (least privilege) ในด้านการอนุญาต (authorization) ที่ว่า "อนุญาตให้ทำปฏิบัติการใดได้บ้าง" แม้ทั้งสองส่วนจะมีความสัมพันธ์ที่ส่งเสริมกัน แต่การทำให้ข้อมูลรับรองมีอายุสั้นลงจะช่วยยกระดับความปลอดภัยของโครงสร้างพื้นฐานด้าน ID ได้ตั้งแต่ต้น

ขั้นตอนสุดท้ายคือการทำให้การเพิกถอน (Revocation) และการหมุนเวียน (Rotation) เป็นไปโดยอัตโนมัติ เพื่อเปลี่ยนไปสู่การดำเนินงานที่ไม่ต้องพึ่งพาแรงงานคน แม้ว่าจะวางรากฐานด้วย ID เฉพาะและโทเค็นที่มีอายุการใช้งานสั้น (Short-lived tokens) ในขั้นตอนที่ 1 และ 2 แล้ว แต่หากการเพิกถอนหรือการเปลี่ยนคีย์ยังคงเป็นงานที่ต้องทำด้วยมือ ความล่าช้าในการจัดการก็จะกลายเป็นความเสี่ยงที่ถูกละเลย เป้าหมายของระบบอัตโนมัติคือการขจัดปัจจัยด้านมนุษย์อย่าง "การลืม" หรือ "การผลัดวันประกันพรุ่ง" ออกไปตั้งแต่ขั้นตอนการออกแบบ

การดำเนินงานที่ควรทำให้เป็นอัตโนมัติมีดังนี้:

• การเพิกถอนอัตโนมัติเมื่อหมดอายุ (การยกเลิก ID หรือโทเค็นที่ใช้งานเกินอายุที่กำหนดไว้ตอนออกเอกสารโดยอัตโนมัติ)
• การหมุนเวียนความลับ (Secret rotation) เป็นระยะ (การอัปเดตโดยอัตโนมัติตามช่วงเวลาที่กำหนด ในกรณีที่จำเป็นต้องใช้ความลับในระยะยาว)
• การเพิกถอน ID ของเอเจนต์ที่เลิกใช้งานแล้ว (การยกเลิก ID ของเอเจนต์ที่หมดหน้าที่ไปแล้ว โดยเชื่อมโยงกับกระบวนการเลิกใช้งาน)

ในการรวมสิ่งเหล่านี้เข้าเป็นกลไก คุณสามารถใช้วิธีต่างๆ เช่น การใช้ฟังก์ชันอัปเดตอัตโนมัติของเครื่องมือจัดการความลับ (เช่น ระบบอย่าง Vault) หรือการกำหนดวันหมดอายุไว้ตั้งแต่ตอนออก ID เพื่อให้ระบบเพิกถอนโดยอัตโนมัติเมื่อถึงกำหนด สิ่งสำคัญคือการทำให้การเพิกถอนและการหมุนเวียนไม่ใช่ "งานที่ต้องมีใครสักคนคอยจำและลงมือทำ" แต่เป็น "การทำงานมาตรฐานที่ระบบดำเนินการเองโดยอัตโนมัติ"

หากระบบอัตโนมัติทำงานได้อย่างมีประสิทธิภาพ แม้จำนวนเอเจนต์จะเพิ่มขึ้นอย่างมหาศาล ก็จะสามารถป้องกันสถานการณ์ที่ ID ซึ่งไม่จำเป็นแล้วยังคงมีสิทธิ์เข้าถึงอยู่ได้ง่าย ในทางกลับกัน หากการออก ID เป็นแบบอัตโนมัติแต่การเพิกถอนยังคงต้องทำด้วยมือ สภาวะที่ไม่สมดุลนี้ถือเป็นกับดักสำคัญที่นำไปสู่ปัญหา NHI Sprawl การทำให้การออกและการเพิกถอนเป็นไปโดยอัตโนมัติอย่างสมดุลคือหัวใจสำคัญที่จะทำให้การดำเนินงานมีความยั่งยืน

หลุมพรางที่มักทำให้สะดุดในการออกแบบ NHI มีอยู่ 2 ประการ ได้แก่ "การนำบัญชีผู้ใช้งานจริงมาใช้ซ้ำ (Human Account Reuse)" และ "การขยายตัวของ NHI ที่ไม่สามารถตรวจสอบได้ (Uninventoryable NHI Sprawl)" ทั้งสองกรณีเป็นรูปแบบที่มักเริ่มต้นด้วยความสะดวกหรือทำไปตามกระแส แต่กลับกลายเป็นสิ่งที่แก้ไขได้ยากในภายหลัง ในบทนี้ เราจะมาดูรายละเอียดกันว่าข้อผิดพลาดในการออกแบบที่พบบ่อยเหล่านี้เกิดขึ้นได้อย่างไร นำไปสู่ความเสียหายแบบไหน และจะมีวิธีหลีกเลี่ยงอย่างไรบ้าง

หลุมพรางที่พบบ่อยที่สุดคือการนำบัญชีผู้ใช้งานทั่วไปมาใช้กับ Agent โดยตรง ตัวอย่างเช่น การที่นักพัฒนาตั้งค่าข้อมูลรับรอง (Credentials) ของบัญชีตนเองให้กับ Agent เพื่อให้เรียกใช้ External API ด้วยสิทธิ์นั้นๆ แม้จะสะดวกในการทดสอบช่วงเริ่มต้นเพราะสามารถใช้งานได้ทันที แต่เมื่อนำไปใช้ในระบบงานจริง (Production) จะนำมาซึ่งปัญหาหลายประการ

ประการแรก คือการสูญเสียความสามารถในการตรวจสอบย้อนกลับ (Traceability) เนื่องจากบันทึกการตรวจสอบ (Audit Log) จะบันทึกการทำงานด้วย ID ของนักพัฒนารายนั้น ทำให้ไม่สามารถแยกแยะได้ว่าเป็นการกระทำของมนุษย์หรือเป็นการกระทำของ Agent ซึ่งส่งผลให้การวิเคราะห์หาสาเหตุเมื่อเกิดปัญหาทำได้ยากขึ้น

ประการที่สอง คือสิทธิ์การเข้าถึงมักจะเกินความจำเป็น (Over-privileged) บัญชีของผู้ใช้งานทั่วไปมักรวมสิทธิ์ต่างๆ ที่จำเป็นต่อการทำงานของบุคคลนั้นไว้มากมาย ในขณะที่ Agent ต้องการเพียงสิทธิ์เพียงบางส่วนเท่านั้น การนำบัญชีมาใช้ซ้ำจึงเป็นการมอบสิทธิ์ทั้งหมดที่ Agent ไม่จำเป็นต้องใช้ให้ไปด้วย หาก Agent ถูกบุกรุก ข้อมูลประจำตัวทั้งหมดของบุคคลนั้นจะตกอยู่ในความเสี่ยงที่จะถูกผู้โจมตีเข้าถึงได้

ประการที่สาม คือวงจรชีวิต (Lifecycle) ที่ไม่สอดคล้องกัน บัญชีของผู้ใช้งานทั่วไปจะถูกยกเลิกเมื่อมีการลาออกหรือย้ายแผนก หาก Agent ทำงานโดยใช้บัญชีของบุคคลนั้น อาจเกิดเหตุการณ์ที่ Agent หยุดทำงานกะทันหันเมื่อบุคคลดังกล่าวลาออก

วิธีแก้ไขนั้นเรียบง่าย คือการออก ID เฉพาะสำหรับ Agent แยกต่างหากจากมนุษย์ แม้ในช่วงแรกอาจดูเป็นภาระ แต่การใช้ ID เฉพาะจะช่วยให้เกิดความสามารถในการตรวจสอบย้อนกลับ, การจำกัดสิทธิ์ให้น้อยที่สุด (Least Privilege) และวงจรชีวิตที่เป็นอิสระ หากสร้างนิสัยการใช้ ID เฉพาะตั้งแต่ขั้นตอนการทดสอบ ก็จะช่วยหลีกเลี่ยงการต้องกลับมาแก้ไขงานใหม่เมื่อต้องย้ายขึ้นระบบงานจริง

อีกหนึ่งกับดักสำคัญคือ NHI Sprawl ซึ่งเป็นสภาวะที่ NHI เพิ่มจำนวนขึ้นจนเกินกว่าจะจัดการได้และไม่สามารถทำรายการตรวจสอบ (Inventory) ได้อีกต่อไป เอเจนต์และเซอร์วิสแอคเคานต์มักถูกสร้างขึ้นอย่างง่ายดายทุกครั้งที่มีการปรับใช้โค้ดหรือทดสอบเล็กๆ น้อยๆ โดยไม่ต้องผ่านกระบวนการคัดกรองเหมือนกับการจ้างงานมนุษย์ แม้การตัดสินใจในแต่ละครั้งจะเป็นเรื่องเล็กน้อย แต่เมื่อสะสมรวมกันกลับกลายเป็นกองทัพของ ID ที่ไม่มีใครมองเห็นภาพรวมทั้งหมด

ความอันตรายของสภาวะนี้คือ ID ที่ไม่จำเป็นจะยังคงตกค้างอยู่โดยไม่มีใครสังเกตเห็น ตัวอย่างเช่น เซอร์วิสแอคเคานต์ที่สร้างขึ้นเพื่อการทดสอบชั่วคราวอาจถูกปล่อยทิ้งไว้โดยไม่ถูกลบและยังคงสิทธิ์การเข้าถึงอยู่แม้การทดสอบจะสิ้นสุดลงแล้ว เมื่อผู้รับผิดชอบย้ายงานและไม่ทราบว่าใครเป็นเจ้าของ ก็จะเกิดการปล่อยทิ้งไว้ด้วยความเกรงใจว่า "ไม่กล้าลบเพราะตัดสินใจไม่ได้ว่าลบได้หรือไม่" ซึ่ง ID ที่ไม่ทราบเจ้าของและไม่ทราบวัตถุประสงค์เหล่านี้กลายเป็นช่องทางที่สมบูรณ์แบบสำหรับผู้โจมตี

การรับมือกับ NHI Sprawl ไม่ใช่การหยุดการเพิ่มจำนวน แต่เป็นการรักษาให้อยู่ในสภาวะที่ยังจัดการได้แม้จำนวนจะเพิ่มขึ้น โดยเฉพาะอย่างยิ่งคือการบังคับใช้กฎระเบียบให้มีการบันทึกเจ้าของ วัตถุประสงค์ และอายุการใช้งานที่คาดการณ์ไว้ทุกครั้งที่มีการออก ID เพื่อให้สามารถตรวจสอบผ่านบัญชีรายชื่อ (Ledger) ได้จากศูนย์กลาง จากนั้นให้ทบทวนบัญชีรายชื่อเป็นระยะเพื่อคัดแยก ID ที่ไม่ทราบเจ้าของหรือไม่ได้ใช้งานเป็นเวลานานออกมาตรวจสอบ การบันทึกข้อมูลเมตา (Metadata) ณ เวลาที่ออก ID ควบคู่ไปกับการตรวจสอบเป็นระยะเท่านั้น จึงจะทำให้การเพิ่มจำนวนอยู่ภายใต้การควบคุมได้

นอกจากนี้ สิ่งที่มีประสิทธิภาพยิ่งกว่าคือการใช้ร่วมกับการทำให้การหมดอายุเป็นไปโดยอัตโนมัติ (Automated Expiration) ตามที่กล่าวถึงในบทก่อนหน้า หากมีกลไกที่กำหนดอายุการใช้งานไว้ตั้งแต่ตอนออก ID และให้หมดอายุโดยอัตโนมัติเมื่อครบกำหนด ก็จะสามารถลดจำนวน ID ที่ถูกปล่อยทิ้งไว้ได้ตั้งแต่ต้น เนื่องจากปัญหา Sprawl เกิดจากความไม่สมดุลที่ว่า "การออก ID นั้นง่าย แต่การยกเลิกต้องทำด้วยมือ" การออกแบบให้ทั้งสองส่วนมีความสมดุลกันจึงเป็นวิธีป้องกันที่ตรงจุดที่สุด

ถาม: Non-Human Identity (NHI) แตกต่างจาก Service Account แบบเดิมอย่างไร? ตอบ: แม้สิ่งที่ครอบคลุมจะทับซ้อนกัน แต่มีมุมมองที่ต่างกัน Service Account เป็นชื่อของกลไกเฉพาะอย่างหนึ่ง ในขณะที่ NHI เป็นแนวคิดระดับสูงที่รวบรวม "ตัวตนที่ไม่ใช่มนุษย์ ซึ่งเป็นเป้าหมายของการพิสูจน์ตัวตน (Authentication) การอนุญาต (Authorization) และการตรวจสอบ (Audit)" เข้าด้วยกัน เช่น Service Account, API Key และ Workload ID เป็นต้น หัวใจสำคัญของ NHI คือแนวคิดในการรวมศูนย์การกำกับดูแล (Governance) ตัวตนที่ไม่ใช่มนุษย์ที่เคยจัดการแยกส่วนกัน โดยใช้แกนกลางร่วมกันคือ เจ้าของ (Owner) อายุการใช้งาน (Lifespan) และสิทธิ์การเข้าถึง (Permission)

ถาม: หากเป็นองค์กรขนาดเล็กที่มี Agent เพียง 1 หรือ 2 ตัว จำเป็นต้องมีกลไก NHI หรือไม่? ตอบ: ในช่วงที่ขนาดองค์กรยังเล็ก การรับมือขั้นต่ำมักจะเพียงพอ แต่การนำแนวคิดนี้มาปรับใช้ตั้งแต่เนิ่นๆ จะช่วยให้ทำงานได้ง่ายขึ้นในภายหลัง อย่างน้อยที่สุด การไม่อาศัยบัญชีผู้ใช้งานที่เป็นมนุษย์ แต่ใช้วิธีออก ID เฉพาะสำหรับ Agent และหลีกเลี่ยงการเขียน Hard-code ของคีย์ระยะยาว (Long-lived key) ก็เป็นสิ่งที่คุ้มค่าที่จะทำแม้ในขณะที่มีจำนวนน้อย เนื่องจาก Agent มักจะเพิ่มจำนวนขึ้นได้ง่าย การใช้งานด้วย ID เฉพาะตั้งแต่ต้นจะช่วยป้องกันการต้องกลับมาแก้ไขใหม่เมื่อจำนวนเพิ่มขึ้นในอนาคต

ถาม: ระหว่างการพิสูจน์ตัวตน (Authentication - ทำงานในฐานะใคร) และการอนุญาต (Authorization - ทำอะไรได้บ้าง) ควรออกแบบสิ่งใดก่อน? ตอบ: ลำดับที่เป็นธรรมชาติคือต้องกำหนดตัวตนให้ชัดเจนด้วยการพิสูจน์ตัวตนก่อน แล้วจึงวางการอนุญาตไว้บนพื้นฐานนั้น เพราะหากไม่ทราบแน่ชัดว่าใครเป็นผู้ส่งคำขอ ก็จะไม่สามารถกำหนดผู้ที่จะได้รับสิทธิ์ขั้นต่ำ (Least Privilege) ได้ บทความนี้มุ่งเน้นไปที่วงจรชีวิตของการพิสูจน์ตัวตนและตัวตน (Identity) ส่วนการออกแบบการอนุญาตอย่างละเอียด เช่น สิทธิ์ขั้นต่ำนั้น ถือเป็นหัวข้อในอีกระดับหนึ่ง

ถาม: การใช้โทเค็นระยะสั้น (Short-lived token) จะทำให้กระบวนการซับซ้อนขึ้นจากการที่ต้องคอยขอโทเค็นใหม่หรือไม่? ตอบ: ในหลายกรณี มาตรฐานหรือกลไกที่มีอยู่เดิม เช่น OAuth 2.0 หรือ Workload Identity Federation จะเป็นผู้รับผิดชอบในการขอและอัปเดตโทเค็น ทำให้ฝั่งแอปพลิเคชันไม่จำเป็นต้องเขียนโค้ดจัดการกระบวนการที่ซับซ้อนด้วยตนเองมากนัก ในทางกลับกัน การใช้งานแบบเขียน Hard-code ของคีย์ระยะยาวลงในโค้ดหรือการตั้งค่า จะสร้างภาระต้นทุนในภายหลัง ทั้งในแง่ของการรับมือเมื่อข้อมูลรั่วไหลและการหมุนเวียนคีย์ (Rotation) โทเค็นระยะสั้นจึงเป็นการออกแบบที่ข้อดีด้านความปลอดภัยในการลดระยะเวลาความเสียหายเมื่อเกิดการรั่วไหลนั้น คุ้มค่ากว่าความยุ่งยากในการติดตั้งใช้งาน