หากคุณเคยเป็น Admin ที่ต้องคอยมานั่ง Add User ทีละคนใส่ใน ACL ของทุกโฟลเดอร์ หรือต้องคอยแก้สิทธิ์ให้พนักงานทีละคนเมื่อมีการเลื่อนตำแหน่ง คุณจะพบว่ามันคือนรกของการจัดการ RBAC หรือ Role-Based Access Control ถูกคิดค้นมาเพื่อแก้ปัญหานี้ โดยเปลี่ยนวิธีการมอง “สิทธิ์” ใหม่ ให้ผูกกับ “บทบาทหน้าที่” แทนตัวบุคคล
ปัญหาของระบบเดิม (ทำไม ACL ถึงไม่พอ?)
ในระบบแบบเก่า (Discretionary Access Control หรือ ACL แบบพื้นฐาน) เรามักจะมอบสิทธิ์แบบ:
“นาย A สามารถอ่านไฟล์บัญชีได้”
สมมติวันหนึ่งนาย A ลาออก และนาย B มาแทน คุณต้องไปไล่ลบสิทธิ์นาย A ออกจากทุกที่ แล้วใส่นาย B เข้าไปแทน ถ้ามีไฟล์เป็นร้อยเป็นพันไฟล์ ความผิดพลาดจะเกิดขึ้นง่ายมาก (Human Error)
“นาย C, D สามารถอ่านไฟล์บัญชีได้ เหมือน B”
ถ้าคนที่มาเพิ่มในแผนกเดียวกัน ทำงาน เหมือนนาย B แปลว่าต้องไล่เพิ่มสิทธิ์ให้ C, D เหมือนกับ B จึงจะสามารถทำงานได้เหมือน B ที่นี้ถ้าแผนกนี้ เพิ่มเป็น 30 คน ก็ …
หลักการทำงานของ RBAC (The Concept)
RBAC แก้ปัญหาด้วยการเพิ่ม “ตัวกลาง” ที่เรียกว่า Role (บทบาท) เข้ามา
- Permission: เรากำหนดก่อนว่าทำอะไรได้บ้าง (เช่น Read, Write, Delete, Approve)
- Role: เราเอากระเป๋ามาใบหนึ่ง เขียนหน้ากระเป๋าว่า “Accounts” แล้วเอา Permission ที่จำเป็นใส่ลงไปในกระเป๋านั้น
- User: เมื่อมีพนักงานใหม่เข้ามา เราแค่ยื่นกระเป๋า “Accounts” ให้เขาถือ
ผลลัพธ์:
- นาย C เป็น Accounts -> นาย C ได้สิทธิ์ทั้งหมดในกระเป๋า Account
- ถ้านาย A ย้ายแผนก -> ก็แค่ดึงกระเป๋า Accounts คืน แล้วยื่นกระเป๋า “Sale” ให้แทน (จบในคลิกเดียว)
ตัวอย่างการใช้งานจริง (Use Case)
ลองนึกภาพระบบหลังบ้านของบริษัท E-commerce
| Role (บทบาท) | Permissions (สิทธิ์ที่ทำได้) |
|---|---|
| Customer Support | ดูข้อมูลลูกค้า, ดูประวัติคำสั่งซื้อ (ห้ามลบ, ห้ามแก้ราคา) |
| Inventory Staff | แก้ไขจำนวนสินค้าในสต็อก, เพิ่มสินค้าใหม่ (ห้ามดูข้อมูลบัตรเครดิตลูกค้า) |
| Super Admin | ทำได้ทุกอย่าง (Full Access) |
สถานการณ์: พนักงานชื่อ “สมชาย” เดิมอยู่ฝ่าย Support ย้ายไปคุมสต็อกสินค้า
- ถ้าไม่มี RBAC: Admin ต้องไปไล่ติ๊กถูกสิทธิ์ Support ออกทีละอัน แล้วไปไล่ติ๊กสิทธิ์ Inventory เข้าใหม่
- ถ้าใช้ RBAC: Admin แค่เปลี่ยน Role ของสมชายจาก
Group: Supportไปเป็นGroup: Inventoryจบงานทันที
ข้อดีและข้อเสียของ RBAC
ข้อดี (Pros)
- ลดความซ้ำซ้อน: ไม่ต้องกำหนดสิทธิ์ซ้ำๆ ให้กับ User ทุกคน
- ความปลอดภัยสูงขึ้น: ใช้หลักการ Least Privilege ได้ง่าย (ให้สิทธิ์เท่าที่ Role นั้นจำเป็นต้องใช้)
- Onboarding เร็ว: พนักงานใหม่มา แค่ Assign Role ก็เริ่มงานได้เลย
ข้อเสีย/ความท้าทาย (Cons)
- Role Explosion: หากออกแบบไม่ดี อาจเกิด Role งอกขึ้นมาเยอะเกินไป เช่น Manager_Level1, Manager_IT, Manager_HR_Copy จน Admin งงเอง
- ความยืดหยุ่นน้อยกว่าในกรณีพิเศษ: ถ้าอยากให้ User คนหนึ่งทำอะไรพิเศษนอกเหนือจาก Role ปกติ อาจต้องสร้าง Role ใหม่ขึ้นมาเฉพาะเพื่อเขาคนเดียว
บทสรุป: เริ่มต้นออกแบบ RBAC อย่างไร?
หากคุณกำลังจะทำระบบ RBAC (ไม่ว่าจะ Config ใน Cloud หรือเขียนโปรแกรมเอง) ให้เริ่มจาก 3 ขั้นตอนนี้:
- List Resources: ในระบบเรามีอะไรบ้าง? (เช่น รายงานการเงิน, ข้อมูลลูกค้า, ปุ่มลบ User)
- Define Roles: ในองค์กรมีตำแหน่งอะไรบ้าง? (Admin, Editor, Viewer)
- Matrix Mapping: ตีตารางจับคู่เลยว่า Role ไหน ทำอะไรกับ Resource ไหนได้บ้าง
คำแนะนำ: อย่าเริ่มจากสร้าง Role ให้เยอะที่สุด แต่ให้เริ่มจาก “Role พื้นฐาน” ก่อน แล้วค่อยๆ เพิ่มเมื่อจำเป็น เพื่อป้องกันปัญหา Role เฟ้อครับ
อ่านเพิ่มเติม