IAM & AWS CLI

IAM (Identity and Access Management) เป็นบริการสำหรับจัดการ ผู้ใช้ (identity) และ สิทธิ์ (permissions) ในบัญชี AWS ของเรา จุดสำคัญที่ออกสอบ: IAM เป็น global service ไม่ผูกกับ region ใด region หนึ่ง — Users, Groups, Roles, Policies ที่สร้างจะมองเห็นได้ทุก region

ตอนสร้างบัญชี AWS ครั้งแรกจะได้ root account ซึ่งมีสิทธิ์เต็ม (full access) แต่ AWS แนะนำว่าไม่ควรใช้ root ในงานประจำวัน และไม่ควรแชร์ออกไป ควรสร้าง IAM User สำหรับใช้งานจริงแทน

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

• Users — บุคคลหนึ่งคนต่อหนึ่ง user (เช่น พนักงาน) สามารถมี credentials ของตัวเอง
• Groups — กลุ่มของ users เท่านั้น (ห้ามมี group ซ้อนใน group และ group ไม่สามารถบรรจุ group อื่นได้)
• Policies — เอกสาร JSON กำหนดสิทธิ์ ผูกกับ user / group / role
• Roles — identity ที่ให้ AWS services หรือ users สวมบทบาทเพื่อรับสิทธิ์ชั่วคราว

Policy คือเอกสาร JSON ที่กำหนดว่าใครทำอะไรกับ resource ไหนได้ ต้องจำโครงสร้างให้ขึ้นใจเพราะออกสอบเป็น JSON บ่อยมาก

• Version — เวอร์ชันภาษานโยบาย ปัจจุบันใช้ "2012-10-17" เสมอ (ค่าทางการล่าสุด)
• Id — (optional) ตัวระบุ policy
• Statement — (required) ประกอบด้วยหนึ่งหรือหลาย statement
• Sid — (optional) statement id
• Effect — Allow หรือ Deny
• Principal — ใคร (account/user/role) ที่ statement นี้มีผล (ใช้ใน resource-based policy)
• Action — รายการ API actions ที่ allow/deny เช่น s3:GetObject
• Resource — รายการ ARN ที่ action มีผล
• Condition — (optional) เงื่อนไขที่ทำให้ statement มีผล

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadSpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

Policy แบ่งตามวิธีบริหารจัดการได้ 3 แบบหลัก ออกสอบเรื่องความแตกต่างและ use case ของแต่ละแบบ

IAM Role คือ identity ที่ไม่มี credentials ถาวร แต่ให้ entity (เช่น EC2 instance, Lambda, ECS task หรือ user) สวมบทบาท (assume) เพื่อรับ credentials ชั่วคราว (temporary credentials) ผ่าน AWS STS (Security Token Service)

หลักการสำคัญ: เมื่อต้องการให้ AWS service (เช่น EC2) เรียก AWS API อื่น ห้ามฝัง access key ลงใน instance เด็ดขาด ให้ผูก IAM Role กับ instance แทน ระบบจะหมุน credentials ให้อัตโนมัติและปลอดภัยกว่า

องค์ประกอบของ Role

• Trust policy (assume role policy) — กำหนดว่าใคร (principal) สวมบท role นี้ได้ เช่น ec2.amazonaws.com
• Permissions policy — กำหนดว่า role นี้ทำอะไรได้บ้างหลังถูกสวมบท
• การ assume ทำผ่าน sts:AssumeRole ได้ credentials ชั่วคราวมีอายุจำกัด

// Trust policy: อนุญาตให้ EC2 service สวมบท role นี้
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

Policy มีสองมุมมองหลักที่ต้องแยกให้ออก: identity-based ผูกกับ identity (user/group/role) และ resource-based ผูกกับ resource (เช่น S3 bucket policy, SQS queue policy, Lambda resource policy)

กรณีข้าม account (cross-account): เมื่อ principal ถูกสวมบท role (assume role) จะ ไม่นำ identity-based policy เดิมของตัวเองติดไปด้วย (ยกเว้น session policy) — ใช้สิทธิ์ของ role ที่ assume แทน แต่ถ้าใช้ resource-based policy ให้สิทธิ์ข้าม account โดยตรง principal จะใช้สิทธิ์ทั้งของ resource-based policy และ identity-based policy ของตัวเองพร้อมกัน

นี่คือหัวข้อที่ออกสอบบ่อยและสำคัญที่สุดข้อหนึ่ง ต้องเข้าใจลำดับการตัดสินว่าคำขอจะถูก allow หรือ deny

หลักการตัดสิน (เรียงลำดับ)

• Default คือ implicit deny — ทุกอย่างถูกปฏิเสธโดยปริยายถ้าไม่มีอะไร allow
• ถ้ามี explicit Allow ที่ตรงกับคำขอ → allow (เว้นแต่มี explicit deny)
• Explicit Deny ชนะทุกอย่างเสมอ — ถ้ามี Deny ที่ตรงคำขอ ไม่ว่าจะมี Allow กี่อันก็ถูกปฏิเสธ
• ลำดับจำง่าย: Explicit Deny > Explicit Allow > Implicit Deny (default)

