สิทธิ์ผู้ใช้ระบบหลังบ้านควรวางอย่างไร? ทำ Permission Matrix ก่อนพัฒนา Web App

คำตอบสั้น ๆ: การวาง สิทธิ์ผู้ใช้ระบบหลังบ้าน ไม่ควรเริ่มจากคำว่า “Admin เห็นทุกอย่าง ส่วน Staff เห็นบางอย่าง” แล้วปล่อยให้ทีมพัฒนาตีความต่อเอง ควรแปลงความต้องการให้เป็น Permission Matrix ที่ตอบให้ครบอย่างน้อย 4 เรื่องคือ Role ไหน → ทำ Action อะไร → กับข้อมูล Scope ไหน → ภายใต้เงื่อนไขอะไร เช่น Sales แก้ไขได้เฉพาะ Lead ของตัวเอง, Supervisor อนุมัติได้เฉพาะทีมตัวเอง และ System Admin จัดการบัญชีผู้ใช้ได้แต่ไม่จำเป็นต้องแก้ข้อมูลการเงินทุกประเภท

เหตุผลที่ต้องแยกละเอียดเช่นนี้ เพราะ “เข้าใช้งานได้” กับ “มีสิทธิ์ทำสิ่งนั้น” เป็นคนละเรื่องกัน การยืนยันตัวตนหรือ Authentication บอกว่าใครกำลังใช้ระบบ ส่วน Authorization ตัดสินว่าคนนั้นได้รับอนุญาตให้ทำอะไรกับทรัพยากรใด แนวทางของ OWASP Authorization Cheat Sheet แนะนำให้ใช้หลัก Least Privilege, Deny by Default และตรวจสิทธิ์ในทุก Request ที่เกี่ยวข้อง แปลเป็นภาษาธุรกิจง่าย ๆ คือ ให้สิทธิ์เท่าที่งานจำเป็น และอย่าถือว่าผู้ใช้ทำได้เพียงเพราะหน้าจอมีปุ่มให้กด

Permission Matrix คืออะไร และช่วยตอนทำระบบหลังบ้านอย่างไร

Permission Matrix คือตารางที่ทำให้กติกาการเข้าถึงกลายเป็นสิ่งที่ทุกฝ่ายอ่านตรงกันได้ แทนที่จะเขียน Requirement แบบกว้างว่า “มี Admin และ Staff” ตารางจะบอกชัดว่าแต่ละ Role สามารถ View, Create, Edit, Approve, Export, Delete หรือ Manage Users ได้หรือไม่ รวมถึงขอบเขตข้อมูลที่กระทำได้ เช่น เฉพาะข้อมูลของตัวเอง เฉพาะทีม หรือทุกข้อมูลในระบบ

แนวคิดนี้สอดคล้องกับ Role-Based Access Control หรือ RBAC ซึ่ง NIST อธิบายว่าเป็นการกำหนดการกระทำที่อนุญาตตาม Role แทนการผูกสิทธิ์กับตัวบุคคลทีละราย จุดสำคัญคือ Role ควรสะท้อนหน้าที่งานจริง เช่น Sales, Approver, Finance หรือ System Administrator ไม่ใช่ตั้งชื่อเพื่อให้ดูเป็นลำดับชั้นแล้วค่อยเดาว่าแต่ละระดับทำอะไรได้บ้าง

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

ทำไมแค่แบ่ง Admin กับ Staff จึงมักไม่พอ

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

อีกจุดที่ทำให้สิทธิ์ซับซ้อนขึ้นคือ Data Scope หรือขอบเขตข้อมูล สมมติ Sales สองคนใช้เมนูเดียวกันและมี Action เหมือนกัน แต่คนแรกควรเห็นเฉพาะลูกค้าที่ตัวเองรับผิดชอบ ขณะที่ Sales Manager เห็นลูกค้าของทั้งทีม ความต่างไม่ได้อยู่ที่ “เมนูไหนเข้าได้” แต่อยู่ที่ “เมื่อเข้าเมนูแล้วเห็นข้อมูลชุดไหน” ถ้า Requirement ระบุเพียงเมนู ระบบอาจเปิดข้อมูลกว้างกว่าที่ธุรกิจตั้งใจ

ดังนั้นก่อนทำ UI ควรแยกสิทธิ์เป็นอย่างน้อย 3 ชั้น: เมนู/หน้าที่เข้าถึงได้, Action ที่ทำได้ และข้อมูลที่ Action นั้นครอบคลุม จากนั้นค่อยเพิ่มเงื่อนไขเฉพาะ เช่น ทำได้เฉพาะสถานะ Draft, ต้องได้รับอนุมัติจากหัวหน้า หรือห้ามแก้หลังปิดงวด

