Least privilege

Least privilege คือหลักการด้านความปลอดภัยที่บอกว่าให้สิทธิ์เท่าที่งานตรงหน้าต้องใช้จริง ไม่ให้เกินกว่านั้น หน้า glossary ของ NIST ซึ่งเป็นหน่วยงานมาตรฐานของสหรัฐ เก็บนิยามของคำนี้ไว้หลายชุด ชุดที่ยกมาจาก CNSSI 4009-2015 และ NIST SP 800-12 Rev. 1 เขียนว่าเป็นหลักการที่ระบบควรจำกัดสิทธิ์การเข้าถึงของผู้ใช้ หรือของ process ที่ทำงานแทนผู้ใช้ ให้เหลือน้อยที่สุดเท่าที่จำเป็นต่อการทำงานที่ได้รับมอบหมายให้สำเร็จ อีกชุดหนึ่งบนหน้าเดียวกันที่มาจาก NIST SP 800-53 Rev. 5 มองจากมุมการออกแบบ คือให้สถาปัตยกรรมความปลอดภัยถูกออกแบบให้แต่ละหน่วยได้รับทรัพยากรและสิทธิ์ขั้นต่ำเท่าที่จำเป็นต่อการทำหน้าที่ของตัวเอง สังเกตว่าวงเล็บที่พูดถึง process ซึ่งทำงานแทนผู้ใช้ อยู่ในนิยามมาตั้งแต่ก่อนที่ agent จะเข้ามาอยู่ในที่ทำงานจริง หลักนี้จึงไม่ใช่ของใหม่ที่คิดขึ้นเพื่อ AI แต่เป็นของเดิมที่จู่ๆ มีสิ่งที่ต้องคุมเพิ่มขึ้นมาอีกประเภท

Microsoft เขียนแบบแผนความปลอดภัยชื่อ Least privilege for AI agents ไว้ในชุดเอกสาร Zero Trust และไล่ปัญหาที่เจอบ่อยไว้ห้าข้อ ตั้งแต่ตัวตนของ agent ที่คลุมเครือเพราะไปใช้ secret หรือ service principal ร่วมกัน สิทธิ์ที่บวมขึ้นเรื่อยๆ เพราะทีมให้ role กว้างไว้ก่อนเพื่อให้ pilot เดินได้ แล้วไม่เคยกลับมาลดขอบเขตตอนงานนิ่งแล้ว ไปจนถึง audit trail ที่อ่อน เพราะ log มักเก็บแค่คำตอบที่ตอบกลับผู้ใช้ ไม่ได้เก็บว่า tool ตัวไหนถูกเรียกด้วย scope อะไรและระบบปลายทางตัดสินใจอนุญาตอย่างไร อีกข้อที่ใกล้ตัวคนทำงานคือข้อ over-broad tool access ซึ่งเอกสารเขียนว่าถ้า agent เรียก tool หรือ action ตัวไหนก็ได้ prompt-injection ครั้งเดียวหรือ bug ใน workflow ครั้งเดียวก็ทำให้เกิดปฏิบัติการที่กระทบสูงอย่างการ export การลบ หรือการเปลี่ยนสิทธิ์ หรือทำให้เกิดการต่อ action ข้ามบริการกันเป็นทอดๆ ได้ ทางแก้ที่หน้านี้แนะนำคือให้ agent มีตัวตนถาวรที่ดูแลตลอดวงจรชีวิต ควบคู่ไปกับการทำให้สิทธิ์สูงมีอายุจำกัดด้วยการยกระดับแบบ just-in-time เช่น เปิด role ชั่วคราว ใช้ token อายุสั้น หรือผ่านการอนุมัติ เพื่อให้สิทธิ์สูงมีอยู่เฉพาะช่วงที่ workflow นั้นทำงานอยู่ และในตัวอย่างของ agent ที่เปิดหรือแก้ ticket ก็แนะนำให้แยก role อ่านออกจาก role เขียน อนุญาตเฉพาะ action สร้างกับแก้ ปิด action ลบและ action ของผู้ดูแลระบบ แล้วให้คนอนุมัติเมื่อมีการแก้ทีละหลายรายการ ซึ่งเป็นจุดที่ human-in-the-loop เข้ามารับช่วง ส่วน entra-agent-id คือตัวอย่างเครื่องมือฝั่งผู้ให้บริการที่ทำให้ agent มีตัวตนของตัวเองเพื่อให้ผูกสิทธิ์และเพิกถอนได้

