Tuần 1 - Ngày 3: IAM Cơ bản

Mục tiêu học tập

• Hiểu các thành phần IAM: User, Group, Role, Policy
• Phân biệt Identity-based và Resource-based policies
• Viết được JSON policy đơn giản
• Nắm vững IAM best practices ở mức Associate

1. Tổng quan IAM

IAM (Identity and Access Management) là service quản lý WHO (authentication) có thể làm WHAT (authorization) trên AWS resources.

Đặc điểm

• Global service — không thuộc Region nào
• Miễn phí — không tính phí riêng
• Tích hợp với hầu hết AWS services
• Hỗ trợ MFA, password policy, identity federation

2. IAM Users

Định nghĩa

IAM User là một identity đại diện cho 1 người hoặc 1 application có truy cập lâu dài vào AWS account.

Đặc điểm

• Tối đa 5000 users / account
• 2 loại credentials:
  • Password (cho Console access)
  • Access Key ID + Secret Access Key (cho CLI/SDK/API)
• Mỗi user có thể có tối đa 2 active access keys (để rotate)

Root User vs IAM User

Best practice: Không dùng root user cho công việc hằng ngày. Tạo IAM User với Admin permission, lock root credentials.

3. IAM Groups

Định nghĩa

Group là tập hợp các IAM Users, dùng để gán policy chung cho nhiều users.

Đặc điểm

• Group không có credentials, chỉ chứa users
• 1 User có thể thuộc nhiều Groups (tối đa 10)
• Group không thể chứa Group khác (no nested groups)
• Group không thể chứa Roles

Ví dụ

4. IAM Roles

Định nghĩa

IAM Role là một identity với policy attached, nhưng không gắn với 1 person cụ thể. Bất kỳ entity nào (user, service, account khác) "assume" role sẽ có temporary credentials.

Khi nào dùng Role?

Trust Policy vs Permission Policy

// TRUST POLICY: AI có thể assume role này?
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ec2.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}

// PERMISSION POLICY: Role được làm gì?
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

5. IAM Policies

Cấu trúc JSON Policy

{
  "Version": "2012-10-17",       // Version language (luôn dùng 2012-10-17)
  "Statement": [
    {
      "Sid": "AllowS3Read",       // Optional: ID của statement
      "Effect": "Allow",           // Allow | Deny
      "Action": [                  // Hành động được phép
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [                // Resource ARN
        "arn:aws:s3:::my-bucket",
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {               // Optional: điều kiện
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    }
  ]
}

Các loại Policies

6. Policy Evaluation Logic

Quy tắc

1. Mặc định DENY mọi action (implicit deny)
2. Explicit ALLOW mới cho phép
3. Explicit DENY luôn thắng Explicit ALLOW
4. Đánh giá tất cả applicable policies (identity + resource + boundary + SCP)

7. Identity-based vs Resource-based Policy

Identity-based Policy (gắn vào User/Group/Role)

• "WHO can do WHAT on WHICH resources"
• Không cần Principal trong policy (principal = entity được attached)

Resource-based Policy (gắn vào Resource)

• "WHO can do WHAT on THIS resource"
• Bắt buộc có Principal trong policy
• Hỗ trợ trên: S3 bucket, SNS topic, SQS queue, KMS key, Lambda function, ECR repository...

Ví dụ Cross-Account S3 Bucket Policy

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::222222222222:root" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-shared-bucket/*"
  }]
}

→ Cho phép Account 222222222222 đọc objects trong bucket.

8. MFA (Multi-Factor Authentication)

Các loại MFA AWS hỗ trợ

• Virtual MFA device: Google Authenticator, Authy, 1Password
• Hardware MFA: Gemalto token, YubiKey
• U2F security key: YubiKey với Console
• SMS MFA: Đã bị deprecated cho IAM users (vẫn dùng cho Cognito)

Best practice

