IAM & AWS CLI

IAM là gì & tài khoản Root

IAM = Identity and Access Management. Đây là nơi bạn tạo ra ai được vào tài khoản AWS và họ được làm gì. Hai câu hỏi đó có tên riêng trong bảo mật:

• Authentication (xác thực) — anh là ai? (mật khẩu, access key, MFA)
• Authorization (phân quyền) — anh được phép làm gì? (policies)

IAM là global service: user, group, role, policy bạn tạo ra dùng chung cho mọi region. Không có chuyện "IAM user ở Singapore" — tạo một lần, dùng khắp nơi. Đây là điểm đề thi rất hay hỏi dưới dạng "dịch vụ nào là global?".

Tài khoản Root — thứ nguy hiểm nhất trong tài khoản

Root account là email bạn dùng để đăng ký AWS. Nó có toàn quyền tuyệt đối, không policy nào chặn được nó, và không thể bị giới hạn. Nếu lộ root là mất trắng tài khoản.

Users, Groups

User = một người thật (Alice, Bob) hoặc một ứng dụng cần credential riêng. Group = một túi chứa user, dùng để cấp quyền theo vai trò (Developers, Operations, Audit).

Tại sao dùng group? Vì gắn policy vào 20 user riêng lẻ thì khi đổi quyền bạn phải sửa 20 chỗ. Gắn vào group thì sửa một chỗ.

Ba quy tắc bắt buộc thuộc lòng

Policies & cấu trúc JSON

Policy là một tài liệu JSON mô tả quyền. Không có policy = không có quyền gì (nguyên tắc implicit deny: mặc định mọi thứ bị từ chối cho đến khi được cho phép tường minh).

Nguyên tắc least privilege

Chỉ cấp đúng quyền tối thiểu để làm việc, không hơn. Đề thi luôn chọn phương án hẹp nhất mà vẫn đủ dùng. Nếu có hai đáp án đều "chạy được", chọn cái ít quyền hơn.

Cấu trúc một policy