จุดที่ต้องอ่านให้ครบคือหัวข้อประโยชน์ของเอกสารฉบับเดียวกัน ซึ่งเขียนว่า RBAC ที่กำหนดขอบเขตชัด ขอบเขตของ resource ข้อมูล และ action ที่ระบุไว้ชัด รวมถึง allowlist ของ tool ช่วยจำกัดผลกระทบของ prompt injection ของ workflow ที่เพี้ยนไปจากที่ตั้งใจ และของการเรียก tool ต่อกันเป็นทอดๆ คำที่เอกสารใช้คือจำกัดผลกระทบ ไม่ใช่ป้องกันไม่ให้เกิด คนทำงานจะเจอหลักนี้ของจริงตอนตั้งค่าเครื่องมือในมือ claude-code มีกฎ permission สามแบบคือ allow ที่ให้ใช้ tool นั้นได้โดยไม่ต้องขออนุมัติ ask ที่ถามยืนยันทุกครั้งที่จะใช้ และ deny ที่ห้ามใช้ เอกสารระบุว่ากฎถูกไล่ตามลำดับ deny แล้วจึง ask แล้วจึง allow กฎที่ตรงเป็นตัวแรกตามลำดับนี้คือตัวตัดสิน และความเจาะจงของกฎไม่ได้เปลี่ยนลำดับ ผลที่ตามมาคือกฎ deny แบบกว้างจะปิดกั้นทุกคำสั่งที่เข้าข่าย รวมถึงคำสั่งที่ตรงกับกฎ allow ที่แคบกว่าด้วย พูดอีกอย่างคือกฎ deny พ่วงข้อยกเว้นแบบ allowlist ไม่ได้ ฝั่งมาตรฐาน mcp ก็มีหัวข้อ Scope Minimization ในคู่มือ security best practices ที่แนะนำให้เริ่มจากชุด scope เล็กที่สุดซึ่งมีแต่ operation ความเสี่ยงต่ำอย่างการสำรวจและการอ่าน แล้วค่อยขอเพิ่มเป็นขั้นเมื่อต้องใช้จริง พร้อมระบุความผิดพลาดที่พบบ่อยไว้ด้วย เช่น การใช้ scope แบบ wildcard หรือ scope รวมทุกอย่างอย่าง *, all และ full-access ข้อควรระวังข้อแรกคือการอนุญาตแบบครึ่งๆ กลางๆ ไม่นับว่าปิดทาง เอกสารของ Claude Code ยกตัวอย่างว่าการจำกัด WebFetch ให้เข้าได้เฉพาะ domain ที่กำหนดอย่างเดียวยังไม่ได้ปิดการเข้าถึงเครือข่าย เพราะถ้ายังเปิด Bash ไว้ Claude ก็ยังใช้ curl หรือ wget ไปยัง URL ไหนก็ได้ ข้อควรระวังข้อที่สองคือกฎเหล่านี้บังคับโดยตัวโปรแกรม ไม่ใช่โดย model คำสั่งที่เราเขียนใน prompt ชี้นำได้แค่ว่า model จะพยายามทำอะไร แต่ไม่เปลี่ยนว่าโปรแกรมยอมให้ทำอะไร ข้อควรระวังข้อสุดท้ายคือต้นทุน เอกสารของ Microsoft ยอมรับไว้ตรงๆ ในหัวข้อ trade-offs ว่าการออกแบบ role ตามงาน ขอบเขต และ allowlist ใช้แรงวางแผนตั้งแต่ต้นมากกว่าการแจก role กว้างๆ ไปเลย ต้องมีกระบวนการดูแลต่อเนื่องทั้งการทบทวนสิทธิ์และการทดสอบการเพิกถอน และการอนุมัติเพิ่มขั้นอาจทำให้งานที่ต้องใช้สิทธิ์สูงช้าลง

