เข้าใจ RBAC, ABAC และ ReBAC: เลือกโมเดลควบคุมสิทธิ์ให้เหมาะกับระบบ

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

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

RBAC: ควบคุมสิทธิ์จากบทบาท

RBAC หรือ Role-Based Access Control เริ่มต้นจากคำถามว่า “ผู้ใช้มีบทบาทอะไร” แล้วกำหนดว่าบทบาทนั้นสามารถทำอะไรได้บ้าง ผู้ใช้แต่ละคนอาจมีหนึ่งหรือหลายบทบาท และได้รับสิทธิ์ตามบทบาทที่ระบบกำหนดไว้

ตัวอย่างการกำหนดสิทธิ์แบบ RBAC ได้แก่

• admin สามารถเพิ่ม ลบ และแก้ไขผู้ใช้ได้
• editor สามารถสร้างและแก้ไขบทความได้
• viewer สามารถอ่านข้อมูลได้อย่างเดียว

จุดเด่นของ RBAC คือเข้าใจง่าย ออกแบบหน้าจอจัดการสิทธิ์ได้ตรงไปตรงมา และอธิบายให้ทีมธุรกิจเข้าใจได้ไม่ยาก โมเดลนี้จึงเหมาะกับระบบที่ขอบเขตหน้าที่ค่อนข้างนิ่ง เช่น back office, CMS และเครื่องมือภายในองค์กร

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

ABAC: ตัดสินสิทธิ์จากคุณลักษณะและบริบท

ABAC หรือ Attribute-Based Access Control ไม่ได้พิจารณาเฉพาะบทบาท แต่ใช้คุณลักษณะของผู้ใช้ ทรัพยากร การกระทำ และบริบทของคำขอประกอบกัน คุณลักษณะเหล่านี้อาจเป็นแผนก ภูมิภาค ระดับความลับ สถานะเอกสาร เวลา หรือเครือข่ายที่ผู้ใช้กำลังเชื่อมต่อ

ตัวอย่าง policy แบบ ABAC อาจเขียนแนวคิดได้ดังนี้

user.department == document.department
AND document.status != "confidential"
AND request.network == "office"

โมเดลนี้เหมาะกับระบบที่มีเงื่อนไขละเอียดและเปลี่ยนแปลงตามสถานการณ์ เช่น ระบบทรัพยากรบุคคล การเงิน หรือ enterprise SaaS ข้อดีคือไม่จำเป็นต้องสร้างบทบาทใหม่ทุกครั้งที่เกิดเงื่อนไขเพิ่มเติม เพราะสามารถเพิ่ม attribute หรือปรับ rule ให้สะท้อน policy ใหม่ได้โดยตรง

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

ReBAC: ให้ความสัมพันธ์เป็นตัวกำหนดสิทธิ์

ReBAC หรือ Relationship-Based Access Control พิจารณาว่าผู้ใช้มีความสัมพันธ์อย่างไรกับทรัพยากรหรือบุคคลอื่นในระบบ สิทธิ์จึงไม่ได้เกิดจากตำแหน่งหรือคุณลักษณะเท่านั้น แต่อาจเกิดจากการเป็นเจ้าของ สมาชิก ผู้รับผิดชอบ หรือบุคคลที่เชื่อมโยงกันผ่านโครงสร้างบางอย่าง

ตัวอย่างการควบคุมสิทธิ์แบบ ReBAC ได้แก่

• ผู้ใช้ดูไฟล์ได้เพราะเป็นสมาชิกทีมเดียวกับเจ้าของไฟล์
• ผู้ใช้แก้ไข ticket ได้เพราะเป็นผู้รับผิดชอบงานนั้น
• ผู้ใช้เห็นโพสต์ได้เพราะเป็นเพื่อนกับผู้เขียน
• สมาชิกเข้าถึงเอกสารได้เพราะอยู่ใน workspace ที่ได้รับการแชร์

