ระบบที่มีเพียง “ผู้ดูแล” กับ “ผู้ใช้ทั่วไป” อาจเริ่มง่าย แต่เมื่อหลายทีมทำงานร่วมกัน มักเจอว่าคนหนึ่งต้องแก้บางข้อมูลแต่ไม่ควรเห็นทุกอย่าง หรือหัวหน้าต้องอนุมัติได้แต่ไม่ควรเปลี่ยนรายการที่อนุมัติแล้วโดยไม่มีประวัติ
การแบ่งสิทธิ์ควรเริ่มจากหน้าที่และข้อมูล ไม่ใช่ตำแหน่งสูงต่ำเพียงอย่างเดียว เขียนให้ได้ว่าใครทำอะไรกับข้อมูลชุดใด ภายใต้เงื่อนไขไหน แล้วจึงนำไปกำหนดบทบาทในระบบ
แยกการเห็นข้อมูลออกจากการเปลี่ยนข้อมูล
การเปิดอ่าน แก้ไข ลบ อนุมัติ และส่งออกเป็นคนละการกระทำ ผู้ที่ต้องดูงานเพื่อช่วยติดตามไม่จำเป็นต้องมีสิทธิ์แก้ทั้งหมด และผู้ที่แก้รายการได้อาจไม่ใช่ผู้มีหน้าที่ยืนยันรายการนั้น
กำหนดขอบเขตข้อมูลด้วย เช่น เฉพาะงานของตัวเอง งานที่ได้รับมอบหมาย งานในสาขา หรือทุกงานที่รับผิดชอบ ชื่อบทบาทว่า “ฝ่ายขาย” ยังไม่บอกว่าควรเปิดรายการของทีมอื่นได้หรือไม่
| บทบาทตัวอย่าง | งานที่ต้องทำ | ขอบเขตที่ต้องตกลง |
|---|---|---|
| ผู้แจ้งงาน | สร้างคำขอและดูผล | คำขอของตนหรือที่ได้รับสิทธิ์ |
| ผู้ปฏิบัติงาน | อัปเดตงานที่รับผิดชอบ | งานที่มอบหมายและข้อมูลประกอบที่จำเป็น |
| หัวหน้าทีม | จัดคนและตรวจผล | งานในทีมและเงื่อนไขการยืนยัน |
| ผู้ตรวจข้อมูล | เปิดดูและให้ข้อสังเกต | ชุดข้อมูลที่ได้รับมอบหมาย โดยไม่แก้ต้นฉบับ |
| ผู้ดูแลระบบ | จัดการบัญชีและการตั้งค่า | แยกจากสิทธิ์อนุมัติธุรกรรมตามความจำเป็น |
ตารางนี้เป็นตัวอย่างการคุย ไม่ใช่ชุดสิทธิ์ที่เหมาะกับทุกธุรกิจ ให้เจ้าของกระบวนการยืนยันว่าข้อมูลใดจำเป็นและเหตุใด ก่อนขยายสิทธิ์เพื่อแก้ปัญหาเฉพาะหน้า
เงื่อนไขของงานอาจสำคัญกว่าชื่อบทบาท
คนเดียวกันอาจแก้ร่างได้แต่แก้รายการที่ยืนยันแล้วไม่ได้ หรือดูโครงการที่ได้รับมอบหมายได้แต่ดูโครงการอื่นไม่ได้ ระบบจึงต้องพิจารณาทั้งผู้ใช้ รายการ และสถานะที่เกี่ยวข้อง
แนวทาง Authorization ของ OWASP เน้นการให้สิทธิ์เท่าที่จำเป็นและตรวจการเข้าถึงอย่างสม่ำเสมอ การซ่อนปุ่มในหน้าจออย่างเดียวไม่ควรเป็นตัวตัดสินว่าคำขอได้รับอนุญาตหรือไม่
สำหรับผู้ใช้ทั่วไป หน้าจอควรอธิบายสถานะและทางขอความช่วยเหลือเมื่อทำบางอย่างไม่ได้ เช่น รายการนี้ปิดแล้วหรือต้องให้ผู้รับผิดชอบดำเนินการ โดยไม่เปิดเผยข้อมูลที่ผู้ใช้ไม่มีสิทธิ์เห็น
หากต้องยกเว้นสิทธิ์ชั่วคราว ให้ระบุเหตุผล ผู้อนุมัติ และเวลาทบทวน ไม่ปล่อยให้การช่วยงานหนึ่งครั้งกลายเป็นสิทธิ์ถาวรที่ไม่มีใครจำได้ว่ามาจากไหน
การย้ายทีมและส่งต่องานต้องเปลี่ยนสิทธิ์ตาม
เมื่อคนเปลี่ยนหน้าที่ ต้องทบทวนทั้งสิทธิ์ใหม่และสิทธิ์เดิมที่ไม่จำเป็น ไม่เพียงเพิ่มกลุ่มใหม่ทับไปเรื่อย ๆ งานค้างของเจ้าของเดิมควรถูกส่งต่อให้คนที่รับผิดชอบจริงตามกระบวนการ
แยกบัญชีบุคคลออกจากบัญชีที่ระบบใช้เชื่อมต่อ เพราะมีวิธีดูแลและผลกระทบต่างกัน บันทึกว่าใครรับผิดชอบบัญชีเชื่อมต่อและงานใดจะหยุดหากเปลี่ยนสิทธิ์ ไม่แก้ด้วยการให้ทุกบัญชีเป็นผู้ดูแลทั้งหมด
กรณีผู้ดูแลหลักไม่อยู่ ควรมีผู้รับผิดชอบสำรองและวิธีขอสิทธิ์ที่ตรวจสอบได้ แผนนี้ต้องรักษาขอบเขตที่จำเป็น ไม่อาศัยการส่งรหัสผ่านร่วมกันไปในกลุ่มแชท
ให้คนรับผิดชอบกระบวนการทบทวนรายชื่อและขอบเขตเป็นระยะตามความเหมาะสม โดยดูว่าผู้ใช้ยังมีงานที่ต้องใช้สิทธิ์นั้นจริงหรือไม่
ตรวจรับด้วยทั้งสิ่งที่อนุญาตและสิ่งที่ต้องปฏิเสธ
ทบทวนสิทธิ์เมื่อฟังก์ชันใหม่เปลี่ยนขอบเขตของการกระทำ เช่น การส่งออกข้อมูลเป็นชุดอาจให้การเข้าถึงมากกว่าการเปิดดูงานที่มอบหมายหนึ่งรายการ แม้จะอยู่ในเมนูเดียวกัน
เตรียมบัญชีทดสอบตามบทบาทและรายการที่ต่างขอบเขต ให้ผู้พัฒนาแสดงว่าคนที่ควรทำงานได้ทำได้ครบ และคนที่ไม่เกี่ยวข้องไม่ได้ข้อมูลหรือเปลี่ยนรายการนั้นผ่านทางอื่น
ครอบคลุมการเปิดลิงก์ตรง ดาวน์โหลดไฟล์ ส่งออก และเปลี่ยนสถานะ ไม่ตรวจเฉพาะเมนูที่มองเห็น หากสิทธิ์เปลี่ยนระหว่างใช้งาน ต้องตรวจว่าขอบเขตใหม่ถูกใช้ตามการออกแบบของระบบ
เก็บหลักฐานการกระทำสำคัญให้ตรวจได้ว่าใครทำอะไรกับรายการใดเมื่อไร โดยเลือกข้อมูลที่จำเป็น ไม่เก็บเนื้อหาสำคัญทั้งหมดในบันทึกเพียงเพราะทำได้
นำกติกาเหล่านี้ใส่ในขอบเขตเว็บแอปรุ่นแรก ตั้งแต่ต้น และหากมีผู้ใช้ภายนอก อ่านการวาง Customer Portal เพื่อแยกสิทธิ์ของลูกค้าออกจากงานภายในให้ครบ
ระบบมีแค่ผู้ดูแลกับผู้ใช้ทั่วไป จนต้องให้สิทธิ์เกินงาน?
Talvyn Labs ช่วยแปลงหน้าที่ของทีมเป็นขอบเขตข้อมูลและการกระทำที่ชัดเจน พร้อมทดสอบทั้งงานที่ควรทำได้และสิ่งที่ต้องถูกปฏิเสธ
วางสิทธิ์ระบบให้ตรงหน้าที่ทีม