Role​-​based​ ​Access​ ​Control​ ​คือ​อะไร​ ​และ​ควร​ออกแบบ​สิทธิ์​ผู้​ใช้​อย่างไร

Role-based Access Control (RBAC) เป็นวิธีกำหนดสิทธิ์โดยผูกการกระทำกับบทบาท เช่น ผู้ยื่น เจ้าหน้าที่ และผู้ดูแล แล้วมอบบทบาทให้ผู้ใช้ แทนการเขียนกฎแยกคนต่อคน วิธีนี้ทำให้ทบทวนสิทธิ์ง่ายขึ้นเมื่อคนย้ายหน้าที่ แต่ชื่อบทบาทอย่าง “Admin” ยังต้องมีขอบเขตชัด

เริ่มจากงานและข้อมูล ไม่ใช่ชื่อบทบาท

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

ภาพที่ 1: การอนุญาตต้องตรวจทั้งบทบาท การกระทำ และรายการข้อมูลที่ขอ

ตัวอย่างสมมติ: ระบบหลายสาขา

ผู้จัดการสาขา A อนุมัติคำขอในสาขา A ได้ แต่ไม่ควรอนุมัติสาขา B แม้มีบทบาทชื่อเดียวกัน API จึงต้องตรวจ branch_id ของรายการจริงร่วมกับสิทธิ์ ไม่เชื่อค่าที่ Frontend ส่งมาเพียงอย่างเดียว หากมีผู้ดูแลส่วนกลาง ให้กำหนดขอบเขตพิเศษอย่างชัดและบันทึกการใช้งานที่สำคัญ

ข้อจำกัดของ RBAC

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

ใช้ในรายงาน

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

อ่าน Authentication กับ Authorization และ Login เว็บแอป หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ ตาราง Role × Action × Scope พร้อมตัวอย่างข้อมูลของแต่ละคน ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

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

แหล่งข้อมูลประกอบ

• OWASP: Authorization Cheat Sheet — RBAC และการตรวจสิทธิ์ระดับรายการ