// แม้จะมี Allow s3:* อยู่ที่อื่น statement Deny นี้ก็ชนะเสมอ
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDeleteEvenIfAllowedElsewhere",
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "arn:aws:s3:::critical-bucket/*"
    }
  ]
}

เมื่อมีหลายชั้นนโยบาย (SCP จาก Organizations, permission boundary, identity-based, resource-based, session policy) การจะ allow ได้ต้อง ผ่านทุกชั้นที่เกี่ยวข้อง และ ไม่มี explicit deny ในชั้นใดเลย

Permission Boundary คือ managed policy ที่ใช้เป็น ขอบเขตสูงสุด (maximum permissions) ที่ identity-based policy สามารถให้ได้กับ IAM user หรือ IAM role (ใช้ได้กับ user/role เท่านั้น ไม่ใช้กับ group)

หลักสำคัญ: permission boundary ไม่ได้ให้สิทธิ์ด้วยตัวเอง แต่เป็นตัวจำกัด สิทธิ์ที่ใช้ได้จริง = intersection (ส่วนที่ทับซ้อนกัน) ระหว่าง identity-based policy กับ permission boundary

• ใช้จำกัดสิทธิ์ของ user/role ไม่ให้เกิน boundary แม้ identity policy จะ allow มากกว่า
• use case: ให้ developer สร้าง user/role ได้เอง แต่จำกัดไม่ให้ escalate สิทธิ์เกินขอบเขต (delegation)
• ทำงานร่วมกับ AWS Organizations SCP ได้ — สิทธิ์จริงต้องผ่านทั้ง SCP, boundary, และ identity policy

MFA (Multi-Factor Authentication) เพิ่มชั้นความปลอดภัยโดยต้องใช้รหัสจากอุปกรณ์ MFA ร่วมกับรหัสผ่าน AWS แนะนำให้เปิด MFA ทั้ง root account และ IAM users ที่มีสิทธิ์สูง

ประเภทอุปกรณ์ MFA

• Virtual MFA device — แอป เช่น Google Authenticator, Authy (รองรับหลายบัญชีในเครื่องเดียว)
• Universal 2nd Factor (U2F) Security Key — เช่น YubiKey (รองรับหลาย root/IAM users ในกุญแจเดียว)
• Hardware Key Fob MFA Device — จาก third party
• Hardware Key Fob MFA Device for AWS GovCloud (US)

Access Keys & วิธีเข้าถึง AWS

• AWS Management Console — ป้องกันด้วย password + MFA
• CLI / SDK — ใช้ Access Keys (Access Key ID + Secret Access Key)
• Access Keys เป็นความลับ ห้ามแชร์ ผู้ใช้สร้าง/จัดการของตัวเอง
• Access Key ID เปรียบเหมือน username, Secret Access Key เปรียบเหมือน password

• อย่าใช้ root account ยกเว้นตอน setup บัญชีครั้งแรก
• หนึ่งคน = หนึ่ง IAM user ห้ามแชร์ user ร่วมกัน
• จัด permission ผ่าน Groups เพื่อบริหารง่าย
• ใช้ strong password policy และเปิด MFA
• ใช้ IAM Roles สำหรับ AWS services (EC2/Lambda) แทน access key
• ใช้ access keys เฉพาะกับ programmatic access ที่จำเป็น และ หมุนเวียน (rotate) เป็นระยะ
• หลัก least privilege (สิทธิ์น้อยที่สุดเท่าที่จำเป็น) — ให้เฉพาะสิทธิ์ที่ต้องใช้จริง
• ตรวจสอบสิทธิ์ด้วย Credentials Report และ Access Advisor สม่ำเสมอ
• อย่าแชร์ IAM users/access keys

AWS มีเครื่องมือสองตัวสำหรับ audit สิทธิ์ ออกสอบเรื่อง 'ใช้ตัวไหนเพื่อทำอะไร' บ่อยมาก ต้องแยกให้ชัด

ใน Shared Responsibility Model สำหรับ IAM: AWS รับผิดชอบ โครงสร้างพื้นฐาน, การดูแล infrastructure ของ IAM, configuration/vulnerability analysis และ compliance validation ส่วน ลูกค้ารับผิดชอบ การจัดการ users/groups/roles/policies, เปิด MFA, หมุน key, ใช้ least privilege และตรวจ permission

AWS CLI ที่เกี่ยวข้อง (ควรคุ้น)

# ดูข้อมูล identity ที่กำลังใช้เรียก API (เช็คว่าใช้ role/user ไหน)
aws sts get-caller-identity

# สวมบท role ข้าม account เพื่อรับ temporary credentials
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/MyCrossAccountRole \
  --role-session-name my-session

# สร้าง credentials report และดาวน์โหลด
aws iam generate-credential-report
aws iam get-credential-report