AWS IAM & Workload Identity

AWS identity ไม่ได้มีเพียง user กับ role แต่เป็นระบบ policy หลายชนิดที่ประกอบกัน การตั้ง Allow 1 จุดอาจถูก guardrail อีกชั้นปฏิเสธ ขณะเดียวกัน resource policy บางแบบก็ grant ไปยัง session ได้โดยตรง การลด IAM เป็นประโยคว่า “ทุก policy เอามา intersect กัน” จึงทำให้วิเคราะห์สิทธิ์ผิดได้

Identity Plane คือ Production Plane#

IAM compromise สามารถเปลี่ยน infrastructure, อ่าน secret, ปิด logging หรือสร้าง persistence ได้โดยไม่ต้อง โจมตี application endpoint ดังนั้น identity plane ต้องได้รับ protection ระดับเดียวกับ production data plane

องค์ประกอบหลัก:

• Principal: user, role, role session, federated session หรือ AWS service
• Action: API operation เช่น s3:GetObject
• Resource: ARN ที่ action กระทำ
• Context: Region, source network, MFA, tags, organization, session attributes และ service-specific keys
• Policy: เอกสารที่กำหนด allow/deny ภายใต้ condition

authorization เกิดทุก request ไม่ได้จบเมื่อ sign in สำเร็จ

Policy Types#

policy คนละชนิดอาจใช้ semantics และ condition keys ต่างกัน ต้องอ่าน documentation ของ service/resource ไม่ควร copy policy แล้วเปลี่ยน ARN อย่างเดียว

Evaluation Mental Model#

เริ่มด้วย implicit deny จากนั้นพิจารณา:

1. มี explicit deny ที่ใช้กับ request หรือไม่ ถ้ามีให้ปฏิเสธ
2. guardrail เช่น SCP, RCP, permissions boundary และ session policy เปิดเพดานไว้หรือไม่
3. มี applicable allow จาก identity หรือ resource policy หรือไม่
4. condition, principal type, resource type และ cross-account boundary ตรงหรือไม่

identity-based policy กับ resource-based policy ใน account เดียวกันมักรวมแบบ union ภายใต้ guardrails แต่ resource policy ที่ grant ให้ IAM role ARN, role session ARN หรือ federated session มีรายละเอียดต่างกัน บางกรณี permission ที่ grant ตรง session ไม่ถูกจำกัดด้วย identity boundary แบบที่คาด

อ่าน Policy อย่างเป็นระบบ#

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadStatementsForOneTenant",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::example-statements/tenant-123/*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalTag/tenant_id": "tenant-123"
        }
      }
    }
  ]
}

ตรวจทีละส่วน:

• Effect เป็น Allow หรือ Deny
• Action แคบถึง operation ที่ต้องใช้หรือมี wildcard
• Resource รองรับ resource-level permission จริงหรือไม่
• Principal เป็น account, role, session, service หรือ public
• Condition key ใช้ได้กับ action/resource/context นั้นหรือไม่
• variable/tag มาจากแหล่งที่ใครแก้ได้
• policy อนุญาต list/discover เพิ่มจาก read/write หรือไม่

NotAction, NotResource และ wildcard ช่วยลด policy length แต่เพิ่มภาระ reasoning และเสี่ยงเปิดสิทธิ์ให้ service/action ใหม่โดยไม่ตั้งใจ

Human Access#

แนวทางหลักคือ federation ผ่าน external IdP หรือ IAM Identity Center แล้วใช้ temporary credentials:

• identity lifecycle อยู่ใน source ที่มี joiner/mover/leaver process
• assign permission sets ตาม job function
• ใช้ MFA ที่เหมาะกับ risk โดย privileged access ควร phishing-resistant
• session duration สั้นตามงานและมี re-authentication สำหรับ sensitive elevation
• แยก read-only, operator และ administrator responsibilities
• ไม่มี shared account หรือ shared access key
• log source identity/session attributes ให้ trace กลับบุคคลได้

IAM user ยังจำเป็นในบาง legacy/workload case แต่ไม่ควรเป็น default สำหรับ workforce

Temporary Credentials#

AWS STS ออก access key ID, secret access key และ session token ที่หมดอายุเอง ประโยชน์คือไม่ต้องเก็บ long-lived secret และจำกัด session context ได้ แต่ระหว่างยัง valid สิทธิ์ของ credential ยังสร้างผลกระทบได้

