跨账号拷贝加密S3对象时权限如何配置？

Question

在跨账号拷贝使用SSE-KMS加密的S3对象时，常见问题是如何正确配置KMS密钥策略与IAM权限以避免“Access Denied”错误。即使目标账号拥有S3写入权限，若KMS密钥未显式授权源账号或委托人解密权限，复制操作仍会失败。需确保源账号中执行复制的角色具有kms:Decrypt权限，且KMS密钥策略允许目标账号的kms:GenerateDataKey和kms:Encrypt操作。此外，S3复制策略需启用跨账号访问并正确设置存储桶策略。如何协调KMS与S3跨账号权限成为关键挑战。

Answer 1

一、背景与核心挑战：跨账号S3对象复制中的SSE-KMS权限协调

在AWS环境中，使用服务器端加密（SSE-KMS）保护S3对象已成为标准安全实践。然而，当需要在不同AWS账户之间复制这些加密对象时，常见的“Access Denied”错误往往源于KMS密钥策略与IAM权限之间的不匹配。

尽管目标账户可能已配置了对目标S3存储桶的完全写入权限，但若未正确设置KMS密钥的访问控制，复制操作仍会失败。根本原因在于SSE-KMS加密的数据在复制过程中需经历解密和重新加密两个阶段：

• 源账户角色需具备对原始KMS密钥的 kms:Decrypt 权限以读取数据；
• 目标账户需能调用源KMS密钥的 kms:GenerateDataKey 和 kms:Encrypt 操作，用于生成新密钥并加密写入目标存储桶的对象。

这种双重权限依赖使得仅配置S3存储桶策略远远不够，必须协同管理KMS密钥策略、IAM角色权限以及S3复制配置。

二、权限模型深度解析：KMS与S3的交互机制

理解跨账号复制中各组件的角色是解决问题的第一步。下表列出了关键操作及其所需权限归属：

操作阶段	执行账户	KMS操作	所需权限	配置位置
读取源对象	源账户	Decrypt	kms:Decrypt	IAM策略 + KMS密钥策略
生成新加密密钥	目标账户	GenerateDataKey	kms:GenerateDataKey	KMS密钥策略
加密目标对象	目标账户	Encrypt	kms:Encrypt	KMS密钥策略
写入目标存储桶	目标账户	-	s3:PutObject	S3存储桶策略
启动复制任务	源账户角色	-	s3:GetObject, s3:ReplicateObject	源S3存储桶策略

三、典型错误场景与诊断路径

实践中，“Access Denied”错误常伴随模糊的CloudTrail日志信息。以下是常见错误模式及排查思路：

1. 错误码：KMS.AccessDeniedException —— 表明执行角色缺少对应KMS操作权限，应检查IAM策略是否包含kms:Decrypt且KMS密钥策略是否允许该委托人。
2. S3异常：InvalidArgument (Server side encryption S3 managed key requires AWS KMS key) —— 通常因未指定正确的SSE-KMS CMK导致。
3. 复制中断但无明确报错 —— 可能因KMS策略未授权目标账户的GenerateDataKey权限，建议启用AWS CloudTrail进行API调用追踪。

可通过以下命令验证KMS密钥策略是否开放跨账号访问：

aws kms get-key-policy --key-id <your-kms-key-id> --policy-name default --query Policy --output text | jq .

四、解决方案架构：实现安全可控的跨账号复制

为确保成功复制，需从三个维度同步配置：

1. KMS密钥策略配置（关键步骤）

必须显式允许源账户的IAM角色执行Decrypt，并允许目标账户使用密钥生成数据密钥。示例策略片段如下：

{
  "Sid": "Allow cross-account decrypt and encrypt",
  "Effect": "Allow",
  "Principal": {
    "AWS": [
      "arn:aws:iam::SOURCE_ACCOUNT_ID:role/CopyRole",
      "arn:aws:iam::DESTINATION_ACCOUNT_ID:root"
    ]
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey",
    "kms:Encrypt"
  ],
  "Resource": "*"
}

2. IAM角色权限绑定

在源账户中，赋予执行复制的角色以下最小权限：

• s3:GetObject
• s3:ReplicateObject
• kms:Decrypt（针对源KMS密钥）

3. S3存储桶策略启用跨账号复制

目标存储桶需允许源账户PutObject操作，并启用跨区域复制（CRR）或批量操作策略。例如：

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Principal": {"AWS": "arn:aws:iam::SOURCE_ACCOUNT_ID:role/CopyRole"},
        "Action": "s3:PutObject",
        "Resource": "arn:aws:s3:::destination-bucket/*"
    }]
}

五、可视化流程：跨账号SSE-KMS复制调用链

以下Mermaid流程图展示了整个复制过程中的权限验证路径：

graph TD
    A[启动复制任务] --> B{源账户是否有GetObject权限?}
    B -- 是 --> C{源角色是否有kms:Decrypt权限?}
    C -- 是 --> D[KMS解密数据]
    D --> E{目标账户是否有kms:GenerateDataKey权限?}
    E -- 是 --> F[KMS生成新数据密钥]
    F --> G{目标账户是否有s3:PutObject权限?}
    G -- 是 --> H[加密并写入目标S3]
    H --> I[复制完成]
    B -- 否 --> J[Access Denied]
    C -- 否 --> J
    E -- 否 --> J
    G -- 否 --> J

六、最佳实践与运维建议

为提升系统安全性与可维护性，推荐以下做法：

• 使用客户托管CMK而非AWS托管密钥（SSE-S3），以便精细控制跨账号访问；
• 通过AWS Organizations结合资源策略实现集中式密钥治理；
• 启用S3 Replication Time Control (RTC) 提供SLA保障；
• 定期审计KMS密钥策略变更，防止权限蔓延；
• 利用AWS Config规则监控非合规的加密配置；
• 在VPC Endpoint级别限制KMS API访问范围；
• 采用标签策略统一管理跨账户密钥共享生命周期；
• 对敏感数据复制启用S3 Object Lock与MFA Delete保护；
• 结合AWS CloudFormation或Terraform实现策略即代码（Policy as Code）；
• 设置CloudWatch告警响应KMS拒绝事件。