本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# SCP 评估
**注意**
本节中的信息***不***适用于管理策略类型，包括备份策略、标签策略、聊天应用程序政策或人工智能服务退出政策。有关更多信息，请参阅 [了解管理策略继承](orgs_manage_policies_inheritance_mgmt.md)。
由于您可以在中附加不同级别的多个服务控制策略 (SCPs) AWS Organizations，因此了解评估 SCPs 方式可以帮助您编写 SCPs 得出正确结果的内容。
**Topics**
+ [如何 SCPs 使用 “允许”](#how_scps_allow)
+ [如何 SCPs 使用 “拒绝”](#how_scps_deny)
+ [使用策略 SCPs](#strategy_using_scps)
## 如何 SCPs 使用 “允许”
要**允许**特定账户获得权限，在从根到账户直接路径中的每个 OU（包括目标账户本身），每个级别都必须有**显式`Allow`语句**。这就是为什么在启用 SCPs时会 AWS Organizations 附加名为 F [ull](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess) 的 AWS 托管 SCP 策略AWSAccess，该策略允许所有服务和操作。如果该政策在组织的任何级别被删除且未被替换，则该级别下的所有 OUs 和账户都将被禁止采取任何行动。
例如，我们来看一下图 1 和图 2 所示的场景。要允许账户 B 获得权限或服务，应将允许该权限或服务的 SCP 附加到根、生产 OU 和账户 B 本身。
SCP 评估遵循 deny-by-default模型，这意味着任何未明确允许的权限 SCPs 都将被拒绝。如果 SCPs 在任何级别（例如根、生产 OU 或账户 B）中都没有允许声明，则访问将被拒绝。
![\[在根、生产 OU 和账户 B 处附加 Allow 语句的组织结构示例\]](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/images/scp_allow_1.png)
*图 1：在根、生产 OU 和账户 B 处附加 `Allow` 语句的组织结构示例*
![\[生产 OU 中缺少 Allow 语句的组织结构示例及其对账户 B 的影响\]](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/images/scp_allow_2.png)
*图 2：生产 OU 中缺少 `Allow` 语句的组织结构示例及其对账户 B 的影响*
## 如何 SCPs 使用 “拒绝”
要**拒绝**特定账户获得权限，在从根到账户直接路径中的每个 OU（包括目标账户本身），**任何 SCP** 都可以拒绝该权限。
例如，假设有一个 SCP 附加到生产 OU，它为给定服务指定了显式 `Deny` 语句。碰巧还有另一个 SCP 附加到根和账户 B，它显式允许访问相同的服务，如图 3 所示。因此，账户 A 和账户 B 都将被拒绝访问该服务，因为将针对其下的所有账户 OUs 和成员账户评估组织中任何级别的拒绝策略。
![\[生产 OU 中附加了 Deny 语句的组织结构示例及其对账户 B 的影响\]](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/images/scp_deny_1.png)
*图 3：生产 OU 中附加了 `Deny` 语句的组织结构示例及其对账户 B 的影响*
## 使用策略 SCPs
在撰写时， SCPs 您可以结合使用`Allow`和`Deny`语句来允许在组织中执行预期的操作和服务。 `Deny`语句是实施限制的有力方法，应该适用于组织中的更广泛部分，或者 OUs 因为当它们应用于根级或 OU 级别时，它们会影响其下的所有帐户。
**提示**
您可以在 [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) 中使用[服务上次访问的数据](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor.html)来更新您的 SCPs ，将访问权限限制为仅您需要 AWS 服务 的内容。有关更多信息，请参阅《IAM 用户指南》**中的[查看 Organizations 的 Organizations 服务上次访问的数据](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_access-advisor-view-data-orgs.html)。
AWS Organizations 创建后，将名为 F [https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess](https://console.aws.amazon.com/organizations/v2/home/policies/service-control-policy/p-FullAWSAccess) 的 AWS 托管 SCP 附加AWSAccess到每个根、OU 和账户。此策略允许所有服务和操作。您可以将 F **ull AWSAccess** 替换为仅允许一组服务的策略，这样除非通过更新明确允许新 AWS 服务 服务，否则不允许使用新服务 SCPs。例如，如果您的组织只想允许在您的环境中使用部分服务，则可以使用 `Allow` 语句来仅允许特定服务。您可以选择在根级别或每个级别替换 F **ull AWSAccess**。如果您在根目录处附加特定于服务的许可名单 SCP，它会自动应用于其下的所有 OUs 帐户，这意味着单个根级策略决定了整个组织的有效服务许可名单，如场景 7 所示。或者，您可以删除和替换AWSAccess每个 OU 和账户的 Ful **l**，这样您就可以实施更精细的服务许可名单，这些许可名单因组织单位或个人账户而异。
注意：仅依赖 allow 语句和隐式 deny-by-default模型可能会导致意外访问，因为更宽或重叠的 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：Deny 策略的影响
此情境演示了组织中较高级别的拒绝策略如何影响其下级所有账户。当沙盒 OU 同时具有 “完全 AWS 访问权限” 和 “拒绝 S3 访问” 策略，而账户 B 具有 “拒绝 EC2 访问” 策略时，结果是账户 B 无法访问 S3（来自 OU 级拒绝）和 EC2（来自其账户级拒绝）。账户 A 没有 S3 访问权限（由于 OU 级别的拒绝策略）。
![\[情境 1：Deny 策略的影响\]](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/images/scp_scenario_1.png)
### 情境 2：每个级别都必须存在允许策略
此情境说明允许策略在 SCP 中的运作方式。要使服务可访问，从根级别到账户级别，每个级别都必须明确允许。在这里，由于沙盒 OU 具有“允许 EC2 访问”策略，该策略仅明确允许 EC2 服务访问，账户 A 和 B 将只具有 EC2 访问权限。
![\[情境 2：每个级别都必须存在允许策略\]](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/images/scp_scenario_2.png)
### 情境 3：在根级别缺少 Allow 语句的影响
在 SCP 中缺少 root 级别的 “允许” 语句是一种严重的配置错误，它将有效地阻止组织中所有成员帐户对 AWS 服务和操作的所有访问权限。
![\[情境 3：在根级别缺少 Allow 语句的影响\]](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/images/scp_scenario_3.png)
### 情境 4：分层 Deny 语句和产生的权限
此情境演示了一个两级深度 OU 结构。根和工作负载 OU 都具有 “完全 AWS 访问权限”，测试 OU 具有 “完全 AWS 访问权限” 和 “拒绝 EC2 访问权限”，生产 OU 具有 “完全 AWS 访问权限”。因此，账户 D 拥有除 EC2 之外的所有服务访问权限，账户 E 和 F 则拥有所有服务访问权限。
![\[情境 4：分层 Deny 语句和产生的权限\]](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/images/scp_scenario_4.png)
### 情境 5：在 OU 级别限制服务访问权限的允许策略
此情境说明如何使用允许策略来限制对特定服务的访问。测试 OU 具有“允许 EC2 访问”策略，这意味着账户 D 仅允许访问 EC2 服务。生产 OU 维持“完全 AWS 访问权限”，因此账户 E 和 F 可以访问所有服务。这演示了如何在 OU 级别实施更严格的允许策略，同时在根级别保持更宽松的允许策略。
![\[情境 5：在 OU 级别限制服务访问权限的允许策略\]](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/images/scp_scenario_5.png)
### 情境 6：根级别的拒绝策略会影响所有账户，无论较低级别有何允许策略
此情境表明，根级别的拒绝策略会影响组织中的所有账户，无论较低级别有何允许策略。根同时具有 “完全 AWS 访问权限” 和 “拒绝 S3 访问” 策略。尽管测试 OU 具有“允许 S3 访问”策略，但根级别的 S3 拒绝策略仍具有优先级。账户 D 没有服务访问权限，因为测试 OU 仅允许 S3 访问，但 S3 在根级别已被拒绝。由于根级别有明确的拒绝策略，账户 E 和 F 可以访问除 S3 之外的其他服务。
![\[情境 6：根级别的拒绝策略会影响所有账户，无论较低级别有何允许策略\]](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/images/scp_scenario_6.png)
### 场景 7：根级别自定义允许策略限制 OU 级别的访问权限
此场景演示了在根级别应用显式服务允许列表时如何 SCPs 发挥作用 AWS Organizations。在组织根级别，附加了两个自定义 “服务允许” SCPs ，明确允许访问有限的一组 AWS 服务 — SCP\$11 允许 IAM 和 Amazon EC2，SCP\$12 允许 Amazon S3 和亚马逊。 CloudWatch在组织单位 (OU) 级别，默认的 “完整” AWSAccess 策略仍处于附加状态。但是，由于交叉行为，这些 OU 下的账户 A 和 B 只能访问根级 SCP 明确允许的服务。限制性更强的根策略优先，实际上只允许访问 IAM、EC2、S3 和 CloudWatch 服务，而不管在较低的组织级别授予的更广泛权限如何。
![\[场景 7：根级别自定义允许策略限制 OU 级别的访问权限\]](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/images/scp_scenario_7.png)