เมื่อระบบหลังบ้านมีผู้ใช้งานมากกว่าหนึ่งบทบาท คำถามสำคัญไม่ใช่เพียงว่าใครเข้าสู่ระบบได้ แต่คือหลังเข้าสู่ระบบแล้วแต่ละคนควรเห็นและเปลี่ยนข้อมูลอะไร Manager ของ ParitLAB ทำหน้าที่ดูแลลูกค้าและ License ภายในพอร์ตที่ Admin มอบหมาย จึงไม่ควรเข้าถึงโปรเจกต์อื่นหรือลูกค้าที่อยู่ในความดูแลของคนอื่น
แบ่งสิทธิ์เป็นสองแกน
เราแยกขอบเขตเป็น “สินค้า” และ “ความเป็นเจ้าของลูกค้า” สินค้ากำหนดว่า Manager จัดการ License ของโปรเจกต์ใดได้ ส่วนความเป็นเจ้าของกำหนดว่ารายชื่อลูกค้าคนใดจะปรากฏใน Portal การมีสิทธิ์สินค้าเพียงอย่างเดียวจึงไม่ทำให้ Manager เปิดข้อมูลลูกค้าทั้งระบบได้ และการเป็นเจ้าของลูกค้าก็ไม่อนุญาตให้สร้าง License ของโปรเจกต์นอกพอร์ต
การซ่อนเมนูไม่ใช่การรักษาความปลอดภัย
ปุ่มและเมนูช่วยให้ผู้ใช้เข้าใจขอบเขต แต่ผู้ใช้ยังสามารถเปลี่ยนค่าใน URL หรือส่ง HTTP request ที่สร้างเองได้ ทุกการสร้างลูกค้า แก้ข้อมูล ให้ License และถอน License จึงต้องตรวจ Manager ID, Customer ownership และ Project assignment ซ้ำที่ฝั่งเซิร์ฟเวอร์ เงื่อนไขถูกใส่ไว้ใน SQL ที่อ่านหรือแก้ข้อมูลโดยตรง เพื่อลดโอกาสที่การลืมตรวจในหน้าจอหนึ่งจะเปิดช่องให้ข้ามสิทธิ์
Session ของ Manager ต้องแยกจาก Admin และลูกค้า
การใช้หน้าตา Portal คล้ายกันไม่ได้หมายความว่าควรใช้ Session เดียวกัน ระบบแยก Session ของ Manager และสร้าง Session ID ใหม่หลัง Login เมื่อ Manager เข้าระบบ จะไม่ถือสิทธิ์ Admin หรือลูกค้าที่อาจค้างอยู่ใน Browser เดียวกัน บัญชีที่ถูกพักหรือเปลี่ยน Session version จะถูกตัดสิทธิ์เมื่อระบบตรวจสถานะรอบถัดไป
Admin ควบคุมสิทธิ์ระดับผลิตภัณฑ์
ในหน้าจัดการ Manager, Admin เลือกสินค้า ลูกค้า และสิทธิ์ทดลองหรือดาวน์โหลดแยกต่อสินค้าได้ การเพิ่มสิทธิ์ใหม่เริ่มจากสถานะปิดเสมอ เพื่อไม่ให้การอัปเดตระบบเปิดไฟล์ให้บัญชีเดิมโดยไม่ตั้งใจ Manager จะเห็นสินค้าในหน้า Portfolio เมื่อมีสิทธิ์ทดลองหรือดาวน์โหลดอย่างน้อยหนึ่งรายการเท่านั้น
สิ่งที่เราทดสอบ
- Manager เห็นลูกค้าของตนเองและไม่พบลูกค้าคนอื่นใน HTML
- โปรเจกต์นอกพอร์ตไม่ปรากฏในตัวเลือก License
- Request ที่ปลอม Project ID ถูกปฏิเสธโดยไม่มี License ใหม่เกิดขึ้น
- Request ที่พยายามแก้ลูกค้าของ Manager อื่นไม่เปลี่ยนข้อมูล
- ผู้ที่ยังไม่ Login ถูกส่งกลับหน้า Manager Login
หลักที่นำไปใช้กับระบบอื่นได้
สิทธิ์ที่ดีควรอธิบายได้ด้วยประโยคสั้น เช่น “Manager คนนี้ดูแลลูกค้ากลุ่มนี้และสินค้าเหล่านี้” จากนั้นทุก Query และทุก Action ต้องพิสูจน์ประโยคนั้นได้ การออกแบบจากข้อมูลที่ผู้ใช้เป็นเจ้าของช่วยให้ระบบขยายจาก Manager หนึ่งคนไปหลายคนได้โดยไม่ต้องสร้างฐานข้อมูลแยก และช่วยให้การตรวจ Audit มีความหมายมากกว่าการบันทึกว่าใครกดปุ่มอะไร