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