Source: Dev.to

AWS SCP 与 RCP 解析：何时使用服务控制策略（SCP）与资源控制策略（RCP）

简介

在 AWS Organizations 中，服务控制策略（SCP） 和 资源控制策略（RCP）（有时也称为资源级别策略）是两类用于限制和管理权限的机制。虽然它们的目标相似——防止用户或角色执行未授权的操作，但它们的作用范围、执行层级以及使用场景却大相径庭。本文将对两者进行对比，帮助你判断在何种情况下应该使用 SCP，何种情况下应该使用 RCP。

什么是服务控制策略（SCP）？

• 层级：SCP 作用于 组织单元（OU）、账户 或 根，在整个组织层面进行权限限制。
• 目的：它们 限制 组织中所有 IAM 实体（用户、角色、组）能够获得的最大权限集合。即使某个 IAM 实体拥有宽松的 IAM 策略，SCP 仍然可以将其权限“削减”。
• 特性
  • 白名单/黑名单：可以使用 Allow 或 Deny 语句来显式允许或拒绝操作。
  • 不可覆盖：Deny 语句在 SCP 中永远不可被覆盖。
  • 不授予权限：SCP 本身不授予任何权限，只是 上限。

示例 SCP（保持原样，不翻译代码块）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootAccess",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalAccount": "123456789012"
        }
      }
    }
  ]
}

什么是资源控制策略（RCP）？

• 层级：RCP 直接附加在 AWS 资源（如 S3 桶、KMS 密钥、SQS 队列等）上。
• 目的：它们 授予 或 限制 对特定资源的访问权限，通常与 IAM 策略配合使用形成细粒度的访问控制。
• 特性
  • 细粒度：可以基于资源属性（标签、ARN、条件键）进行权限控制。
  • 可覆盖：如果 IAM 策略中有 Allow，而资源策略中有 Deny，Deny 会优先生效。
  • 授予权限：RCP 可以直接授予跨账户访问权限，这在跨账户共享 S3 桶或 KMS 密钥时尤为常见。

示例 RCP（保持原样，不翻译代码块）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountRead",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:root"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

关键区别

何时使用 SCP？

1. 全局安全基线：当你想在整个组织层面强制执行安全最佳实践（例如，强制启用 MFA、禁止删除 CloudTrail）时。
2. 合规需求：满足 PCI‑DSS、HIPAA 等合规框架要求的“最小权限”上限。
3. 跨账户限制：阻止子账户自行创建具有管理员权限的角色或策略。
4. 防止意外破坏：例如，阻止在任何账户中关闭 S3 版本控制或删除关键 KMS 密钥。

提示：SCP 只能 削减 权限，不能 授予 权限。因此，即使你在根账户上没有显式的 Allow，只要该账户的 IAM 策略已经授予了权限，SCP 仍然可以把它们削减到更低的水平。

何时使用 RCP？

1. 跨账户资源共享：当你希望让另一个 AWS 账户访问你的 S3 桶、RDS 实例或 KMS 密钥时。
2. 细粒度访问控制：例如，仅允许特定 IAM 角色读取 S3 桶中的 logs/ 前缀。
3. 资源级别的合规：对特定资源施加额外的合规约束（如仅允许特定 VPC 端点访问 DynamoDB 表）。
4. 临时授权：通过在资源上添加短期的 Allow 策略来实现临时访问，而不必更改全局 IAM 策略。

最佳实践

• 先定义组织级别的安全基线（SCP），再在资源层面细化访问（RCP）。
• 使用白名单（Allow）SCP 来明确哪些服务可以被使用，默认拒绝其余所有操作。
• 在 RCP 中使用条件键（如 aws:SourceVpce、aws:PrincipalTag）实现更精细的控制。
• 定期审计：利用 AWS Config 规则或 IAM Access Analyzer 检查是否有策略冲突或过宽的权限。
• 分离职责：让安全团队负责 SCP，业务团队负责各自资源的 RCP，避免权限争用。

结论

• SCP 是组织层面的“权限上限”，适用于 全局安全、合规 与 防止破坏。
• RCP 是资源层面的“细粒度授权”，适用于 跨账户共享、特定资源访问控制 与 临时授权。

通过在合适的层级使用正确的策略类型，你可以在保持安全的同时，提供灵活且可审计的访问模型。

---

本文基于 AWS 官方文档与实践经验撰写，旨在帮助 AWS Organizations 使用者更好地理解并运用 SCP 与 RCP。

使用资源控制策略（RCP）实现现代 AWS 治理

现代 AWS 环境是为规模而构建的——多个账户、共享团队以及需要跨边界运行的资源。虽然这种灵活性提升了敏捷性，但也带来了关键的治理挑战：即使 IAM 策略和 SCP 已正确配置，资源策略仍可能配置错误，导致访问范围过宽或出现意外暴露。

正是为了解决这一缺口，**资源控制策略（RCP）**应运而生。

RCP 的作用

RCP 让您能够在资源上直接强制执行不可协商的规则，例如：

