SCP 如何与 IAM 权限结合

组织中的访问权限由两层控制：AWS 组织设置的 SCP 上限，以及账户内授予的 IAM 权限。理解这两者如何组合，是治理领域最常考的概念之一，因为最终结果取决于两者是否都允许。

规则简单但很严格：某项操作只有在同时获得适用的 SCP 和账户 IAM 策略允许时才会被允许。有效权限是它们的交集。没有匹配的 IAM 允许时，SCP 不会授予任何权限；被 SCP 阻止的 IAM 允许也不会授予任何权限。

如果 SCP 允许某项操作，但没有 IAM 策略授予该操作，结果会因 IAM 的隐式拒绝而被拒绝。SCP 只是让该操作成为可能；仍然必须由 IAM 实际授予权限。许多学习者会忘记，SCP 是上限，而不是授权。

反过来，如果 IAM 策略允许某项操作，但 SCP 拒绝该操作，结果仍然会被拒绝。无论 IAM 授予的权限多么宽泛，SCP 的拒绝都会限制账户。这正是组织强制执行硬性限制、使本地管理员无法绕过这些限制的方式。

只有在 SCP 和 IAM 策略都允许该操作，且任何位置都不存在显式拒绝时，请求才会被允许。这种交集逻辑与权限边界的工作方式相似，并且两者可以同时生效，进一步收窄权限。

在完全受治理的环境中，多个上限会层层叠加：SCP（账户级别）、权限边界（身份级别）、任何会话策略（会话级别）以及身份策略（授权）。有效权限是所有上限的交集加上授权，再扣除任何显式拒绝。

假设某个 IAM 策略授予 s3:* 和 ec2:*，权限边界只允许 s3:*，而 SCP 只允许 s3:GetObject。有效权限就只有 s3:GetObject，即三层权限的交集。每个上限都会进一步削减权限。

在每一层中，任何策略、SCP、边界、会话、身份或资源中的显式拒绝都会立即阻止该操作。任何允许的组合都无法覆盖它。分析场景时，请先查找任何显式拒绝；如果找到，答案就是拒绝。

基于资源的策略可以独立于身份策略授予同一账户内的访问权限，但 SCP 仍会限制主体所在账户的权限。对于跨账户访问，两个账户的控制措施以及双方的策略都会生效。交集规则会相应扩展，但核心思想不变：每个适用的上限都必须允许该操作。

当组织中的访问意外失败时，请从内向外检查：确认身份策略授予了该操作，然后检查权限边界，再检查账户及其每个父级 OU 上的 SCP，接着检查任何会话策略，最后扫描所有层是否存在显式拒绝。第一个未包含该操作的上限，或任何一个拒绝，就是导致问题的原因。

SCP 和 IAM 通过交集组合：某项操作必须同时获得两者的允许，还要通过任何边界和会话上限，并且任何位置都不能存在显式拒绝。SCP 和边界只会限制权限；IAM 策略负责授予权限。要允许某项操作，每个上限都必须允许它，并且至少要存在一项授权。

测试组合逻辑。

SCP 和 IAM 通过交集组合：只有在两者都允许某项操作，并且该操作通过任何权限边界和会话策略上限，同时任何位置都不存在显式拒绝时，该操作才会被允许。SCP 和边界只会限制权限；IAM 策略负责授予权限。任何层中的显式拒绝始终优先于所有允许。