การควบคุมการเข้าถึง (access control) ทำงานอย่างไร (RBAC, least privilege)?

Question

Accepted Answer

**Access control** ควบคุมว่าผู้ใช้ที่ยืนยันตัวตนแล้วทำอะไรได้บ้าง ผ่านโมเดลอย่าง **RBAC** (Role-Based Access Control) และหลักการอย่าง **least privilege** การควบคุมการเข้าถึงที่เหมาะสมเป็นเรื่องสำคัญยิ่ง เนื่องจาก broken access control เป็นช่องโหว่อันดับ 1 ของ OWASP

## โมเดลการควบคุมการเข้าถึง

```text
RBAC (Role-Based Access Control) → assign users to ROLES; roles have PERMISSIONS:
  → user → role(s) (admin, editor, viewer) → permissions → access decisions
  → manageable, common; change a role's permissions, all its users update
ABAC (Attribute-Based) → decisions based on ATTRIBUTES (user, resource, context) → flexible,
  fine-grained (e.g. "editors can edit docs in their department during business hours")
ACLs → per-resource lists of who can do what
```

## หลักการของ least privilege

```text
LEAST PRIVILEGE → grant the MINIMUM access needed to do the job, nothing more:
  → limits the BLAST RADIUS if an account/component is compromised
  → applies to users, services, processes, database accounts, API keys, etc.
→ a foundational security principle (default to LESS access; grant more only as needed)
```

## การนำการควบคุมการเข้าถึงมาใช้อย่างปลอดภัย

```text
⚠️ BROKEN ACCESS CONTROL is OWASP #1 — common and serious:
✓ ENFORCE authorization on the SERVER for EVERY protected action/resource (never trust
  the client; don't rely on hiding UI elements)
✓ Check the user is authorized for the SPECIFIC resource (prevent IDOR — accessing
  others' data by changing an ID)
✓ DENY by default; verify on each request; centralize authorization logic
✓ Test access control (a common gap — easy to miss authorization checks)
```

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

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

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

การเข้าใจ **โมเดลต่าง ๆ** **RBAC** (การกำหนดผู้ใช้ให้ role ที่มี permission ซึ่งจัดการได้และพบบ่อย) **ABAC** (การตัดสินใจตาม attribute สำหรับการควบคุมที่ยืดหยุ่นและละเอียด) และ ACL (รายการ permission ต่อทรัพยากร) ให้กรอบสำหรับการจัดโครงสร้างสิทธิ์ โดย RBAC เป็นแบบที่พบบ่อยที่สุดที่ควรเข้าใจ

การเข้าใจ **หลักการของ least privilege** การให้ **สิทธิ์ขั้นต่ำที่จำเป็น** ซึ่ง **จำกัด blast radius หากบัญชีหรือคอมโพเนนต์ถูกเจาะ** เป็นหลักการความปลอดภัยพื้นฐานที่นำไปใช้ได้กว้าง (ผู้ใช้ บริการ บัญชีฐานข้อมูล API key) และเป็นหนึ่งในแนวคิดความปลอดภัยที่สำคัญที่สุด

ที่สำคัญ การเข้าใจวิธี **นำการควบคุมการเข้าถึงมาใช้อย่างปลอดภัย** จัดการกับช่องโหว่อันดับ 1: **การบังคับใช้ authorization บนเซิร์ฟเวอร์สำหรับทุกการกระทำที่ได้รับการป้องกัน** (ไม่เชื่อ client หรือพึ่งพาการซ่อน UI ซึ่งเป็นข้อผิดพลาดที่พบบ่อย) **การตรวจสอบ authorization สำหรับทรัพยากรเฉพาะ** (ป้องกัน IDOR ที่ผู้ใช้เข้าถึงข้อมูลของผู้อื่นโดยเปลี่ยน ID ซึ่งเป็นข้อบกพร่อง broken access control ที่พบบ่อย) **การปฏิเสธโดยปริยาย** การตรวจสอบในทุก request และ **การทดสอบการควบคุมการเข้าถึง** (ช่องว่างที่พบบ่อย เพราะการตรวจสอบ authorization ที่ขาดหายไปมองข้ามได้ง่าย)

เนื่องจากการควบคุมการเข้าถึงกำหนดว่าผู้ใช้ทำอะไรได้บ้างและ broken access control เป็นช่องโหว่อันดับต้น (พบบ่อยและร้ายแรง) และเนื่องจากการเข้าใจโมเดลต่าง ๆ (RBAC) หลักการ least privilege และการนำมาใช้อย่างปลอดภัย (การบังคับใช้ฝั่งเซิร์ฟเวอร์ การตรวจสอบเฉพาะทรัพยากร การปฏิเสธโดยปริยาย) เป็นเรื่องสำคัญยิ่งต่อความปลอดภัย การเข้าใจการควบคุมการเข้าถึงจึงเป็นความรู้ด้านความปลอดภัยที่มีคุณค่าและสำคัญยิ่งในทางปฏิบัติ จัดการกับความเสี่ยงด้านความปลอดภัยอันดับ 1 เป็นพื้นฐานของการควบคุมสิ่งที่ผู้ใช้ทำได้ และจำเป็นสำหรับการหลีกเลี่ยงข้อบกพร่อง broken access control (เช่น IDOR และการตรวจสอบ authorization ที่ขาดหายไป) ซึ่งเป็นหนึ่งในช่องโหว่ที่พบบ่อยและร้ายแรงที่สุด