Update nexus: fix conflicts and sync local changes
This commit is contained in:
Shen Wei
@@ -1,98 +1,98 @@
|
||||
---
|
||||
title: "Service Control Policies (SCPs)"
|
||||
type: concept
|
||||
tags: [AWS, Organizations, Policy, Security, Compliance, Tagging]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Service Control Policies（SCPs，服务控制策略）是 AWS Organizations 的一种高级策略类型，用于集中定义在组织单元（OU）或账户级别上所有成员账户的最大可用权限。SCPs 属于预防性控制（Preventive Controls），在 IAM 权限被评估之前先被执行，确保任何账户中的任何操作都不会超出组织设定的安全边界。与 IAM 策略不同，SCPs 本身不授予权限，而是限制可授予的权限范围。
|
||||
|
||||
## Aliases
|
||||
- SCP
|
||||
- Service Control Policy
|
||||
- Organization Policy
|
||||
- AWS Organization Policy
|
||||
|
||||
## Core Attributes
|
||||
|
||||
| 属性 | 说明 |
|
||||
|------|------|
|
||||
| 作用层级 | Organization Root / Organizational Unit (OU) / Account |
|
||||
| 策略类型 | 预防性控制（Preventive） |
|
||||
| 执行顺序 | 在 IAM 权限评估之前执行 |
|
||||
| 默认行为 | 除非显式允许，否则拒绝（Default Deny） |
|
||||
| 影响范围 | 组织内所有成员账户 |
|
||||
| 不支持的操作 | 无法在根账户上附加 SCP |
|
||||
|
||||
## Use Cases
|
||||
|
||||
### 1. 标签合规性强制执行
|
||||
在该组织的 AWS Landing Zone 中，SCPs 用于强制执行标签规范——阻止不合规资源（如缺少必需标签键或标签值不在允许列表中）的创建。这确保了新资源从一开始就符合组织的安全和网络策略要求。
|
||||
|
||||
### 2. 服务限制
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "DenyUnapprovedRegions",
|
||||
"Effect": "Deny",
|
||||
"Action": "*",
|
||||
"Resource": "*",
|
||||
"Condition": {
|
||||
"StringNotEquals": {
|
||||
"aws:RequestedRegion": ["us-east-1", "eu-west-1"]
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Limitations
|
||||
|
||||
| 限制 | 说明 |
|
||||
|------|------|
|
||||
| 存量资源 | SCPs 无法修改或删除已存在的资源，只能阻止新资源的创建 |
|
||||
| 根账户 | 无法对组织的根账户附加 SCP |
|
||||
| 服务控制粒度 | 无法直接基于资源标签值做细粒度控制（需配合其他机制） |
|
||||
| Tag-based SCPs | 可基于标签键存在性做过滤，但无法基于标签值列表做精确限制 |
|
||||
|
||||
在标签合规性场景下，SCPs 可以强制要求"必须包含某标签键"，但对于"标签值必须在允许列表中"这类精确验证，则需要依赖 Tag Validation Tool 进行审计。
|
||||
|
||||
## SCPs vs IAM Policies
|
||||
|
||||
| 维度 | SCPs | IAM Policies |
|
||||
|------|------|-------------|
|
||||
| 作用对象 | 组织/OU/账户级别 | IAM 用户/角色/组 |
|
||||
| 执行顺序 | 先于 IAM | 后于 SCPs |
|
||||
| 授予权限 | 否（仅限制范围） | 是 |
|
||||
| 覆盖范围 | 全账户所有实体 | 指定实体 |
|
||||
|
||||
## Context in This Wiki
|
||||
|
||||
SCPs 与 Tag Validation Tool 在标签治理中形成互补关系：
|
||||
|
||||
```
|
||||
SCPs（预防性控制）
|
||||
↓ 阻止不合规资源的新建
|
||||
↓
|
||||
Tag Validation Tool（检测性控制）
|
||||
↓ 发现已存在的不合规存量资源
|
||||
↓
|
||||
CSV 审计报告 → 团队手动修复
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[AWS-Tagging-Standards]]：SCPs 强制执行的对象规范
|
||||
- [[Tag-Validation-Tool]]：SCPs 的下游补充（处理存量资源审计）
|
||||
- [[Policy-as-Code]]：SCPs 本身应以代码形式管理（版本控制/GitOps）
|
||||
- [[AWS-Organizations]]：SCPs 的承载平台
|
||||
- [[Zero-Trust-Architecture]]：SCPs 是零信任原则在 AWS Organizations 中的体现
|
||||
|
||||
## Sources
|
||||
|
||||
- [[ctp-topic-28-aws-tag-validation-tool]]
|
||||
---
|
||||
title: "Service Control Policies (SCPs)"
|
||||
type: concept
|
||||
tags: [AWS, Organizations, Policy, Security, Compliance, Tagging]
|
||||
last_updated: 2026-04-14
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Service Control Policies（SCPs，服务控制策略）是 AWS Organizations 的一种高级策略类型，用于集中定义在组织单元（OU）或账户级别上所有成员账户的最大可用权限。SCPs 属于预防性控制（Preventive Controls），在 IAM 权限被评估之前先被执行，确保任何账户中的任何操作都不会超出组织设定的安全边界。与 IAM 策略不同，SCPs 本身不授予权限，而是限制可授予的权限范围。
|
||||
|
||||
## Aliases
|
||||
- SCP
|
||||
- Service Control Policy
|
||||
- Organization Policy
|
||||
- AWS Organization Policy
|
||||
|
||||
## Core Attributes
|
||||
|
||||
| 属性 | 说明 |
|
||||
|------|------|
|
||||
| 作用层级 | Organization Root / Organizational Unit (OU) / Account |
|
||||
| 策略类型 | 预防性控制（Preventive） |
|
||||
| 执行顺序 | 在 IAM 权限评估之前执行 |
|
||||
| 默认行为 | 除非显式允许，否则拒绝（Default Deny） |
|
||||
| 影响范围 | 组织内所有成员账户 |
|
||||
| 不支持的操作 | 无法在根账户上附加 SCP |
|
||||
|
||||
## Use Cases
|
||||
|
||||
### 1. 标签合规性强制执行
|
||||
在该组织的 AWS Landing Zone 中，SCPs 用于强制执行标签规范——阻止不合规资源（如缺少必需标签键或标签值不在允许列表中）的创建。这确保了新资源从一开始就符合组织的安全和网络策略要求。
|
||||
|
||||
### 2. 服务限制
|
||||
```json
|
||||
{
|
||||
"Version": "2012-10-17",
|
||||
"Statement": [
|
||||
{
|
||||
"Sid": "DenyUnapprovedRegions",
|
||||
"Effect": "Deny",
|
||||
"Action": "*",
|
||||
"Resource": "*",
|
||||
"Condition": {
|
||||
"StringNotEquals": {
|
||||
"aws:RequestedRegion": ["us-east-1", "eu-west-1"]
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Limitations
|
||||
|
||||
| 限制 | 说明 |
|
||||
|------|------|
|
||||
| 存量资源 | SCPs 无法修改或删除已存在的资源，只能阻止新资源的创建 |
|
||||
| 根账户 | 无法对组织的根账户附加 SCP |
|
||||
| 服务控制粒度 | 无法直接基于资源标签值做细粒度控制（需配合其他机制） |
|
||||
| Tag-based SCPs | 可基于标签键存在性做过滤，但无法基于标签值列表做精确限制 |
|
||||
|
||||
在标签合规性场景下，SCPs 可以强制要求"必须包含某标签键"，但对于"标签值必须在允许列表中"这类精确验证，则需要依赖 Tag Validation Tool 进行审计。
|
||||
|
||||
## SCPs vs IAM Policies
|
||||
|
||||
| 维度 | SCPs | IAM Policies |
|
||||
|------|------|-------------|
|
||||
| 作用对象 | 组织/OU/账户级别 | IAM 用户/角色/组 |
|
||||
| 执行顺序 | 先于 IAM | 后于 SCPs |
|
||||
| 授予权限 | 否（仅限制范围） | 是 |
|
||||
| 覆盖范围 | 全账户所有实体 | 指定实体 |
|
||||
|
||||
## Context in This Wiki
|
||||
|
||||
SCPs 与 Tag Validation Tool 在标签治理中形成互补关系：
|
||||
|
||||
```
|
||||
SCPs（预防性控制）
|
||||
↓ 阻止不合规资源的新建
|
||||
↓
|
||||
Tag Validation Tool（检测性控制）
|
||||
↓ 发现已存在的不合规存量资源
|
||||
↓
|
||||
CSV 审计报告 → 团队手动修复
|
||||
```
|
||||
|
||||
## Related Concepts
|
||||
|
||||
- [[AWS-Tagging-Standards]]：SCPs 强制执行的对象规范
|
||||
- [[Tag-Validation-Tool]]：SCPs 的下游补充（处理存量资源审计）
|
||||
- [[Policy-as-Code]]：SCPs 本身应以代码形式管理（版本控制/GitOps）
|
||||
- [[AWS-Organizations]]：SCPs 的承载平台
|
||||
- [[Zero-Trust-Architecture]]：SCPs 是零信任原则在 AWS Organizations 中的体现
|
||||
|
||||
## Sources
|
||||
|
||||
- [[ctp-topic-28-aws-tag-validation-tool]]
|
||||
|
||||
Reference in New Issue
Block a user