Chương 02: IAM - Identity & Access Management

Tổng Quan

IAM là dịch vụ miễn phí và toàn cầu (global) của AWS, giúp bạn kiểm soát ai (identity) có thể làm gì (access) trên tài khoản AWS. Đây là chủ đề nặng nhất trong Domain 1 (Secure Architectures - 30%).

1. Các Thành Phần Cơ Bản Của IAM

1.1 Root Account

Tài khoản được tạo đầu tiên khi đăng ký AWS.
Có toàn quyền trên mọi dịch vụ → CỰC KỲ NGUY HIỂM nếu bị lộ.
Best Practice: KHÔNG BAO GIỜ dùng root account cho công việc hàng ngày. Chỉ dùng để tạo IAM User đầu tiên và quản lý billing.

1.2 IAM Users

Đại diện cho 1 người hoặc 1 ứng dụng cần truy cập AWS.
Có credentials riêng (username/password cho Console, Access Key cho CLI/API).
Best Practice: Mỗi người dùng 1 IAM User riêng, không chia sẻ.

1.3 IAM Groups

Là tập hợp các IAM Users.
Dùng để gán quyền cho nhiều users cùng lúc (VD: nhóm "Developers", nhóm "Admins").
Lưu ý:
- 1 User có thể thuộc nhiều Groups.
- Groups KHÔNG thể chứa Groups khác (không lồng nhau).
- Groups KHÔNG phải identity → không thể dùng Group trong IAM Policy Principal.

1.4 IAM Roles

Giống như một "bộ quyền tạm thời" mà dịch vụ AWS hoặc user có thể "mặc vào".
Use cases phổ biến:
- EC2 Instance cần truy cập S3 → Gán IAM Role cho EC2 (KHÔNG dùng Access Key).
- Lambda function cần ghi vào DynamoDB → Gán IAM Role cho Lambda.
- Cross-Account Access → User ở Account A assume Role ở Account B.
Bao gồm: Trust Policy (ai được assume) + Permission Policy (được làm gì).

1.5 IAM Policies

Là tài liệu JSON định nghĩa quyền (Allow/Deny) cho Users, Groups, hoặc Roles.

2. IAM Policies Chi Tiết

2.1 Cấu trúc JSON Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3Read",
      "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"
        }
      }
    }
  ]
}

Trường	Ý nghĩa
Version	Luôn là `"2012-10-17"`
Effect	`Allow` hoặc `Deny`
Action	Hành động allowed/denied (VD: `s3:GetObject`)
Resource	Tài nguyên áp dụng (ARN)
Condition	Điều kiện bổ sung (tùy chọn)

2.2 Các Loại Policy

Loại	Mô tả
AWS Managed Policy	Do AWS tạo sẵn (VD: `AmazonS3ReadOnlyAccess`). Tiện lợi nhưng không tùy chỉnh được.
Customer Managed Policy	Do bạn tự tạo. Best practice vì kiểm soát được hoàn toàn.
Inline Policy	Gán trực tiếp vào 1 User/Group/Role cụ thể. Dùng khi quyền chặt chẽ 1:1.

2.3 Quy Tắc Đánh Giá Policy (Policy Evaluation Logic)

1. Mặc định: TẤT CẢ đều bị DENY (Implicit Deny)
2. Kiểm tra tất cả policies áp dụng
3. Nếu có BẤT KỲ Explicit Deny → DENY (ưu tiên cao nhất)
4. Nếu có Allow → ALLOW
5. Nếu không có Allow nào → DENY (Implicit Deny)

⚠️ Quy tắc vàng: Explicit Deny LUÔN thắng Allow.

3. MFA (Multi-Factor Authentication)

Thêm lớp bảo mật thứ 2 ngoài password.

Loại MFA	Mô tả
Virtual MFA Device	App trên điện thoại (Google Authenticator, Authy)
U2F Security Key	Thiết bị vật lý (YubiKey)
Hardware MFA	Thiết bị phần cứng token (Gemalto)

Best Practice: Bật MFA cho Root Account và tất cả IAM Users có quyền cao.

4. IAM Access Phương Thức

Phương thức	Dùng cho	Credentials
AWS Management Console	Giao diện web	Username + Password + MFA
AWS CLI	Dòng lệnh terminal	Access Key ID + Secret Access Key
AWS SDK	Code (Python, Node.js...)	Access Key ID + Secret Access Key

⚠️ KHÔNG BAO GIỜ nhúng Access Key vào source code. Dùng IAM Roles hoặc Environment Variables.

5. AWS Organizations & SCPs

5.1 AWS Organizations

Quản lý nhiều AWS accounts dưới 1 tổ chức.
Consolidated Billing: Gộp hóa đơn tất cả accounts → hưởng volume discount.
Tổ chức theo Organizational Units (OUs) — VD: OU-Dev, OU-Prod, OU-Security.

Root (Management Account)
├── OU: Production
│   ├── Account: Prod-App
│   └── Account: Prod-DB
├── OU: Development
│   ├── Account: Dev-Team-A
│   └── Account: Dev-Team-B
└── OU: Security
    └── Account: Security-Audit

