策略评估决策流程

任何请求到达 AWS 后，IAM 引擎都会运行精确的评估流程来决定允许还是拒绝。记住这一顺序是备考 SCS-C02 最有价值的事情之一，因为复杂的场景题取决于多个策略同时生效时哪种策略类型优先。

起点始终是隐式拒绝。如果评估过程中没有任何内容授予访问权限，请求就会被拒绝。这种默认拒绝的立场意味着，您必须在某处明确 Allow 某个操作，该操作才能成功；没有明确允许就等于拒绝。

最重要的一条规则是：任何适用策略中的显式 Deny都会覆盖所有 Allow。无论有多少条语句授予该操作，只要有一条匹配的 Deny，就会阻止该操作。这正是防护机制和 SCP 强制执行硬性限制的方式，下层策略无法覆盖这些限制。

AWS 会按以下概念顺序进行评估：1) 检查任何策略（SCP、权限边界、身份策略、资源策略、会话策略）中是否存在显式 Deny——如果存在，则拒绝。2) 如果有适用的 SCP 且它不允许该操作，则拒绝。3) 检查权限边界、会话策略以及身份策略或资源策略是否存在 Allow。任何缺口都会导致隐式拒绝。

AWS Organizations 中的服务控制策略（SCP）会设置账户的最大权限。某个操作必须同时得到 SCP 和 IAM 策略的允许才能成功。SCP 本身不会授予访问权限；它们只会限制上限或拒绝访问。如果 SCP 不允许某个操作，任何 IAM allow 都无法挽救它。

权限边界是一种高级策略，用于限制特定用户或角色的最大权限。实际生效的权限是边界与身份策略的交集。与 SCP 一样，边界只能限制权限，不能扩大基于身份的策略所授予的权限。

使用会话策略代入角色时，该策略会进一步缩小本次会话的权限。结果同样是一个交集：会话能够执行的操作不会超出角色策略和会话策略共同允许的范围。会话策略就是在代入角色时缩小权限范围的方式。

对于同一账户中的请求，基于资源的 Allow 可以在没有身份 Allow 的情况下授予访问权限（并集）。对于跨账户请求，两者都必不可少。同时，在整个过程中，这些策略中的任何显式 Deny 仍然优先。资源策略会参与同一个整体流程。

假设某个身份策略允许 s3:DeleteObject，但某个 SCP 拒绝生产环境中的所有 s3:Delete*。结果是拒绝，因为 SCP 中的显式拒绝覆盖了身份策略中的允许。反过来，如果 SCP 允许该操作，但没有身份策略授予该操作，结果同样会因隐式拒绝而被拒绝。两层策略必须同时同意，操作才能被允许。

考试场景会叠加 SCP、权限边界、身份策略和资源策略，然后询问最终结果。可靠的方法是先查找任何显式拒绝，确认 SCP 允许，确认边界和会话策略允许，再确认存在身份策略或资源策略中的 Allow。如果这些条件全部满足且没有拒绝，答案就是允许。

请记住这份检查清单：(1) 是否存在显式拒绝？有则拒绝。(2) SCP 是否允许？如果不允许，则拒绝。(3) 边界或会话策略是否允许？如果不允许，则拒绝。(4) 是否存在身份策略或资源策略允许？如果存在且没有拒绝，则允许；否则就是隐式拒绝。机械地应用这套方法，即使是涉及多个策略的问题也会变得直接明了。

IAM 评估从隐式拒绝开始，并且显式 Deny 始终优先。要允许某个操作：任何地方都不能有显式拒绝，SCP 必须允许该操作，权限边界和会话策略（交集）必须允许该操作，并且必须存在身份策略或资源策略中的 Allow。SCP 和边界只能限制权限，不能授予权限。