AWS Data Perimeter 实战：多层数据外泄防护体系

什么是 Data Perimeter

Data Perimeter（数据边界）是 AWS 在 2021 年 re:Invent 提出的安全概念，核心思想是：不在组织内的资源不能访问我的数据，我的数据也不能流出到组织外。它不是单一的策略，而是一组多层防护机制的组合。

在实际的多账号架构中，数据外泄可能发生在多个层面：合法的跨账号授权被滥用、AccessKey 泄露后从公网调用 API、S3 桶策略配置错误导致公开等。单一防护手段无法覆盖所有场景，需要构建纵深防御体系。

整体架构

┌─────────────────────────────────────────────────────────┐
│                   组织级：SCP                            │
│  禁止退出组织、禁止篡改审计服务、禁止跨组织资源访问      │
├─────────────────────────────────────────────────────────┤
│                   资源侧：RCP                            │
│  限制 S3/KMS/SQS/SNS 只能被组织内主体访问               │
├─────────────────────────────────────────────────────────┤
│               账号级：S3 Block Public Access             │
│              全账号开启四层封锁                          │
├─────────────────────────────────────────────────────────┤
│               VPC 级：Endpoint Policy                    │
│          Gateway Endpoint 限制只允许特定桶/表            │
├─────────────────────────────────────────────────────────┤
│              密钥级：KMS Key Policy                      │
│         限制解密操作只能由组织内主体执行                 │
└─────────────────────────────────────────────────────────┘

第一层：SCP（服务控制策略）— 组织级护栏

SCP 是 Data Perimeter 的第一道防线，在组织层面划定边界。它作用于所有账号的所有主体（包括 Root 用户），无法被账号管理员绕过。

生效策略概览

以下 10 条 SCP 覆盖 21 个 Sid（Statements），构成完整的防护面：

#	策略名	核心禁止操作	豁免	范围
1	禁止退出组织	退出组织、关闭账号	无	Root OU
2	禁止篡改审计服务	停止/删除 CloudTrail、Config、GuardDuty、Security Hub、Inspector	Terraform role	Root OU
3	禁止组织共享篡改	禁用 RAM 组织共享、删除 Resource Explorer 索引	无	Root OU
4	禁止 Root 操作（非 BreakGlass OU）	Root 用户除密码/MFA/账单/支持外全部禁止	无	非 BreakGlass OU
5	禁止不安全数据创建	未加密的 S3 上传/EBS/RDS、公开 S3 ACL/Policy、公开 EBS 快照	无	Root OU
6	禁止 IAM AccessKey 创建	在受限 OU 中创建 IAM 访问密钥	无	受限 OU
7	保护审计存储	删除/修改审计 S3 桶、审计日志对象、审计 CloudWatch 日志组	Terraform role	Root OU
8	区域限制	非 ap-northeast-1 操作（全局服务除外）	无	非 BreakGlass OU
9	禁止跨组织资源访问	aws:ResourceOrgID 不匹配时拒绝 S3/KMS/EC2 操作	无	Root OU
10	强制 Permission Boundary	创建 IAM Role 必须绑定 Permission Boundary	Terraform role	Workloads/Prod OU

关键策略详解

禁止跨组织资源访问（策略 9）是 Data Perimeter 的核心。它使用 aws:ResourceOrgID 条件键，配合 StringNotEqualsIfExists 写法：

{
  "Effect": "Deny",
  "Action": ["s3:*", "kms:*", "ec2:*"],
  "Resource": "*",
  "Condition": {
    "StringNotEqualsIfExists": {
      "aws:ResourceOrgID": "o-xxxxxxxxxx"
    }
  }
}

StringNotEqualsIfExists 的含义是：只有请求携带 aws:ResourceOrgID 时才检查，不携带的请求自动放行。这样既覆盖了大多数主流服务，又不会误伤不支持该条件键的旧服务。

不需要排除 organizations:*。Organizations 的 API 操作的目标资源都属于本组织，ResourceOrgID 必定匹配。

豁免模式

所有 SCP 豁免统一使用 ArnNotLike 条件：

terraform_role_arn_patterns = [
  "arn:aws:iam::*:role/OrganizationAccountAccessRole",
  "arn:aws:iam::*:role/GitHubActionsTerraformRole",
]

