SCP 评估 - AWS Organizations
如何 SCPs 使用 “允许”如何 SCPs 使用 “拒绝”使用策略 SCPs

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

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）中都没有允许声明，则访问将被拒绝。

备注

  • SCP 中的 Allow 语句允许 Resource 元素仅包含一个 "*" 条目。

  • SCP 中的 Allow 语句完全不能有 Condition 元素。

Organizational structure diagram showing Root, OU, and Member accounts with SCP permissions.

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

Organizational structure with Root, OUs, and member accounts showing SCP allow and deny actions.

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

如何 SCPs 使用 “拒绝”

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

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

Organizational structure showing Root, OUs, and member accounts with SCP permissions.

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

使用策略 SCPs

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

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

提示

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

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

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

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

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

现在，考虑以下示例组织结构，以了解如何在组织中的不同 SCPs 级别上应用多个组织结构。

Organizational structure diagram showing Root, OUs, and member accounts in a hierarchical layout.

下表显示了沙盒 OU 中的有效策略。

场景 根处的 SCP 沙盒 OU 处的 SCP 账户 A 处的 SCP 账户 A 处生成的策略 账户 B 和账户 C 处生成的策略
1 完全 AWS 访问权限 完全 AWS 访问权限 + 拒绝 S3 访问权限 完全 AWS 访问权限 + 拒绝 EC2 访问 没有 S3，没有 EC2 访问权限 没有 S3 访问
2 完全 AWS 访问权限 允许 EC2 访问 允许 EC2 访问 允许 EC2 访问 允许 EC2 访问
3 拒绝 S3 访问 允许 S3 访问 完全 AWS 访问权限 无服务访问 无服务访问

下表显示了工作负载 OU 中的有效策略。

场景 根处的 SCP 工作负载 OU 处的 SCP 测试 OU 处的 SCP 账户 D 处生成的策略 生产 OU、账户 E 和账户 F 处生成的策略
1 完全 AWS 访问权限 完全 AWS 访问权限 完全 AWS 访问权限 + 拒绝 EC2 访问 无法 EC2 访问 完全 AWS 访问权限
2 完全 AWS 访问权限 完全 AWS 访问权限 允许 EC2 访问 允许 EC2 访问 完全 AWS 访问权限
3 拒绝 S3 访问 完全 AWS 访问权限 允许 S3 访问 无服务访问 没有 S3 访问