ป้ายกำกับ: PBAC

Security & Authentication (JWT Bearer Tokens, Role-based & Policy-based Authorization)Security & Authentication (JWT Bearer Tokens, Role-based & Policy-based Authorization)

ในสถาปัตยกรรม Microservices ยุคใหม่ การจัดการตัวตน (Authentication) และการกำหนดสิทธิ์ (Authorization) คือรากฐานของความมั่นคงปลอดภัย ระบบไม่สามารถพึ่งพา Session แบบเดิมได้อีกต่อไป เราจึงต้องใช้กลไกที่รองรับการขยายตัว (Scalability) และทำงานแบบไร้สถานะ (Stateless) ซึ่งหัวใจสำคัญของเรื่องนี้คือการใช้ JWT (JSON Web Token) ร่วมกับการจัดการสิทธิ์ที่ซับซ้อนอย่าง RBAC และ PBAC โดยมี PostgreSQL เป็นฐานข้อมูลหลักในการจัดเก็บและบังคับใช้กฎเกณฑ์ความปลอดภัย

🔑 JWT Bearer Tokens: การยืนยันตัวตนแบบไร้สถานะ (Stateless Authentication)

JWT คือมาตรฐานที่ใช้ในการสร้างโทเคนดิจิทัลที่บรรจุข้อมูลสำคัญของผู้ใช้งาน เช่น User ID, Role, และวันหมดอายุ (Expiration Time) โทเคนนี้จะถูกส่งให้ Client ใช้ในการเรียก API ทุกครั้ง ทำให้ Service ต่างๆ สามารถตรวจสอบตัวตนได้ทันทีโดยไม่ต้องเรียกฐานข้อมูลส่วนกลางตลอดเวลา PostgreSQL จะทำหน้าที่เก็บข้อมูลผู้ใช้และ Role ต่างๆ เพื่อใช้ในการออก (Issuance) และตรวจสอบความถูกต้องของข้อมูลที่ถูกเข้ารหัสไว้ในโทเคน.

🛡️ Authorization: RBAC และ PBAC ใน PostgreSQL

เมื่อผ่านการยืนยันตัวตนแล้ว เราต้องกำหนดสิทธิ์การเข้าถึงทรัพยากร ซึ่งมีสองแนวทางหลัก:

1. Role-based Access Control (RBAC)

RBAC ผูกสิทธิ์ไว้กับบทบาท (Role) เช่น ‘Admin’ หรือ ‘Viewer’ ทำให้การจัดการง่ายและเป็นระเบียบ เราสามารถใช้ PostgreSQL สร้างตารางเพื่อเชื่อมโยงผู้ใช้กับบทบาทและสิทธิ์ที่เกี่ยวข้อง:

SQL

-- สร้างตาราง Roles และ Permissions<br>CREATE TABLE roles (role_id SERIAL PRIMARY KEY, role_name VARCHAR(50) UNIQUE);<br>CREATE TABLE user_roles (user_id INT, role_id INT, PRIMARY KEY (user_id, role_id));<br>-- ตัวอย่างการกำหนดสิทธิ์: ผู้ใช้ ID 1 เป็น Admin<br>INSERT INTO user_roles (user_id, role_id) VALUES (1, 101);

2. Policy-based Access Control (PBAC)

PBAC คือระดับความละเอียดสูงสุด เพราะไม่ได้ผูกสิทธิ์แค่ Role แต่กำหนดนโยบาย (Policy) ที่ซับซ้อนว่า ‘ใคร (Subject) สามารถทำอะไร (Action) กับทรัพยากรใด (Resource) ภายใต้เงื่อนไขใด (Condition)’ ซึ่ง PostgreSQL มีคุณสมบัติที่ทรงพลังในการจัดการเรื่องนี้คือ Row-Level Security (RLS)

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

SQL

-- ตัวอย่างการใช้ RLS เพื่อจำกัดการเข้าถึงข้อมูลตาม Department ID<br>-- สมมติว่าผู้ใช้มี Department ID เป็น 5<br>ALTER TABLE projects ENABLE ROW LEVEL SECURITY;<br>CREATE POLICY dept_policy ON projects FOR SELECT USING (department_id = current_setting('app.user_dept_id')::INT);<br>-- เมื่อผู้ใช้เรียก SELECT ข้อมูล จะเห็นเฉพาะแถวที่ department_id ตรงกับที่ตั้งค่าไว้เท่านั้น

✅ บทสรุป: การผสานพลังของเทคโนโลยี

การใช้ JWT ในการยืนยันตัวตนที่รวดเร็วและไร้สถานะ ร่วมกับการใช้ PostgreSQL ในการบังคับใช้สิทธิ์ผ่าน Policy-based Access Control (โดยเฉพาะ RLS) ทำให้เราได้สถาปัตยกรรมความปลอดภัยที่ทั้งยืดหยุ่น ปลอดภัย และสามารถขยายตัวได้อย่างไม่มีขีดจำกัด นี่คือแนวทางที่ Senior Architect ทุกคนควรนำไปพิจารณาในการออกแบบระบบระดับองค์กร