ทำอย่างไรให้เราสามารถควบคุม AI Agent และ Non-Human Identity ได้: จัดการความเสี่ยงที่มองไม่เห็นในองค์กร
เรามักจะได้ยินคำถามนี้บ่อยครั้งจากองค์กรต่างๆ:
"เรามี Service Account และ AI Agent ทำงานอยู่เบื้องหลังเป็นร้อยๆ ตัว เราไม่ได้เป็นคนสร้างส่วนใหญ่ขึ้นมาเองด้วยซ้ำ และก็ไม่รู้ว่าใครเป็นเจ้าของ แล้วเราจะรักษาความปลอดภัยของพวกมันได้อย่างไร?"
ทุกวันนี้ ทุกองค์กรไม่ได้ขับเคลื่อนด้วยพนักงานที่เป็นมนุษย์เพียงอย่างเดียว แต่เบื้องหลังนั้นมี "ข้อมูลระบุตัวตนที่ไม่ใช่มนุษย์" (Non-Human Identities หรือ NHI) นับพัน ไม่ว่าจะเป็น Service Account, API Token ไปจนถึง AI Agent ที่คอยเข้าถึงระบบ, โอนย้ายข้อมูล และทำงานต่างๆ ตลอด 24 ชั่วโมง
สิ่งเหล่านี้ไม่ใช่เรื่องใหม่ แต่กำลังเพิ่มจำนวนขึ้นอย่างรวดเร็ว และส่วนใหญ่ไม่ได้ถูกสร้างขึ้นโดยคำนึงถึงความปลอดภัยเป็นหลัก
เครื่องมือจัดการข้อมูลระบุตัวตนแบบดั้งเดิมถูกออกแบบมาโดยตั้งสมมติฐานว่าผู้ใช้งานมี "เจตนา", "บริบท" และ "ความเป็นเจ้าของ" แต่ Non-Human Identity ไม่มีคุณสมบัติเหล่านี้เลย พวกมันไม่ได้ล็อกอินหรือล็อกเอาต์ ไม่ได้ถูกลบออกจากระบบเมื่อเลิกใช้งาน และด้วยการมาถึงของ Agent ที่ทำงานได้ด้วยตนเอง (Autonomous Agents) พวกมันเริ่มตัดสินใจเองได้ โดยมักจะมาพร้อมกับสิทธิ์การเข้าถึงที่กว้างขวางแต่มีการควบคุมดูแลเพียงน้อยนิด
สถานการณ์นี้ได้สร้างจุดบอดใหม่ๆ ด้านความปลอดภัยขึ้นแล้ว และนี่เป็นเพียงแค่จุดเริ่มต้นเท่านั้น
ในบทความนี้ เราจะมาดูกันว่าความเสี่ยงจาก Non-Human Identity กำลังเปลี่ยนแปลงไปอย่างไร, องค์กรส่วนใหญ่ยังมีช่องโหว่ตรงไหน และโครงสร้างความปลอดภัยด้านข้อมูลระบุตัวตน (Identity Security Fabric) จะช่วยให้ทีมรักษาความปลอดภัยรับมือกับปัญหานี้ได้อย่างไร ก่อนที่ทุกอย่างจะขยายใหญ่จนไม่สามารถจัดการได้
การเติบโต (และความเสี่ยง) ของ Non-Human Identity
สถาปัตยกรรมแบบ Cloud-first ทำให้โครงสร้างพื้นฐานมีความซับซ้อนและส่งผลให้ Identity ที่ทำงานเบื้องหลังเพิ่มขึ้นอย่างมหาศาล ยิ่งสภาพแวดล้อมเหล่านี้เติบโต จำนวน Identity เหล่านี้ก็ยิ่งเพิ่มขึ้นตามไปด้วย โดยส่วนใหญ่มักถูกสร้างขึ้นโดยอัตโนมัติ ขาดเจ้าของที่ชัดเจน และไม่มีการกำกับดูแล ในหลายกรณี Identity เหล่านี้มีจำนวนมากกว่าผู้ใช้งานที่เป็นมนุษย์ในอัตราส่วนที่สูงกว่า 80 ต่อ 1
สิ่งที่ทำให้สถานการณ์นี้เสี่ยงเป็นพิเศษคือ ทีมส่วนใหญ่แทบไม่รู้อะไรเกี่ยวกับพวกมันเลย NHI มักถูกสร้างขึ้นโดยอัตโนมัติระหว่างการติดตั้งหรือการเตรียมระบบ แล้วก็หายไปจากสายตา ไม่มีการติดตาม ไม่มีเจ้าของ และมักจะได้รับสิทธิ์เกินความจำเป็น (Over-permissioned)
โดยเฉพาะอย่างยิ่ง Service Account นั้นมีอยู่ทุกที่ ใช้ในการถ่ายโอนข้อมูลระหว่างระบบ, รันงานตามกำหนดเวลา และยืนยันตัวตนของบริการต่างๆ แต่การขยายตัวของมันกลับมองไม่เห็น และสิทธิ์การเข้าถึงก็แทบไม่เคยถูกตรวจสอบ เมื่อเวลาผ่านไป มันจึงกลายเป็นช่องทางที่สมบูรณ์แบบสำหรับผู้โจมตีในการเคลื่อนที่ไปส่วนอื่นๆ ในระบบ (Lateral Movement) และยกระดับสิทธิ์การเข้าถึง (Privilege Escalation)
แต่ Service Account เป็นเพียงส่วนหนึ่งของปัญหาเท่านั้น เพราะเมื่อการนำ AI มาใช้เพิ่มขึ้น Non-Human Identity ประเภทใหม่ก็ได้ถือกำเนิดขึ้นและนำมาซึ่งความเสี่ยงที่คาดเดายากยิ่งกว่าเดิม
ทำไม AI Agent ถึงแตกต่าง และทำไมมันถึงสำคัญ
สิ่งที่แตกต่างจาก Identity ของเครื่องจักรทั่วไปคือ AI Agent สามารถริเริ่มการกระทำต่างๆ ได้ด้วยตัวเอง เช่น โต้ตอบกับ API, ค้นหาข้อมูล และตัดสินใจได้อย่างอิสระ
ความเป็นอิสระนี้ต้องแลกมาด้วยต้นทุนด้านความปลอดภัย AI Agent มักต้องการเข้าถึงข้อมูลและ API ที่ละเอียดอ่อน แต่มีเพียงไม่กี่องค์กรเท่านั้นที่มีมาตรการป้องกันว่าพวกมันสามารถทำอะไรได้บ้าง หรือจะเพิกถอนสิทธิ์การเข้าถึงนั้นได้อย่างไร
ที่แย่ไปกว่านั้นคือ AI Agent ส่วนใหญ่ขาดเจ้าของที่ชัดเจน ไม่มีวงจรชีวิตที่เป็นมาตรฐาน และแทบไม่สามารถตรวจสอบพฤติกรรมการทำงานจริงของมันได้เลย พวกมันอาจถูกสร้างโดยนักพัฒนา, ฝังอยู่ในเครื่องมือต่างๆ หรือถูกเรียกใช้งานผ่าน API ภายนอก และเมื่อเริ่มทำงานแล้ว ก็สามารถทำงานต่อไปได้เรื่อยๆ โดยไม่มีกำหนด พร้อมกับ Credential (ข้อมูลยืนยันตัวตน) และสิทธิ์การเข้าถึงที่สูง
และเนื่องจากพวกมันไม่ได้ผูกติดอยู่กับผู้ใช้หรือเซสชันใดๆ จึงเป็นเรื่องยากที่จะติดตามด้วยสัญญาณบ่งชี้ตัวตนแบบดั้งเดิม เช่น ที่อยู่ IP, ตำแหน่งที่ตั้ง หรือบริบทของอุปกรณ์
ต้นทุนของการเข้าถึงที่มองไม่เห็น
ข้อมูลลับถูกฝังไว้ในโค้ด (Hardcoded), โทเค็นถูกนำกลับมาใช้ซ้ำ และ Identity ที่ถูกทิ้งร้าง (Orphaned Identity) ยังคงใช้งานได้นานเป็นเดือนๆ หรือบางครั้งเป็นปี
ความเสี่ยงเหล่านี้ไม่ใช่เรื่องใหม่ แต่การมี Credential ที่ไม่เปลี่ยนแปลงและการเข้าถึงที่เปิดกว้างอาจพอจัดการได้ในตอนที่คุณมี Service Account เพียงไม่กี่สิบตัว แต่เมื่อมี NHI หลายพันหรือหลายหมื่นตัวที่ทำงานอย่างอิสระบนบริการคลาวด์ต่างๆ การติดตามด้วยตนเองจึงเป็นไปไม่ได้อีกต่อไป
นี่คือเหตุผลที่ทีมรักษาความปลอดภัยหลายแห่งกำลังทบทวนนิยามของ "Identity" กันใหม่ เพราะถ้า AI Agent สามารถยืนยันตัวตน, เข้าถึงข้อมูล และตัดสินใจได้ มันก็คือ "Identity" รูปแบบหนึ่ง และถ้า Identity นั้นไม่ถูกควบคุมดูแล มันก็คือ "หนี้สินทางความปลอดภัย" (Liability) ดีๆ นี่เอง
ความท้าทายด้านความปลอดภัยของ NHI ที่พบบ่อย
การเข้าใจว่า Non-Human Identity เป็นความเสี่ยงที่เพิ่มขึ้นเป็นเรื่องหนึ่ง แต่การจัดการความเสี่ยงนั้นเป็นอีกเรื่องหนึ่ง ปัญหาหลักคือเครื่องมือและกระบวนการที่สร้างขึ้นเพื่อจัดการ Identity ของมนุษย์นั้นไม่สามารถนำมาใช้กับโลกของ API, Service Account และ AI Agent ได้ ซึ่งก่อให้เกิดช่องว่างด้านความปลอดภัยที่อันตรายหลายประการ
1. คุณไม่สามารถปกป้องสิ่งที่คุณมองไม่เห็น
ความท้าทายพื้นฐานที่สุดคือการขาดการมองเห็น (Visibility) ทีมรักษาความปลอดภัยส่วนใหญ่ไม่มีรายการทั้งหมดของ NHI ที่ทำงานอยู่ในระบบของตน Identity เหล่านี้มักถูกสร้างขึ้นแบบไดนามิกโดยนักพัฒนาหรือระบบอัตโนมัติเพื่อทำหน้าที่เฉพาะกิจ เมื่อสร้างเสร็จแล้ว พวกมันก็แทบไม่เคยถูกบันทึกหรือติดตามในระบบจัดการ Identity ส่วนกลาง จนกลายเป็น "Shadow Identities" ที่ยังทำงานอยู่แต่ไม่มีใครมองเห็น หากไม่มีภาพรวมที่สมบูรณ์ว่ามี NHI ใดบ้าง, ใคร (หรืออะไร) สร้างมันขึ้นมา, และมันกำลังเข้าถึงอะไรอยู่ ก็เป็นไปไม่ได้เลยที่จะสร้างกลยุทธ์ความปลอดภัยที่มีประสิทธิภาพ
2. "ตั้งค่าแล้วลืม" คือหายนะด้านความปลอดภัย
แนวทางปฏิบัติทั่วไปของนักพัฒนาคือการกำหนดสิทธิ์ที่กว้างขวางให้กับ NHI เพื่อให้แน่ใจว่าบริการหรือแอปพลิเคชันจะทำงานได้โดยไม่สะดุด คล้ายกับการที่คุณติดตั้งแอปบนมือถือแล้วกดยินยอมให้เข้าถึงทุกอย่างเพื่อรีบใช้งานแล้วก็ลืมไป การให้สิทธิ์ที่กว้างเกินไปกับ NHI อาจทำให้การตั้งค่าง่ายขึ้น แต่ก็สร้างช่องโหว่ขนาดใหญ่เอาไว้ หลักการให้สิทธิ์น้อยที่สุด (Principle of Least Privilege) มักถูกละเลยเพื่อแลกกับความเร็วและความสะดวกสบาย ทำให้ Identity ที่มีสิทธิ์สูงเหล่านี้กลายเป็นเป้าหมายที่น่าสนใจสำหรับผู้โจมตี
3. ไม่มีบริบท ก็ไม่มีการควบคุมที่ทันสมัย
ความปลอดภัยของ Identity สมัยใหม่ต้องอาศัย "บริบท" เช่น เมื่อผู้ใช้ล็อกอิน เราสามารถตรวจสอบตัวตนจากตำแหน่ง, อุปกรณ์ และเครือข่าย และอาจร้องขอการยืนยันตัวตนหลายปัจจัย (MFA) หากมีสิ่งผิดปกติ แต่ NHI ไม่มีบริบทเหล่านี้เลย มันเป็นเพียงโค้ดที่ทำงานบนเซิร์ฟเวอร์ และเนื่องจากมันยืนยันตัวตนด้วย Credential ที่คงที่และมีอายุการใช้งานยาวนาน MFA จึงใช้ไม่ได้ผล ซึ่งหมายความว่าหาก Credential ถูกขโมยไป ก็ไม่มีด่านที่สองมาขวางผู้โจมตีได้
4. Identity กำพร้า และผีดิจิทัล
จะเกิดอะไรขึ้นเมื่อนักพัฒนาที่สร้าง Service Account ลาออกจากบริษัท? หรือเมื่อแอปพลิเคชันที่ใช้ API Token ถูกยกเลิกการใช้งาน? ในองค์กรส่วนใหญ่ NHI ที่เกี่ยวข้องมักจะถูกทิ้งไว้เบื้องหลัง Identity "กำพร้า" เหล่านี้ยังคงทำงานได้พร้อมสิทธิ์เดิม แต่ไม่มีใครเป็นเจ้าของหรือรับผิดชอบอีกต่อไป "ผีดิจิทัล" เหล่านี้คือฝันร้ายด้านการปฏิบัติตามข้อกำหนดและความเสี่ยงด้านความปลอดภัย เพราะมันคือประตูหลังที่ถูกทิ้งร้างและไม่มีใครเฝ้ามอง
ทีมรักษาความปลอดภัยจะกลับมาควบคุมได้อย่างไร
เมื่อต้องเผชิญกับพื้นที่เสี่ยงต่อการโจมตี (Attack Surface) ที่ขยายตัวและทำงานได้เองมากขึ้น ทีมรักษาความปลอดภัยชั้นนำกำลังเปลี่ยนจากการแก้ปัญหาเฉพาะหน้าไปสู่การกำกับดูแลเชิงรุก โดยเริ่มต้นจากการยอมรับว่าทุกระบบ, สคริปต์ และ Agent ที่มี Credential คือ Identity ที่สมควรได้รับการควบคุม
ค้นหาและจัดทำรายการ NHI ทั้งหมด: แพลตฟอร์ม Identity สมัยใหม่สามารถสแกนสภาพแวดล้อมต่างๆ เช่น AWS, GCP เพื่อค้นหาโทเค็นที่ซ่อนอยู่, Service Account ที่ไม่มีการจัดการ และสิทธิ์ที่เกินความจำเป็น
จัดลำดับความสำคัญและจัดการ Identity ความเสี่ยงสูงก่อน: ไม่ใช่ NHI ทุกตัวจะเสี่ยงเท่ากัน ควรจัดลำดับความสำคัญในการแก้ไขตามระดับสิทธิ์และการเข้าถึง จากนั้นจึงปรับขนาดสิทธิ์ให้เหมาะสมตามหลักการให้สิทธิ์น้อยที่สุด และใช้มาตรการที่เข้มงวดขึ้น เช่น การหมุนเวียน Credential อัตโนมัติ หรือการสร้าง "Kill Switch" เพื่อหยุดการทำงานของ AI Agent ทันทีที่พบพฤติกรรมผิดปกติ
ทำให้การกำกับดูแลและวงจรชีวิตเป็นอัตโนมัติ: NHI ก็ต้องการวงจรชีวิตที่เข้มงวดเช่นเดียวกับมนุษย์ (การสร้าง, การเปลี่ยนบทบาท, การลบออก) องค์กรชั้นนำกำลังทำให้กระบวนการเหล่านี้เป็นอัตโนมัติทั้งหมด เพื่อไม่ให้เกิดบัญชีกำพร้าที่ถูกทิ้งไว้
ทำไมโครงสร้างความปลอดภัยด้านข้อมูลระบุตัวตน (Identity Security Fabric) จึงเปลี่ยนเกม
ความเสี่ยงส่วนใหญ่ของ NHI ไม่ได้มาจากตัวตนของมันเอง แต่มาจากระบบที่แยกส่วนกันในการจัดการ การมีแพลตฟอร์มความปลอดภัยด้านข้อมูลระบุตัวตนแบบครบวงจรจะช่วยรวบรวม Identity ทั้งหมด ทั้งที่เป็นมนุษย์และไม่ใช่มนุษย์ มาอยู่ภายใต้ระนาบการควบคุมเดียวกัน (Single Control Plane)
ด้วยแพลตฟอร์มอย่าง Okta ทีมจะสามารถ:
- ค้นหา Identity และช่องว่างด้านความปลอดภัยโดยอัตโนมัติ
- ใช้หลักการสิทธิ์น้อยที่สุดด้วยการหมุนเวียนและจัดเก็บข้อมูลลับอย่างปลอดภัย
- กำหนดนโยบายวงจรชีวิตสำหรับทุก Identity
- ขยายรูปแบบการควบคุม Identity ไปยังบริการและงานเบื้องหลัง
- ควบคุมการเข้าถึงบริการ AI ของ AWS เช่น Bedrock และ Amazon Q
แทนที่จะต้องแก้ปัญหาด้วยเครื่องมือหลายชิ้น ทีมสามารถกำหนดนโยบายควบคุม Identity เพียงครั้งเดียวและนำไปใช้ได้ทุกที่ ซึ่งหมายถึงจุดบอดที่น้อยลง, การตอบสนองที่เร็วขึ้น และลดพื้นที่เสี่ยงต่อการโจมตี
อย่าปล่อยให้ NHI กลายเป็นจุดบอดที่ใหญ่ที่สุดของคุณ
AI Agent และ Non-Human Identity กำลังเปลี่ยนแปลงภูมิทัศน์ความปลอดภัยของคุณอย่างรวดเร็ว คุณไม่จำเป็นต้องสร้างกลยุทธ์ใหม่ทั้งหมด แต่คุณต้องปฏิบัติต่อ Non-Human Identity ในฐานะที่เป็นจุดเข้าถึงที่สำคัญซึ่งสมควรได้รับการกำกับดูแลเช่นเดียวกับผู้ใช้ทุกคน
ด้วยแพลตฟอร์ม Identity แบบครบวงจร ทีมรักษาความปลอดภัยสามารถตรวจสอบสิ่งที่กำลังทำงานอยู่, ใช้การควบคุมที่ขยายผลได้ และตัดการเข้าถึงที่มีความเสี่ยงออกไปก่อนที่จะถูกโจมตี ไม่ใช่หลังจากเกิดเหตุไปแล้ว
#ดรกฤษฎาแก้ววัดปริง #ไทยสมาร์ทซิตี้ #SmartCity #DRKRIT #สมาร์ทซิตี้คลิก