Advanced Identity

1. AWS STS

Ở chương IAM (chương 2), chúng ta đã biết IAM Role cho phép “mượn quyền” tạm thời thay vì gắn quyền cố định vào một User. Nhưng cơ chế nào thực sự đứng sau việc “mượn quyền” đó? Câu trả lời là AWS STS (Security Token Service). STS là dịch vụ chịu trách nhiệm tạo ra các bộ thông tin xác thực tạm thời (temporary security credentials) — gồm Access Key ID, Secret Access Key và một Session Token — có quyền hạn chế và có thời gian sống hữu hạn (bạn tự cấu hình, ví dụ từ 15 phút đến vài giờ).

Hãy tưởng tượng IAM User giống như một chiếc thẻ nhân viên vĩnh viễn, còn thông tin xác thực do STS cấp giống như một thẻ khách mời có giờ hết hạn — sau khi hết hạn, thẻ đó tự động mất tác dụng, không ai cần phải thu hồi tay. Đây là lý do STS được dùng ở khắp mọi nơi trong AWS mỗi khi cần cấp quyền “chỉ dùng trong một khoảng thời gian ngắn, cho một mục đích cụ thể”.

Ba tình huống sử dụng STS phổ biến nhất:

Identity Federation (liên kết định danh): Khi công ty bạn đã có một hệ thống quản lý người dùng riêng (ví dụ Active Directory nội bộ, hoặc hệ thống đăng nhập của công ty), bạn không cần tạo IAM User cho từng người. Thay vào đó, hệ thống ngoài đó xác thực người dùng, sau đó “đổi” định danh đã xác thực này để lấy một token tạm thời từ STS, và dùng token đó để truy cập tài nguyên AWS.
IAM Role cho truy cập cùng tài khoản hoặc liên tài khoản (cross-account): Một User ở Account A muốn truy cập tài nguyên ở Account B — User đó “assume” (nhận vai) một Role được Account B tin tưởng, và STS cấp token tạm thời tương ứng.
IAM Role cho Amazon EC2: Khi bạn gắn một IAM Role vào một EC2 Instance, thực chất phía sau EC2 liên tục gọi STS để lấy và làm mới thông tin xác thực tạm thời, rồi nạp vào Instance Metadata cho ứng dụng sử dụng — bạn không cần nhúng Access Key cố định vào code.

Luồng hoạt động tổng quát: User → “assume” một IAM Role (cùng tài khoản hoặc khác tài khoản) thông qua dịch vụ STS → nhận về Temporary Security Credentials → dùng thông tin xác thực đó để gọi API truy cập tài nguyên AWS.

2. Amazon Cognito

IAM được thiết kế cho người dùng nội bộ, đáng tin cậy, thuộc về công ty bạn — số lượng thường chỉ vài chục đến vài trăm người, và mỗi IAM User có thể truy cập trực tiếp AWS Console/CLI. Nhưng nếu bạn đang xây một ứng dụng di động hay website có hàng triệu người dùng công khai (khách hàng bên ngoài) cần đăng nhập, đăng ký tài khoản, đặt lại mật khẩu… thì việc tạo IAM User cho từng người là hoàn toàn không khả thi (vừa tốn kém, vừa mất an toàn vì IAM User có thể chạm tới tài nguyên AWS nội bộ).

Amazon Cognito giải quyết đúng vấn đề này: nó là một “cơ sở dữ liệu người dùng” dành riêng cho ứng dụng web và mobile, tách biệt hoàn toàn khỏi IAM của tài khoản AWS. Cognito gồm hai thành phần chính (ở mức khái quát của kỳ thi Cloud Practitioner, bạn chỉ cần hiểu ý tưởng tổng thể):

Cognito User Pools: nơi lưu trữ và quản lý danh tính người dùng — đăng ký, đăng nhập, quên mật khẩu, xác minh email/số điện thoại.
Người dùng cũng có thể đăng nhập thông qua các nhà cung cấp định danh xã hội (Social Identity Provider) như Facebook, Google, hay Twitter — tức là dùng lại tài khoản mạng xã hội có sẵn để đăng nhập vào ứng dụng của bạn, giống như nút “Đăng nhập bằng Google” bạn vẫn thấy trên nhiều website.

Nói ngắn gọn: IAM = định danh cho nhân viên/hệ thống quản trị AWS; Cognito = định danh cho khách hàng sử dụng ứng dụng của bạn. Hai hệ thống này không nên bị nhầm lẫn với nhau.

3. Microsoft Active Directory

Trước khi nói về AWS Directory Service, cần hiểu rõ Active Directory (AD) — vì đây là công nghệ rất phổ biến trong các doanh nghiệp dùng Windows Server. AD có sẵn trên mọi Windows Server có cài đặt vai trò AD Domain Services, và về bản chất, nó là một cơ sở dữ liệu tập trung chứa các đối tượng trong tổ chức:

Tài khoản người dùng (User Accounts)
Máy tính (Computers)
Máy in (Printers)
Thư mục chia sẻ file (File Shares)
Nhóm bảo mật (Security Groups) — lưu ý: đây là “Security Group” theo nghĩa của Windows/AD, khác hoàn toàn với “Security Group” trong EC2/VPC mà bạn đã học ở các chương trước.

