AWS IAM – Danh tính & Truy cập

1. IAM là gì? Users & Groups

IAM (Identity and Access Management) là dịch vụ của AWS dùng để quản lý danh tính và quyền truy cập vào các tài nguyên trên tài khoản AWS của bạn. Đây là một dịch vụ global — nghĩa là nó không gắn với một Region cụ thể nào, cấu hình IAM của bạn áp dụng trên toàn bộ tài khoản, ở mọi Region.

Khi bạn tạo một tài khoản AWS mới, AWS sẽ tự động tạo cho bạn một Root Account (tài khoản gốc). Đây là tài khoản có toàn quyền tuyệt đối trên mọi tài nguyên và cấu hình của tài khoản AWS đó — chính vì quyền lực quá lớn này, root account không nên được sử dụng cho công việc hàng ngày, và tuyệt đối không nên chia sẻ cho bất kỳ ai, kể cả đồng nghiệp trong nhóm.

Thay vào đó, IAM cho phép bạn tạo ra các Users (người dùng) — đại diện cho những người cụ thể trong tổ chức của bạn (ví dụ từng nhân viên). Các user này có thể được tập hợp lại thành Groups (nhóm) để dễ quản lý quyền hạn theo phòng ban hoặc vai trò công việc.

Một Group chỉ có thể chứa các User, không thể chứa Group khác bên trong nó (không có nhóm lồng nhóm).
Một User không bắt buộc phải thuộc về bất kỳ Group nào.
Một User có thể thuộc về nhiều Group khác nhau cùng lúc.

2. Permissions & Least Privilege

Việc tạo User và Group chỉ là bước xác định “ai là ai” — còn “ai được làm gì” thì do Policies (chính sách quyền hạn) quyết định. Policy là các văn bản định dạng JSON được gắn (attach) vào User hoặc Group, mô tả chi tiết quyền hạn của người dùng đó: được phép làm gì, với tài nguyên nào.

Một nguyên tắc vàng khi thiết lập quyền hạn trong IAM (và trong bảo mật nói chung) là Least Privilege Principle (nguyên tắc quyền hạn tối thiểu): không bao giờ cấp cho user nhiều quyền hơn mức họ thực sự cần để hoàn thành công việc. Việc này giúp giảm thiểu rủi ro nếu tài khoản đó bị lộ hoặc bị lạm dụng.

Dưới đây là một ví dụ policy JSON điển hình, cấp quyền chỉ-đọc (read-only, thông qua các action bắt đầu bằng “Describe” hoặc “List”) đối với EC2, Elastic Load Balancing và CloudWatch:

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

Với policy này, user được phép xem thông tin (không được sửa, xóa) về các EC2 instance, load balancer, và các chỉ số giám sát trên CloudWatch — trên toàn bộ tài nguyên (“Resource”: “*”) trong tài khoản.

3. Cấu trúc IAM Policy

Mọi IAM Policy đều theo một cấu trúc chuẩn, gồm các thành phần sau:

Version: phiên bản của ngôn ngữ policy (policy language) đang dùng — hầu như luôn luôn là chuỗi cố định "2012-10-17" (đây là ngày phiên bản ngôn ngữ policy hiện tại được phát hành, không phải ngày bạn tạo policy).
Id: một định danh (identifier) tùy chọn cho policy — không bắt buộc phải có.
Statement: một hoặc nhiều “câu lệnh” quyền hạn — đây là phần bắt buộc và là “trái tim” của policy. Mỗi Statement bao gồm:
- Sid (Statement ID): định danh tùy chọn cho từng statement riêng lẻ.
- Effect: giá trị là Allow (cho phép) hoặc Deny (từ chối).
- Principal: tài khoản, user hoặc role mà policy này áp dụng cho (thường dùng trong resource-based policy).
- Action: danh sách các hành động (API action) được cho phép hoặc bị từ chối, ví dụ ec2:StartInstances, s3:GetObject.
- Resource: danh sách các tài nguyên mà các Action ở trên áp dụng lên (có thể là một ARN cụ thể, hoặc * nghĩa là mọi tài nguyên).
- Condition (tùy chọn): điều kiện bổ sung để policy có hiệu lực, ví dụ chỉ cho phép truy cập từ một địa chỉ IP nhất định, hoặc trong một khoảng thời gian nhất định.

4. Kế thừa Policy & Inline Policy

