能否以默认黑名单模式配置AWS SCP并逐步添加权限？实操存疑

你的实操结果是对的，讲师的说法确实存在认知偏差，问题出在对AWS SCP的权限评估逻辑理解错误上。

SCP的核心评估逻辑 #

SCP是用来定义账号的最大权限边界的，它的规则是：

• 一个操作要能被执行，必须满足：所有应用到该账号的SCP（包括根、父OU、自身的SCP）都没有显式拒绝这个操作，并且至少有一个应用到该账号的SCP显式允许这个操作。
• 更关键的是：如果上层（比如根）的SCP没有允许某个操作，那么下层（子OU/账号）的SCP即使添加了允许规则，也无法突破这个边界——因为上层的SCP已经把这个操作排除在最大权限之外了。

你的实操场景分析 #

1. 你给根账号配置的No-op SCP只允许iam:GetLoginProfile，这意味着整个组织的最大权限边界就被限定在这个动作上了。
2. 当你给Fun-One账号单独添加Allow-EC2 SCP时，这个账号同时受到根的No-op和自身的Allow-EC2两个SCP约束：
   • 根SCP没有允许ec2:*，所以这个操作不在最大权限边界内
   • 哪怕子账号的SCP允许了，也无法突破上层的边界，所以用户还是不能操作EC2
3. 而把Allow-EC2加到根后，根的两个SCP（No-op+Allow-EC2）合并后的允许集合包含了iam:GetLoginProfile和ec2:*，整个组织的最大权限边界就扩展到这两个动作，Fun-One账号继承这个边界后，用户自然就能操作EC2了。

正确的反向配置思路 #

如果要做最小权限的反向配置，正确的姿势应该是：

• 根账号保留默认的FullAWSAccess SCP（或者一个允许大部分基础操作的SCP），然后通过Deny类型的SCP来全局禁用绝对不能使用的服务/操作
• 针对子OU/账号，再通过额外的Deny SCP进一步缩减权限；或者如果要做严格的最小权限，应该是根不设置Allow类的限制SCP，而是直接在子OU/账号上配置仅允许必要操作的Allow SCP（此时根的FullAWSAccess相当于允许所有，子账号的Allow SCP会把边界缩小到自己定义的范围）

你的后记结论是对的：如果上层OU（包括根）隐式或显式拒绝/未允许某个服务，下层的子OU/账号无法通过添加Allow SCP来开放这个服务的权限。

内容的提问来源于stack exchange，提问作者Wellspring