Role Permission: ออกแบบสิทธิ์หลายแผนกให้ปลอดภัยและดูแลง่าย

Role Permission คือการกำหนดว่าแต่ละหน้าที่ทำกิจกรรมใดได้ และทำกับข้อมูลในขอบเขตใด สำหรับระบบหลายแผนกควรแยกบทบาท สิทธิ์ และขอบเขตข้อมูลออกจากกัน เช่น ผู้จัดการอนุมัติได้เฉพาะสาขาตนเอง ส่วนบัญชีอ่านได้หลายสาขาแต่แก้จำนวนสินค้าไม่ได้

การมีชื่อ Admin, Manager และ User ยังไม่เพียงพอ หากไม่ได้บอกว่าส่งออก ยกเลิก หรืออนุมัติเอกสารของใครได้บ้าง ระบบอาจเปิดข้อมูลเกินจำเป็นแม้หน้าเมนูดูเรียบร้อย บทความนี้อธิบายวิธีออกแบบกติกาที่ทดสอบและดูแลต่อได้

Role Permission คืออะไร

Role คือกลุ่มหน้าที่ เช่น ผู้ขอ ผู้ตรวจ ผู้อนุมัติ และเจ้าหน้าที่บัญชี Permission คือสิทธิ์ทำกิจกรรม เช่น อ่าน สร้าง แก้ไข อนุมัติ ส่งออก และยกเลิก ส่วน Scope คือขอบเขตข้อมูล เช่น บริษัท สาขา แผนก โครงการ หรือเจ้าของรายการ

Authentication ยืนยันว่าเป็นใคร ส่วน Authorization ตัดสินว่าทำสิ่งที่ขอได้หรือไม่ การ Login สำเร็จไม่ได้แปลว่าอ่านเอกสารทุกฉบับได้ และการเห็นรายการไม่ได้แปลว่าอนุมัติรายการนั้นได้

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

เริ่มจากกิจกรรมที่มีผลต่อธุรกิจ

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

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

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

Role Permission สำหรับหลายแผนกควรใช้ Matrix อย่างไร

ทำตารางกิจกรรมกับหน้าที่ ระบุว่าอนุญาต ปฏิเสธ หรืออนุญาตภายใต้เงื่อนไข พร้อมขอบเขตข้อมูล เช่น เจ้าหน้าที่ฝ่ายขายแก้คำสั่งซื้อที่ตนรับผิดชอบได้เฉพาะก่อนส่งคลัง ผู้จัดการสาขาอนุมัติคำขอในสาขาตามวงเงิน

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

RBAC และเงื่อนไขเพิ่มเติมควรใช้เมื่อไร

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

ไม่ควรสร้าง Role ใหม่สำหรับทุกคู่สาขาและวงเงินจนมีชื่อจำนวนมากที่ดูแลไม่ได้ ให้ Role ตอบว่า “ทำอะไรได้” แล้วใช้ Scope กับกฎเพิ่มเติมตอบว่า “ทำกับรายการไหนและเมื่อไร” โดยเลือกความซับซ้อนเท่าที่งานจริงต้องการ

OWASP Authorization Cheat Sheet แนะนำการให้สิทธิ์เท่าที่จำเป็น ปฏิเสธโดยปริยาย และตรวจทุกคำขอ หลักนี้ช่วยวางจุดตรวจกลางและลดกฎที่กระจัดกระจายตามหน้าจอ

ตัวอย่าง: ผู้จัดการที่รับผิดชอบหลายสาขา

สมมติบริษัทมีสาขา A และ B ผู้จัดการ A ดูเอกสาร A ได้ ผู้จัดการภูมิภาคดูทั้งสองสาขาได้ แต่อนุมัติได้ตามวงเงินที่ได้รับ ส่วนฝ่ายบัญชีเห็นเอกสารที่อนุมัติแล้วเพื่อทำงานต่อ

เมื่อผู้จัดการ A เปิดเลขเอกสารของ B ผ่านลิงก์ ระบบต้องปฏิเสธแม้รู้เลขถูกต้อง การเปลี่ยนตัวกรองหน้าเว็บไม่ใช่หลักฐานว่ามีสิทธิ์ ส่วนรายงานรวมที่เปิดดูได้ต้องไม่เปิดรายละเอียดของรายการนอกขอบเขตโดยไม่ได้รับอนุญาต

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

สถาปัตยกรรมการตรวจสิทธิ์

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

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

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

สิทธิ์ระดับช่องข้อมูล รายงาน และการส่งออก

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

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

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

