AWS 执行代码逻辑如何评估允许或拒绝访问的请求

默认情况下，除 AWS 账户根用户 外，所有请求都被隐式否定，具有完全访问权限。

请求必须由遵循以下被允许的评估逻辑的策略或一组策略明确允许。

显式拒绝将会覆盖显式允许。

Deny evaluation（拒绝评估）- 默认情况下，所有请求都被拒绝。这称为隐式拒绝。AWS 执行代码评估账户中应用于请求的所有策略。其中包含 AWS Organizations SCP 和 RCP、基于资源的策略、基于身份的策略、IAM 权限边界和会话策略。在所有这些策略中，执行代码查找应用于请求的 Deny 语句。这称为显式拒绝。如果执行代码找到一个适用的显式拒绝，则该执行代码将返回 Deny 的最终决定。如果没有显式拒绝，则执行代码评估会继续。

Organizations RCP：然后，执行代码会评估适用于请求的 AWS Organizations 资源控制策略（RCP）。RCP 适用于附加了 RCP 的账户的资源。如果执行代码没有在 RCP 中找到任何适用的 Allow 语句，则执行代码将返回 Deny 的最终决定。如果没有 RCP，或者 RCP 允许所请求的操作，则执行代码评估继续适用。

Organizations SCP：执行代码会评估适用于请求的 AWS Organizations 服务控制策略（SCP）。SCP 适用于附加 SCP 的账户的主体。如果执行代码没有在 SCP 中找到任何适用的 Allow 语句，则执行代码将返回 Deny 的最终决定。如果没有 SCP，或者 SCP 允许所请求的操作，则执行代码评估继续。

基于资源的策略 — 在同一账户中，基于资源的策略会对策略评估产生不同的影响，具体取决于访问资源的主体类型以及基于资源的策略中允许的主体。根据主体的类型，Allow 在基于资源的策略中可能会导致最终决定 Allow，即使基于身份的策略、权限边界或会话策略中存在隐式拒绝。

对于大多数资源，您只需要在基于身份的策略或基于资源的策略中明确 Allow 主体访问权限。IAM 角色信任策略和 KMS 密钥策略是此逻辑的例外，因为它们必须明确允许主体的访问权限。

当指定的主体是 IAM 用户、IAM 角色或会话主体时，基于资源的策略逻辑会与其他策略类型有所不同。会话主体包括 IAM 角色会话或者 IAM 联合身份用户会话。如果基于资源的策略直接向提出请求的 IAM 用户或会话主体授予权限，则基于身份的策略、权限边界或会话策略中的隐式拒绝不会影响最终决策。

基于身份的策略：执行代码会检查主体的基于身份的策略。对于 IAM 用户，这包括用户策略和来自用户所属组的策略。如果没有基于身份的策略或者基于身份的策略中没有允许请求动作的语句，那么请求被隐式否定，执行代码返回 Deny 的最终决定。如果任何适用的基于身份的策略中的任何语句都允许请求的动作，则代码评估继续适用。

IAM 权限边界：执行代码会检查主体使用的 IAM 实体是否具有权限边界。如果用于设置权限边界的策略不允许所请求的操作，则请求会被隐式拒绝。执行代码将返回拒绝最终决定。如果没有权限边界，或者权限边界允许所请求的操作，则代码评估继续适用。

会话策略：执行代码检查主体是否为会话主体。会话主体包括 IAM 角色会话或者 IAM 联合身份用户会话。如果主体不是会话主体，执行代码将返回 Allow 的最终决定。

对于会话主体，执行代码检查请求中是否传递了会话策略。您可以传递会话策略，同时使用 AWS CLI 或 AWS API 为某个角色或 IAM 联合身份用户获取临时凭证。如果您没有传递会话策略，则会创建默认会话策略，执行代码返回 Allow 的最终决定。