涉及 9 个 Sid，覆盖 Terraform 需要维护的资源：Config 配置、GuardDuty/Security Hub/Inspector 设置、审计存储保护、Permission Boundary 管理。

第二层：RCP（资源控制策略）— 资源侧互补

RCP（Resource Control Policies）是 AWS 2024 年底发布的新能力。与 SCP 从主体侧限制不同，RCP 从资源侧限制——它直接附着在资源上，控制该资源能被谁访问。

SCP vs RCP

维度	SCP	RCP
作用对象	账号/OU 内的所有主体	资源本身
限制方式	主体侧拒绝	资源侧拒绝
绕过风险	无法被账号管理员绕过	无法被资源拥有者绕过
覆盖范围	几乎全部 AWS 服务	S3、KMS、IAM Role、SQS、SNS
发布状态	成熟	2024 年底发布，Terraform 支持已验证

当前 RCP 配置

策略	目标	状态
RCP-S3	限制 S3 只能被组织内主体访问	已启用
RCP-KMS	限制 KMS 只能被组织内主体访问	已启用
RCP-IAM-Role	限制 IAM Role 只能被组织内 Assume	暂停（会误伤 SSO）
RCP-SQS	限制 SQS 只能被组织内主体访问	暂停
RCP-SNS	限制 SNS 只能被组织内主体访问	暂停（ap-northeast-1 暂不支持）

RCP 与 SCP 是互补关系，不是重叠关系。SCP 从主体侧说”你不能访问组织外的资源”，RCP 从资源侧说”组织外的主体不能访问我”。两层同时生效时，即使某个账号的 SCP 被意外放宽，RCP 仍然能阻止外部访问。

第三层：S3 Block Public Access — 账号级兜底

S3 Block Public Access 是 AWS 提供的账号级安全开关，四层封锁全部开启：

设置项	效果
BlockPublicAcls	禁止授予公开 ACL
IgnorePublicAcls	忽略已有公开 ACL
BlockPublicPolicy	禁止声明公开 Bucket Policy
RestrictPublicBuckets	限制公开桶只能通过 AWS 服务访问

覆盖 Management、Log-Archive、Audit、Emergency、Billing、Prod、Network 全部 7 个账号。这层防护虽然基础，但能有效防止因 Bucket Policy 配置错误导致的数据泄露——即便 SCP 和 RCP 都被绕过，账号级封锁仍然是最后一道屏障。

第四层：VPC Endpoint Policy — 网络级精控

VPC Endpoint Policy 在网络层面做最后一公里的限制。即使攻击者拿到 AccessKey，如果请求不是从指定 VPC 发起的，也会被拒绝。

典型的 S3 Gateway Endpoint Policy：

{
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::audit-bucket/*",
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-xxxxxxxx"
        }
      }
    }
  ]
}

这层防护在 SCP + Bucket Policy 之间提供了第三层防御——即使 SCP 和 Bucket Policy 都被修改，Endpoint Policy 仍然生效。

各层防护对比总结

防护层	粒度	可绕过性	实施难度	覆盖范围
SCP	账号/OU	极低（组织级强制）	低	几乎所有服务
RCP	资源	极低（资源侧强制）	中	5 个服务
S3 Block Public Access	账号	低（账号级）	低	S3 公开访问
VPC Endpoint Policy	网络	低（网络层）	中	特定服务
KMS Key Policy	密钥	低（密钥级）	中	KMS 加密

优先级建议：

P0: SCP `aws:ResourceOrgID` + S3 Block Public Access  ← 基础必做
P1: VPC Endpoint Policy + KMS Key Policy              ← 强烈建议
P2: RCP + sts:SourceIdentity 强制                      ← 增强防护

小结

Data Perimeter 不是单一策略，而是一组从组织级到资源级再到网络级的纵深防御组合。在实践中最关键的认知是：每层防护都有其盲区，没有哪一层是银弹。SCP 管不了资源侧的外部访问，RCP 管不了主体侧的越权操作，网络策略管不了组织内的合法请求。只有多层叠加，才能形成真正有效的数据外泄防护体系。