Framework 4 ขั้นตอนก่อนส่ง Requirement ให้ทีมพัฒนา

1. เริ่มจาก Action ที่มีผลจริง ไม่ใช่เริ่มจากชื่อ Role

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

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

2. สร้าง Role ตามหน้าที่ ไม่ใช่ตามชื่อบุคคล

แทนที่จะเขียนว่า “คุณเอแก้ได้ คุณบีอนุมัติได้ คุณซีเห็นทุกอย่าง” ให้ถามว่าคนเหล่านี้กำลังทำหน้าที่อะไร แล้วสร้าง Role ที่นำกลับมาใช้กับคนอื่นได้ เช่น Requester, Sales, Supervisor, Approver, Finance, Content Editor หรือ System Admin วิธีนี้ทำให้เมื่อมีพนักงานใหม่ ไม่ต้องเริ่มกำหนดสิทธิ์จากศูนย์ทุกครั้ง

Role ไม่จำเป็นต้องตรงกับชื่อตำแหน่ง HR แบบคำต่อคำ หาก Workflow ต้องการหน้าที่ข้ามแผนก ตัวอย่างเช่น “Approver” อาจเป็นผู้จัดการคนละคนตามวงเงินหรือประเภทงาน การออกแบบที่ดีจึงเริ่มจากความรับผิดชอบในระบบ แล้วค่อยผูกกับผู้ใช้หรือกลุ่มผู้ใช้จริง

3. ระบุ Data Scope: Own, Team, All หรือ Scope เฉพาะธุรกิจ

สิทธิ์ View และ Edit ควรมีขอบเขตข้อมูลเสมอเมื่อธุรกิจไม่ได้ต้องการให้ทุกคนเห็นทุกอย่าง สามารถเริ่มจากภาษาง่าย ๆ เช่น Own = ข้อมูลที่ตัวเองเป็นเจ้าของหรือรับผิดชอบ, Team = ข้อมูลของทีม และ All = ทั้งองค์กร แล้วค่อยเปลี่ยนเป็น Scope ที่ตรงกับธุรกิจ เช่น สาขา, เขตขาย, แบรนด์, ลูกค้ากลุ่มหนึ่ง หรือโครงการที่ได้รับมอบหมาย

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

4. ใส่ Condition และ Exception ที่สำคัญ

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

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

ตัวอย่าง Permission Matrix สำหรับใช้เริ่มคุยกับทีม

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

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

ใช้ Least Privilege และ Deny by Default เป็นกติกาตั้งต้น

OWASP แนะนำหลัก Least Privilege คือให้ผู้ใช้มีสิทธิ์เท่าที่จำเป็นต่อการทำงาน และ Deny by Default คือสิ่งที่ไม่ได้อนุญาตไว้อย่างชัดเจนควรถูกปฏิเสธก่อน หลักสองข้อนี้มีประโยชน์มากตอน Requirement ยังไม่สมบูรณ์ เพราะช่วยเปลี่ยนคำถามจาก “จะห้ามอะไรบ้าง” เป็น “งานของ Role นี้ต้องทำอะไรจริง ๆ บ้าง”

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

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

ซ่อนปุ่มไม่เท่ากับบังคับสิทธิ์

หน้าจอที่ดีควรซ่อนหรือ Disable Action ที่ผู้ใช้ทำไม่ได้ เพื่อไม่ให้สับสน แต่การควบคุม Authorization ต้องเกิดในชั้นที่ระบบตรวจ Request จริงด้วย ตามแนวทางของ OWASP Developer Guide เรื่อง Access Controls การควบคุมสิทธิ์ควรถูกออกแบบตั้งแต่ต้น ใช้แนวทางปฏิเสธเป็นค่าเริ่มต้น ตรวจสิทธิ์ และมีการทดสอบกติกาการเข้าถึง

ตัวอย่างง่าย ๆ คือ Staff ไม่มีปุ่ม “ลบลูกค้า” บนหน้าจอ แต่ถ้า Endpoint สำหรับลบยังยอมรับ Request จากบัญชี Staff ได้ การซ่อนปุ่มไม่ได้ป้องกันการกระทำนั้น ดังนั้น Acceptance Criteria ของงานสิทธิ์ควรเขียนว่า “Staff เรียก Action ลบไม่ได้” ไม่ใช่เพียง “Staff ไม่เห็นปุ่มลบ”