Khi một Policy được gắn (attach) vào một Group, mọi User thuộc Group đó sẽ tự động kế thừa (inherit) toàn bộ quyền hạn trong policy ấy. Đây là cách quản lý quyền hạn hiệu quả nhất ở quy mô lớn — bạn không cần cấp quyền cho từng người một, chỉ cần gắn policy vào group, rồi thêm/xóa user khỏi group khi cần.

Tuy nhiên, đôi khi có những trường hợp đặc biệt: một user cần một quyền hạn riêng biệt mà không muốn (hoặc không thể) tạo hẳn một group mới cho việc đó. Trong trường hợp này, AWS cho phép gắn một Inline Policy (policy gắn trực tiếp) ngay vào một User cụ thể, tách biệt hoàn toàn với các policy được kế thừa từ group.

5. IAM Password Policy

Một trong những nguyên tắc bảo mật cơ bản nhất: mật khẩu mạnh đồng nghĩa với an ninh cao hơn. IAM cho phép quản trị viên tài khoản thiết lập một Password Policy áp dụng cho toàn bộ IAM User trong tài khoản, với các tùy chọn:

Đặt độ dài tối thiểu cho mật khẩu (minimum password length).
Yêu cầu các loại ký tự cụ thể phải có trong mật khẩu: chữ hoa, chữ thường, số, ký tự không phải chữ-số (non-alphanumeric).
Cho phép (hoặc không cho phép) IAM user tự đổi mật khẩu của chính họ.
Yêu cầu đổi mật khẩu sau một khoảng thời gian nhất định (password expiration).
Ngăn không cho tái sử dụng lại các mật khẩu cũ đã dùng trước đó (prevent password re-use).

Việc thiết lập một password policy chặt chẽ là bước đầu tiên trong việc bảo vệ tài khoản khỏi các cuộc tấn công dò mật khẩu (brute-force) hay các mật khẩu yếu dễ bị đoán.

6. Multi-Factor Auth (MFA)

Vì các User có quyền truy cập và có thể thay đổi cấu hình hoặc xóa tài nguyên, việc bảo vệ Root Account và các IAM User là vô cùng quan trọng — và công cụ mạnh nhất để làm điều đó là MFA (xác thực đa yếu tố).

MFA hoạt động theo nguyên tắc kết hợp hai yếu tố: mật khẩu mà bạn biết (password you know) + thiết bị bảo mật mà bạn sở hữu (security device you own). Lợi ích chính của MFA: nếu mật khẩu của bạn bị đánh cắp hoặc bị hack, kẻ tấn công vẫn KHÔNG thể đăng nhập vào tài khoản của bạn nếu không có thêm thiết bị vật lý thứ hai đó — tài khoản của bạn vẫn được an toàn.

AWS hỗ trợ nhiều loại thiết bị MFA khác nhau:

Loại thiết bị MFA	Mô tả
Virtual MFA device	Ứng dụng chạy trên điện thoại, ví dụ Google Authenticator (chỉ hỗ trợ trên điện thoại) hoặc Authy (chỉ hỗ trợ trên điện thoại, nhưng hỗ trợ nhiều token trên cùng một thiết bị).
Universal 2nd Factor (U2F) Security Key	Thiết bị khóa bảo mật vật lý cắm USB, ví dụ YubiKey của hãng thứ ba Yubico — hỗ trợ nhiều root/IAM user cùng dùng chung một khóa bảo mật vật lý.
Hardware Key Fob MFA Device	Thiết bị phần cứng nhỏ dạng móc khóa, cung cấp bởi hãng thứ ba Gemalto.
Hardware Key Fob MFA Device cho AWS GovCloud (US)	Dành riêng cho khu vực GovCloud (Hoa Kỳ), cung cấp bởi hãng thứ ba SurePassID.

7. Các cách truy cập AWS

Có ba cách chính để người dùng tương tác và truy cập vào các dịch vụ AWS:

AWS Management Console: giao diện web trực quan, được bảo vệ bằng mật khẩu (password) kết hợp MFA.
AWS CLI (Command Line Interface): công cụ dòng lệnh, được bảo vệ bằng Access Keys.
AWS SDK: dùng để viết code (chương trình) tương tác với AWS, cũng được bảo vệ bằng Access Keys.

