AWS IAM – Định danh & Phân quyền

1. IAM là gì — User và Group

IAM (Identity and Access Management) là dịch vụ quản lý ai là ai và ai được làm gì trên tài khoản AWS của bạn. Đây là một Global service — bạn tạo user một lần và dùng được ở mọi Region (xem lại Bắt đầu với AWS).

Khi bạn mở một tài khoản AWS, AWS tạo sẵn cho bạn một root account. Đây là tài khoản có toàn quyền tuyệt đối, và nguyên tắc là không nên dùng và không được chia sẻ nó. Thay vào đó bạn tạo các IAM User cho từng con người thật trong tổ chức, và gom họ vào Group.

Hai quy tắc về Group mà đề thi hay kiểm tra:

• Group chỉ chứa user, không chứa group khác — không có chuyện group lồng group.
• User không bắt buộc phải thuộc group nào, và một user có thể thuộc nhiều group cùng lúc.

Ví dụ thực tế

Trong sơ đồ của slide: Alice, Bob, Charles nằm trong group Developers; David, Edward nằm trong group Operations; Alice và David đồng thời nằm trong group Audit Team; còn Fred không thuộc group nào cả — Fred vẫn là một IAM user hợp lệ, chỉ là quyền của anh ta phải gán trực tiếp.

2. Permission và Policy

Bản thân một user mới tạo thì không có quyền gì. Muốn cho quyền, bạn gán cho user hoặc group một policy — là một tài liệu JSON mô tả chính xác những hành động nào được phép hoặc bị từ chối.

Nguyên tắc vàng khi viết policy trên AWS là least privilege principle (nguyên tắc quyền tối thiểu): đừng cấp cho một user nhiều quyền hơn mức họ thực sự cần.

Một policy mẫu, cho phép xem thông tin EC2, Elastic Load Balancing và một số API của CloudWatch:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "elasticloadbalancing:Describe*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "cloudwatch:ListMetrics",
        "cloudwatch:GetMetricStatistics",
        "cloudwatch:Describe*"
      ],
      "Resource": "*"
    }
  ]
}

Kế thừa policy

Policy có thể gắn ở hai chỗ, và một user nhận tổng hợp của cả hai:

• Gắn vào group — mọi user trong group đó đều được thừa hưởng. Đây là cách nên dùng.
• Gắn trực tiếp vào user — gọi là inline policy.

Trong sơ đồ của slide, Fred (không thuộc group nào) được cấp quyền bằng một inline policy; còn Alice và David thuộc hai group nên nhận quyền từ cả Developers/Operations lẫn Audit Team.

3. Cấu trúc một IAM Policy

Đây là phần rất dễ ra câu hỏi “trường nào bắt buộc, trường nào tùy chọn”. Một policy gồm:

Trường	Bắt buộc?	Ý nghĩa
Version	Luôn ghi	Phiên bản ngôn ngữ policy, luôn dùng "2012-10-17"
Id	Tùy chọn	Định danh cho cả policy
Statement	Bắt buộc	Một hoặc nhiều statement riêng lẻ

Bên trong mỗi Statement lại có các trường:

• Sid (tùy chọn) — định danh cho riêng statement đó.
• Effect — statement này cho phép hay từ chối truy cập: Allow hoặc Deny.
• Principal — account/user/role mà policy này áp dụng lên.
• Action — danh sách các hành động được cho phép hoặc bị từ chối.
• Resource — danh sách tài nguyên mà các hành động đó áp dụng lên.
• Condition (tùy chọn) — điều kiện để policy này có hiệu lực.

Lưu ý khi thi

Ba trường dễ bị hỏi nhất: Version luôn là 2012-10-17 (không phải ngày hôm nay), Statement là trường bắt buộc duy nhất ở cấp ngoài, và Sid / Id / Condition đều là tùy chọn.

4. Password Policy

Mật khẩu mạnh nghĩa là tài khoản an toàn hơn — nghe đơn giản nhưng AWS cho bạn áp đặt chuyện đó bằng chính sách, không phải bằng lời nhắc nhở. Trên IAM bạn thiết lập được một password policy với các mục:

• Đặt độ dài mật khẩu tối thiểu.
• Yêu cầu các loại ký tự cụ thể: chữ in hoa, chữ thường, chữ số, ký tự không phải chữ-số (non-alphanumeric).
• Cho phép mọi IAM user tự đổi mật khẩu của mình.
• Buộc người dùng đổi mật khẩu sau một khoảng thời gian (password expiration).
• Chặn dùng lại mật khẩu cũ (prevent password re-use).