หลักเดียวกันใช้กับ API, Export, รายงาน,ไฟล์แนบ และ URL รายละเอียด ผู้ใช้ที่ไม่ได้รับสิทธิ์ไม่ควรเข้าถึงข้อมูลได้เพียงเพราะเดา URL หรือรู้รหัสรายการ การวาง Permission Matrix จึงควรส่งต่อไปถึงกติกาฝั่ง Backend และ Test Case ไม่ใช่จบที่ Mockup หน้าจอ

Checklist ก่อนเริ่มพัฒนา Permission ของ Web App

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

• Role: มี Role อะไรบ้าง และแต่ละ Role สะท้อนหน้าที่จริงอะไร?
• View: แต่ละ Role เห็นข้อมูลของตัวเอง ทีม สาขา หรือทั้งองค์กร?
• Create: ใครสร้างรายการได้ และสร้างแทนคนอื่นได้หรือไม่?
• Edit: แก้ข้อมูลได้ถึงสถานะไหน และแก้ข้อมูลส่วนใดไม่ได้?
• Approve: ใครอนุมัติได้ ต้องเป็นคนละคนกับผู้สร้างหรือไม่ และมี Scope อะไร?
• Export: ใครดาวน์โหลดข้อมูลออกจากระบบได้ และ Export ได้ระดับใด?
• Delete / Cancel: ต้องลบจริงหรือควรเปลี่ยนสถานะเพื่อเก็บประวัติ?
• Manage Users: ใครสร้าง ปิดบัญชี Reset สิทธิ์ หรือเปลี่ยน Role ได้?
• Condition: มีเงื่อนไขตามสถานะ วงเงิน ทีม สาขา หรือผู้รับผิดชอบหรือไม่?
• Audit: Action สำคัญใดควรเก็บว่าใครทำ เมื่อไร และเปลี่ยนจากอะไรเป็นอะไร?
• Test: มี Test Case สำหรับทั้งสิ่งที่ “ต้องทำได้” และ “ต้องทำไม่ได้” หรือยัง?
• Review: เมื่อคนย้ายทีม เปลี่ยนหน้าที่ หรือลาออก ระบบจะปรับหรือถอนสิทธิ์อย่างไร?

Checklist นี้ช่วยเปลี่ยนการประชุม Requirement จากการคุยชื่อเมนูเป็นการคุยกติกาของงานจริง และช่วยลดกรณีที่นักพัฒนาต้องถามทีละหน้าว่า “ปุ่มนี้ Staff กดได้ไหม” หลังเริ่มพัฒนาไปแล้ว

ตัวอย่างการใช้ Matrix กับ Workflow ธุรกิจ 3 แบบ

งานขาย: Sales, Sales Manager และ Admin

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

การตอบคำถามแบบนี้ก่อนพัฒนาช่วยให้ระบบไม่ใช้ Rule ง่ายเกินไป เช่น “Role สูงกว่าเห็นทุกอย่าง” ทั้งที่ความจริงบาง Action ต้องแยกตามหน้าที่และความจำเป็น

งานจัดซื้อ: Requester, Approver และ Finance

Requester อาจสร้างคำขอและแก้ได้ก่อนส่งอนุมัติ Approver ตรวจและอนุมัติได้เฉพาะคำขอที่อยู่ใน Scope ของตัวเอง ส่วน Finance อาจเห็นรายการที่อนุมัติแล้วเพื่อดำเนินการต่อ แต่ไม่ควรแก้รายละเอียดต้นทางบางช่องโดยไม่มีเหตุผล หาก Workflow มีหลายระดับอนุมัติ Condition อาจขึ้นกับประเภทค่าใช้จ่าย หน่วยงาน หรือกติกาที่ธุรกิจกำหนด

กรณีนี้ Permission Matrix จะทำให้เห็นชัดว่า “Approve” เป็น Action แยกจาก “Edit” และ “View” และ Role ที่อนุมัติไม่จำเป็นต้องมีสิทธิ์ทุกอย่างในรายการ

งานบริการ: Operator, Supervisor และ System Admin

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

Permission Matrix ช่วยคุย Scope พัฒนา Web App ได้อย่างไร

