เข้าสู่ระบบแล้ว ทำไมยังต้องตรวจสิทธิ์ทีละรายการ

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

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

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

รู้ว่าเป็นใครกับอนุญาตให้ทำอะไรเป็นคนละขั้น

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

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

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

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

รหัสรายการเป็นตัวระบุ ไม่ใช่หลักฐานสิทธิ์

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

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

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

ซ่อนปุ่มช่วยคนใช้ แต่บริการต้องตัดสินเอง

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

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

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

สิทธิ์ต้องตามไปกับไฟล์และงานเบื้องหลังด้วย

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

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

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

การเสริมด้วยฐานข้อมูลต้องรู้บทบาทที่เชื่อมต่อจริง

PostgreSQL มี row-level security สำหรับจำกัดแถวตาม policy ซึ่งอาจใช้เป็นส่วนหนึ่งของการแยกข้อมูลได้ แต่ต้องออกแบบร่วมกับตัวตนที่ฐานข้อมูลเห็น ไม่ถือว่าชื่อผู้ใช้ในแอปจะกลายเป็น database role เฉพาะคนนั้นเองโดยอัตโนมัติ

เอกสารยังระบุข้อยกเว้นของ superuser, role ที่มี BYPASSRLS และเจ้าของตารางตามเงื่อนไขที่กำหนดไว้ หากแอปเชื่อมต่อด้วยบทบาทที่ข้ามกติกา การเปิด policy ก็อาจไม่ได้ป้องกันเส้นทางอย่างที่คิด จึงต้องตรวจบทบาทและขั้นส่งบริบทตามสถาปัตยกรรมจริง

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

ตรวจจากคู่ที่ควรผ่านและคู่ที่ต้องไม่ผ่าน

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

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

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