5. Multi Factor Authentication (MFA)

Người dùng trong tài khoản của bạn có thể thay đổi cấu hình hoặc xóa tài nguyên. Nghĩa là một mật khẩu bị lộ không chỉ gây rủi ro về dữ liệu, mà còn có thể phá hủy cả hệ thống. Vì vậy bạn cần bảo vệ root account và các IAM user.

MFA = mật khẩu bạn biết + thiết bị bảo mật bạn có. Lợi ích chính của MFA rất rõ ràng: nếu mật khẩu bị đánh cắp hoặc bị hack, tài khoản vẫn chưa bị chiếm — vì kẻ tấn công không có thiết bị thứ hai.

Các loại thiết bị MFA trên AWS

Loại	Ví dụ	Ghi chú
Virtual MFA device	Google Authenticator (chỉ điện thoại), Authy (chỉ điện thoại)	Authy hỗ trợ nhiều token trên cùng một thiết bị
Universal 2nd Factor (U2F) Security Key	YubiKey của Yubico (hãng thứ ba)	Hỗ trợ nhiều root user và IAM user trên cùng một security key
Hardware Key Fob MFA Device	Do Gemalto cung cấp (hãng thứ ba)	Thiết bị vật lý dạng móc khóa
Hardware Key Fob MFA Device for AWS GovCloud (US)	Do SurePassID cung cấp (hãng thứ ba)	Dành riêng cho AWS GovCloud (US)

Lưu ý khi thi

Hai chi tiết phân biệt hay được hỏi: virtual MFA device hỗ trợ nhiều token trên một thiết bị, còn U2F security key hỗ trợ nhiều user (cả root và IAM) trên một chiếc khóa. Và nhớ có một dòng thiết bị riêng dành cho AWS GovCloud (US).

6. Ba cách truy cập AWS

Để truy cập AWS, bạn có ba lựa chọn, và mỗi lựa chọn được bảo vệ bằng một kiểu credential khác nhau:

Cách truy cập	Được bảo vệ bằng
AWS Management Console	Mật khẩu + MFA
AWS Command Line Interface (CLI)	Access keys
AWS Software Developer Kit (SDK) — dùng trong code	Access keys

Về Access Keys, có mấy điểm phải nhớ:

• Access key được tạo ra qua AWS Console.
• Người dùng tự quản lý access key của mình.
• Access key là thứ bí mật, giống như mật khẩu — không được chia sẻ.
• Cách đối chiếu để dễ nhớ: Access Key ID ≈ username, Secret Access Key ≈ password.

Ví dụ (giả) về một cặp key để bạn nhận dạng được hình dáng của chúng:

Access key ID:     AKIASK4E37PV4983d6C
Secret Access Key: AZPN3zojWozWCndIjhB0Unh8239a1bzbzO5fqqkZq

Lưu ý khi thi

Đừng nhầm: Console dùng mật khẩu + MFA, còn CLI và SDK dùng access keys. Nếu đề bài nói về “truy cập theo cách lập trình” (programmatic access), đáp án luôn liên quan tới access keys chứ không phải mật khẩu.

7. AWS CLI

AWS CLI là công cụ cho bạn tương tác với các dịch vụ AWS bằng câu lệnh trong shell dòng lệnh, thay vì bấm chuột trong Console.

• Nó truy cập trực tiếp vào các public API của các dịch vụ AWS.
• Bạn có thể viết script để quản lý tài nguyên — đây là điểm mạnh lớn nhất so với Console.
• Nó là open-source, mã nguồn ở github.com/aws/aws-cli.
• Nó là phương án thay thế cho AWS Management Console.

8. AWS SDK

AWS SDK (AWS Software Development Kit) là tập các thư viện API theo từng ngôn ngữ lập trình, cho phép bạn truy cập và quản lý dịch vụ AWS bằng code, và nó được nhúng bên trong ứng dụng của bạn.

SDK được cung cấp cho ba nhóm môi trường:

• SDK cho ngôn ngữ lập trình: JavaScript, Python, PHP, .NET, Ruby, Java, Go, Node.js, C++.
• Mobile SDK: Android, iOS, …
• IoT Device SDK: Embedded C, Arduino, …

Một chi tiết vui và cũng dễ ra đề: AWS CLI được xây dựng trên AWS SDK for Python — nghĩa là CLI thực chất là một ứng dụng dùng SDK.

9. IAM Role cho các dịch vụ

Không chỉ con người mới cần quyền. Một số dịch vụ AWS cần thực hiện hành động thay mặt bạn — ví dụ một EC2 instance cần đọc file trong S3. Bạn không thể (và không nên) nhét access key của một user vào trong máy đó.