Access Keys (khóa truy cập) được tạo ra thông qua AWS Console, và chính người dùng đó phải tự quản lý (bảo mật) các access key của mình — AWS không lưu lại bản sao secret key sau khi tạo. Access Key thực chất gồm hai phần, tương tự như một cặp tên đăng nhập/mật khẩu:

Access Key ID: tương đương với “tên người dùng” (username) — ví dụ dạng AKIAIOSFODNN7EXAMPLE.
Secret Access Key: tương đương với “mật khẩu” (password) — ví dụ dạng wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

Access Key có tính bí mật giống như một mật khẩu thực sự — tuyệt đối không được chia sẻ access key của bạn cho bất kỳ ai, và không nên nhúng (hardcode) chúng trực tiếp vào mã nguồn công khai (ví dụ đẩy nhầm lên GitHub công khai — đây là một trong những nguyên nhân rò rỉ bảo mật phổ biến nhất trong thực tế).

8. AWS CLI là gì?

AWS CLI (Command Line Interface) là một công cụ cho phép bạn tương tác trực tiếp với các dịch vụ AWS bằng các lệnh gõ trong cửa sổ dòng lệnh (command-line shell), thay vì phải click chuột qua giao diện web của Console.

Cho phép truy cập trực tiếp vào các API công khai (public APIs) của mọi dịch vụ AWS.
Cho phép bạn viết các script để tự động hóa việc quản lý tài nguyên (ví dụ: một script tự động tạo hàng loạt EC2 instance, hoặc tự động backup S3 bucket theo lịch).
Là một công cụ mã nguồn mở (open-source), có repository công khai tại github.com/aws/aws-cli.
Là một lựa chọn thay thế cho AWS Management Console — nhiều kỹ sư vận hành thích dùng CLI vì tốc độ và khả năng tự động hóa.

9. AWS SDK là gì?

AWS SDK (Software Development Kit) là tập hợp các thư viện dành riêng cho từng ngôn ngữ lập trình (language-specific APIs), giúp lập trình viên truy cập và quản lý các dịch vụ AWS ngay trong mã nguồn ứng dụng của mình — tức là gọi AWS trực tiếp từ code, không cần thoát ra ngoài dùng dòng lệnh riêng.

AWS SDK hỗ trợ rất nhiều nền tảng khác nhau:

SDK cho các ngôn ngữ phổ biến: JavaScript, Python, PHP, .NET, Ruby, Java, Go, Node.js, C++.
Mobile SDK: cho Android và iOS.
IoT Device SDK: cho Embedded C, Arduino — dùng cho các thiết bị IoT nhỏ, hạn chế tài nguyên.

Một điều thú vị (và giúp bạn nhớ mối liên hệ giữa CLI và SDK): bản thân AWS CLI được xây dựng dựa trên AWS SDK cho Python (thư viện boto3) — nghĩa là CLI thực chất là một “lớp vỏ” dòng lệnh được viết trên nền SDK.

10. IAM Roles

Không chỉ con người (User) mới cần quyền hạn — nhiều dịch vụ AWS cũng cần thực hiện các hành động thay mặt cho bạn (perform actions on your behalf). Ví dụ, một EC2 instance có thể cần đọc dữ liệu từ một S3 bucket, hoặc một Lambda function cần ghi log vào CloudWatch. Trong những trường hợp này, bạn không nên gắn Access Key của một User thật vào dịch vụ — thay vào đó, IAM cung cấp cơ chế IAM Roles.

IAM Role tương tự như một “bộ quyền hạn tạm thời” mà một dịch vụ AWS có thể “đóng vai” (assume) để thực hiện công việc, không gắn với bất kỳ mật khẩu hay access key cố định nào — an toàn hơn nhiều so với việc nhúng access key vào bên trong một dịch vụ.

Một số loại Role phổ biến thường gặp:

EC2 Instance Roles: gắn vào một EC2 instance để nó có quyền gọi các dịch vụ AWS khác (ví dụ đọc/viết S3, gọi DynamoDB…) mà không cần lưu access key trên máy chủ.
Lambda Function Roles: gắn vào một Lambda function, cấp quyền cho function đó tương tác với các dịch vụ AWS khác khi nó chạy.
Roles for CloudFormation: cấp quyền cho CloudFormation để nó có thể tự động tạo/xóa/cập nhật các tài nguyên AWS khi triển khai một stack.

11. IAM Security Tools

