Policy evaluation logic: các loại policy tham gia đánh giá request
Một request tới AWS chỉ được thực hiện khi mọi lớp kiểm soát quyền liên quan đều cho phép; chỉ cần một lớp từ chối là request bị chặn.
Một request có thể bị chặn tại nhiều lớp: SCP của Organizations giới hạn toàn bộ account, permissions boundary giới hạn quyền tối đa của một user/role, identity policy cấp quyền, và với truy cập cross-account, resource policy (ví dụ bucket policy) cũng phải cho phép. Thay đổi từng lớp và quan sát kết quả.
- SCPSCP cho phép action này.
- Permissions boundaryKhông thiết lập permissions boundary.
- Identity policyPolicy gắn vào user/role cho phép action.
Quy tắc: một explicit deny tại bất kỳ lớp nào luôn được ưu tiên. Ngoài ra, mọi lớp áp dụng đều phải cho phép; lớp không đề cập tới action được xem là từ chối ngầm định.
- Explicit deny luôn được ưu tiên.
- SCP giới hạn cả root user của member account nhưng không ảnh hưởng service-linked role.
- Permissions boundary ngăn leo thang đặc quyền (developer tự gắn AdministratorAccess).
- Truy cập cross-account: cần cả identity policy phía bên gọi lẫn resource policy phía tài nguyên.
Policy evaluation logic: the policy types that evaluate a request
A request to AWS succeeds only when every relevant permission layer allows it; a single layer that denies it blocks the request.
A request can be stopped at several layers: an Organizations SCP limits the whole account, a permissions boundary limits the maximum permissions of a user/role, an identity policy grants permissions, and for cross-account access, a resource policy (for example a bucket policy) must also allow it. Change each layer and watch the result.
- SCPSCP cho phép action này.
- Permissions boundaryKhông thiết lập permissions boundary.
- Identity policyPolicy gắn vào user/role cho phép action.
Quy tắc: một explicit deny tại bất kỳ lớp nào luôn được ưu tiên. Ngoài ra, mọi lớp áp dụng đều phải cho phép; lớp không đề cập tới action được xem là từ chối ngầm định.
- An explicit deny always takes precedence.
- SCPs restrict even the root user of a member account but do not affect service-linked roles.
- A permissions boundary prevents privilege escalation (a developer attaching AdministratorAccess to themselves).
- Cross-account access: needs both an identity policy on the caller’s side and a resource policy on the resource’s side.