ABAC คืออะไร: การให้สิทธิ์ตามคุณสมบัติที่ยืดหยุ่นกว่า Role

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

ABAC ย่อมาจาก Attribute-Based Access Control หรือการควบคุมสิทธิ์ด้วยคุณสมบัติของข้อมูล โดยใช้เงื่อนไขจากหลายมิติประกอบการตัดสินใจ เช่น owner, department, status, region, time, device หรือ plan

แนวคิดนี้เหมาะมากกับระบบที่สิทธิ์ไม่สามารถสรุปง่าย ๆ ได้ด้วย role ไม่กี่แบบ โดยเฉพาะระบบที่เติบโตเร็ว มีหลายทีม หลาย tenant หรือมีเงื่อนไขทางธุรกิจที่ซับซ้อน

ABAC ทำงานอย่างไร

หัวใจของ ABAC คือการตัดสินใจว่า อนุญาตหรือไม่อนุญาต โดยอิงจาก attribute ของ 3 ส่วนหลัก

• User attribute เช่น รหัสผู้ใช้ แผนก ระดับสิทธิ์ ตำแหน่ง
• Resource attribute เช่น เจ้าของเอกสาร สถานะเอกสาร ประเภทข้อมูล
• Context attribute เช่น เวลา IP อุปกรณ์ tenant หรือระดับความน่าเชื่อถือของอุปกรณ์

แทนที่ระบบจะถามเพียงว่า “ผู้ใช้นี้เป็นพนักงานหรือไม่” ระบบจะถามลึกขึ้น เช่น

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

ตัวอย่าง ABAC แบบเข้าใจง่าย

สมมติว่ามีเอกสารหนึ่งชุดที่มี attribute ดังนี้

• owner = user_123
• department = finance
• status = draft

เมื่อมีคนพยายามเปิดอ่านเอกสาร ระบบจะไม่ตรวจแค่ว่าเขาเป็น “พนักงาน” หรือเปล่า แต่จะตรวจเงื่อนไขเพิ่มเติม เช่น

• user.id ตรงกับ owner หรือไม่
• user.department ตรงกับ document.department หรือไม่
• document.status อยู่ในสถานะที่อนุญาตให้อ่านหรือไม่

ตัวอย่างกฎที่เป็นไปได้ เช่น

• ถ้าเป็น owner ให้อ่านได้
• ถ้าอยู่แผนก finance ให้อ่านได้เฉพาะเมื่อ status = approved
• ถ้าเป็น intern ห้ามดาวน์โหลด

นี่คือเสน่ห์ของ ABAC เพราะกฎสามารถสะท้อนเงื่อนไขจริงทางธุรกิจได้อย่างตรงไปตรงมา

ABAC ต่างจาก RBAC อย่างไร

RBAC หรือ Role-Based Access Control เป็นแนวคิดที่เริ่มจาก role เช่น admin, editor, viewer แล้วกำหนดสิทธิ์ตามบทบาทนั้น

RBAC เหมาะกับระบบที่โครงสร้างสิทธิ์ค่อนข้างนิ่งและไม่ซับซ้อนมาก แต่เมื่อระบบขยายตัว เงื่อนไขมักเริ่มละเอียดขึ้น เช่น

• ดูได้เฉพาะข้อมูลของทีมตัวเอง
• แก้ไขได้ถ้ารายการยังไม่ approved
• ลบได้เฉพาะผู้สร้างภายใน 24 ชั่วโมง

ถ้าพยายามยัดทุกเงื่อนไขลงใน role จะเกิดปัญหา role explosion ทันที เพราะต้องสร้าง role ย่อยจำนวนมากเพื่อรองรับทุกสถานการณ์ เช่น role ที่ชื่อยาวและเฉพาะทางจนดูแลยาก

ABAC จึงเข้ามาช่วยให้ policy เขียนออกมาเป็นภาษาธุรกิจได้ชัดเจนกว่า เช่น

allow edit invoice
if user.department == invoice.department
and invoice.status == "draft"
and user.level >= 3

ข้อดีคือคนอ่านสามารถเข้าใจได้ทันทีว่ากฎทางธุรกิจคืออะไร โดยไม่จำเป็นต้องสร้าง role พิเศษจำนวนมาก

ทำไม ABAC สำคัญกับ Backend, Chatbot และ AI Agent

ในระบบ backend สมัยใหม่ โดยเฉพาะ chatbot หรือ AI agent เรื่อง authorization สำคัญมาก เพราะระบบเหล่านี้มักเป็นประตูไปสู่ข้อมูลหลายประเภท

ตัวอย่างเช่น

• ลูกค้าอาจถามข้อมูลยอดขาย
• พนักงานอาจถามข้อมูล HR
• ผู้จัดการอาจขอรายงานของทีม