AssumeRole รองรับ session ตั้งแต่ 15 นาทีถึง maximum ของ role ซึ่งกำหนดได้สูงสุด 12 ชั่วโมง ค่า default โดยทั่วไปคือ 1 ชั่วโมง และ role chaining จำกัด session สูงสุด 1 ชั่วโมง

ควรกำหนด:

• minimum practical duration
• session name/source identity ที่ตรวจสอบได้
• session tags จาก trusted attributes
• audience และ trust ของ federation
• session policy เมื่อต้องลดสิทธิ์เฉพาะ task
• revocation/containment plan เพราะ token ไม่หายทันทีจากเครื่องที่ compromise

short-lived credential ลด exposure window ไม่ได้เปลี่ยน broad administrator เป็น least privilege

Workload Identity#

workload ควรรับ temporary credential จาก execution environment:

• EC2 instance profile
• ECS task role
• Lambda execution role
• EKS Pod Identity หรือ IRSA
• service role/service-linked role ตาม AWS service

ห้าม embed access key ใน source, container image, AMI, user data หรือ environment bundle ระยะยาว

แยก Role ตาม Workload#

role ควรผูกกับ application/component/environment ไม่ใช้ role เดียวร่วมทั้ง cluster หรือ account:

• API รับคำขออาจอ่าน customer profile แต่ไม่ควร administer database
• reconciliation worker อาจอ่าน object prefix เฉพาะและเขียนผลลัพธ์อีก prefix
• deployment role เปลี่ยน infrastructure ได้ แต่ runtime role ไม่ควรทำได้
• observability agent ส่ง telemetry ได้ แต่ไม่ควรอ่าน application secrets

การแยก role ทำให้ revoke, investigation และ permission tuning มี granularity ที่พอใช้

Trust Policy#

permission policy ตอบว่า role ทำอะไรได้ ส่วน trust policy ตอบว่าใคร assume role ได้

ตรวจ trust policy ที่:

• principal แคบถึง account/role/service ที่ตั้งใจ
• condition ผูก organization, source identity, tags, MFA หรือ workload context ตาม use case
• wildcard principal ไม่ถูกเปิดโดย condition ที่แก้ได้เอง
• identity ที่แก้ trust policy ถูกจำกัดและ monitored
• role assumption ถูก log และ alert ตาม sensitivity

การสร้าง role สิทธิ์แคบไม่ช่วย หาก attacker เปลี่ยน trust policy หรือ PassRole ให้ service ที่ควบคุมได้

PassRole#

iam:PassRole อนุญาตส่ง role ให้ AWS service เช่น Lambda, ECS หรือ EC2 ผู้ใช้ไม่จำเป็นต้อง assume role เองก็อาจทำให้ service execute ด้วยสิทธิ์นั้นได้

ลดความเสี่ยงด้วย:

• จำกัด role ARN ที่ pass ได้
• ใช้ iam:PassedToService เมื่อเหมาะสม
• แยก role creation/attachment จาก workload deployment
• จำกัด service configuration ที่ใช้ role นั้น
• alert การ pass privileged role หรือสร้าง compute ใหม่

PassRole ที่ใช้ Resource: "*" มักเป็น privilege-escalation primitive สำคัญ

Cross-Account Access#

โดยทั่วไป caller ต้องมี permission เรียก sts:AssumeRole และ role ปลายทางต้อง trust caller

สำหรับ third-party provider:

• ใช้ dedicated role ต่อ provider/purpose
• principal ต้องเป็น account/role ที่ provider ระบุ ไม่ใช่ public
• ใช้ unpredictable ExternalId ตาม workflow ของ provider เพื่อช่วยป้องกัน confused deputy
• จำกัด action/resource/session duration
• ไม่ให้ provider เลือก arbitrary session tags หรือ source identity
• monitor usage และ revoke เมื่อ contract/lifecycle จบ

ExternalId ไม่ใช่ password และอาจปรากฏใน configuration/log ได้ จุดประสงค์คือ bind request กับ customer context ที่ provider จัดการ ไม่ใช่ใช้แทน authentication

Permissions Boundary#

permissions boundary เป็นเพดานให้ identity-based permissions ใช้กับ delegated IAM administration เช่น อนุญาตทีมสร้าง workload role ได้แต่ role ที่สร้างห้ามออกนอก service/data boundary

