AWS Cloud Practitioner · Tiếng Việt
Chương 17 / 20

Advanced Identity: STS, Cognito, Directory Service...

Ngoài IAM cơ bản (User/Group/Role) cho nhân viên nội bộ, AWS còn có một nhóm dịch vụ định danh nâng cao để cấp quyền tạm thời, quản lý hàng triệu người dùng ứng dụng, và kết nối với hệ thống Active Directory hay hạ tầng đăng nhập doanh nghiệp.

Nội dung chương

  1. AWS STS – Security Token Service
  2. Amazon Cognito – định danh cho ứng dụng web/mobile
  3. Microsoft Active Directory là gì?
  4. AWS Directory Service – ba lựa chọn AD trên AWS
  5. AWS IAM Identity Center – đăng nhập một lần (SSO)

1. AWS STS – Security Token Service

Ở 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:

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.

Lưu ý khi thi: Đề thi hay hỏi "khi nào dùng STS" — hãy nhớ ba từ khóa: temporary (tạm thời), federation (liên kết định danh với hệ thống ngoài), và assume role (nhận vai trò để truy cập tài nguyên, kể cả cross-account). STS không thay thế IAM User/Role, mà là "cơ chế cấp phát" đứng sau Role.
Ví dụ thực tế: Một công ty có hệ thống đăng nhập nội bộ dùng Active Directory. Khi nhân viên đăng nhập vào cổng nội bộ, hệ thống xác thực họ với AD, sau đó gọi STS để đổi lấy token AWS tạm thời tương ứng với quyền của nhân viên đó — nhân viên chưa từng có IAM User riêng nhưng vẫn truy cập được S3, EC2 theo đúng quyền được cấp, và token tự hết hạn sau vài giờ.

2. Amazon Cognito – định danh cho ứng dụng web/mobile

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ể):

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.

Lưu ý khi thi: Câu hỏi kinh điển: "Công ty muốn cho phép hàng triệu người dùng bên ngoài đăng nhập vào ứng dụng mobile, dịch vụ nào phù hợp?" → đáp án là Amazon Cognito, không phải IAM. Đừng nhầm Cognito (định danh người dùng cuối) với IAM Identity Center (đăng nhập một lần cho nhân viên/nội bộ ở mục 5).
Ví dụ thực tế: Một ứng dụng đặt vé xem phim có 5 triệu người dùng. Thay vì tạo 5 triệu IAM User (không thể và cũng không nên), nhà phát triển dùng Cognito User Pool để quản lý đăng ký/đăng nhập, cho phép người dùng đăng nhập bằng Facebook hoặc Google, sau đó ứng dụng dùng thông tin đó (thường kết hợp với STS) để truy cập các tài nguyên AWS phía sau như S3 hay DynamoDB một cách an toàn.

3. Microsoft Active Directory là gì?

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:

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 – ba lựa chọn AD trên AWS

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 ánMô 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".

Lưu ý khi thi: Câu hỏi thường mô tả tình huống rồi hỏi chọn loại nào. Từ khóa "muốn tiếp tục dùng người dùng đang có trên AD on-premise, không muốn nhân bản dữ liệu" → AD Connector. Từ khóa "cần một AD đầy đủ chức năng chạy trên AWS và có thể thiết lập trust với AD on-premise" → AWS Managed Microsoft AD. Từ khóa "cần directory đơn giản, chi phí thấp, không cần liên kết on-premise" → Simple AD.
Ví dụ thực tế: Một công ty đã vận hành Active Directory tại văn phòng suốt 10 năm, có hàng nghìn tài khoản nhân viên. Khi triển khai một ứng dụng nội bộ mới trên EC2, họ dùng AD Connector để ứng dụng đó xác thực nhân viên ngay với AD hiện có, không cần đồng bộ hay tạo lại tài khoản.

5. AWS IAM Identity Center – đăng nhập một lần (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ả:

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

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ẻ.

Lưu ý khi thi: Phân biệt rõ ba dịch vụ dễ gây nhầm trong chương này: STS = cấp credential tạm thời cho một hành động cụ thể; Cognito = định danh cho người dùng ứng dụng web/mobile (khách hàng bên ngoài); IAM Identity Center = đăng nhập một lần cho nhân viên nội bộ khi làm việc với nhiều tài khoản AWS/ứng dụng doanh nghiệp. Cả ba đều "quản lý định danh" nhưng phục vụ đối tượng và mục đích khác nhau hoàn toàn.
Ví dụ thực tế: Một công ty có 15 tài khoản AWS khác nhau cho các phòng ban (Dev, Test, Prod, Finance...) được tổ chức trong một AWS Organizations. Thay vì nhân viên phải đăng nhập riêng vào từng tài khoản, bộ phận IT thiết lập IAM Identity Center kết nối với Active Directory công ty — nhân viên đăng nhập một lần bằng tài khoản công ty và thấy danh sách tất cả tài khoản AWS/ứng dụng họ có quyền truy cập, chỉ cần bấm chọn.

Tổng kết chương

← Chương trước Chương sau →