โจทย์จึงไม่ใช่แค่ว่าโมเดล “ตอบได้ไหม” แต่ต้องถามว่า “ควรตอบได้หรือไม่” ด้วย

สมมติผู้ใช้อยู่ department = sales แต่ถามว่า

สรุป pipeline ของทีม finance ให้หน่อย

แม้โมเดลจะสามารถสร้างคำตอบได้ ระบบ authorization ต้องสามารถตัดสินใจว่า ไม่อนุญาต เพราะ attribute ของผู้ใช้ไม่ผ่านเงื่อนไขการเข้าถึงข้อมูลนั้น

นี่คือเหตุผลที่ ABAC มีบทบาทสำคัญในระบบ AI เพราะช่วยกันไม่ให้ความสามารถของโมเดลกลายเป็นช่องโหว่ด้านความปลอดภัย

จุดสำคัญที่ต้องออกแบบให้ดี

การใช้ ABAC ให้มีประสิทธิภาพ ไม่ได้มีแค่การเขียน policy แต่ต้องใส่ใจกับแหล่งที่มาของ attribute ด้วย

1. Attribute ต้องน่าเชื่อถือ

• User attribute อาจมาจาก identity provider
• Resource attribute อาจมาจาก database
• Context attribute อาจมาจาก request เช่น เวลา IP tenant หรือ device trust

ถ้า attribute เหล่านี้ไม่น่าเชื่อถือ ต่อให้ policy เขียนดีแค่ไหน ระบบก็ยังตัดสินใจผิดได้

2. อย่ากระจายเงื่อนไขสิทธิ์ไว้ทั่ว codebase

อีกปัญหาที่พบได้บ่อยคือการเขียน if permission กระจายอยู่หลายจุดในระบบ ทำให้ดูแลยาก แก้ไขยาก และตรวจสอบได้ยาก

แนวทางที่ดีกว่าคือมี policy layer ที่ชัดเจน เช่น service กลางที่มีหน้าที่ตอบว่า allow หรือ deny พร้อมเหตุผลประกอบ

ประโยชน์ของแนวทางนี้คือ

• ทำให้ logic เรื่องสิทธิ์รวมศูนย์
• debug ได้ง่ายขึ้น
• รู้ได้ชัดว่าโดนปฏิเสธเพราะอะไร เช่น owner ไม่ตรง หรือ status ยังเป็น draft

3. ออกแบบให้รองรับการเติบโตของระบบ

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

ABAC ไม่จำเป็นต้องแทนที่ RBAC เสมอไป

ABAC ไม่ได้หมายความว่าต้องเลิกใช้ RBAC ในทันที เพราะในทางปฏิบัติ หลายระบบใช้ทั้งสองแนวทางร่วมกันได้ดี

วิธีที่พบได้บ่อยคือ

• ใช้ role เพื่อกำหนดขอบเขตหน้าที่แบบกว้าง ๆ
• ใช้ attribute เพื่อกำหนดเงื่อนไขเชิงลึก

ตัวอย่างเช่น

• role = manager
• และ user.department == report.department

แนวทางแบบผสมช่วยให้ระบบยังเข้าใจง่ายในระดับโครงสร้าง และยังยืดหยุ่นพอสำหรับกฎทางธุรกิจที่ซับซ้อน

เมื่อไรควรเลือกใช้ ABAC

ABAC เหมาะอย่างยิ่งเมื่อระบบของคุณมีลักษณะดังนี้

• สิทธิ์ขึ้นกับหลายปัจจัย ไม่ใช่แค่ตำแหน่งหรือ role
• มีหลายทีม หลายหน่วยงาน หรือหลาย tenant
• ข้อมูลมีหลายสถานะ เช่น draft, approved, archived
• ต้องการให้ policy สะท้อน business rule ชัดเจน
• มี chatbot หรือ AI agent ที่เข้าถึงข้อมูลอ่อนไหว

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

สรุป

ABAC คือการให้สิทธิ์โดยมองจากข้อมูลจริงรอบด้าน ไม่ใช่ดูแค่บทบาทของผู้ใช้ แต่พิจารณาว่าใครกำลังทำอะไร กับทรัพยากรไหน ภายใต้บริบทแบบใด

แนวทางนี้เหมาะกับระบบที่มีเงื่อนไขซับซ้อน ต้องการความยืดหยุ่นสูง และต้องรักษาความปลอดภัยของข้อมูลอย่างจริงจัง โดยเฉพาะในงาน backend, chatbot และ AI agent ที่มีโอกาสเข้าถึงข้อมูลสำคัญหลายประเภท

สรุปสั้นที่สุดคือ ABAC ไม่ได้มีหน้าที่แค่ล็อกประตู แต่ช่วยให้ระบบรู้ด้วยว่า ใครควรเปิดประตูบานไหนได้บ้าง