boundary:

• ไม่ grant permission ด้วยตัวเอง
• ไม่แทน SCP หรือ resource policy
• ต้องป้องกันไม่ให้ delegated principal ถอด/เปลี่ยน boundary
• ต้องจำกัด CreatePolicyVersion, SetDefaultPolicyVersion, PassRole และ trust-policy changes ที่ใช้ bypass
• ต้อง test กับ principal/resource-policy semantics จริง

boundary ที่ attach แล้วแต่ผู้สร้างลบได้ ไม่ใช่ guardrail

Attribute-Based Access#

principal/resource/session tags ช่วยขยายระบบโดยไม่สร้าง policy ต่อ resource แต่ tag กลายเป็น security input:

• กำหนด vocabulary และ source of truth
• จำกัดผู้แก้ security-sensitive tags
• validate tag ตอน provision และ deployment
• ป้องกัน missing/null tag behavior
• แยก metadata สำหรับ billing จาก authorization tags
• audit tag change และ stale ownership

ABAC ลดจำนวน policy ได้ แต่ไม่ได้ลดความจำเป็นในการดูแล attribute lifecycle

Least-Privilege Lifecycle#

1. เริ่มจาก task และ resource ที่จำเป็น
2. ใช้ managed/service documentation สร้าง baseline
3. ทดสอบ positive และ denied paths
4. ดู CloudTrail/last-accessed evidence ในช่วงที่ representative
5. ลด action/resource/condition
6. deploy แบบ staged พร้อม rollback
7. review เมื่อ architecture, owner หรือ data classification เปลี่ยน

IAM Access Analyzer ช่วย validate policy, หา external/public access และ generate policy จาก CloudTrail usage แต่ช่วง trace ที่ไม่พบ action ไม่ได้พิสูจน์ว่า action นั้นไม่จำเป็นใน month-end, failover หรือ incident

Identity Detection#

use cases ที่ควรตรวจ:

• root sign-in/action
• access key สร้างใหม่หรือใช้จาก context/Region ผิดปกติ
• privileged role assumption และ break-glass usage
• trust policy, permissions boundary, SCP หรือ IdP integration เปลี่ยน
• PassRole ไป compute/service ใหม่
• failed authorization burst และ policy simulation/discovery
• long-lived key ที่ไม่ rotate/ไม่ใช้
• cross-account principal หรือ session tag ใหม่

alert ต้องเชื่อม owner, expected-change context, runbook และ containment permission

Credential Incident#

เมื่อสงสัย credential compromise:

1. ระบุ principal/session, permissions และ active resources
2. preserve CloudTrail/IdP/workload evidence
3. disable/delete key หรือ revoke session ตาม mechanism
4. ลด/deny permission และ isolate workload เมื่อจำเป็น
5. ค้น persistence เช่น new role, trust, key, policy, Lambda หรือ instance
6. rotate downstream secrets ที่ credential เข้าถึงได้
7. restore จาก known-good configuration
8. review root cause และเพิ่ม preventive/detective controls

การ rotate key เดียวไม่พอ หาก attacker สร้าง role หรือ resource-based backdoor แล้ว

Review Checklist#

• workforce ใช้ federation/Identity Center และ temporary credentials
• workload ใช้ dedicated role ไม่มี embedded long-lived key
• policy ระบุ action/resource/condition แคบและมี denied-path tests
• trust policy, PassRole และ role creation ถูกจำกัด/monitored
• STS duration, source identity และ session tags สอดคล้องกับ task
• cross-account/third-party role มี scoped principal, permission และ lifecycle
• ExternalId ใช้เมื่อมี confused-deputy scenario และไม่ถือเป็น secret
• permissions boundary ป้องกันการถอด/แก้/bypass และไม่ถูกเข้าใจว่า grant สิทธิ์
• authorization tags มี protected source และ lifecycle
• Access Analyzer/usage evidence มี representative window และ human review
• break-glass short-lived, phishing-resistant, alert และ post-use review
• incident runbook ครอบคลุม session revoke, persistence hunt และ downstream rotation

Further Reading#

• AWS IAM — Policy Evaluation Logic
• AWS IAM — Policy Evaluation across Accounts
• AWS IAM Best Practices
• AWS STS AssumeRole
• AWS IAM Access Analyzer