IAM role และ policy ทำงานในเชิงลึกอย่างไร?

Question

Accepted Answer

นอกเหนือจาก IAM พื้นฐาน การเข้าใจ **role** (identity ที่ถูก assume) **ประเภทของ policy และการประเมิน** (วิธีกำหนดสิทธิ์) และรูปแบบอย่าง **cross-account access** และ **service role** เป็นสิ่งสำคัญสำหรับการจัดการการเข้าถึง AWS ที่ปลอดภัยและ well-architected

## Role ในเชิงลึก — ใครจะ assume อะไร

```text
A ROLE has TWO key policies:
  TRUST POLICY → WHO can assume the role (which principals: a service, account, user)
  PERMISSION POLICIES → WHAT the role can do once assumed
Use cases:
  → SERVICE roles — an EC2/Lambda assumes a role to access AWS (no embedded keys)
  → CROSS-ACCOUNT — account B's role trusts account A → A's users assume it (controlled access)
  → FEDERATION/SSO — external identities assume roles (temporary credentials)
→ Roles give TEMPORARY credentials (auto-rotated) — far safer than long-lived keys.
```

## ประเภทของ policy

```text
IDENTITY-BASED → attached to users/groups/roles (what THEY can do)
RESOURCE-BASED → attached to a resource (e.g. an S3 bucket policy: who can access IT)
PERMISSION BOUNDARIES → a max-permissions limit on an identity (cap delegated permissions)
SCPs (Service Control Policies) → org-wide guardrails (limit what accounts can do)
→ Effective permissions = the combination, with rules for how they interact.
```

## การประเมิน policy (วิธีตัดสินการเข้าถึง)

```text
1. Explicit DENY anywhere → DENIED (deny always wins)
2. Else, an explicit ALLOW (from identity/resource policy) within bounds → ALLOWED
3. Else (no allow) → DENIED (default deny)
→ Default deny; explicit deny overrides any allow; you need an allow + no deny + within
  any boundaries/SCPs.
```

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

การเข้าใจ IAM role และ policy ในเชิงลึกเป็นสิ่งสำคัญสำหรับ **การจัดการการเข้าถึง AWS ที่ปลอดภัยและ well-architected** จึงเป็นความรู้ที่มีคุณค่านอกเหนือจาก IAM พื้นฐาน

การเข้าใจ **role ในเชิงลึก** ทั้ง **trust policy** (ใครจะ assume role ได้) และ **permission policy** (มันทำอะไรได้) เป็นกุญแจสู่รูปแบบการเข้าถึงที่ปลอดภัยซึ่งสำคัญที่สุด ได้แก่ **service role** (ให้ EC2 instance และฟังก์ชัน Lambda เข้าถึงทรัพยากร AWS ผ่าน credential ชั่วคราวที่หมุนเวียนอัตโนมัติแทน key ระยะยาวที่ฝังไว้ ซึ่งเป็นแนวปฏิบัติด้านความปลอดภัยที่สำคัญ) **cross-account access** (การเข้าถึงที่ควบคุมได้ระหว่างบัญชี AWS ผ่านการ assume role) และ **federation/SSO** (identity ภายนอก assume role เพื่อการเข้าถึงชั่วคราว)

การที่ role ให้ credential ชั่วคราวแทน key ระยะยาวเป็นการยกระดับความปลอดภัยขั้นพื้นฐาน

การเข้าใจ **ประเภทของ policy** ได้แก่ identity-based (สิ่งที่ user/role ทำได้) resource-based (อย่าง S3 bucket policy ที่ควบคุมว่าใครเข้าถึงทรัพยากรได้) permission boundary (จำกัดสิทธิ์ที่มอบหมาย) และ SCP (guardrail ระดับองค์กร) จำเป็นต่อการควบคุมการเข้าถึงที่ซับซ้อนในองค์กรจริง

การเข้าใจ **ตรรกะการประเมิน policy** (default deny; explicit deny ที่ใดก็ตามชนะเสมอ; คุณต้องมี explicit allow ภายในขอบเขตใด ๆ และไม่มี deny) จำเป็นต่อการให้เหตุผลอย่างถูกต้องว่าสิทธิ์ที่ได้จริงเป็นอย่างไร ซึ่งเป็นต้นเหตุของความสับสนที่พบบ่อย โดยการเข้าใจผิดนำไปสู่ทั้งการเข้าถึงที่กว้างเกินไป (ความเสี่ยงด้านความปลอดภัย) หรือการถูกปฏิเสธโดยไม่คาดคิด (อุปสรรคในการดำเนินงาน)

เนื่องจากการจัดการการเข้าถึงที่ปลอดภัยมีความสำคัญยิ่งต่อความปลอดภัยของ AWS (และการตั้งค่า IAM ผิดพลาดเป็นสาเหตุหลักของการละเมิด) และเนื่องจากการเข้าใจ role อย่างลึกซึ้ง (เพื่อรูปแบบการเข้าถึงที่ปลอดภัยโดยไม่ใช้ credential ฝังไว้) ประเภทของ policy (เพื่อการควบคุมแบบหลายชั้น) และการประเมิน policy (เพื่อการให้เหตุผลที่ถูกต้องเรื่องสิทธิ์) จำเป็นต่อการเข้าถึงที่ well-architected และปลอดภัย การเข้าใจ IAM role และ policy ในเชิงลึกจึงเป็นความรู้ AWS ที่มีคุณค่าและสำคัญในทางปฏิบัติด้านความปลอดภัย ต่อยอดจาก IAM พื้นฐานเพื่อเปิดทางรูปแบบการเข้าถึงที่ปลอดภัยและการให้เหตุผลเรื่องสิทธิ์ที่ถูกต้องซึ่งความปลอดภัย AWS ระดับมืออาชีพต้องการ เป็นด้านสำคัญที่ความลึกของความเข้าใจส่งผลโดยตรงต่อสถานะความปลอดภัย