ReBAC เหมาะกับระบบที่สิทธิ์เคลื่อนไปตามโครงสร้างความสัมพันธ์ เช่น social network, collaboration tool, workspace, folder sharing ตลอดจนระบบที่มีรูปแบบคล้าย Google Drive หรือ GitHub organization โมเดลนี้สะท้อนโลกจริงได้ดี เพราะสิทธิ์จำนวนมากเกิดจากความสัมพันธ์กับทรัพยากรมากกว่าตำแหน่งอย่างเป็นทางการ

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

เลือกโมเดลให้ตรงกับลักษณะสิทธิ์

การเลือกโมเดลควรเริ่มจากรูปแบบของ policy ที่ระบบต้องรองรับ ไม่ควรเริ่มจากการเลือกเทคโนโลยีที่ดูทรงพลังที่สุด เพราะความสามารถที่เพิ่มขึ้นมักมาพร้อมต้นทุนด้านการพัฒนา การดูแล และการตรวจสอบปัญหา

แนวทางตัดสินใจเบื้องต้นมีดังนี้

• เลือก RBAC เมื่อระบบมีบทบาทชัดเจน สิทธิ์ไม่ซับซ้อน และเปลี่ยนแปลงไม่บ่อย
• เลือก ABAC เมื่อสิทธิ์ขึ้นอยู่กับเงื่อนไข เช่น แผนก ภูมิภาค ระดับความลับ เวลา หรือสถานะข้อมูล
• เลือก ReBAC เมื่อสิทธิ์ขึ้นอยู่กับความสัมพันธ์ เช่น owner, member, assignee, team, friend หรือ parent folder

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

ระบบจริงอาจใช้แบบผสม

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

ตัวอย่างเช่น ผู้ใช้จะแก้ไขเอกสารได้เมื่อผ่านเงื่อนไขทั้งหมดต่อไปนี้

1. มีบทบาทเป็น editor ตาม RBAC
2. อยู่ภูมิภาคเดียวกับเอกสารตาม ABAC
3. เป็นสมาชิกของ workspace ที่เก็บเอกสารตาม ReBAC

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

สิ่งที่ต้องมีไม่ว่าจะใช้โมเดลใด

โมเดลควบคุมสิทธิ์ที่ดีต้องมาพร้อมเครื่องมือสำหรับตรวจสอบพฤติกรรมของมัน Policy test ควรครอบคลุมทั้งกรณีที่อนุญาต กรณีที่ต้องปฏิเสธ และกรณีขอบที่เกิดจากข้อมูลหรือความสัมพันธ์หลายระดับ เพื่อป้องกันการแก้ policy หนึ่งข้อแล้วทำให้สิทธิ์ส่วนอื่นเปลี่ยนโดยไม่ตั้งใจ

องค์ประกอบสำคัญที่ควรเตรียมไว้ ได้แก่

• ชุดทดสอบ policy ที่ทำงานซ้ำได้
• Audit log ที่บันทึกผู้ใช้ การกระทำ ทรัพยากร และ policy ที่เกี่ยวข้อง
• Error reason ที่อธิบายสาเหตุได้โดยไม่เปิดเผยข้อมูลอ่อนไหว
• เครื่องมือตรวจสอบสิทธิ์ของผู้ใช้แต่ละราย
• กระบวนการทบทวน policy เมื่อโครงสร้างองค์กรหรือข้อกำหนดเปลี่ยนแปลง

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

สรุป

RBAC เหมาะกับสิทธิ์ที่แบ่งตามบทบาทอย่างชัดเจน ABAC เหมาะกับ policy ที่ต้องพิจารณาคุณลักษณะและบริบท ส่วน ReBAC เหมาะกับระบบที่สิทธิ์ไหลไปตามความสัมพันธ์ระหว่างผู้ใช้กับทรัพยากร ระบบจำนวนมากสามารถใช้ทั้งสามแนวคิดร่วมกัน โดยให้แต่ละโมเดลรับผิดชอบส่วนที่มันอธิบายได้ดีที่สุด

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