AD cho phép quản lý bảo mật tập trung: quản trị viên tạo một tài khoản, gán quyền truy cập vào các tài nguyên (máy in, file, máy tính) một lần, và toàn bộ hệ thống trong tổ chức đều tuân theo. Thành phần điều phối trung tâm của AD gọi là Domain Controller — máy chủ giữ toàn bộ “sổ cái” định danh này.

4. AWS Directory Service

Nhiều doanh nghiệp đã đầu tư rất nhiều vào hạ tầng Active Directory tại chỗ (on-premise) và muốn tiếp tục dùng nó khi chuyển lên AWS, hoặc muốn có AD ngay trên AWS mà không cần tự cài đặt/vận hành Domain Controller. AWS Directory Service cung cấp ba phương án khác nhau, mỗi phương án phù hợp với một tình huống:

Phương án	Mô tả	Kết nối với AD on-premise?
AWS Managed Microsoft AD	AWS tạo và quản lý một AD thật (chạy Domain Controller thật) ngay trong AWS. Bạn quản lý User cục bộ trên đó, hỗ trợ MFA.	Có — có thể thiết lập quan hệ “trust” hai chiều với AD on-premise để dùng chung định danh.
AD Connector	Không tạo AD mới — chỉ là một “cổng chuyển tiếp” (Directory Gateway/proxy) chuyển mọi yêu cầu xác thực về AD on-premise sẵn có. Hỗ trợ MFA.	Có — bắt buộc, vì AD Connector không lưu trữ định danh, chỉ redirect. Người dùng vẫn được quản lý hoàn toàn trên AD on-premise.
Simple AD	Một dịch vụ directory tương thích AD được AWS quản lý, chi phí thấp, phù hợp nhu cầu cơ bản (ví dụ chỉ cần một AD nhỏ cho ứng dụng chạy trên AWS).	Không — không thể join/kết nối với AD on-premise.

Cách phân biệt dễ nhớ: Managed Microsoft AD = “có AD thật trên AWS, có thể bắt tay với AD on-premise (trust)”; AD Connector = “không có AD nào trên AWS cả, chỉ là đường ống nối tới AD on-premise có sẵn”; Simple AD = “AD giá rẻ, độc lập, không nối được với on-premise”.

5. IAM Identity Center (SSO)

AWS IAM Identity Center (tên trước đây là AWS Single Sign-On) giải quyết một vấn đề rất thực tế: khi tổ chức của bạn có nhiều tài khoản AWS (quản lý qua AWS Organizations — xem lại chương 16) và/hoặc dùng nhiều ứng dụng doanh nghiệp khác nhau, nhân viên sẽ phải nhớ và đăng nhập lại nhiều lần vào từng hệ thống. IAM Identity Center cho phép nhân viên đăng nhập một lần duy nhất (Single Sign-On) rồi truy cập được tất cả:

Nhiều tài khoản AWS nằm trong AWS Organizations.
Các ứng dụng SaaS doanh nghiệp phổ biến như Salesforce, Box, Microsoft 365.
Bất kỳ ứng dụng nào hỗ trợ chuẩn SAML 2.0.
Các EC2 Windows Instance (đăng nhập vào máy Windows chạy trên EC2 bằng cùng một định danh).

Về nguồn định danh (identity provider), IAM Identity Center có thể dùng:

Kho định danh tích hợp sẵn ngay trong IAM Identity Center (tạo User trực tiếp ở đó).
Hoặc kết nối tới một nguồn thứ ba đã có sẵn: Active Directory (on-premise hoặc AWS Managed Microsoft AD), hoặc các nhà cung cấp SSO doanh nghiệp như OneLogin, Okta.

Nhờ đó, một nhân viên chỉ cần một bộ tài khoản/mật khẩu duy nhất để làm việc trên toàn bộ hệ sinh thái công cụ của công ty, thay vì phải nhớ nhiều mật khẩu cho từng tài khoản AWS hay từng ứng dụng riêng lẻ.

Tổng kết chương

IAM: quản lý danh tính & truy cập trong nội bộ một tài khoản AWS, cho người dùng đáng tin cậy thuộc công ty bạn.
AWS Organizations: quản lý nhiều tài khoản AWS cùng lúc (đã học ở chương 16).
AWS STS: cấp thông tin xác thực tạm thời, quyền hạn chế, dùng cho federation, cross-account role, và Role gắn vào EC2.
Amazon Cognito: cơ sở dữ liệu người dùng cho ứng dụng web & mobile, hỗ trợ đăng nhập qua Facebook/Google/Twitter.
AWS Directory Service: tích hợp Microsoft Active Directory với AWS — ba lựa chọn: Managed Microsoft AD (AD thật, có trust), AD Connector (proxy về AD on-premise), Simple AD (AD giá rẻ, độc lập).
AWS IAM Identity Center: đăng nhập một lần (SSO) cho nhiều tài khoản AWS và nhiều ứng dụng doanh nghiệp/SAML.