IAM cung cấp hai công cụ quan trọng giúp bạn kiểm tra (audit) tình trạng bảo mật của tài khoản:

IAM Credentials Report (báo cáo ở cấp tài khoản – account-level): đây là một báo cáo liệt kê tất cả các User trong tài khoản AWS của bạn, cùng với trạng thái của các loại thông tin xác thực (credentials) của từng người — ví dụ mật khẩu có được thiết lập không, có đang dùng MFA không, access key đã tạo bao lâu, lần cuối xoay (rotate) access key là khi nào… Đây là công cụ để rà soát toàn bộ tài khoản một lượt.
IAM Access Advisor (báo cáo ở cấp người dùng – user-level): công cụ này cho biết những quyền dịch vụ (service permissions) đã được cấp cho một User cụ thể, và quan trọng hơn — lần cuối các quyền đó thực sự được sử dụng là khi nào. Nhờ đó, bạn có thể phát hiện những quyền đã cấp nhưng không hề dùng đến, và thu hẹp lại (revise) policy theo đúng nguyên tắc quyền hạn tối thiểu.

12. Best Practices cho IAM

IAM Guidelines & Best Practices

Không sử dụng Root Account ngoại trừ lúc thiết lập ban đầu tài khoản AWS.
Một người dùng thật = một IAM User (One physical user = One AWS user) — không dùng chung một tài khoản IAM cho nhiều người.
Xếp các User vào các Group, và cấp quyền hạn ở cấp Group (chứ không cấp riêng lẻ cho từng user) để dễ quản lý.
Thiết lập một chính sách mật khẩu mạnh (strong password policy).
Kích hoạt và bắt buộc sử dụng MFA cho mọi tài khoản.
Tạo và sử dụng IAM Roles để cấp quyền cho các dịch vụ AWS, thay vì dùng access key cố định.
Chỉ dùng Access Keys cho mục đích truy cập programmatic (qua CLI/SDK), không dùng cho việc khác.
Thường xuyên rà soát quyền hạn bằng IAM Credentials Report và IAM Access Advisor.
Không bao giờ chia sẻ IAM User hay Access Key cho người khác.

Trách nhiệm chung với IAM

Cũng giống như mô hình trách nhiệm chung tổng quát đã học ở Chương 1, IAM cũng có sự phân chia trách nhiệm rõ ràng giữa AWS và khách hàng:

Trách nhiệm của AWS	Trách nhiệm của khách hàng
Bảo vệ hạ tầng (an ninh mạng toàn cầu — global network security)	Quản lý và giám sát User, Group, Role, Policy
Cấu hình và phân tích lỗ hổng của dịch vụ IAM	Kích hoạt MFA trên mọi tài khoản
Xác nhận tuân thủ (compliance validation) của dịch vụ	Xoay (rotate) toàn bộ các key thường xuyên
—	Sử dụng các công cụ IAM để áp dụng đúng quyền hạn phù hợp
—	Phân tích các mẫu truy cập (access patterns) & rà soát lại quyền hạn định kỳ

Tổng kết chương

Users: gắn với một người dùng thật cụ thể, dùng mật khẩu để đăng nhập AWS Console.
Groups: chỉ chứa Users (không chứa group khác), giúp cấp quyền hàng loạt.
Policies: văn bản JSON quy định quyền hạn, gồm Version + Statement (Sid, Effect, Principal, Action, Resource, Condition); gắn vào User/Group qua kế thừa từ group hoặc qua inline policy.
Roles: cấp quyền tạm thời cho các EC2 instance hoặc dịch vụ AWS khác (Lambda, CloudFormation…), không dùng access key cố định.
Bảo mật: kết hợp MFA (password bạn biết + thiết bị bạn có) và Password Policy chặt chẽ.
AWS CLI: quản lý AWS bằng dòng lệnh, mã nguồn mở, xây trên AWS SDK.
AWS SDK: quản lý AWS bằng một ngôn ngữ lập trình cụ thể, ngay trong code ứng dụng.
Access Keys: dùng để truy cập AWS qua CLI hoặc SDK, gồm Access Key ID (username) + Secret Access Key (password), tuyệt đối không chia sẻ.
Audit (kiểm tra bảo mật): IAM Credentials Report (toàn tài khoản) và IAM Access Advisor (theo từng user).
Nguyên tắc cốt lõi: least privilege, không dùng root account, một người = một user, luôn bật MFA.