Web​ ​Application​ ​ควร​วาง​ระบบ​ ​Login​ ​และ​สิทธิ์​ผู้​ใช้​อย่างไร​ตั้งแต่​ต้น

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

วาดตารางบทบาทก่อนเขียนหน้าจอ

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

ภาพที่ 1: หลังยืนยันตัวตน ระบบยังต้องตรวจสิทธิ์ของการกระทำและขอบเขตข้อมูลในฝั่งเซิร์ฟเวอร์

4 ข้อที่ไม่ควรเลื่อน

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

แนวทางนี้สอดคล้องกับ OWASP Authentication และ OWASP Authorization ซึ่งแยกการยืนยันตัวตนออกจากการอนุญาต และแนะนำให้ตรวจสิทธิ์ที่ทุกคำขอ

คำถามก่อนให้ทีมประเมินงาน

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

แยก 3 ชั้นของการเข้าถึง

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

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

ตัวอย่างสมมติ: ตารางสิทธิ์ของระบบคำขอ

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

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

วิธีทดสอบที่ควรเขียนไว้ในข้อกำหนด

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

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

ประเด็นสำหรับรายงานออกแบบระบบ

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

หากกำลังวางระบบตั้งแต่เริ่ม ดู บริการพัฒนา Web Application และ แนวทางกำหนดขอบเขต MVP

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

• OWASP Authorization Cheat Sheet — การตรวจสิทธิ์ทุกคำขอและหลักปฏิเสธไว้ก่อน
• OWASP Session Management Cheat Sheet — แนวทางดูแล Session
• OWASP Authentication Cheat Sheet — แนวทางยืนยันตัวตน