SCP 评估

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

SCP 如何与“允许”配合使用

要允许特定账户获得权限，在从根到账户直接路径中的每个 OU（包括目标账户本身），每个级别都必须有显式Allow语句。这就是为什么在您启用 SCP 时，AWS Organizations 会附加一个名为 FullAWSAccess 的 AWS 托管 SCP 策略，该策略允许所有服务和操作。如果该策略在组织的任何级别被删除而未被替换，那么该级别下的所有 OU 和账户都将被阻止采取任何行动。

例如，我们来看一下图 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 更广泛的部分，因为当它们应用于根级别或 OU 级别时，会影响其下的所有账户。

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

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

JSON

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

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

JSON

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

要演示如何在 AWS Organization 中应用多个服务控制策略（SCP），请考虑以下组织结构和情境。

情境 1：Deny 策略的影响

此情境演示了组织中较高级别的拒绝策略如何影响其下级所有账户。当沙盒 OU 同时具有“完全 AWS 访问权限”和“拒绝 S3 访问”策略，而账户 B 具有“拒绝 EC2 访问”策略时，结果是账户 B 无法访问 S3（由于 OU 级别的拒绝策略）和 EC2（由于其账户级别的拒绝策略）。账户 A 没有 S3 访问权限（由于 OU 级别的拒绝策略）。

情境 2：每个级别都必须存在允许策略

此情境说明允许策略在 SCP 中的运作方式。要使服务可访问，从根级别到账户级别，每个级别都必须明确允许。在这里，由于沙盒 OU 具有“允许 EC2 访问”策略，该策略仅明确允许 EC2 服务访问，账户 A 和 B 将只具有 EC2 访问权限。

情境 3：在根级别缺少 Allow 语句的影响

在 SCP 中的根级别缺少“Allow”语句是一种严重的配置错误，这将有效地屏蔽组织中所有成员账户对 AWS 服务和操作的所有访问权限。

情境 4：分层 Deny 语句和产生的权限

此情境演示了一个两级深度 OU 结构。根和工作负载 OU 都具有“完全 AWS 访问权限”，测试 OU 具有“完全 AWS 访问权限”和“拒绝 EC2 访问”，生产 OU 具有“完全 AWS 访问权限”。因此，账户 D 拥有除 EC2 之外的所有服务访问权限，账户 E 和 F 则拥有所有服务访问权限。

情境 5：在 OU 级别限制服务访问权限的允许策略

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

情境 6：根级别的拒绝策略会影响所有账户，无论较低级别有何允许策略

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