5.2 Service Control Policies (SCPs)

Là rào chắn tối đa (guardrails) cho các accounts trong Organization.
SCP KHÔNG cấp quyền, chỉ giới hạn quyền tối đa mà accounts con có thể có.
SCP áp dụng cho tất cả users & roles trong account (kể cả root user của account con).
KHÔNG áp dụng cho Management Account.

Ví dụ SCP — Cấm xóa CloudTrail:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "cloudtrail:DeleteTrail",
      "Resource": "*"
    }
  ]
}

6. IAM Identity Center (AWS SSO)

Single Sign-On cho nhiều AWS Accounts và ứng dụng.
Tích hợp với Active Directory (AD) hoặc SAML 2.0 Identity Providers.
Dùng khi tổ chức cần quản lý quyền truy cập tập trung cho nhiều accounts.

7. STS (Security Token Service)

AWS STS cung cấp credentials tạm thời (temporary credentials) có thời hạn.
Dùng cho:
- AssumeRole: User/Service assume một Role để lấy quyền tạm thời.
- Cross-Account Access: User Account A assume Role ở Account B.
- Federation: User từ bên ngoài (AD, Google, Facebook) lấy credentials tạm để truy cập AWS.

User Account A ──AssumeRole──> Role in Account B
                                  │
                                  ▼
                          Temporary Credentials
                          (Access Key + Secret + Session Token)
                          Hết hạn sau 1-12 giờ

8. IAM Best Practices (Tổng Hợp)

❌ Không dùng Root Account cho công việc hàng ngày
✅ Bật MFA cho Root và tất cả IAM Users
✅ Áp dụng nguyên tắc Least Privilege (chỉ cấp quyền tối thiểu cần thiết)
✅ Dùng IAM Roles cho EC2/Lambda thay vì Access Keys
✅ Dùng Groups để gán quyền, không gán trực tiếp cho Users
✅ Tạo Password Policy mạnh (độ dài, ký tự đặc biệt, hết hạn)
✅ Regular audit quyền bằng IAM Access Analyzer và Credential Report
✅ Dùng aws:SourceIp Condition để giới hạn truy cập từ IP cụ thể

Exam Tips 💡

"Principle of Least Privilege" — Nếu đề hỏi cách bảo mật tốt nhất thì luôn chọn đáp án cấp ít quyền nhất.
IAM Role cho EC2 là best practice — Không bao giờ chọn đáp án dùng Access Key trên EC2.
SCP không cấp quyền, chỉ giới hạn. SCP + IAM Policy phải đều Allow thì mới được phép.
IAM là Global — Không thuộc bất kỳ Region nào.
Cross-Account Access = STS AssumeRole. Không tạo IAM User ở mỗi account.
Explicit Deny > Allow trong mọi trường hợp.

Câu Hỏi Ôn Tập 📝

Câu 1: Đội phát triển cần truy cập S3 bucket từ EC2 instance. Cách nào bảo mật và đúng best practice nhất?

A. Tạo IAM User, lưu Access Key vào file trên EC2
B. Gán IAM Role cho EC2 instance với quyền S3
C. Dùng Root Account credentials
D. Chia sẻ Access Key qua email cho team

Xem đáp án

B. Gán IAM Role cho EC2 instance. Role cung cấp temporary credentials tự động, không cần quản lý Access Key thủ công. Đây là best practice #1 của AWS.

Câu 2: Công ty bạn có 10 AWS accounts. Bạn muốn NGĂN tất cả accounts không được tạo tài nguyên ở Region eu-west-1. Bạn nên dùng gì?

Xem đáp án

Service Control Policy (SCP) trong AWS Organizations. SCP cho phép bạn Deny actions ở các Regions cụ thể, áp dụng cho tất cả users/roles trong các accounts con.

Câu 3: IAM Policy có 1 statement Allow s3:* và 1 statement Deny s3:DeleteObject. User có thể xóa object trong S3 không?

Xem đáp án

Không. Explicit Deny luôn thắng Allow. User có thể thực hiện mọi hành động S3 khác, nhưng không thể DeleteObject.

Câu 4: Sự khác nhau giữa IAM User và IAM Role?

Xem đáp án

IAM User có credentials cố định (long-term) dành cho 1 người/ứng dụng cụ thể. IAM Role có credentials tạm thời (short-term) và có thể được "assume" bởi users, services, hoặc accounts khác nhau.

Câu 5: Bạn muốn cho phép nhân viên đăng nhập 1 lần duy nhất vào nhiều AWS accounts bằng corporate credentials (Active Directory). Dùng dịch vụ nào?

Xem đáp án

IAM Identity Center (AWS SSO). Dịch vụ này cho phép Single Sign-On, tích hợp với Active Directory, và quản lý quyền truy cập tập trung cho nhiều AWS accounts.

⬅️ Chương 01: AWS Fundamentals | Chương 03: VPC & Networking ➡️

← Chương trước AWS Fundamentals Chương tiếp →VPC & Networking