roles และ privileges ใน PostgreSQL ทำงานอย่างไร?

Question

Accepted Answer

PostgreSQL จัดการการควบคุมการเข้าถึงผ่าน **roles** (ซึ่งทำหน้าที่เป็นทั้ง users และ groups) และ **privileges** (สิทธิ์ที่ให้บน object) ระบบนี้ควบคุมว่าใครเชื่อมต่อได้และทำอะไรได้บ้าง ซึ่งเป็นพื้นฐานของความปลอดภัยของฐานข้อมูล

## roles — รวม users และ groups เข้าด้วยกัน

```sql
-- a role can be a USER (can log in) or a GROUP (collection of permissions)
CREATE ROLE app_user WITH LOGIN PASSWORD 'secret';   -- a login role (a "user")
CREATE ROLE readonly;                                 -- a group role (no login)

-- roles can be members of other roles (inherit their privileges)
GRANT readonly TO app_user;          -- app_user inherits readonly's privileges
```

ใน Postgres **role** เป็นแนวคิดที่รวมเป็นหนึ่งเดียว มันสามารถ log in ได้ (ทำหน้าที่เป็น user) และ/หรือบรรจุ role อื่น (ทำหน้าที่เป็น group) โมเดลที่ยืดหยุ่นนี้จัดการได้ทั้ง users และกลุ่มสิทธิ์

## privileges — การให้สิทธิ์บน object

```sql
-- grant specific privileges on objects
GRANT SELECT ON users TO readonly;                    -- read-only on a table
GRANT SELECT, INSERT, UPDATE, DELETE ON orders TO app_user;  -- full data access
GRANT USAGE ON SCHEMA sales TO app_user;              -- access a schema
GRANT ALL PRIVILEGES ON DATABASE mydb TO admin;

REVOKE INSERT ON orders FROM app_user;                -- take away a privilege
```

privileges (`SELECT`, `INSERT`, `UPDATE`, `DELETE`, `USAGE` ฯลฯ) ถูกให้บน object (ตาราง, schemas, ฐานข้อมูล) แก่ roles เพื่อควบคุมว่าแต่ละ role ทำอะไรได้บ้างอย่างแม่นยำ

## หลักการ least privilege

```sql
-- ✅ grant only the permissions each role actually needs
GRANT SELECT ON reports TO analyst;     -- analyst can only READ reports
-- ❌ don't grant ALL PRIVILEGES or superuser broadly — minimize the blast radius
```

**Least privilege** — การให้แต่ละ role เฉพาะสิทธิ์ที่มันต้องการ — เป็นแนวปฏิบัติด้านความปลอดภัยหลักที่จำกัดความเสียหายจาก credentials ที่ถูกบุกรุกหรือจากความผิดพลาด

## default privileges และ ownership

```sql
-- the object's OWNER has full control; new objects need explicit grants
ALTER DEFAULT PRIVILEGES IN SCHEMA sales
  GRANT SELECT ON TABLES TO readonly;   -- auto-grant on FUTURE tables
```

## ทำไมจึงสำคัญ

การเข้าใจ roles และ privileges ของ PostgreSQL สำคัญต่อ **ความปลอดภัยของฐานข้อมูล** การควบคุมว่าใครเข้าถึงฐานข้อมูลได้และทำอะไรได้เป็นพื้นฐานในการปกป้องข้อมูล ดังนั้นความรู้นี้จึงมีคุณค่าสำหรับฐานข้อมูล production ใด ๆ

การเข้าใจแนวคิด **role** (โมเดลรวมของ Postgres ที่ roles ทำหน้าที่เป็นทั้ง users — ที่ log in ได้ — และ groups — ชุดของสิทธิ์ที่ role อื่นสืบทอดได้) เป็นสิ่งจำเป็นสำหรับการจัดการการเข้าถึง เพราะมันเป็นวิธีที่คุณสร้าง user ของฐานข้อมูลและจัดระเบียบสิทธิ์

การรู้วิธี grant และ revoke **privileges** (`SELECT`, `INSERT` ฯลฯ) บน object (ตาราง, schemas, ฐานข้อมูล) แก่ roles เป็นสิ่งจำเป็นสำหรับการควบคุมว่า user หรือแอปพลิเคชันแต่ละตัวทำอะไรได้บ้างอย่างแม่นยำ

สิ่งที่สำคัญอย่างยิ่งคือ **หลักการ least privilege** — การให้แต่ละ role เฉพาะสิทธิ์ที่มันต้องการอย่างแท้จริง (เช่น role analyst แบบ read-only, role แอปพลิเคชันที่มีเฉพาะการเข้าถึงที่จำเป็น) แทนที่จะให้สิทธิ์กว้างหรือ superuser — ซึ่งเป็นแนวปฏิบัติด้านความปลอดภัยหลักที่จำกัดความเสียหายจาก credentials ที่ถูกบุกรุก, บั๊ก หรือความผิดพลาด (การป้องกันที่จริงและสำคัญ)

การเข้าใจ default privileges และ ownership (เจ้าของ object มีการควบคุมเต็มที่; object ในอนาคตอาจต้องการ grant อย่างชัดเจน) ช่วยเติมเต็มการจัดการการเข้าถึงในทางปฏิบัติ

เนื่องจากความปลอดภัยของฐานข้อมูลมีความสำคัญอย่างยิ่ง (ฐานข้อมูลเก็บข้อมูลที่อ่อนไหวและมีค่า) และเนื่องจากการควบคุมการเข้าถึงอย่างเหมาะสมผ่าน roles และการ grant แบบ least-privilege เป็นวิธีปกป้องข้อมูลนั้นและจำกัดความเสี่ยง การเข้าใจ roles และ privileges ของ PostgreSQL — โมเดล role แบบรวม, การ grant/revoke privileges และโดยเฉพาะหลักการ least-privilege — จึงเป็นความรู้ที่เกี่ยวข้องกับความปลอดภัยที่สำคัญสำหรับการดูแลและรักษาความปลอดภัยฐานข้อมูล production ซึ่งเป็นความรับผิดชอบที่เกี่ยวข้องบ่อยและเป็นหัวข้อที่พบบ่อยสำหรับทุกคนที่จัดการการเข้าถึงฐานข้อมูล