{
  "Version": "2012-10-17",        ← luôn là ngày này, không phải ngày hôm nay
  "Id": "S3-Account-Permissions", ← tùy chọn, chỉ để đặt tên
  "Statement": [
    {
      "Sid": "1",                             ← tùy chọn, id của statement
      "Effect": "Allow",                      ← Allow hoặc Deny
      "Principal": {                          ← AI được áp dụng
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": [                             ← LÀM GÌ (dạng service:Operation)
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": ["arn:aws:s3:::mybucket/*"], ← TRÊN TÀI NGUYÊN NÀO
      "Condition": {                           ← tùy chọn: KHI NÀO
        "IpAddress": {"aws:SourceIp": "203.0.113.0/24"}
      }
    }
  ]
}

Phân loại policy

Điểm khác biệt để nhận diện: resource-based policy bắt buộc có Principal (vì phải nói rõ ai được truy cập), còn identity-based thì không cần — bản thân việc gắn vào user đã là principal rồi.

Ngoài ra còn Inline policy trên group và khái niệm kế thừa: user nhận toàn bộ quyền từ mọi group nó thuộc, cộng với policy gắn trực tiếp lên nó.

Cách AWS đánh giá quyền

Chương 4 của Maarek chỉ nói lướt phần này, nhưng đề thi dùng nó liên tục nên bạn nắm sớm sẽ lợi. Khi một request đến, AWS xử theo thứ tự:

1. Mặc định là Deny (implicit deny) — không ai có quyền gì cả.
2. Tìm thấy Allow tường minh ở bất kỳ policy nào → cho phép.
3. Tìm thấy Deny tường minh ở bất kỳ policy nào → từ chối, và không gì lật ngược được.

Quyền của một user = hợp (union) của: policy gắn trực tiếp + policy của mọi group nó thuộc. Không có chuyện "group này ưu tiên hơn group kia" — tất cả cộng dồn, rồi mới áp quy tắc Deny thắng.

Công cụ để thử trước khi áp dụng: IAM Policy Simulator — nhập user + action + resource, nó trả lời cho phép hay không, và policy nào quyết định.

Password Policy & MFA

Password Policy

Mật khẩu mạnh là lớp phòng thủ đầu tiên. Trong IAM, bạn cấu hình được:

• Độ dài tối thiểu
• Bắt buộc loại ký tự: chữ hoa, chữ thường, số, ký tự đặc biệt
• Cho phép/không cho phép user tự đổi mật khẩu
• Bắt đổi mật khẩu sau N ngày (password expiration)
• Cấm dùng lại mật khẩu cũ (prevent password reuse)

MFA — Multi Factor Authentication

Nguyên lý: password (thứ bạn biết) + security device (thứ bạn sở hữu). Kẻ tấn công có mật khẩu vẫn không vào được vì không cầm thiết bị trong tay.

Bốn loại thiết bị MFA — bảng vàng của chương này

Console, CLI, SDK & CloudShell

Có đúng ba cách truy cập AWS, mỗi cách dùng credential khác nhau:

Access Keys

Access key gồm hai phần:

• Access Key ID ~ vai trò như username (dạng AKIA...)
• Secret Access Key ~ vai trò như password

CLI vs SDK — phân biệt cho chắc

Cả hai đều gọi cùng một bộ API công khai của AWS. Console cũng vậy — nó chỉ là giao diện web bọc quanh API đó.

Vài lệnh CLI nên quen tay

aws configure                  # nhập Access Key, Secret, region, output format
aws configure --profile work   # cấu hình nhiều profile song song
aws iam list-users             # kiểm tra kết nối
aws sts get-caller-identity    # "tôi đang là ai?" — cực hữu ích khi debug quyền
aws s3 ls --region ap-southeast-1

AWS CloudShell

Terminal chạy ngay trong trình duyệt, ngay trong Console. Điểm hay: nó tự dùng quyền của user đang đăng nhập — không cần cấu hình access key, không cần aws configure.

• File bạn tạo trong CloudShell được lưu lại giữa các phiên (thư mục home có dung lượng riêng).
• Upload/download file được qua menu Actions.
• ⚠️ Không có ở tất cả region — điểm này đề hay hỏi.

IAM Roles — phần ra thi nặng nhất chương

Vấn đề: một EC2 instance cần đọc file từ S3. Nó không phải người, không có username/password. Vậy cấp quyền cho nó kiểu gì?

Câu trả lời: IAM Role. Role giống hệt user (cũng có policy gắn vào), nhưng thay vì dành cho người, nó dành cho dịch vụ AWS đảm nhận (assume).

Vì sao Role an toàn hơn Access Key

• Credential do role cấp là tạm thời và tự động xoay vòng — không có secret cố định nằm trên đĩa để bị lộ.
• Muốn thu hồi quyền: sửa policy của role, có hiệu lực ngay, không phải đi tìm và xóa key ở từng máy.
• Cùng một role dùng cho hàng trăm instance trong Auto Scaling Group.

Các role thường gặp

IAM Security Tools

Đúng hai công cụ, và đề thi thích ra câu bắt phân biệt chúng.

Shared Responsibility Model cho IAM

AWS lo bảo mật CỦA cloud, bạn lo bảo mật TRONG cloud. Áp vào IAM cụ thể:

IAM Best Practices

1. Không dùng root account trừ lúc setup ban đầu.
2. Một user vật lý = một IAM user. Không dùng chung tài khoản.
3. Gán quyền qua group, không rải trực tiếp lên user.
4. Đặt password policy mạnh.
5. Bật MFA — root và mọi user quan trọng.
6. Ứng dụng chạy trên AWS → IAM Role, tuyệt đối không access key.
7. Cần dùng access key (ngoài AWS) → cấp quyền hẹp, xoay vòng định kỳ.
8. Kiểm tra định kỳ bằng Credentials Report và Access Advisor.
9. Least privilege là mặc định trong mọi quyết định.
10. Không chia sẻ IAM user hay access key với bất kỳ ai.

Map từ khóa đề thi

Cheat sheet 60 giây

• IAM là global, miễn phí, nền tảng của mọi dịch vụ khác.
• Root: chỉ setup, bật MFA, rồi cất đi. Không tạo access key cho root.
• Group chứa user, không chứa group. User thuộc 0–n group.
• Policy JSON: Effect, Principal, Action, Resource (+ Sid, Condition tùy chọn), Version 2012-10-17.
• Mặc định Deny → Allow tường minh mới có quyền → Deny tường minh thắng tất cả.
• Resource-based policy bắt buộc có Principal.
• MFA: Virtual (Authy) · U2F (YubiKey) · Key fob (Gemalto) · GovCloud (SurePassID).
• Access key: Secret chỉ hiện một lần; mất thì tạo cặp mới.
• CLI xây trên boto3 (Python SDK); CloudShell không có ở mọi region.
• Dịch vụ AWS cần quyền → Role. Ngoài AWS → access key.
• Credentials Report = account, credential. Access Advisor = user, quyền đã dùng.