IAM và quản lý truy cập
User, group, role, policy, cách AWS đánh giá quyền, quyền tạm thời qua STS, nhiều tài khoản với Organizations và IAM Identity Center.
- DomainThiết kế bảo mật
- 9 sơ đồ
- 10 tình huống
- 9 dịch vụ
5 phút phải nhớ
- Mặc định mọi request đều bị từ chối (implicit deny); cần ít nhất một Allow phù hợp, và một Deny tường minh ở bất kỳ policy nào thắng mọi Allow.Đọc câu hỏi quyền: tìm Deny trước, rồi tới SCP, rồi resource / identity policy, permissions boundary, session policy.
- User = danh tính lâu dài (mật khẩu, access key); role = danh tính được "mượn" bằng thông tin tạm thời từ STS.AWS khuyên dùng role và federation thay cho access key lâu dài; ứng dụng trên EC2 / Lambda / ECS luôn dùng role.
- EC2 nhận quyền qua instance profile (role gắn vào máy); SDK tự lấy thông tin tạm thời từ instance metadata.Đáp án "lưu access key trong file cấu hình trên EC2" luôn sai.
- Role có trust policy (ai được assume) và permission policy (assume xong làm được gì).Cho tài khoản B vào tài khoản A: tạo role ở A tin tưởng B, người ở B cần quyền sts:AssumeRole tới role đó. Bên thứ ba thì thêm External ID.
- Policy dựa trên tài nguyên (bucket policy, key policy, queue policy…) có trường Principal, cho phép truy cập khác tài khoản không cần assume role.Khác tài khoản với resource policy: người gọi giữ nguyên quyền của mình; với role: người gọi đổi sang quyền của role.
- SCP của Organizations đặt trần quyền cho user / role ở tài khoản thành viên, không cấp quyền nào; không áp dụng cho tài khoản quản lý và service-linked role."Cấm mọi tài khoản tắt CloudTrail / dùng Region ngoài danh sách" → SCP Deny gắn vào OU hoặc root.
- Permissions boundary đặt trần quyền cho một user / role cụ thể; quyền thật = giao của identity policy và boundary.Cho developer tự tạo role nhưng không leo thang quyền: bắt buộc role mới phải gắn boundary.
- IAM Identity Center: đăng nhập một lần vào nhiều tài khoản trong Organizations, gán quyền bằng permission set, nối được với IdP ngoài (Entra ID, Okta…).Nhân viên dùng tài khoản công ty để vào nhiều tài khoản AWS: Identity Center là đáp án hiện đại, thay cho tạo IAM user ở từng tài khoản.
- Cognito user pool là thư mục người dùng (đăng ký, đăng nhập, MFA, mạng xã hội); identity pool đổi danh tính đó lấy thông tin tạm thời AWS.Ứng dụng di động / web cho khách hàng truy cập S3, DynamoDB trực tiếp: Cognito, không phải IAM user.
- Bảo vệ root: bật MFA, không tạo access key, chỉ dùng cho vài việc bắt buộc.Việc hằng ngày dùng user / role có quyền tối thiểu; root chỉ cho các tác vụ như đổi gói support, đóng tài khoản.
- Thông tin tạm thời của role sống 1–12 giờ tuỳ cấu hình; role chaining (từ role này assume role khác) giới hạn 1 giờ.Phiên bị ngắt sau 1 giờ dù đã đặt 12 giờ: thường là do role chaining.
- IAM Access Analyzer tìm tài nguyên đang chia sẻ ra ngoài vùng tin cậy (tài khoản / tổ chức) và kiểm tra policy trước khi áp dụng."Tìm bucket, key, role đang cho bên ngoài truy cập" → Access Analyzer.
- Điều kiện (Condition) trong policy: aws:SourceIp, aws:MultiFactorAuthPresent, aws:RequestedRegion, aws:PrincipalOrgID, tag (ABAC)…Cho phép theo tag (ABAC) giúp ít policy hơn khi số dự án tăng; aws:PrincipalOrgID chia sẻ cho cả tổ chức mà không liệt kê từng tài khoản.
Sơ đồ
AWS đánh giá một request thế nào
Từng bước
- Có Deny ở bất kỳ policy nào áp dụng → DENY ngay.
- SCP / RCP của tổ chức không cho phép → DENY.
- Không có Allow nào từ identity hay resource policy → DENY (implicit deny).
- Permissions boundary và session policy (nếu có) cũng phải cho phép → ALLOW.
EC2 gọi S3 bằng role, không cần access key
Từng bước
- Role gắn vào EC2 qua instance profile; quyền nằm trong permission policy của role.
- SDK tự đọc thông tin tạm thời từ instance metadata (IMDSv2).
- Gọi S3 bằng thông tin tạm thời; không có khoá lâu dài nào trên máy.
Người ở tài khoản B dùng role ở tài khoản A
Permissions boundary: quyền thật là phần giao
SCP đặt trần cho cả OU
Từng bước
- Tài khoản xếp vào OU; SCP gắn ở root hoặc OU.
- Mọi tài khoản trong OU Prod kế thừa SCP: không ai (kể cả root của tài khoản đó) dùng Region ngoài danh sách.
IAM Identity Center: một lần đăng nhập, nhiều tài khoản
Từng bước
- Nhân viên đăng nhập bằng tài khoản công ty; nhóm đồng bộ sang Identity Center (SCIM).
- Mỗi nhóm có permission set khác nhau trên từng tài khoản; nghỉ việc thì tắt ở IdP.
Federation SAML 2.0 vào console
Cognito: khách hàng của app truy cập S3
IAM Access Analyzer tìm truy cập từ bên ngoài
Từng bước
- Access Analyzer phân tích policy của bucket, key, role, queue…
- Bucket policy cho tài khoản ngoài tổ chức → sinh finding để xem và xử lý.
So sánh nhanh
Các loại policy
| Loại | Gắn vào | Cấp quyền? | Dùng khi |
|---|---|---|---|
| Identity-based | User, group, role | Có | Cấp quyền cho danh tính trong tài khoản |
| Resource-based | Bucket, key, queue, topic, role (trust)… | Có (kể cả khác tài khoản) | Cho principal khác tài khoản vào tài nguyên |
| Permissions boundary | User, role | Không, chỉ đặt trần | Uỷ quyền tạo role mà không leo thang |
| SCP (Organizations) | Root, OU, tài khoản | Không, chỉ đặt trần | Rào chắn cho cả tài khoản / OU |
| RCP (Organizations) | Root, OU, tài khoản | Không, chỉ đặt trần | Rào chắn trên tài nguyên trong tổ chức |
| Session policy | Phiên assume role / federation | Không, chỉ đặt trần | Thu hẹp quyền cho một phiên |
Truy cập khác tài khoản
| Assume role | Resource-based policy | |
|---|---|---|
| Cách làm | Người gọi đổi sang quyền của role ở tài khoản đích | Tài nguyên tự cho principal khác tài khoản |
| Quyền ở tài khoản gốc | Tạm bỏ trong phiên | Giữ nguyên (ví dụ chép từ bucket A sang bucket B cùng lúc) |
| Dịch vụ hỗ trợ | Mọi dịch vụ | Chỉ dịch vụ có resource policy (S3, SQS, SNS, KMS, Lambda…) |
| Bên thứ ba | Thêm External ID để chống confused deputy | Dùng điều kiện aws:SourceAccount / SourceArn |
Danh tính cho ai
| Ai | Dùng | Ghi chú |
|---|---|---|
| Nhân viên, nhiều tài khoản | IAM Identity Center (+ IdP công ty) | Permission set → role ở từng tài khoản |
| Nhân viên, một tài khoản, có AD | SAML 2.0 federation → AssumeRoleWithSAML | Hoặc Identity Center nối AD |
| Ứng dụng trên EC2 / ECS / Lambda | Role (instance profile, task role, execution role) | Không lưu access key |
| Khách hàng của app web / mobile | Cognito user pool + identity pool | Đăng nhập mạng xã hội, MFA |
| Máy chủ ngoài AWS | IAM Roles Anywhere (chứng chỉ X.509) | Thay access key lâu dài |
| Tình huống khẩn cấp | IAM user break-glass có MFA | Giữ chặt, theo dõi |
Organizations và Control Tower
| Organizations | Control Tower | |
|---|---|---|
| Là gì | Gom tài khoản thành cây OU, thanh toán hợp nhất, SCP / RCP | Dựng landing zone nhiều tài khoản theo mẫu tốt nhất |
| Rào chắn | Bạn tự viết SCP | Controls có sẵn (preventive = SCP, detective = Config) |
| Dùng khi | Cần kiểm soát linh hoạt | Cần dựng nhanh môi trường nhiều tài khoản đúng chuẩn |
Tình huống đề hay gặp
1Ứng dụng trên EC2 cần đọc một bucket S3.
Xem đáp án
Đúng: Role có quyền s3:GetObject trên bucket, gắn vào EC2 qua instance profile
SDK tự lấy thông tin tạm thời từ metadata, AWS tự xoay vòng.
Sai: Tạo IAM user, lưu access key trong file cấu hình trên máy
Khoá lâu dài dễ lộ, phải tự xoay vòng.
Sai: Bucket policy cho phép mọi principal
Mở bucket cho cả thế giới.
2Người dùng có policy AdministratorAccess nhưng vẫn không tắt được CloudTrail ở tài khoản thành viên.
Xem đáp án
Đúng: Có SCP Deny cloudtrail:StopLogging ở OU / root
SCP đặt trần cho mọi user, role (kể cả root) của tài khoản thành viên; Deny thắng mọi Allow.
Sai: Thiếu quyền cloudtrail:StopLogging
AdministratorAccess đã có; quyền bị chặn ở tầng trên.
3Công ty kiểm toán (bên thứ ba) cần đọc tài nguyên trong tài khoản của bạn.
Xem đáp án
Đúng: Role cho tài khoản của họ assume, trust policy yêu cầu External ID
Thông tin tạm thời, thu hồi được; External ID chống confused deputy.
Sai: Tạo IAM user và gửi access key cho họ
Khoá lâu dài nằm ngoài tầm kiểm soát của bạn.
4Cho developer tự tạo role cho Lambda nhưng không để họ tạo role có quyền cao hơn chính mình.
Xem đáp án
Đúng: Permissions boundary: cho phép iam:CreateRole chỉ khi role mới gắn boundary đã định
Quyền thật của role mới không vượt quá boundary.
Sai: Chỉ dặn developer không gán AdministratorAccess
Không có gì ngăn được.
Sai: SCP
SCP áp cho cả tài khoản, không phân biệt role do ai tạo.
5500 nhân viên đăng nhập bằng tài khoản Microsoft Entra ID để vào 40 tài khoản AWS.
Xem đáp án
Đúng: IAM Identity Center nối với Entra ID, gán permission set cho nhóm theo tài khoản
Đăng nhập một lần, quyền theo nhóm, nghỉ việc thì tắt ở IdP là mất quyền.
Sai: Tạo IAM user cho từng người ở từng tài khoản
20.000 user, không quản lý nổi, thêm khoá lâu dài.
6App di động cho người dùng đăng nhập bằng Google rồi tải ảnh lên thư mục riêng của họ trên S3.
Xem đáp án
Đúng: Cognito user pool (đăng nhập Google) + identity pool cấp role tạm; policy giới hạn prefix theo id người dùng
Mỗi người chỉ có quyền tạm thời trên thư mục của mình.
Sai: Nhúng access key vào app
Ai giải nén app cũng lấy được khoá.
7Cần biết bucket, KMS key, role nào đang cho tài khoản ngoài tổ chức truy cập.
Xem đáp án
Đúng: IAM Access Analyzer với vùng tin cậy là tổ chức
Tự phân tích policy, báo finding cho mỗi đường truy cập ra ngoài.
Sai: Đọc thủ công từng policy
Không theo kịp khi số tài nguyên lớn, dễ sót.
8Chia sẻ bucket cho mọi tài khoản trong tổ chức, kể cả tài khoản tạo sau này.
Xem đáp án
Đúng: Bucket policy với điều kiện aws:PrincipalOrgID bằng ID tổ chức
Tài khoản mới trong tổ chức tự có quyền, tài khoản ngoài thì không.
Sai: Liệt kê từng ID tài khoản trong bucket policy
Phải sửa policy mỗi khi có tài khoản mới.
9Script assume role A rồi từ A assume role B với DurationSeconds 4 giờ thì lỗi.
Xem đáp án
Đúng: Role chaining giới hạn phiên tối đa 1 giờ
Muốn phiên dài: assume B trực tiếp bằng danh tính gốc.
Sai: Role B có max session duration 1 giờ
Có thể, nhưng ở đây lý do chắc chắn là role chaining.
10Cần MFA mới được xoá đối tượng trong bucket quan trọng.
Xem đáp án
Đúng: Policy Deny s3:DeleteObject khi aws:MultiFactorAuthPresent không đúng (và cân nhắc MFA Delete khi bật versioning)
Điều kiện MFA áp lên đúng hành động cần bảo vệ.
Sai: Chỉ bật MFA cho đăng nhập console
Không ràng buộc với từng thao tác API.
Chọn nhanh
Cấp / giới hạn quyền bằng gì?
| Khi cần | Dùng |
|---|---|
| Ứng dụng trên EC2 / Lambda / ECS cần gọi AWS | Role (instance profile, execution role, task role) · xem sơ đồ |
| Người ở tài khoản khác cần vào | Role + trust policy (bên thứ ba: External ID) · xem sơ đồ |
| Cho tài khoản khác dùng một tài nguyên | Resource-based policy (bucket / key / queue policy) · xem sơ đồ |
| Cấm hành động cho cả tài khoản / OU | SCP · xem sơ đồ |
| Giới hạn trần quyền của một user / role | Permissions boundary · xem sơ đồ |
| Nhân viên đăng nhập một lần vào nhiều tài khoản | IAM Identity Center · xem sơ đồ |
| Đăng nhập bằng AD công ty vào một tài khoản | SAML 2.0 federation · xem sơ đồ |
| Khách hàng của app web / mobile | Cognito user pool + identity pool · xem sơ đồ |
| Tìm tài nguyên đang chia sẻ ra ngoài | IAM Access Analyzer · xem sơ đồ |
| Hiểu vì sao bị Deny | Đi theo thứ tự đánh giá policy · xem sơ đồ |
Bẫy hay gặp
- Lưu access key trên EC2 hay trong code thay vì dùng role.
- Nghĩ SCP cấp quyền: SCP chỉ đặt trần, vẫn cần identity policy.
- Nghĩ SCP chặn được tài khoản quản lý: không áp dụng cho tài khoản quản lý.
- Quên rằng Deny tường minh thắng mọi Allow, kể cả AdministratorAccess.
- Cho bên thứ ba assume role mà không có External ID.
- Dùng root cho việc hằng ngày, hoặc tạo access key cho root.
- Dùng IAM user cho khách hàng của ứng dụng (đó là việc của Cognito).
- Lẫn user pool (đăng nhập) với identity pool (đổi lấy thông tin AWS).
- Liệt kê từng tài khoản trong bucket policy thay vì aws:PrincipalOrgID.
- Tưởng permissions boundary cấp thêm quyền.
- Quên role chaining giới hạn phiên 1 giờ.
Dịch vụ trong module
IAMai được làm gì- STScấp credential tạm thời
IAM Identity Centerđăng nhập một lần (SSO)
Organizationsquản lý nhiều tài khoản
Control Towerdựng landing zone đa account- Access Analyzerphân tích quyền truy cập iam
Cognitođăng nhập cho người dùng app
Directory Serviceactive directory được quản lý
Resource Access Managerchia sẻ tài nguyên giữa account
Số liệu dễ thay đổi (đã kiểm với tài liệu AWS)
- Mặc định: 20 managed policy mỗi role (tối đa 25), 10 mỗi user (tối đa 20), 10 mỗi group; 1.000 role mỗi tài khoản (tối đa 10.000). kiểm ngày 2026-10-16 ↗
- Managed policy tối đa 6.144 ký tự; tổng inline policy: user 2.048, group 5.120, role 10.240 ký tự (không tính khoảng trắng). kiểm ngày 2026-10-16 ↗
- Phiên role từ 15 phút tới tối đa 12 giờ tuỳ max session duration; mặc định 1 giờ nếu không chỉ định. kiểm ngày 2026-10-16 ↗
- Role chaining giới hạn phiên tối đa 1 giờ, bất kể max session duration của role. kiểm ngày 2026-10-16 ↗
- Thứ tự đánh giá: Deny tường minh → RCP → SCP → resource-based → identity-based → permissions boundary → session policy; Deny tường minh thắng mọi Allow. kiểm ngày 2026-10-16 ↗
- SCP không cấp quyền, không áp dụng cho user / role của tài khoản quản lý và service-linked role; áp dụng cả root của tài khoản thành viên. kiểm ngày 2026-10-16 ↗
- SCP tối đa 10.240 ký tự; tối đa 10 SCP gắn trực tiếp vào root, mỗi OU, mỗi tài khoản; OU lồng tối đa 5 cấp. kiểm ngày 2026-10-16 ↗
- Organizations mặc định tối đa 10 tài khoản (tăng được qua Service Quotas). kiểm ngày 2026-10-16 ↗