Advanced Identity trong AWS

1. Từ một account tới nhiều account

Ở mức cơ bản, bạn quản lý quyền bằng IAM User, Group, Role và Policy trong một AWS account. Nhưng khi tổ chức lớn lên — nhiều đội, nhiều môi trường dev/test/prod, nhiều dự án — mô hình một account bắt đầu chật chội: hóa đơn lẫn lộn, quyền khó khoanh vùng, một sai sót ở dev có thể chạm tới prod.

Chương này nói về các công cụ identity ở “tầng trên”: cách gom nhiều account thành một tổ chức (AWS Organizations), cách siết quyền ở tầng tổ chức (SCP, Permission Boundaries), cách cho người dùng đăng nhập một lần vào tất cả account (IAM Identity Center), cách nối với Active Directory sẵn có (AWS Directory Services), và cách dựng sẵn một môi trường multi-account đúng best practice (AWS Control Tower).

2. AWS Organizations

AWS Organizations là dịch vụ global cho phép bạn quản lý nhiều AWS account cùng lúc.

Account chính gọi là management account; các account còn lại là member account.
Một member account chỉ thuộc về đúng một organization.
Consolidated Billing — gom hóa đơn của tất cả account về một phương thức thanh toán duy nhất.
Có lợi ích về giá nhờ cộng dồn mức sử dụng (volume discount cho EC2, S3…).
Chia sẻ mức giảm giá của Reserved Instances và Savings Plans giữa các account.
Có API để tự động hóa việc tạo AWS account mới.

Organizational Unit (OU)

Cấu trúc của một organization là hình cây: trên cùng là Root Organizational Unit (OU) chứa management account, bên dưới là các OU (Dev, Prod, HR, Finance…) chứa các member account. Slide đưa ba cách chia OU thường gặp:

Cách chia	Cấu trúc ví dụ
Business Unit	Sales OU, Retail OU, Finance OU — mỗi OU chứa các account của phòng ban đó
Environmental Lifecycle	Prod OU, Dev OU, Test OU — chia theo môi trường
Project-Based	Project 1 OU, Project 2 OU, Project 3 OU — mỗi dự án một OU

Lợi ích của mô hình nhiều account

Slide nêu rõ đây là sự đánh đổi giữa Multi Account và One Account Multi VPC. Với multi account, bạn có:

Áp dụng chuẩn tagging để phục vụ mục đích tính tiền (billing).
Bật CloudTrail trên tất cả account, gửi log về một S3 account trung tâm.
Gửi CloudWatch Logs về một logging account trung tâm.
Thiết lập Cross Account Role cho các nhu cầu quản trị.
Bảo mật ở tầng tổ chức bằng Service Control Policies (SCP).

3. Service Control Policies (SCP)

SCP là các IAM policy được áp lên OU hoặc Account để giới hạn quyền của User và Role trong đó. Hai đặc tính cực kỳ hay bị hỏi:

SCP không áp dụng cho management account — account này luôn giữ toàn quyền admin.
Để một hành động được phép, phải có explicit allow từ root đi xuyên qua từng OU trên đường trực tiếp tới account đích. SCP không cho phép gì theo mặc định — giống cơ chế của IAM.

Đọc một cây SCP

Slide dựng một ví dụ rất đáng học. Cây gồm: OU (Root) có FullAWSAccess, và ngay dưới root là management account — account này bị gắn một policy Deny Athena. Bên dưới root còn có OU (Sandbox) với FullAWSAccess + Deny S3 và OU (Workloads) với FullAWSAccess. Trong Sandbox có Account A (FullAWSAccess + Deny EC2), Account B, Account C. Trong Workloads có OU (Test) mang Allow EC2 chứa Account D, và OU (Prod) với FullAWSAccess chứa Account E, Account F.

Kết quả quyền:

Đối tượng	Quyền thực tế
Management Account	Làm được mọi thứ — SCP không áp lên management account, nên kể cả `Deny Athena` gắn trực tiếp lên nó cũng không có tác dụng gì
Account A	Làm được mọi thứ TRỪ S3 (explicit Deny từ Sandbox OU) và TRỪ EC2 (explicit Deny tại chính account)
Account B & C	Làm được mọi thứ TRỪ S3 (explicit Deny từ Sandbox OU)
Account D	Truy cập được EC2 (nhờ `Allow EC2` ở OU Test)
Prod OU, Account E & F	Làm được mọi thứ