• 该资源永远不能在组织外部共享。
• 只有获批的身份才能在此承担角色。
• 即使是管理员也无法破坏这些规则。

注意： RCP 并不取代 IAM 或 SCP——它们填补了最后缺失的治理层。

实操演示

⚠️ 强烈建议在开发/测试账户中先测试 RCP，再将其应用到生产环境。不要直接在根级别应用。

本演示涵盖两个场景：

1. 在所有 S3 存储桶上强制仅使用 HTTPS 访问
2. 阻止外部账户解密 KMS 密钥（或禁用跨账户使用 KMS 密钥）

场景 #1 – 在 S3 存储桶上强制仅使用 HTTPS

1. 创建一个权限过宽的存储桶策略

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "S3rcppolicy",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::XXXX-XXXXX-demo-XXXXXXX/*"
    }
  ]
}

该存储桶包含一个内容为 RCP HTTPS test 的简单文件。

2. 验证 HTTP 与 HTTPS 均可工作

• HTTP 测试

  

• HTTPS 测试

  

3. 在账户层级应用仅允许 HTTPS 的 RCP

4. 观察结果

• HTTP 请求 → AccessDenied（在截图中已高亮）

  

• HTTPS 请求 → 成功

要点： 一旦 RCP 生效，它会约束现有以及新建的资源策略。在强制 RCP 之前，请务必检查哪些资源是有意在组织内共享的。

场景 #2 – 阻止外部账户解密 KMS 密钥

本示例阻止除在密钥策略中白名单列出的主体之外的任何主体解密 AWS KMS 密钥。

1. 示例 KMS 密钥策略（授予跨账户访问）

{
  "Sid": "Enable IAM User Permissions",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::714XXXXXXXXX:root"
  },
  "Action": "kms:*",
  "Resource": "*"
},
{
  "Sid": "Allow use of the key",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::599XXXXXXXXX:root"
  },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:ReEncrypt*",
    "kms:GenerateDataKey*",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}

2. 在未使用 RCP 时测试解密

• 在 账户 A（714XXXXXXXXX）使用该 KMS 密钥 加密文件。

• 从以下两个账户尝试 解密：

  • 账户 A（同一账户）——成功。
  • 账户 B（599XXXXXXXXX）——也成功，因为策略中已授予跨账户权限。

账户 A 的解密结果

账户 B 的解密结果（为节省篇幅已截断）

3. 应用 禁止跨账户解密 的 RCP

在账户或 OU 级别附加相应的 RCP 后，账户 B 再尝试解密密钥时会被拒绝，而 账户 A 仍保留使用该密钥的权限。

结果： RCP 强制执行了“最大权限”原则，阻止了未授权的跨账户解密。

在 KMS 资源上设置规则，覆盖对任何外部主体的宽松密钥策略。

摘要

• IAM 控制 谁 可以对 哪些 资源执行 什么 操作。
• SCP 设置 IAM 主体在账户/组织单元中可能拥有的 最大 权限。
• RCP 设置可以应用于 特定资源 的 最大 权限，无论调用者是谁。

通过添加 RCP，您可以弥补最后的治理缺口，确保即使是完美编写的 IAM 策略或 SCP 也无法被错误配置的资源策略绕过。请在非生产账户中彻底测试，然后有策略地推广，以保护您最关键的资源。

将 RCP 应用于账户 A

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": [
    "kms:Decrypt",
    "kms:Encrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalAccount": [
        "714XXXXXXXXX"
      ]
    }
  }
}

在实施资源控制策略（RCP）之前

RCP 是 AWS 的强大功能，用于设计数据边界。它们可以保护数据、阻止泄露并强制执行真实的云边界——但如果不慎部署，也可能导致生产工作负载中断。

我们必须在将 RCP 应用于关键工作负载之前先创建并测试它们。
在部署任何 RCP 之前，请确保它通过了正式的测试周期。

需要测试的内容

使用 AWS IAM Access Analyzer 了解：

• 当前哪些资源是公开的
• 哪些资源被外部共享
• 哪些身份依赖跨账户访问

这有助于避免破坏合法的访问路径。

随后使用以下工具验证策略逻辑：

• IAM Policy Simulator
• 受控的沙箱账户
• 生产前的开发组织单元（OU）

还要测试 服务控制策略（SCP）与 RCP 之间的交互。

记住： 任意一个的 deny 都会阻止访问。

其他高影响力的 RCP 用例可供探索

AWS 维护了一个极好的 真实世界 RCP 模式仓库：

• 🔐 强制仅组织内部的 STS 访问
• 🔑 锁定 OIDC 提供商（GitHub Actions 等）
• 🗄️ 阻止数据存储的外部共享

如果审慎使用，RCP 能够弥补数据访问、跨账户信任和配置错误方面的最后漏洞。

好的安全并不是信任人，而是设计出即使出现错误也能保持安全的系统。

感谢阅读——希望这能帮助您构建更安全、更具弹性的 AWS 环境。