ตัวอย่างจากบทสนทนาจริง

หัวหน้าฝ่ายจัดซื้อ: ทีม IT จะให้ agent ที่มาช่วยเปิดใบสั่งซื้อ ใช้ account เดียวกับที่ต่อระบบบัญชีอยู่แล้ว ซึ่งมีสิทธิ์เต็มทุกอย่าง เขาบอกว่าวิธีนี้ติดตั้งวันเดียวเสร็จ แบบนี้มีปัญหาตรงไหนคะ

ฝ่ายความปลอดภัยข้อมูล: ปัญหาคือวันที่มันทำพลาด เราจะจำกัดความเสียหายไม่ได้เลยครับ ถ้าให้สิทธิ์เท่าที่ต้องใช้จริง คือแยกสิทธิ์อ่านข้อมูลผู้ขายออกจากสิทธิ์สร้างใบสั่งซื้อ แล้วไม่ให้สิทธิ์ลบกับสิทธิ์ผู้ดูแลระบบไปเลย ต่อให้ agent เข้าใจคำสั่งผิดหรือโดนหลอกด้วยข้อความแปลกปลอมในเอกสารที่มันอ่าน สิ่งที่มันทำได้ก็ยังอยู่ในกรอบเดิม แนวนี้ตรงกับที่เอกสาร Zero Trust ของ Microsoft ยกไว้เป็นตัวอย่างสำหรับ agent ที่เปิดหรือแก้ ticket พอดี คือแยก role อ่านออกจาก role เขียน อนุญาตเฉพาะ action สร้างกับแก้ และให้คนอนุมัติเมื่อมีการแก้ทีละหลายรายการ

ระวังสับสนกับ

• rbac : RBAC คือกลไกที่จับสิทธิ์มารวมเป็น role แล้วผูก role กับคนหรือกับ agent ส่วน least privilege คือหลักที่บอกว่า role นั้นควรเล็กแค่ไหน องค์กรที่วาง RBAC ครบแล้วแต่ยังแจก role กว้างเกินงาน ก็ยังไม่ได้ทำตามหลักนี้
• sandbox : sandbox จำกัดในระดับระบบปฏิบัติการว่าโปรแกรมแตะไฟล์หรือเครือข่ายส่วนไหนได้บ้าง ส่วน least privilege เป็นหลักที่ใช้ตั้งแต่ชั้นสิทธิ์ของบัญชีและ scope ของ token สองอย่างนี้ใช้คู่กัน เอกสารของ Claude Code ระบุว่ากฎ deny ของ Read และ Edit ใช้กับ tool ไฟล์ของตัวเองและคำสั่งไฟล์ที่มันรู้จักใน Bash แต่ไม่ครอบคลุม subprocess ที่ไปเปิดไฟล์เอง ถ้าต้องการการบังคับระดับระบบปฏิบัติการที่กันทุก process ต้องเปิด sandbox
• permission-request : permission request คือจังหวะที่ระบบเด้งขึ้นมาถามก่อนลงมือ ซึ่งเป็นวิธีบังคับใช้อย่างหนึ่ง ส่วน least privilege คือการตัดสินใจตั้งแต่ต้นว่าอะไรไม่ควรมีให้ถามด้วยซ้ำ งานที่ agent ไม่ควรทำได้ ควรถูกปิดไว้ ไม่ใช่ปล่อยไว้ให้มาถามแล้วรอคนกดผ่านตอนรีบ
• audit-log : audit log บอกย้อนหลังว่าเกิดอะไรขึ้นและใครเป็นคนทำ ส่วน least privilege กำหนดล่วงหน้าว่าอะไรเกิดขึ้นได้บ้าง เอกสารของ Microsoft ใช้สองอย่างนี้คู่กัน เพราะระบุว่าหนึ่งในปัญหาของ agent คือ log มักเก็บแค่คำตอบที่ตอบกลับผู้ใช้ ไม่ได้เก็บ tool action และ scope ที่ใช้จริง