Data Perimeter（数据边界）是 AWS 安全体系中定义”信任边界”的一套策略组合。核心目标只有两条：组织内资源只能被组织内账号访问、组织内账号只能访问组织内资源。
实现方式不是单一策略，而是从不同维度分层控制。以下按控制维度逐一说明。
一、主体侧控制：SCP aws:ResourceOrgID
控制什么：限制 IAM 主体只能操作归属于本组织的资源。
原理：aws:ResourceOrgID 是全局条件键，在 API 请求中携带目标资源所属的组织 ID。SCP 判断该 ID 是否匹配本组织。
1
2
3
4
5
6
7
8
9
10
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:ResourceOrgID": "o-xxxxxxxxxx"
}
}
}
注意事项：
StringNotEqualsIfExists表示当条件键存在时才检查，不存在则放行。这能兼容不支持 ResourceOrgID 的旧服务。如果用StringNotEquals配合Null会更严格（不存在的也拒绝），但首次部署风险较高- SSO 和 Terraform AssumeRole 不受影响，因为操作的资源都在组织内
- 建议首次部署时 exclude
organizations:*和support:*，这两类 API 可能不携带 ResourceOrgID - 部署前用 IAM Access Analyzer 的
CheckNoNewAccess策略预检
二、资源侧控制：RCP
控制什么：限制资源只能被组织内的主体访问。与 SCP 互补——SCP 管”谁能操作”，RCP 管”谁能被操作”。
| 维度 | SCP | RCP |
|---|---|---|
| 作用对象 | IAM 主体 | 资源 |
| 限制方式 | 主体的权限天花板 | 资源的访问规则 |
| 覆盖服务 | 几乎所有服务 | S3、KMS、IAM Role、SQS、SNS |
注意事项：
- RCP 只覆盖 5 个服务，不能替代 SCP
- 跨账号请求必须同时通过 SCP 和 RCP 检查
- RCP 发布较新（2024 年底），Terraform 支持的稳定性需要验证
三、网络接入控制：VPC Endpoint Policy
控制什么：限制通过 VPC Endpoint 的 API 调用只能访问指定资源。
价值：即使 SCP 和资源策略（Bucket Policy 等）都被修改，Endpoint Policy 仍然生效——这是独立于 IAM 体系之外的第三层防御。
以 S3 Gateway Endpoint Policy 为例：
1
2
3
4
5
6
7
8
9
10
11
12
13
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::*",
"Condition": {
"ArnNotEquals": {
"aws:SourceArn": "arn:aws:s3:::audit-bucket/*"
}
}
}]
}
注意事项：
- 需要配合 Gateway Endpoint（S3/DynamoDB 免费）或 Interface Endpoint（其他服务，按小时计费）使用
- Endpoint Policy 只影响经过该 Endpoint 的流量，不限制公网 API 调用
- 适合保护特定桶或表，不适合做全局限制
四、网络位置控制：SCP aws:SourceVpc
控制什么：限制敏感 API 调用只能从指定 VPC 发起。
解决的问题：即使身份凭证在组织内，如果攻击者从公网拿到 AccessKey，仍然可以从任意位置调用 API。SourceVpc 把调用位置也纳入限制。
1
2
3
4
5
6
7
8
9
10
11
12
13
{
"Effect": "Deny",
"Action": ["s3:PutObject", "kms:Decrypt", "ec2:CopySnapshot"],
"Resource": "*",
"Condition": {
"StringNotEqualsIfExists": {
"aws:SourceVpc": "vpc-xxxxx"
},
"Null": {
"aws:SourceVpc": "true"
}
}
}
注意事项：
- 必须配合 VPC Interface Endpoint 使用——只有经过 Endpoint 的请求才携带
aws:SourceVpc Null: true的作用：当请求来自公网（无 SourceVpc 键）时直接拒绝- 不适合直接全局应用，会阻断所有公网 API 调用。建议先针对 S3 PutObject、KMS Decrypt 等敏感操作逐步收窄
- 与 SCP ResourceOrgID 配合时，先加上 ResourceOrgID 策略，稳定后再逐步启用 SourceVpc
五、操作可追溯：SCP sts:SourceIdentity
控制什么：强制跨账号角色切换时必须传递操作人身份信息。
解决的问题：没有 SourceIdentity 时，CloudTrail 只能看到”哪个角色执行了操作”，无法追溯到具体操作人。
1
2
3
4
5
6
7
8
9
10
{
"Effect": "Deny",
"Action": "sts:AssumeRole",
"Resource": "*",
"Condition": {
"Null": {
"sts:SourceIdentity": "true"
}
}
}
注意事项：
- 需要调用方在
sts:AssumeRole时主动设置SourceIdentity参数，SSO 和一些自动化工具可能不默认携带 - 开启前需要确认所有 AssumeRole 的调用方都支持设置 SourceIdentity
- 单纯靠 SCP 强制还不够，需要配合 CloudTrail 日志查询才体现价值
六、基础防护：S3 Block Public Access
控制什么：组织级和账号级禁止 S3 桶公开访问。这是最基础的防护，应该最先部署。
注意事项：
- 可以在组织级（ Management 账号）和账号级两个层面开启
- 组织级开启后，子账号无法自行关闭
- 开启前检查是否有现有的公开桶依赖
实施建议
P0（必须先做）：S3 Block Public Access + SCP aws:ResourceOrgID P1（强烈建议）：VPC Endpoint Policy + KMS Key Policy 组织限制 P2（建议做）：aws:SourceVpc SCP + S3 Data Events 审计 P3（按需）：sts:SourceIdentity + RCP
小结
Data Perimeter 的每一层策略覆盖一个不同的攻击维度：SCP ResourceOrgID 管主体、RCP 管资源、Endpoint Policy 管网络通道、SourceVpc 管调用位置、SourceIdentity 管操作追溯。没有单一策略能覆盖所有场景，分层组合才是关键。