1. Dịch vụ AWS Identity and Access Management (IAM)

IAM là một dịch vụ toàn cầu (Global Service) của AWS, cho phép bạn quản lý quyền truy cập của người dùng và các thực thể AWS khác (như ứng dụng, dịch vụ) vào tài nguyên AWS một cách an toàn.

💡 Tóm tắt đơn giản: IAM là trung tâm kiểm soát an ninh và phân quyền của bạn trên AWS. Nó giúp bạn xác định ai được phép làm gì và với tài nguyên nào.

1.1. Các Thực thể Chính trong IAM

Thực thể	Định nghĩa	Trường hợp sử dụng
Users (Người dùng)	Đại diện cho một cá nhân hoặc một ứng dụng cần tương tác với AWS (ví dụ: một kỹ sư DevOps, một nhà phát triển).	Cung cấp thông tin đăng nhập và quyền cụ thể cho một người dùng để truy cập console hoặc API.
Groups (Nhóm)	Một tập hợp các Users IAM. Bạn gán quyền (Policies) cho Group, và tất cả Users trong Group sẽ thừa hưởng những quyền đó.	Quản lý quyền truy cập cho nhiều người dùng có vai trò tương tự một cách dễ dàng (ví dụ: Nhóm “Developers” hoặc “ReadOnly”).
Roles (Vai trò)	Một danh tính có thể được đảm nhận bởi các dịch vụ AWS (ví dụ: EC2, Lambda) hoặc người dùng bên ngoài (ví dụ: thông qua liên kết danh tính). Role không có thông tin đăng nhập vĩnh viễn (mật khẩu/Access Key) mà sử dụng quyền tạm thời.	Cho phép một dịch vụ AWS (ví dụ: một máy chủ EC2) truy cập an toàn vào một dịch vụ AWS khác (ví dụ: S3) mà không cần nhúng Access Key vào code.
Policies (Chính sách)	Một tài liệu JSON định nghĩa chi tiết quyền hạn (cho phép/từ chối) mà một User, Group, hoặc Role có.	Xác định chính xác quyền: Allow/Deny hành động s3:GetObject trên tài nguyên arn:aws:s3:::my-bucket/*.

1.2. Tài khoản Root (Root Account) – Chìa Khóa Tổng

Tài khoản Root Account là tài khoản được tạo bằng địa chỉ email khi bạn lần đầu tiên đăng ký AWS.

• Quyền lực tuyệt đối: Tài khoản Root có toàn quyền (Superuser Access) đối với tất cả các dịch vụ và tài nguyên trong tài khoản AWS của bạn, bao gồm cả các hành động liên quan đến thanh toán và thay đổi cài đặt tài khoản cốt lõi mà IAM Users không thể thực hiện được.
• Nguy cơ bảo mật: Do có quyền lực tối thượng, việc sử dụng Root Account cho các tác vụ hàng ngày là một rủi ro bảo mật lớn nhất. Nếu thông tin đăng nhập Root bị lộ, toàn bộ tài khoản AWS của bạn có thể bị kiểm soát.

Các Bước Bắt Buộc để Bảo Mật Root Account:

1. Sử dụng Mạnh mẽ IAM Users:
   • Không bao giờ sử dụng Root Account cho các tác vụ hàng ngày.
   • Tạo một IAM User riêng cho mỗi cá nhân cần quyền truy cập.
   • Tạo một Admin Group và gán Policy AdministratorAccess cho nhóm này.
   • Thêm User cá nhân vào Admin Group.
2. Kích hoạt MFA:
   • Bắt buộc kích hoạt Multi-Factor Authentication (MFA) trên Root Account. Việc này thêm một lớp bảo mật yêu cầu mã từ thiết bị vật lý hoặc ứng dụng MFA của bạn.
3. Bảo mật Thông tin Đăng nhập:
   • Lưu trữ mật khẩu Root Account ở nơi cực kỳ an toàn (ví dụ: trình quản lý mật khẩu).
   • Xóa các Access Key của Root Account (nếu có) sau khi bạn đã thiết lập User/Group quản trị.

2. Tài liệu Chính sách IAM (IAM Policy Documents)

Tài liệu Chính sách IAM là cơ chế cốt lõi trong AWS để kiểm soát quyền truy cập. Chúng được sử dụng để xác định ai có thể thực hiện hành động nào trên tài nguyên nào. Các chính sách này được viết dưới dạng tài liệu JSON theo một cấu trúc nghiêm ngặt.

2.1. Cấu trúc Cơ bản của IAM Policy

Một tài liệu chính sách điển hình bao gồm các thành phần sau:

• Version:
  • Ý nghĩa: Chỉ định phiên bản ngôn ngữ của chính sách.
  • Giá trị tiêu chuẩn: Hầu như luôn là “2012-10-17”, đây là phiên bản cú pháp chính sách mới nhất và ổn định.
• Statement:
  • Ý nghĩa: Một danh sách (mảng) các quy tắc hoặc khối quyền. Mỗi đối tượng trong mảng này xác định một bộ quyền cụ thể.
• Các Trường trong Khối Statement:
  • Effect:
    • Ý nghĩa: Kết quả của quy tắc.
    • Giá trị:
      • “Allow”: Cho phép hành động được chỉ định.
      • “Deny”: Từ chối hành động được chỉ định.
  • Action:
    • Ý nghĩa: Hành động cụ thể mà quyền này cho phép hoặc từ chối.
    • Ví dụ: “s3:ListBucket”, “ec2:StartInstances”.
    • Ký tự đại diện: “*” có nghĩa là tất cả các hành động trong dịch vụ (ví dụ: “s3:*”) hoặc trên tất cả các dịch vụ (ví dụ: “*”).
  • Resource:
    • Ý nghĩa: Tài nguyên AWS mà hành động này được áp dụng.
    • Ví dụ: Một Amazon Resource Name (ARN) cụ thể, như “arn:aws:s3:::my-bucket/*”.
    • Ký tự đại diện: “*” có nghĩa là tất cả các tài nguyên trong tài khoản (được sử dụng cẩn thận!).

2.2. Ví dụ Chính sách Đơn giản

{

  “Version“: “2012-10-17”,

  “Statement“: [

    {

      “Effect“: “Allow”,

      “Action“: “*”,

      “Resource“: “*”

    }

  ]

}

Cảnh báo: Chính sách trên cấp quyền toàn bộ quyền quản trị trên tất cả tài nguyên trong tài khoản. Chỉ nên dùng cho mục đích học tập hoặc trong trường hợp rất đặc biệt và cần hạn chế tối đa.

2.3. Nguyên tắc Đánh giá Chính sách (Deny Luôn Ưu Tiên)

• Từ chối Tường minh (Explicit Deny) luôn ghi đè Cho phép Tường minh (Explicit Allow).
• Nếu có bất kỳ chính sách nào áp dụng cho Người dùng/Vai trò/Nhóm chứa một Effect: “Deny” cho một hành động, thì người dùng đó sẽ bị từ chối hành động đó, ngay cả khi có chính sách khác chứa Effect: “Allow” cho hành động tương tự.
• Mặc định là Từ chối (Implicit Deny). Nếu không có chính sách nào cấp quyền truy cập (Allow), quyền truy cập sẽ bị từ chối.

2.4. Nơi Chính sách được Gán (IAM Entities)

Chính sách được đính kèm vào các thực thể IAM sau:

• User (Người dùng):
  • Đại diện cho một người hoặc ứng dụng cụ thể.
  • Sử dụng: Chỉ gán trực tiếp cho người dùng khi cần quyền riêng biệt.
• Group (Nhóm):
  • Một tập hợp Người dùng IAM.
  • Sử dụng: Thực hành tốt nhất (Best Practice). Gán chính sách cho Nhóm và sau đó thêm Người dùng vào Nhóm đó. Điều này đơn giản hóa việc quản lý quyền khi nhóm người dùng có cùng vai trò (ví dụ: Developers, Auditors).
• Role (Vai trò):
  • Một danh tính IAM có tập hợp quyền cụ thể.
  • Sử dụng: Cung cấp quyền tạm thời cho:
    • Các dịch vụ AWS (ví dụ: EC2 Role cho phép instance EC2 truy cập S3).
    • Người dùng trong tài khoản khác hoặc danh tính bên ngoài (External Identities).

2.5. Phân loại Chính sách

• AWS Managed Policies:
  • Được tạo và quản lý bởi AWS (có biểu tượng AWS màu cam trên Console).
  • Chúng rất tiện lợi, nhưng không thể chỉnh sửa.
  • Ví dụ: AmazonS3ReadOnlyAccess.
• Customer Managed Policies:
  • Chính sách tùy chỉnh do bạn tự tạo và quản lý để phù hợp với nhu cầu cụ thể của tổ chức.
• Inline Policies:
  • Các chính sách được đính kèm trực tiếp vào một User, Group, hoặc Role. Chúng được xóa khi thực thể đó bị xóa.

Lưu ý Quan trọng: IAM là Dịch vụ Toàn cầu

• IAM là một dịch vụ toàn cầu (Global Service) của AWS.
• Các IAM User, Group, và Role được định nghĩa ở cấp độ tài khoản AWS và không bị giới hạn bởi bất kỳ Vùng (Region) cụ thể nào.

3. Quản Lý Danh Tính và Truy Cập (IAM) trong AWS

AWS IAM là một dịch vụ cốt lõi, toàn cầu cho phép bạn quản lý quyền truy cập một cách an toàn vào các tài nguyên AWS. IAM kiểm soát xác thực (Authentication) – Bạn là ai? và ủy quyền (Authorization) – Bạn được phép làm gì?

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

Thành phần	Định nghĩa	Trường hợp sử dụng	Mẹo quan trọng
Users (Người dùng)	Đại diện cho một cá nhân vật lý hoặc một ứng dụng cần truy cập. Mỗi user có thông tin xác thực riêng (tên đăng nhập/mật khẩu, Access Keys).	Đăng nhập AWS Management Console, truy cập AWS qua CLI/SDK.	Không chia sẻ Users. Bật MFA cho tất cả Users.
Groups (Nhóm)	Một tập hợp các Users chia sẻ cùng một tập hợp các quyền.	Quản lý quyền cho các vai trò công việc chung (ví dụ: Developers, Auditors, Admins).	Thực tiễn Tốt nhất: Gán Policies cho Groups, không phải Users riêng lẻ.
Roles (Vai trò)	Một tập hợp các quyền được ủy thác cho các thực thể mà không có thông tin đăng nhập vĩnh viễn (temporary credentials).	1. Dịch vụ AWS: Cho phép một dịch vụ (ví dụ: EC2, Lambda) truy cập tài nguyên của dịch vụ khác (ví dụ: S3). 2. Người dùng bên ngoài: Cho phép người dùng ngoài AWS hoặc các ứng dụng bên ngoài truy cập tài khoản AWS của bạn (Cross-Account Access).	Roles được assume (đảm nhận) bởi thực thể, cung cấp quyền tạm thời, là phương thức an toàn nhất để cấp quyền cho các dịch vụ.
Identity Provider (IdP)	Cho phép người dùng đăng nhập vào AWS bằng danh tính đã tồn tại của họ từ một dịch vụ bên ngoài (còn gọi là SSO – Single Sign-On).	1. SAML 2.0: Tích hợp với Active Directory, Okta, OneLogin (thường dùng trong doanh nghiệp). 2. OpenID Connect: Tích hợp với Google, Facebook, v.v.	Giảm gánh nặng quản lý User, tăng cường bảo mật và trải nghiệm người dùng.

3.2. Chính Sách Phân Quyền (Policies)

Policies là các tài liệu JSON định nghĩa rõ ràng các quyền truy cập. Chúng là cơ chế để thực hiện Ủy quyền (Authorization).

• Định nghĩa: Policies xác định Ai được làm Gì trên Tài nguyên nào và trong Điều kiện nào.
• Cấu trúc ví dụ: Effect: Allow/Deny, Action: s3:PutObject, Resource: arn:aws:s3:::tên-bucket/*.
• Thực tiễn Tốt nhất:
  • Gán quyền cho Groups hoặc Roles: Hạn chế gán quyền trực tiếp cho IAM Users riêng lẻ. Việc gán Policies cho Groups/Roles giúp việc quản lý thay đổi quy mô và dễ dàng hơn nhiều.

3.3. Nguyên Tắc An Toàn Cốt Lõi

A. Nguyên Tắc Quyền Tối Thiểu (Least Privilege)

• Khái niệm: Chỉ cấp đúng và đủ quyền cần thiết để hoàn thành công việc. Không hơn.
• Lợi ích: Hạn chế tối đa phạm vi thiệt hại nếu một User hoặc một dịch vụ bị xâm phạm (ví dụ: nếu một nhân viên kế toán chỉ có quyền đọc dữ liệu, họ sẽ không thể xóa bất kỳ EC2 instance nào, ngay cả khi tài khoản của họ bị đánh cắp).
• Thực hành: Bắt đầu bằng quyền hạn chế nhất có thể và chỉ cấp thêm quyền nếu có yêu cầu công việc rõ ràng. Tránh sử dụng Policies quản lý (Managed Policies) quá rộng như AdministratorAccess hoặc FullAccess cho các vai trò không phải Admin.

B. Quản Lý IAM Users và Người Dùng Thật

• 1:1 Mapping: Mỗi IAM User phải gắn liền với một cá nhân duy nhất.
• Khả năng Kiểm toán (Auditability): Việc không chia sẻ tài khoản cho phép theo dõi chính xác ai đã làm gì (bạn biết chính xác user-lam-A chứ không phải nhom-chung đã thực hiện hành động) thông qua dịch vụ AWS CloudTrail.
• Bảo mật:
  • Bắt buộc sử dụng Multi-Factor Authentication (MFA) cho tất cả người dùng và đặc biệt là tài khoản Root/Admin.
  • Không sử dụng User Root cho các tác vụ hàng ngày. Lưu trữ Access Keys của Root User ở nơi cực kỳ an toàn.

Lưu ý quan trọng

• Tính Toàn cầu của IAM: IAM là một dịch vụ Toàn cầu (Global), không bị ràng buộc bởi Vùng (Region) cụ thể. Khi bạn tạo một User/Group/Role, chúng có thể được sử dụng ở mọi Region trong tài khoản của bạn.
• Kiểm tra Access Analyzer: Sử dụng IAM Access Analyzer để xác định các tài nguyên của bạn đang được chia sẻ với các thực thể bên ngoài tổ chức của bạn. Đây là một công cụ mạnh mẽ để đảm bảo an toàn.
• Quản lý Khóa Truy cập (Access Keys): Luôn xoay vòng (rotate) Access Keys thường xuyên và không bao giờ hardcode chúng vào mã ứng dụng của bạn. Sử dụng IAM Roles cho các ứng dụng chạy trên AWS là phương pháp được khuyến nghị.

4. Phân biệt IAM Permission và IAM Role trong AWS

4.1. Use case

Tôi có hai người dùng dev-user1 và dev-user2.

• dev-user1 cần truy cập vào hai bucket appconfig01 và appconfig02
• dev-user2 thì chỉ cần truy cập vào 2 bucket đó trong khoảng ba tháng mà thôi.

Ở đây, ta sẽ cấp permission cho dev-user1, còn với dev-user2, ta sẽ dùng role để user2 có thể consume permission.

4.2. Phân Tích Trường Hợp Sử Dụng (Use Case Analysis)

Người dùng	Yêu cầu Truy cập	Giải pháp Khuyến nghị	Lý do
dev-user1	Truy cập liên tục/dài hạn vào bucket appconfig01 và appconfig02.	Gán IAM Policy trực tiếp.	Phù hợp cho nhu cầu quyền cố định, không thay đổi, đơn giản hóa quản lý.
dev-user2	Truy cập tạm thời trong 3 tháng vào bucket appconfig01 và appconfig02.	Sử dụng IAM Role (Assume Role).	Đảm bảo nguyên tắc Least Privilege (Quyền tối thiểu) và dễ dàng thu hồi quyền theo thời gian.

4.3. So Sánh Chi Tiết: Permission (Policy) và Role (Vai trò)

Permission Trực Tiếp (Policy Gán vào User/Group)

Thuộc tính	Chi tiết
Định nghĩa	Là một tập hợp các quy tắc cho phép (Allow) hoặc từ chối (Deny) các hành động trên các tài nguyên AWS. Policy này được gắn trực tiếp vào một IAM User hoặc IAM Group.
Đặc điểm	Quyền “dính” vĩnh viễn (hoặc đến khi bị gỡ) vào thực thể IAM.
Credential	User sử dụng IAM Credential tĩnh (Access Key ID và Secret Access Key, hoặc Username/Password) để truy cập.
Thời gian Hiệu lực	Liên tục, dài hạn cho đến khi Policy bị sửa đổi hoặc gỡ bỏ.
Trường hợp Sử dụng	Lý tưởng cho các người dùng/service cần quyền cố định, liên tục (ví dụ: quản trị viên, người dùng ứng dụng chính).
Áp dụng trong Ví dụ	Gán IAM Policy (cho phép S3:List/Get/Put trên 2 bucket) trực tiếp cho dev-user1.

IAM Role (Vai trò)

Thuộc tính	Chi tiết
Định nghĩa	Một thực thể IAM không có Credential cố định. Nó là một “bộ quyền” mà bất kỳ Trusted Entity (IAM User, Service, Account AWS khác) nào cũng có thể assume (nhập vai).
Đặc điểm	Quyền không thuộc về ai cố định. Khi được Assume, AWS sẽ cấp Temporary Security Credentials (Khóa bảo mật tạm thời).
Credential	Temporary Security Credentials (Token, Access Key ID, Secret Access Key) với thời hạn giới hạn (mặc định 1 giờ, tối đa 12 giờ).
Thời gian Hiệu lực	Tạm thời, chỉ có hiệu lực trong khoảng thời gian Assume Role. Điều này giúp hạn chế rủi ro bảo mật.
Trường hợp Sử dụng	Quyền tạm thời, Chia sẻ quyền (Cross-Account Access), gán quyền cho AWS Service (EC2, Lambda), hoặc thực thi nguyên tắc Least Privilege với thời hạn.
Áp dụng trong Ví dụ	Tạo IAM Role với Policy truy cập S3. Gán quyền Assume Role cho dev-user2. Sau 3 tháng, chỉ cần gỡ quyền Assume Role khỏi dev-user2 (hoặc disable Role).

4.4. Tóm Tắt Sự Khác Biệt Cốt Lõi

Tiêu chí	Permission trực tiếp (Policy gán vào User)	IAM Role (Assume Role)
Ai sở hữu	Gắn trực tiếp vào User/Group.	Không ai sở hữu cố định, được cung cấp cho Entity được tin cậy.
Credential	Credential tĩnh của User.	Credential tạm thời, do AWS cấp khi Assume Role.
Thời gian	Liên tục, dài hạn.	Giới hạn (tối đa vài giờ), lý tưởng cho quyền tạm thời.
Quản lý Hết hạn	Khó quản lý (phải nhớ gỡ Policy).	Dễ quản lý (chỉ cần gỡ quyền Assume Role hoặc Role tự hết hạn).

Mẹo và Trường hợp Sử dụng Tốt nhất

• Cảnh báo Bảo mật (Security Best Practice): Luôn ưu tiên sử dụng IAM Role cho các ứng dụng AWS Services (ví dụ: gán Role cho một instance EC2 để nó có thể truy cập S3). Việc lưu trữ Access Key/Secret Key tĩnh trong code là một lỗ hổng bảo mật nghiêm trọng.
• Chức năng Phù hợp nhất:
  • Permission Trực tiếp: Dành cho người dùng IAM (con người) cần truy cập console hoặc qua CLI thường xuyên.
  • IAM Role: Dành cho truy cập tạm thời, truy cập Cross-Account (giữa các tài khoản AWS), hoặc gán quyền cho AWS Services (ví dụ: Lambda Role, EC2 Role).