Về chiến lược viết SCP, slide gọi tên hai hướng: Blocklist (mặc định cho phép, chặn một số thứ) và Allowlist (mặc định chặn, chỉ cho phép một số thứ).

4. Tag Policies

Tag Policies của AWS Organizations giúp chuẩn hóa tag trên các resource trong toàn organization: đảm bảo tag nhất quán, audit được resource đã gắn tag, giữ việc phân loại resource đúng đắn.

Bạn định nghĩa tag key và các giá trị được phép cho key đó.
Hỗ trợ cho AWS Cost Allocation Tags và Attribute-based Access Control.
Ngăn các thao tác gắn tag không tuân thủ trên những dịch vụ và resource đã chỉ định — nhưng không có tác dụng với resource không có tag nào.
Sinh được report liệt kê toàn bộ resource đã gắn tag / không tuân thủ.
Dùng EventBridge để theo dõi các tag không tuân thủ.

5. IAM Conditions

IAM policy không chỉ nói “được làm gì trên resource nào”, mà còn kèm Condition — điều kiện phải thỏa mãn. Bốn condition key hay xuất hiện trong đề:

Condition key	Ý nghĩa
`aws:SourceIp`	Giới hạn IP của client gọi API
`aws:RequestedRegion`	Giới hạn region mà API call nhắm tới
`ec2:ResourceTag`	Giới hạn theo tag của resource
`aws:MultiFactorAuthPresent`	Bắt buộc dùng MFA

IAM cho S3: quyền cấp bucket vs cấp object

Một chỗ rất dễ viết sai ARN:

