本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
SCP评估
注意
此部分中的信息不适用于管理策略类型,包括 AI 服务选择退出策略、备份策略或标签策略。有关更多信息,请参阅 了解管理策略继承。
由于您可以在中附加不同级别的多个服务控制策略 (SCPs) AWS Organizations,因此了解评估SCPs方式可以帮助您编写SCPs得出正确结果的内容。
如何SCPs使用 “允许”
要允许特定账户获得权限,在从根到账户直接路径中的每个 OU(包括目标账户本身),每个级别都必须有显式Allow
语句。这就是为什么在启用SCPs时会 AWS Organizations 附加一个名为 F
例如,我们来看一下图 1 和图 2 所示的场景。要允许账户 B 的权限或服务,应将允许SCP该权限或服务的权限或服务附加到 Root、生产 OU 和账户 B 本身。
SCP评估遵循 deny-by-default 模型,这意味着中未明确允许的任何权限SCPs都将被拒绝。如果SCPs在任何级别(例如根、生产 OU 或账户 B)中都没有允许声明,则访问将被拒绝。
注意
-
中的
Allow
语句只SCP允许该Resource
元素有一个"*"
条目。 -
中的
Allow
语句根本SCP不能有Condition
元素。
![Organizational structure diagram showing Root, OU, and Member accounts with SCP permissions.](images/scp_allow_1.png)
图 1:在根、生产 OU 和账户 B 处附加 Allow
语句的组织结构示例
![Organizational structure with Root, OUs, and member accounts showing SCP allow and deny actions.](images/scp_allow_2.png)
图 2:生产 OU 中缺少 Allow
语句的组织结构示例及其对账户 B 的影响
如何SCPs使用 “拒绝”
要拒绝特定账户的权限,SCP从根账户到账户直接路径中的每个 OU(包括目标账户本身)都可以拒绝该权限。
例如,假设生产 OU 中有一个SCP附件,它为给定服务指定了明确的Deny
语句。Root 和账户 B 上还恰好有另一个SCP附加项,它明确允许访问相同的服务,如图 3 所示。因此,账户 A 和账户 B 都将被拒绝访问该服务,因为将针对组织下的所有账户OUs和成员账户评估附加到组织中任何级别的拒绝策略。
![Organizational structure showing Root, OUs, and member accounts with SCP permissions.](images/scp_deny_1.png)
图 3:生产 OU 中附加了 Deny
语句的组织结构示例及其对账户 B 的影响
使用策略 SCPs
在撰写时,SCPs您可以结合使用Allow
和Deny
语句来允许在组织中执行预期的操作和服务。 Deny
报表是实施限制的有力方法,应该适用于组织中的更广泛部分,或者OUs因为当它们应用于根级或 OU 级别时,它们会影响其下的所有帐户。
例如,您可以使用Deny
语句 阻止成员账户退出组织在根级别实施策略,该策略将对组织中的所有账户生效。拒绝语句还支持条件元素,这有助于创建例外情况。
提示
您可以使用中的服务上次访问数据IAM来更新您的,SCPs以限制仅访问您需要的 AWS 服务。有关更多信息,请参阅《IAM用户指南》中的 “查看组织服务上次访问数据”。
AWS Organizations 创建后,将SCP名为 F ullAWSAccessAllow
语句来仅允许特定服务。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ec2:*", "cloudwatch:*", "organizations:*" ], "Resource": "*" } ] }
将两个语句组合在一起的策略可能与以下示例类似,它阻止成员账户离开组织并允许使用所需的 AWS 服务。组织管理员可以分离 F ullAWSAccess 策略并改为附加此策略。
{ "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.](images/scp_deny_2.png)
下表显示了沙盒 OU 中的有效策略。
场景 | SCPat root | SCP在 Sandbox OU | SCP在账户 A | 账户 A 处生成的策略 | 账户 B 和账户 C 处生成的策略 |
---|---|---|---|---|---|
1 | 完全 AWS 访问权限 | 完全 AWS 访问权限 + 拒绝 S3 访问权限 | 完全 AWS 访问权限 + 拒绝EC2访问 | 没有 S3,没有EC2访问权限 | 没有 S3 访问 |
2 | 完全 AWS 访问权限 | 允许EC2访问 | 允许EC2访问 | 允许EC2访问 | 允许EC2访问 |
3 | 拒绝 S3 访问 | 允许 S3 访问 | 完全 AWS 访问权限 | 无服务访问 | 无服务访问 |
下表显示了工作负载 OU 中的有效策略。
场景 | SCPat root | SCPat 工作负载 OU | SCP在测试中 OU | 账户 D 处生成的策略 | 生产 OU、账户 E 和账户 F 处生成的策略 |
---|---|---|---|---|---|
1 | 完全 AWS 访问权限 | 完全 AWS 访问权限 | 完全 AWS 访问权限 + 拒绝EC2访问 | 无法EC2访问 | 完全 AWS 访问权限 |
2 | 完全 AWS 访问权限 | 完全 AWS 访问权限 | 允许EC2访问 | 允许EC2访问 | 完全 AWS 访问权限 |
3 | 拒绝 S3 访问 | 完全 AWS 访问权限 | 允许 S3 访问 | 无服务访问 | 无服务访问 |