• Bật MFA cho root user (BẮT BUỘC)
• Bật MFA cho tất cả IAM users có Console access
• Force MFA bằng IAM policy condition: "aws:MultiFactorAuthPresent": "true"

9. IAM Best Practices (Top 10)

1. Lock root user — chỉ dùng cho tác vụ bắt buộc (đổi billing, đóng account)
2. Bật MFA cho root + tất cả users có Console access
3. Tạo IAM User cá nhân thay vì dùng chung credentials
4. Dùng Groups để gán permission, không gán trực tiếp vào User
5. Áp dụng Least Privilege — chỉ cấp quyền cần thiết
6. Dùng Roles cho EC2/Lambda thay vì hard-code Access Key
7. Rotate Access Keys định kỳ (90 ngày)
8. Dùng IAM Access Analyzer để phát hiện over-permissive policies
9. Strong password policy (length, complexity, expiration)
10. Enable CloudTrail để audit mọi API call

Câu hỏi ôn tập

1. Sự khác biệt chính giữa IAM User và IAM Role là gì?

   Xem đáp án

   IAM User có long-term credentials (password + access keys) gắn cố định với một người hoặc application. IAM Role không có long-term credentials — bất kỳ entity nào (EC2, Lambda, user từ account khác) có thể "assume" role để nhận temporary credentials (qua AWS STS). Role không gắn với một người cụ thể — đây là cơ chế phù hợp nhất cho services, cross-account access, và federation.

2. Khi có Explicit Allow và Explicit Deny cho cùng action, kết quả là gì?

   Xem đáp án

   Explicit Deny luôn thắng, kết quả là DENY. Đây là nguyên tắc cơ bản của IAM policy evaluation: Deny > Allow > implicit Deny. Bất kể bao nhiêu Allow statements, chỉ cần một Explicit Deny là action bị chặn. Điều này quan trọng khi dùng SCPs trong Organizations hoặc Permission Boundaries.

3. EC2 cần access S3 — nên dùng cách nào: Access Key trong code hay IAM Role?

   Xem đáp án

   IAM Role (Instance Profile). Hard-code Access Key trong code hoặc config file là anti-pattern nghiêm trọng: key có thể bị lộ qua git history, logs, hay nếu instance bị compromise. IAM Role cung cấp temporary credentials tự động rotate qua Instance Metadata Service (IMDSv2) — không cần quản lý key, tuân thủ least privilege, và dễ audit qua CloudTrail.

4. Resource-based policy bắt buộc có element nào mà identity-based policy không cần?

   Xem đáp án

   Principal element. Resource-based policy (gắn vào S3 bucket, KMS key, SQS queue...) phải khai báo rõ "WHO được phép" — ví dụ "Principal": {"AWS": "arn:aws:iam::222222222222:root"}. Identity-based policy không cần Principal vì entity được attach chính là principal ngầm định.

5. Group có thể chứa Group khác không?

   Xem đáp án

   Không. IAM Groups không hỗ trợ nesting (không có nested groups). Group chỉ có thể chứa IAM Users, không thể chứa Group khác hay Roles. Một User có thể thuộc tối đa 10 Groups. Đây là giới hạn thiết kế của IAM — nếu cần hierarchy phức tạp hơn, xem xét dùng AWS Organizations với SCPs.

Bài tập thực hành

• Tạo IAM User mới với Admin access, bật MFA, dùng cho công việc hằng ngày
• Tạo Group "Developers" với policy AmazonEC2ReadOnlyAccess
• Tạo IAM Role cho EC2 access S3 bucket cụ thể, attach role vào EC2 instance
• Viết JSON policy: cho phép đọc/ghi S3 bucket "my-app-data" nhưng chỉ từ Region us-east-1
• Enable IAM Access Analyzer

Tài liệu tham khảo chính thức

• IAM User Guide
• IAM Best Practices
• Policy Evaluation Logic
• IAM Roles for EC2

---

Tiếp theo: Billing và Cost Management