s3:ListBucket áp dụng cho arn:aws:s3:::test → đây là quyền ở cấp bucket (bucket level permission).
s3:GetObject, s3:PutObject, s3:DeleteObject áp dụng cho arn:aws:s3:::test/* → đây là quyền ở cấp object (object level permission).

6. Resource Policy và `aws:PrincipalOrgID`

Condition key aws:PrincipalOrgID dùng được trong bất kỳ resource policy nào để giới hạn truy cập chỉ cho các account là member của một AWS Organization.

Ví dụ trong slide: một S3 Bucket tên 2022-financial-data có bucket policy dùng aws:PrincipalOrgID trỏ tới organization o-yyyyyyyyyy. Kết quả: các member account trong organization truy cập được, còn user nằm ngoài organization thì bị chặn — dù bạn không phải liệt kê từng account ID một.

7. IAM Role vs Resource-Based Policy

Khi cần truy cập xuyên account (cross account), bạn có hai cách:

Gắn một resource-based policy vào resource — ví dụ S3 bucket policy cho phép principal ở account khác.
Hoặc dùng một Role làm proxy — user ở Account A assume một Role ở Account B rồi dùng quyền của Role đó.

Khác biệt bản chất nằm ở chỗ quyền gốc của bạn có bị mất hay không:

Khi bạn assume một role (dù là user, application hay service), bạn từ bỏ quyền ban đầu của mình và nhận quyền của role đó.
Khi dùng resource-based policy, principal không phải từ bỏ quyền của mình.

Đây chính là lý do một số bài toán chỉ giải được bằng resource-based policy. Ví dụ trong slide: một user ở Account A cần scan một bảng DynamoDB ở Account A rồi ghi kết quả vào S3 bucket ở Account B — nếu assume role của Account B thì mất quyền đọc DynamoDB ở Account A, nên cách đúng là dùng bucket policy ở Account B.

Resource-based policy được hỗ trợ bởi: Amazon S3 bucket, SNS topic, SQS queue, và các dịch vụ khác.

EventBridge và hai kiểu quyền

Khi một EventBridge rule chạy, nó cần quyền trên target. Và target quyết định dùng kiểu quyền nào:

Resource-based policy — cho Lambda, SNS, SQS, S3 bucket, API Gateway… (ví dụ: Lambda có resource-based policy “Allow EventBridge”).
IAM role — cho EC2 Auto Scaling, Systems Manager Run Command, ECS task…

8. IAM Permission Boundaries

IAM Permission Boundaries là tính năng nâng cao: dùng một managed policy để đặt mức quyền tối đa mà một IAM entity có thể có.

Được hỗ trợ cho user và role — không hỗ trợ cho group.
Quyền thực tế là phần giao: Permission Boundary ∩ quyền từ IAM Policy. Slide minh họa trường hợp hai vòng không giao nhau → kết quả là No Permissions.
Có thể kết hợp với SCP của AWS Organizations.

Use case theo slide:

Ủy quyền cho người không phải admin trong giới hạn quyền của họ — ví dụ cho phép họ tạo IAM user mới.
Cho developer tự gán policy và tự quản lý quyền của mình, nhưng đảm bảo họ không thể “escalate” đặc quyền (tự biến mình thành admin).
Hữu ích khi cần giới hạn một user cụ thể, thay vì giới hạn cả account bằng Organizations & SCP.

Đánh giá policy

Toàn bộ logic đánh giá — thứ tự AWS cân nhắc từng loại policy — nằm trong tài liệu IAM chứ không nằm trong chương này. Nhưng những gì chương này đã dựng thường đủ để giải một câu hỏi thi: explicit deny ở bất kỳ đâu cũng thắng, SCP phải allow ở mọi cấp từ root đi xuống, và permission boundary đặt trần lên những gì identity policy cấp.

Bài tập đi kèm là đọc một policy rồi trả lời ba câu hỏi về nó: bạn có thực hiện được sqs:CreateQueue không, sqs:DeleteQueue không, và ec2:DescribeInstances không? Hãy làm tay ít nhất một lần — đi từng action đối chiếu với từng statement, xét deny trước — thay vì tin vào một quy tắc chung.

9. AWS IAM Identity Center

AWS IAM Identity Center (tên trước đây là AWS Single Sign-On) cho bạn một lần đăng nhập (single sign-on) để vào:

Tất cả AWS account trong AWS Organizations.
Các ứng dụng cloud của doanh nghiệp (ví dụ Salesforce, Box, Microsoft 365…).
Các ứng dụng hỗ trợ SAML 2.0.
EC2 Windows Instances.

Nguồn danh tính (identity provider) có thể là:

Built-in identity store ngay trong IAM Identity Center.
Hoặc bên thứ ba: Active Directory (AD), OneLogin, Okta…

Theo diagram kiến trúc: người dùng đăng nhập qua Browser Interface vào IAM Identity Center; danh tính được lưu/lấy từ Built-in Identity Store hoặc từ Active Directory (on-premises hoặc cloud) chứa user & group; từ đó Permission Sets cấp quyền vào AWS Organization, các Business Cloud App, các app SAML 2.0 tùy chỉnh, và cả EC2 Windows.

Permission Sets hoạt động thế nào

Ví dụ trong slide: IAM Identity Center đặt tại Management Account của AWS Organization. Có một Group (Developers) gồm Bob và Alice. Group này được assign hai Permission Set khác nhau tùy môi trường: ReadOnlyAccess cho các account trong OU (Production) và FullAccess cho các account trong OU (Development). Nghĩa là cùng một nhóm người, cùng một lần đăng nhập, nhưng quyền khác nhau theo từng account.

Phân quyền chi tiết

Slide chia thành ba nhóm khả năng:

Multi-Account Permissions — quản lý truy cập xuyên các AWS account trong Organization. Permission Set là một tập hợp gồm một hay nhiều IAM Policy được gán cho user và group để định nghĩa quyền truy cập AWS.
Application Assignments — SSO vào nhiều ứng dụng doanh nghiệp SAML 2.0 (Salesforce, Box, Microsoft 365…); bạn cần cung cấp URL, certificate và metadata tương ứng.
Attribute-Based Access Control (ABAC) — phân quyền chi tiết dựa trên thuộc tính của user lưu trong IAM Identity Center Identity Store, ví dụ cost center, title, locale. Use case: định nghĩa quyền một lần, sau đó chỉ cần đổi thuộc tính của user là quyền truy cập AWS thay đổi theo.

Diagram ABAC minh họa: một Permission Set tên DB Admins được gán cho nhóm Database Admins; ở cả Dev Account và Prod Account, Permission Set này được assume thành một IAM Role cho phép truy cập RDS và Aurora.

10. Microsoft Active Directory và AWS Directory Services

Active Directory là gì

Microsoft Active Directory (AD) có trên mọi Windows Server bật AD Domain Services. Nó là một database các object: User Account, Computer, Printer, File Share, Security Group.

Cho phép quản lý bảo mật tập trung: tạo account, gán quyền.
Các object được tổ chức thành tree (cây); một nhóm tree gọi là forest.
Thành phần xác thực là Domain Controller — nơi kiểm tra user/password.

Ba lựa chọn của AWS Directory Services

Lựa chọn	Đặc điểm
AWS Managed Microsoft AD	Tạo AD của riêng bạn trong AWS, quản lý user ngay tại đó, hỗ trợ MFA; thiết lập được kết nối “trust” với AD on-premises
AD Connector	Là một Directory Gateway (proxy) chuyển hướng về AD on-premises, hỗ trợ MFA; user vẫn được quản lý ở AD on-premises
Simple AD	Directory được quản lý, tương thích AD trên AWS; không thể join với AD on-premises

Nối IAM Identity Center với Active Directory

Hai cách theo slide:

Kết nối tới AWS Managed Microsoft AD (Directory Service) — tích hợp có sẵn, không cần cấu hình gì thêm (out of the box).
Kết nối tới Self-Managed Directory — bằng cách tạo Two-way Trust Relationship dùng AWS Managed Microsoft AD, hoặc tạo một AD Connector làm proxy.

11. AWS Control Tower

AWS Control Tower là cách dễ dàng để dựng và quản trị một môi trường AWS nhiều account, an toàn và tuân thủ, dựa trên best practices. Nó dùng AWS Organizations bên dưới để tạo account.

Lợi ích:

Tự động thiết lập môi trường chỉ trong vài cú click.
Tự động hóa việc quản lý policy liên tục bằng guardrails.
Phát hiện vi phạm policy và khắc phục (remediate) chúng.
Theo dõi compliance qua một dashboard tương tác.

Guardrails

Guardrail cung cấp quản trị liên tục cho môi trường Control Tower (các AWS Account của bạn), và chia làm hai loại:

Preventive Guardrail — dùng SCP. Ví dụ: giới hạn các region được phép dùng trên tất cả account.
Detective Guardrail — dùng AWS Config. Ví dụ: nhận diện các resource chưa gắn tag.

Diagram minh họa một Detective Guardrail đầy đủ: AWS Control Tower giám sát các Member Account; AWS Config theo dõi các resource chưa gắn tag và đánh dấu NON_COMPLIANT; sự kiện đó trigger SNS để thông báo cho Admin và invoke Lambda để tự khắc phục (thêm tag).

Tóm tắt nhanh

Chủ đề	Cần nhớ
AWS Organizations	Global; một management account cộng các member account (mỗi account thuộc đúng một organization); consolidated billing, volume discount, chia sẻ Reserved Instances và Savings Plans; có API tạo account
Organizational Unit	Root OU với các OU lồng bên dưới, thường chia theo business unit, môi trường, hoặc dự án
SCP	Không áp lên management account; mặc định không cho phép gì, nên cần explicit allow từ root xuyên qua mọi OU trên đường đi xuống; explicit deny luôn thắng; chiến lược Blocklist hoặc Allowlist
Tag Policies	Chuẩn hóa tag key và các giá trị cho phép; hỗ trợ Cost Allocation Tags và ABAC; không tác dụng với resource không có tag; theo dõi vi phạm bằng EventBridge
IAM Conditions	`aws:SourceIp`, `aws:RequestedRegion`, `ec2:ResourceTag`, `aws:MultiFactorAuthPresent`
IAM cho S3	`s3:ListBucket` ở cấp bucket (`arn:aws:s3:::test`); `GetObject`, `PutObject`, `DeleteObject` ở cấp object (`arn:aws:s3:::test/*`)
`aws:PrincipalOrgID`	Dùng trong bất kỳ resource policy nào để giới hạn truy cập cho member của một Organization
Role vs resource-based policy	Assume role thì mất quyền gốc; resource-based policy thì giữ nguyên — bài toán DynamoDB ở account A ghi sang S3 ở account B
EventBridge target	Resource-based policy cho Lambda, SNS, SQS, S3, API Gateway; IAM role cho EC2 Auto Scaling, SSM Run Command, ECS task
Permission Boundaries	Chỉ cho user và role, không cho group; là trần chứ không cấp quyền; quyền thực tế là phần giao với IAM policy; chống privilege escalation
IAM Identity Center	SSO cho AWS account trong Organization, business app, app SAML 2.0 và EC2 Windows; identity store built-in hoặc AD / OneLogin / Okta; Permission Set, application assignment và ABAC
Directory Services	Managed Microsoft AD (AD riêng trong AWS, trust với on-prem, MFA) · AD Connector (proxy, user ở on-prem, MFA) · Simple AD (không join được AD on-prem)
Control Tower	Dựng và quản trị môi trường multi-account trên nền Organizations; preventive guardrail = SCP, detective guardrail = AWS Config