SCP 评估 - AWS Organizations

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

SCP 评估

注意

本节中的信息适用于管理策略类型,包括备份策略、标签策略、聊天应用程序策略或 AI 服务选择退出策略。有关更多信息,请参阅 了解管理策略继承

由于您可以在中附加不同级别的多个服务控制策略 (SCPs) AWS Organizations,因此了解评估 SCPs 方式可以帮助您编写 SCPs 得出正确结果的内容。

如何 SCPs 使用 “允许”

允许特定账户获得权限,在从根到账户直接路径中的每个 OU(包括目标账户本身),每个级别都必须有显式Allow语句。这就是为什么在启用 SCPs时会 AWS Organizations 附加名为 F ull 的 AWS 托管 SCP 策略AWSAccess,该策略允许所有服务和操作。如果该政策在组织的任何级别被删除且未被替换,则该级别下的所有 OUs 和账户都将被禁止采取任何行动。

例如,我们来看一下图 1 和图 2 所示的场景。要允许账户 B 获得权限或服务,应将允许该权限或服务的 SCP 附加到根、生产 OU 和账户 B 本身。

SCP 评估遵循 deny-by-default模型,这意味着任何未明确允许的权限 SCPs 都将被拒绝。如果 SCPs 在任何级别(例如根、生产 OU 或账户 B)中都没有允许声明,则访问将被拒绝。

在根、生产 OU 和账户 B 处附加了 Allow 语句的组织结构示例

图 1:在根、生产 OU 和账户 B 处附加 Allow 语句的组织结构示例

在生产 OU 中缺少 Allow 语句的组织结构示例,及其对账户 B 的影响

图 2:生产 OU 中缺少 Allow 语句的组织结构示例及其对账户 B 的影响

如何 SCPs 使用 “拒绝”

拒绝特定账户获得权限,在从根到账户直接路径中的每个 OU(包括目标账户本身),任何 SCP 都可以拒绝该权限。

例如,假设有一个 SCP 附加到生产 OU,它为给定服务指定了显式 Deny 语句。碰巧还有另一个 SCP 附加到根和账户 B,它显式允许访问相同的服务,如图 3 所示。因此,账户 A 和账户 B 都将被拒绝访问该服务,因为将针对其下的所有账户 OUs 和成员账户评估组织中任何级别的拒绝策略。

在生产 OU 中附有 “拒绝” 声明的组织结构示例,及其对账户 B 的影响

图 3:生产 OU 中附加了 Deny 语句的组织结构示例及其对账户 B 的影响

使用策略 SCPs

在撰写时, SCPs 您可以结合使用AllowDeny语句来允许在组织中执行预期的操作和服务。 Deny语句是实施限制的有力方法,应该适用于组织中的更广泛部分,或者 OUs 因为当它们应用于根级或 OU 级别时,它们会影响其下的所有帐户。

例如,您可以使用对Deny账单 阻止成员账户退出组织在根级别实施策略,该策略将对组织中的所有账户都生效。拒绝语句还支持条件元素,这有助于创建例外情况。

提示

您可以在 IAM 中使用上次访问的服务数据来更新您的 SCPs ,将访问权限限制为仅您需要 AWS 服务 的内容。有关更多信息,请参阅《IAM 用户指南》中的查看 Organizations 的 Organizations 服务上次访问的数据

AWS Organizations 创建后,将名为 F ull 的 AWS 托管 SCP 附加AWSAccess到每个根、OU 和账户。此策略允许所有服务和操作。您可以将 F ull AWSAccess 替换为仅允许一组服务的策略,这样除非通过更新明确允许新 AWS 服务 服务,否则不允许使用新服务 SCPs。例如,如果您的组织只想允许在您的环境中使用部分服务,则可以使用 Allow 语句来仅允许特定服务。

JSON
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" } ] }

将两个语句组合在一起的策略可能与以下示例类似,它阻止成员账户离开组织并允许使用所需的 AWS 服务。组织管理员可以分离 “完整” AWSAccess 策略,改为附加此策略。

JSON
{ "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" }, { "Effect": "Deny", "Action":"organizations:LeaveOrganization", "Resource": "*" } ] }

要演示如何在 AWS 组织中应用多个服务控制策略 (SCPs),请考虑以下组织结构和方案。

场景 1:拒绝策略的影响

此场景演示了组织中更高级别的拒绝策略如何影响以下所有账户。当沙盒 OU 同时具有 “完全 AWS 访问权限” 和 “拒绝 S3 访问” 策略,而账户 B 具有 “拒绝 EC2 访问” 策略时,结果是账户 B 无法访问 S3(来自 OU 级别的拒绝)和 EC2 (来自其账户级别的拒绝)。账户 A 没有 S3 访问权限(来自 OU 级别的拒绝)。

场景 1:拒绝策略的影响

场景 2:允许策略必须存在于每个级别

此场景显示了允许策略在中是如何运作的 SCPs。为了使服务可以访问,从根目录到账户,每个级别都必须有明确的允许。在这里,由于沙盒 OU 具有 “允许 EC2 访问” 策略,该策略仅明确允许 EC2 服务访问,因此账户 A 和 B 只能 EC2访问服务。

场景 2:允许策略必须存在于每个级别

场景 3:在根级别缺少 Allow 语句的影响

在 SCP 中缺少 root 级别的 “允许” 语句是一种严重的配置错误,它将有效地阻止组织中所有成员帐户对 AWS 服务和操作的所有访问权限。

场景 3:在根级别缺少 Allow 语句的影响

场景 4:分层拒绝语句和由此产生的权限

此场景演示了两级深度 OU 结构。根和工作负载组织单位都具有 “完全 AWS 访问权限”,测试 OU 具有 “完全 AWS 访问权限” 和 “拒绝 EC2 访问”,生产 OU 具有 “完全 AWS 访问权限”。因此,账户 D 拥有除之外 EC2 的所有服务访问权限,账户 E 和 F 拥有所有服务访问权限。

场景 4:分层拒绝语句和由此产生的权限

场景 5:允许 OU 级别的策略限制服务访问权限

此场景显示了如何使用允许策略来限制对特定服务的访问。测试 OU 具有 “允许 EC2 访问” 政策,这意味着账户 D 仅允许 EC2服务。生产 OU 保持 “完全 AWS 访问权限”,因此账户 E 和 F 可以访问所有服务。这说明了如何在 OU 级别实施更严格的允许策略,同时在根级别保持更广泛的允许。

场景 5:允许 OU 级别的策略限制服务访问权限

场景 6:根级拒绝会影响所有账户,无论低级别的允许如何

此场景表明,根级别的拒绝策略会影响组织中的所有账户,无论较低级别的允许策略如何。根同时具有 “完全 AWS 访问权限” 和 “拒绝 S3 访问” 策略。尽管测试 OU 具有 “允许 S3 访问” 策略,但根级 S3 拒绝仍优先。账户 D 没有服务访问权限,因为测试 OU 仅允许 S3 访问,但 S3 在根级别被拒绝。由于根级别的明确拒绝,账户 E 和账户 F 可以访问除 S3 之外的其他服务。

场景 6:根级拒绝会影响所有账户,无论低级别的允许如何