แยกหน้าที่และสิทธิ์ผู้ดูแล

ผู้ดูแลเทคนิคไม่จำเป็นต้องมีสิทธิ์อนุมัติธุรกรรมทุกชนิด แยกการจัดการบัญชี การเปลี่ยน Role และการเปลี่ยนกฎอำนาจออกจากกันตามความเสี่ยง และบันทึกการเปลี่ยนสิทธิ์ที่สำคัญ

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

เมื่อต้องส่งให้ Vendor ช่วยดูแล ให้จำกัดระบบ ข้อมูล และระยะเวลา มีเจ้าของบัญชีในบริษัทและวิธีถอนสิทธิ์เมื่อจบงาน

กระบวนการรับเข้า ย้ายงาน และออกจากองค์กร

1. ผู้รับผิดชอบยืนยันหน้าที่และขอบเขตที่พนักงานต้องใช้
2. ตั้งสิทธิ์จากชุดที่ผ่านการตกลง ไม่คัดลอกจากเพื่อนทั้งชุดโดยไม่ตรวจ
3. เมื่อย้ายตำแหน่ง ตรวจสิทธิ์ที่ต้องเพิ่มและที่ควรถอนพร้อมกัน
4. รับช่วงงานค้างและมอบหมายเจ้าของใหม่ตามกติกา
5. เมื่อออกจากองค์กร ปิดการเข้าถึงและจัดการ Session หรือ Token ที่ยังใช้งาน
6. ทบทวนบัญชี บทบาท และสิทธิ์พิเศษตามรอบที่เหมาะกับความเสี่ยง

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

ทดสอบสิทธิ์ทั้งสิ่งที่ทำได้และสิ่งที่ต้องทำไม่ได้

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

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

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

เชื่อม API และเพิ่มผู้ใช้งานอย่างไร

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

เมื่อมีหลายบริษัทหรือผู้ใช้มากขึ้น การตรวจ Scope ต้องสม่ำเสมอกับทุกช่องทาง การทำดัชนีค้นหา รายงาน และ Cache ไม่ควรทำให้ข้อมูลข้ามบริษัทปนกันโดยไม่มีตัวแยกที่ตรวจได้

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

ปัญหาที่พบบ่อยและต้นทุนที่ควรเผื่อ

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

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

เช็กลิสต์ Role Permission ก่อนใช้งานจริง

• แยก Role, Permission และ Scope ชัดเจน
• กำหนดข้อห้ามเมื่อคนเดียวมีหลายหน้าที่
• ตรวจสิทธิ์ที่ Server กับทุกกิจกรรมสำคัญ
• ครอบคลุมไฟล์ รายงาน ส่งออก ค้นหา และ API
• ถอนสิทธิ์กับ Session ได้ตามนโยบายที่ตกลง
• เก็บประวัติการเปลี่ยนสิทธิ์และผู้รับผิดชอบ
• ทดสอบข้ามสาขา ข้ามบริษัท และข้อมูลหลายสถานะ
• มีรอบทบทวนสิทธิ์กับเจ้าของหน่วยงาน

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

สรุป: สิทธิ์ที่ดีตรงกับงานและตรวจสอบได้

Role Permission สำหรับระบบหลายแผนกต้องควบคุมทั้งกิจกรรมและขอบเขตข้อมูล เริ่มจากกติกาธุรกิจที่มีเจ้าของ ตรวจทุกคำขอ และทดสอบสิ่งที่ต้องปฏิเสธ เมื่อมีขั้นตอนปรับสิทธิ์ตามการย้ายงาน ระบบจึงดูแลได้ต่อเนื่องและลดโอกาสเปิดข้อมูลเกินจำเป็น

อ่านต่อเรื่อง Audit Log ในระบบบริษัท เพื่อวางหลักฐานการเปลี่ยนข้อมูลและการปรับสิทธิ์ให้ตรวจย้อนหลังได้

ต้องการทีมพัฒนาที่เข้าใจทั้งธุรกิจและเทคโนโลยี?

Zairosoft ให้บริการพัฒนาเว็บไซต์ ระบบ Web Application, AI Chatbot, AI Automation และระบบเฉพาะทางสำหรับองค์กร โดยเน้นการออกแบบที่รองรับการเติบโต การทำ SEO และประสิทธิภาพการใช้งานจริง

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

📞 โทร 065-389-6356
💬 LINE zairosoft

คำถามที่พบบ่อยเกี่ยวกับ Role Permission