Cách làm đúng là gán quyền cho dịch vụ bằng IAM Role. Role trông giống như một “bộ quyền” mà dịch vụ được phép “đeo vào” khi cần gọi AWS. Các role phổ biến:

• EC2 Instance Roles — cho máy chủ ảo EC2.
• Lambda Function Roles — cho function Lambda.
• Roles for CloudFormation — cho CloudFormation.

Trong sơ đồ của slide: một EC2 instance (máy chủ ảo) được gắn một IAM Role, và nhờ role đó nó truy cập được vào các dịch vụ AWS khác.

Ví dụ thực tế

Ứng dụng của bạn chạy trên EC2 và cần ghi log lên một dịch vụ khác của AWS. Thay vì tạo một IAM user rồi dán access key vào file cấu hình trên máy (nơi bất kỳ ai SSH vào cũng đọc được), bạn gắn một EC2 Instance Role cho máy đó — quyền được cấp ở tầng hạ tầng, không có secret nào nằm trên đĩa.

10. Hai công cụ bảo mật của IAM

IAM có hai công cụ giúp bạn soát lại quyền hạn đã cấp, và điểm khác biệt giữa chúng là phạm vi:

Công cụ	Phạm vi	Nội dung
IAM Credentials Report	Cấp tài khoản (account-level)	Báo cáo liệt kê toàn bộ user của tài khoản và trạng thái các loại credential của họ
IAM Access Advisor	Cấp người dùng (user-level)	Cho thấy những quyền dịch vụ đã cấp cho một user và lần cuối họ truy cập các dịch vụ đó

Access Advisor đặc biệt hữu ích: nhờ biết user đã lâu không dùng tới một dịch vụ, bạn có căn cứ để chỉnh lại policy cho gọn hơn, tiến gần hơn tới nguyên tắc quyền tối thiểu.

Lưu ý khi thi

Ghi nhớ bằng phạm vi: Credentials Report = toàn bộ tài khoản (danh sách user + credential), Access Advisor = một user (quyền nào, dùng lần cuối khi nào). Đề thi hay đảo hai cái này.

11. Hướng dẫn và thực hành tốt nhất

Slide chốt lại chín nguyên tắc vận hành IAM. Đây là những câu trả lời “an toàn” cho hầu hết câu hỏi tình huống về bảo mật danh tính:

• Không dùng root account, trừ lúc thiết lập tài khoản AWS ban đầu.
• Một người thật = một AWS user, không dùng chung tài khoản.
• Gán user vào group, và gán quyền cho group thay vì cho từng user.
• Tạo một password policy mạnh.
• Dùng và bắt buộc dùng MFA.
• Tạo và dùng Role để cấp quyền cho các dịch vụ AWS.
• Dùng Access Keys cho truy cập theo cách lập trình (CLI / SDK).
• Audit quyền hạn của tài khoản bằng IAM Credentials Report và IAM Access Advisor.
• Không bao giờ chia sẻ IAM user và Access Keys.

Tóm tắt nhanh

Chủ đề	Cần nhớ
IAM	Global service; user tạo một lần dùng được ở mọi Region
Root account	Được tạo sẵn; không dùng ngoài lúc thiết lập account, không chia sẻ
Users	Ứng với một con người thật, có mật khẩu để vào AWS Console
Groups	Chỉ chứa user (không chứa group); một user có thể thuộc nhiều group hoặc không thuộc group nào
Policies	Tài liệu JSON mô tả quyền, gán cho user hoặc group; áp dụng least privilege
Trường của policy	Version (luôn 2012-10-17), Id, Statement; trong mỗi statement có Sid, Effect, Principal, Action, Resource, Condition
Roles	Quyền cho EC2 instance và các dịch vụ AWS — không nhét access key lên máy
Security	MFA + Password Policy; MFA = mật khẩu bạn biết + thiết bị bạn có
Thiết bị MFA	Virtual (Google Authenticator, Authy), U2F key (YubiKey), hardware key fob (Gemalto; SurePassID cho GovCloud US)
AWS CLI	Quản lý dịch vụ AWS bằng dòng lệnh; open-source, xây trên AWS SDK for Python
AWS SDK	Quản lý dịch vụ AWS bằng ngôn ngữ lập trình, nhúng trong ứng dụng
Access Keys	Truy cập AWS qua CLI hoặc SDK; Access Key ID ≈ username, Secret Access Key ≈ password
Audit	IAM Credentials Report (cấp tài khoản) và IAM Access Advisor (cấp user)