本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
SCP 评估
注意
本节中的信息不适用于声明性策略类型，包括备份策略、标签策略、聊天应用程序策略或 AI 服务选择退出策略。有关更多信息，请参阅 了解声明式策略继承。
由于您可以在 AWS Organizations中的不同级别附加多个服务控制策略 (SCP)，因此了解 SCP 的评估方式可以帮助您编写产生正确结果的 SCP。
SCP 如何与“允许”配合使用
要允许特定账户获得权限，在从根到账户直接路径中的每个 OU（包括目标账户本身），每个级别都必须有显式Allow语句。这就是为什么在启用 SCP 时，会 AWS Organizations 附加一个名为 fullawsAccess 的 AWS 托管 SCP 策略，该策略允许所有服务和
例如，我们来看一下图 1 和图 2 所示的场景。要允许账户 B 获得权限或服务，应将允许该权限或服务的 SCP 附加到根、生产 OU 和账户 B 本身。
SCP 评估遵循“默认拒绝”模式，这意味着 SCP 中未明确允许的任何权限都将被拒绝。如果在任何级别（例如根、生产 OU 或账户 B）的 SCP 中不存在允许语句，则访问将被拒绝。
图 1：在根、生产 OU 和账户 B 处附加 Allow 语句的组织结构示例
图 2：生产 OU 中缺少 Allow 语句的组织结构示例及其对账户 B 的影响
SCP 如何使用“拒绝”
要拒绝特定账户获得权限，在从根到账户直接路径中的每个 OU（包括目标账户本身），任何 SCP 都可以拒绝该权限。
例如，假设有一个 SCP 附加到生产 OU，它为给定服务指定了显式 Deny 语句。碰巧还有另一个 SCP 附加到根和账户 B，它显式允许访问相同的服务，如图 3 所示。因此，账户 A 和账户 B 都将被拒绝访问该服务，因为附加到组织中任何级别的拒绝策略都会针对其下的所有 OU 和成员账户进行评估。
图 3：生产 OU 中附加了 Deny 语句的组织结构示例及其对账户 B 的影响
使用 SCP 的策略
在编写 SCP 时，你可以结合使用Allow和Deny语句来允许在组织中执行预期的操作和服务。 Deny对账单是实施限制的有力方法，对于组织或业务单元的更广泛部分来说，这些限制应该是正确的，因为当它们应用于根目录或其下的所有帐户时， OU-level 它们会影响其下的所有帐户。
提示
您可以使用 IAM 中的服务上次访问数据来更新您的 SCP，从而仅允许访问您需要的 AWS 服务 。有关更多信息，请参阅《IAM 用户指南》中的查看 Organizations 的 Organizations 服务上次访问的数据。
AWS Organizations 创建名为 ful lawsAccess 的 AWS 托管 SAllow 语句来仅允许特定服务。你可以选择在根级别或每个级别替换 Full awsAccess。如果您在根目录处附加特定于服务的许可名单 SCP，它会自动应用于其下的所有 OU 和帐户，这意味着单个根级策略决定了整个组织的有效服务许可名单，如场景 7 所示。或者，您可以删除和替换每个 OU 和账户的 Ful l awsAccess，这样您就可以实施更精细的服务许可名单，这些许可名单因组织单位或个人账户而异。
注意：仅依赖 allow 语句和隐式的默认拒绝模型可能会导致意外访问，因为更广泛或重叠的 Allow 语句可能会覆盖限制性更强的语句。
将两个语句组合在一起的策略可能与以下示例类似，它阻止成员账户离开组织并允许使用所需的 AWS 服务。组织管理员可以分离 FullAWSAccess 策略并改为附加此策略。
要演示如何在 AWS Organization 中应用多个服务控制策略（SCP），请考虑以下组织结构和情境。
情境 1：Deny 策略的影响
此情境演示了组织中较高级别的拒绝策略如何影响其下级所有账户。当沙盒 OU 同时具有 “完全 AWS 访问权限” 和 “拒绝 S3 访问” 策略，而账户 B 具有 “拒绝 EC2 访问” 策略时，结果是账户 B 无法访问 S3（来自 OU-level 拒绝）和 EC2（来自账户级拒绝）。账户 A 没有 S3 访问权限（来自 OU-level拒绝）。
情境 2：每个级别都必须存在允许策略
此情境说明允许策略在 SCP 中的运作方式。要使服务可访问，从根级别到账户级别，每个级别都必须明确允许。在这里，由于沙盒 OU 具有“允许 EC2 访问”策略，该策略仅明确允许 EC2 服务访问，账户 A 和 B 将只具有 EC2 访问权限。
情境 3：在根级别缺少 Allow 语句的影响
在 SCP 中缺少 root 级别的 “允许” 语句是一种严重的配置错误，它将有效地阻止组织中所有成员帐户对 AWS 服务和操作的所有访问权限。
情境 4：分层 Deny 语句和产生的权限
此情境演示了一个两级深度 OU 结构。根和工作负载 OU 都具有 “完全 AWS 访问权限”，测试 OU 具有 “完全 AWS 访问权限” 和 “拒绝 EC2 访问权限”，生产 OU 具有 “完全 AWS 访问权限”。因此，账户 D 拥有除 EC2 之外的所有服务访问权限，账户 E 和 F 则拥有所有服务访问权限。
场景 5：允许的 OU-level 策略限制服务访问权限
此情境说明如何使用允许策略来限制对特定服务的访问。测试 OU 具有“允许 EC2 访问”策略，这意味着账户 D 仅允许访问 EC2 服务。生产 OU 维持“完全 AWS 访问权限”，因此账户 E 和 F 可以访问所有服务。这表明了如何在根级别上保持更广泛的允许的 OU-level 同时实施更严格的允许策略。
场景 6： Root-level 拒绝会影响所有账户，无论是否允许较低级别
此情境表明，根级别的拒绝策略会影响组织中的所有账户，无论较低级别有何允许策略。根同时具有 “完全 AWS 访问权限” 和 “拒绝 S3 访问” 策略。尽管测试 OU 具有“允许 S3 访问”策略，但根级别的 S3 拒绝策略仍具有优先级。账户 D 没有服务访问权限，因为测试 OU 仅允许 S3 访问，但 S3 在根级别已被拒绝。由于根级别有明确的拒绝策略，账户 E 和 F 可以访问除 S3 之外的其他服务。
场景 7：根级自定义允许策略限制 OU-level 访问权限
此场景演示了具有显式服务允许列表的 SCP 在应用于中的根级别时是如何运作的 AWS Organizations。在组织根级别，附加了两个自定义 “服务允许” SCP，明确允许访问有限的一组 AWS 服务 — SCP_1 允许 IAM 和 Amazon EC2，SCP_2 允许 Amazon S3 和亚马逊。 CloudWatch在组织单位 (OU) 级别，默认的 FullawsAccess 策略仍处于附加状态。但是，由于交叉行为，这些 OU 下的账户 A 和 B 只能访问根级 SCP 明确允许的服务。限制性更强的根策略优先，实际上只允许访问 IAM、EC2、S3 和 CloudWatch 服务，而不管在较低的组织级别授予的更广泛权限如何。