การทำ Permission Matrix ไม่ได้มีประโยชน์เฉพาะเรื่อง Security แต่ช่วยให้ Scope ของ การพัฒนา Web App และระบบหลังบ้านสำหรับธุรกิจ ชัดขึ้นด้วย เพราะสิทธิ์ส่งผลต่อหลายส่วนพร้อมกัน ตั้งแต่โครงสร้างผู้ใช้ ความสัมพันธ์กับทีมและสาขา Query ที่ใช้กรองข้อมูล API ที่ต้องตรวจสิทธิ์ ไปจนถึง Test Case และหน้าจอสำหรับจัดการ Role

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

หากกำลังสำรวจรูปแบบระบบที่เหมาะกับธุรกิจ สามารถดู ตัวอย่าง Web App และระบบหลังบ้าน เพื่อเทียบว่าระบบประเภทต่าง ๆ ต้องใช้ Role, Workflow และข้อมูลแบบใด แต่ไม่ควรคัดลอก Permission จากระบบอื่นมาใช้ตรง ๆ เพราะขอบเขตข้อมูลและความรับผิดชอบของแต่ละธุรกิจต่างกัน

Permission Matrix ควรเชื่อมกับ Requirement อื่นอย่างไร

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

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

ข้อผิดพลาดที่ควรหลีกเลี่ยงตอนออกแบบสิทธิ์

• ใช้ชื่อ Role เป็น Requirement จบในตัว: “Admin ทำได้ทั้งหมด” มักกว้างเกินไปและทำให้ความรับผิดชอบด้านเทคนิคกับธุรกิจปนกัน
• กำหนดสิทธิ์เฉพาะระดับเมนู: เข้าเมนูเดียวกันได้ไม่ได้หมายความว่าควรเห็นหรือแก้ข้อมูลชุดเดียวกัน
• ตั้งสิทธิ์รายคนจำนวนมาก: เมื่อคนย้ายงานหรือทีมโต จะตามไม่ทันว่าใครได้ข้อยกเว้นอะไรไว้
• เปิดสิทธิ์กว้างก่อนแล้วค่อยลด: สิทธิ์ที่เปิดเพื่อความสะดวกมักกลายเป็นค่าเริ่มต้นถาวร หากไม่มีเจ้าของงานกลับมาทบทวน
• ซ่อนปุ่มแต่ไม่ตรวจ Backend: UX กับ Authorization เป็นคนละชั้น ต้องบังคับสิทธิ์เมื่อ Request ถึงระบบด้วย
• ไม่มี Test ฝั่งปฏิเสธ: อย่าทดสอบแค่ว่า Approver อนุมัติได้ ควรทดสอบด้วยว่า Staff ที่ไม่ใช่ Approver อนุมัติไม่ได้
• ไม่กำหนดเจ้าของการเปลี่ยนสิทธิ์: เมื่อ Role เปลี่ยน ต้องรู้ว่าใครมีอำนาจอนุมัติและดำเนินการเปลี่ยนสิทธิ์

สรุป: เริ่มจาก “ใครทำอะไรกับข้อมูลไหน” ก่อนเริ่มเขียน Permission Code

สิทธิ์ผู้ใช้ระบบหลังบ้านที่ชัดไม่ได้เริ่มจากจำนวน Role เยอะ ๆ แต่เริ่มจากการตอบคำถามให้ตรงกับงานจริงว่า ใครทำ Action อะไร กับข้อมูล Scope ไหน ภายใต้เงื่อนไขอะไร เมื่อคำตอบเหล่านี้ถูกวางลง Permission Matrix ทีมธุรกิจ นักออกแบบ และนักพัฒนาจะมีภาษากลางเดียวกัน และสามารถเขียน Acceptance Criteria ที่ตรวจได้จริง

สำหรับระบบขนาดเล็ก Matrix อาจมีเพียงไม่กี่ Role และไม่กี่ Action ก็เพียงพอ จุดสำคัญคืออย่าปล่อยให้คำว่า Admin, Staff หรือ Manager ทำหน้าที่แทน Requirement ทั้งหมด จากนั้นค่อยใช้หลัก Least Privilege และ Deny by Default เป็นฐาน ตรวจ Authorization ที่ฝั่งระบบ และทดสอบทั้งกรณีที่ควรอนุญาตกับกรณีที่ควรปฏิเสธ

เมื่อ Permission ชัดแล้ว การคุยเรื่องหน้าจอ Workflow, API, Audit Log และขอบเขตการพัฒนา Web App จะง่ายขึ้น เพราะทุกฝ่ายรู้ว่าระบบไม่ได้มีหน้าที่เพียง “เก็บข้อมูล” แต่ต้องรักษากติกาว่าใครสามารถทำอะไรกับข้อมูลนั้นได้ตลอดอายุของ Workflow