เจาะลึกระบบควบคุมการเข้าถึงข้อมูล: ทำไมควรไว้ใจฐานข้อมูลมากกว่า UI
นักพัฒนาชี้การซ่อนปุ่มบนหน้าจอ UI ไม่ใช่ระบบความปลอดภัยที่แท้จริง พร้อมแนะใช้ Postgres RLS เพื่อความปลอดภัยของข้อมูลระดับฐานข้อมูล
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- การซ่อนปุ่มใน UI ไม่ถือเป็นระบบควบคุมการเข้าถึงข้อมูลที่แท้จริง
- การใช้ Postgres Row-Level Security (RLS) ช่วยบังคับสิทธิ์ที่ระดับฐานข้อมูล
- ระบบ Audit Trail แบบ Append-Only ป้องกันการแก้ไขหรือลบประวัติย้อนหลัง
- ความปลอดภัยของข้อมูลควรเป็นคุณสมบัติของฐานข้อมูล ไม่ใช่ภาระของโค้ด
ปัญหาข้อผิดพลาดด้านการควบคุมการเข้าถึงข้อมูลที่พบบ่อยที่สุดไม่ใช่เรื่องซับซ้อน แต่มักเป็นการที่แอปพลิเคชันซ่อนปุ่มบางปุ่มแล้วนักพัฒนาคิดว่างานเสร็จสิ้น ทั้งที่ข้อมูลยังคงมีความเสี่ยงหากมีคำขอที่ถูกสร้างขึ้นมาเป็นพิเศษ หากระบบยืนยันตัวตนและการอนุญาตสิทธิ์อยู่แค่ที่หน้าจอผู้ใช้งาน (UI) เท่ากับว่าระบบความปลอดภัยนั้นไม่มีอยู่จริง
แนวทางแก้ไขคือการผลักดันระบบควบคุมการเข้าถึงลงไปในจุดที่ข้อมูลอยู่จริง นั่นคือระดับฐานข้อมูล โดยใช้ฟีเจอร์ Postgres Row-Level Security (RLS) ซึ่งได้ถูกนำไปปรับใช้จริงกับแพลตฟอร์มการศึกษา Cendekia, พอร์ทัลปฏิบัติการของผู้ให้บริการอินเทอร์เน็ต (ISP) และแอปพลิเคชันจัดการแรงงานในอุตสาหกรรมเหมืองแร่ ซึ่งแต่ละระบบมีบทบาทหน้าที่ของผู้ใช้งานที่หลากหลายและต้องมองเห็นเฉพาะข้อมูลส่วนของตนเองเท่านั้น
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
เมื่อเปิดใช้งาน RLS ตารางข้อมูลจะไม่ส่งคืนแถวข้อมูลที่ผู้ใช้งานไม่มีสิทธิ์มองเห็น แม้ว่าตัวคำสั่งค้นหาจะร้องขอก็ตาม นโยบายดังกล่าวจะถูกผูกติดไว้กับตัวตารางโดยตรง ทำให้ไม่ว่าหน้าจอ, API endpoint หรือคำสั่ง query ใดจะเป็นผู้เรียกใช้งาน กฎระเบียบนี้ก็จะถูกบังคับใช้เสมอ นักศึกษาจะเห็นเฉพาะเกรดของตนเอง อาจารย์จะเห็นเฉพาะชั้นเรียนที่รับผิดชอบ และผู้ดูแลระบบจะเห็นข้อมูลทะเบียน โดยมี Postgres เป็นผู้บังคับใช้กฎเหล่านี้ แทนที่จะต้องมาคอยใส่คำสั่ง WHERE ในทุกฟังก์ชัน handler
การใช้ Postgres Row-Level Security (RLS) ถือเป็นแนวทางปฏิบัติที่เรียกว่า Defense in Depth หรือการป้องกันหลายชั้น ช่วยลดความเสี่ยงจาก Human Error ที่นักพัฒนาอาจลืมใส่เงื่อนไขกรองข้อมูลในบาง API endpoint ใหม่ๆ ที่ถูกสร้างขึ้นในอนาคต การกำหนดนโยบายไว้ที่ระดับฐานข้อมูลจึงช่วยอุดรอยรั่วได้อย่างเบ็ดเสร็จ
จุดเปลี่ยนสำคัญคือการทำให้การอนุญาตสิทธิ์กลายเป็นคุณสมบัติของข้อมูล ไม่ใช่พฤติกรรมที่ต้องคอยเขียนโค้ดคุม ทำให้ endpoint ใหม่ๆ สามารถรับสิทธิ์เหล่านี้ไปได้โดยอัตโนมัติ และการลืมใส่ตัวกรองข้อมูลก็จะไม่ทำให้ข้อมูลรั่วไหลอีกต่อไป เนื่องจากฐานข้อมูลจะเป็นผู้ปฏิเสธคำขอนั้นเอง
นอกจากการควบคุมการอ่านและเขียนแล้ว อีกครึ่งหนึ่งที่สำคัญคือการป้องกันไม่ให้ข้อมูลที่ถูกบันทึกไปแล้วถูกแก้ไขอย่างเงียบๆ ในภายหลัง สำหรับระบบบันทึกเวลาเข้างานและการอนุมัติในแอปพลิเคชันเหมืองแร่ ระบบ Audit Trail ถูกออกแบบให้เป็นแบบ Append-Only ที่ระดับฐานข้อมูล โดยใช้ Postgres triggers คอยปฏิเสธคำสั่ง UPDATE และ DELETE บนตารางเหล่านั้น แอปพลิเคชันสามารถเพิ่มข้อมูลใหม่ได้ แต่ไม่สามารถแก้ไขประวัติย้อนหลังได้ เมื่อระบบเงินเดือนหรือการตรวจสอบข้อพิพาทต้องพึ่งพาบันทึกเหล่านี้ การรับประกันจากฐานข้อมูลจึงมีความน่าเชื่อถือกว่าคำกล่าวอ้างที่ว่าไม่มีใครเข้ามาแก้ไขข้อมูล
การซ่อนปุ่มควบคุมเป็นเพียงเรื่องของประสบการณ์ผู้ใช้งาน (UX) แต่การบังคับใช้สิทธิ์ในฐานข้อมูลคือความปลอดภัยอย่างแท้จริง การทำเช่นนี้พร้อมกับการจัดทำดัชนี (index) อย่างเหมาะสม และมีบันทึกที่แอปพลิเคชันไม่ได้รับอนุญาตให้แก้ไข จะช่วยให้มั่นใจได้ว่าระบบความปลอดภัยจะยังคงทำงานได้อย่างสมบูรณ์ไม่ว่าส่วนหน้าบ้านจะทำงานอย่างไรก็ตาม
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น