📚 课程目录第4章 CloudTrail日志加密配置

CloudTrail 日志加密配置

日志加密这事，说简单也简单，说复杂能让你折腾一整天。我在排查过不少加密故障后，发现大部分人都是在配置阶段埋下了雷。今天我们就来拆解一下 SSE-S3 和 SSE-KMS 这两种方式，看看密钥怎么选，Bucket Policy 怎么写才不翻车。

两种加密方式，怎么选？

CloudTrail 支持两种服务端加密：SSE-S3 和 SSE-KMS。说白了，区别就在于谁来管密钥。

特性	SSE-S3	SSE-KMS
密钥管理	AWS 自动管理	你通过 KMS 管理
额外成本	免费	KMS 调用费用
访问控制	仅 S3 桶策略控制	桶策略 + KMS 密钥策略
审计能力	有限	可通过 CloudTrail 审计密钥调用
密钥轮换	自动	可手动或自动轮换

我的建议：合规要求严格的场景，选 SSE-KMS。普通日志归档，SSE-S3 完全够用，还省成本。

SSE-S3 配置

SSE-S3 是最省心的方案。创建追踪时勾选「启用 SSE-S3」即可，或者通过控制台直接对存储桶开启默认加密。

但这里有个坑——默认加密不等于 CloudTrail 自动用 SSE-S3。CloudTrail 写日志时，会读取存储桶的默认加密配置。如果你后来改了默认加密，新日志可能会用不同方式加密。

注意：SSE-S3 不提供单独的密钥审计日志。如果你需要追踪谁解密了日志，那就别选 SSE-S3。

SSE-KMS 配置

SSE-KMS 才是重头戏。我个人习惯在生产环境用它，因为控制力更强。但配置起来需要注意几个关键点。

第一步：创建 KMS 密钥

建议用对称加密密钥，别图新鲜用非对称的——CloudTrail 不支持。密钥策略要明确允许 CloudTrail 服务使用。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": [
        "kms:GenerateDataKey*",
        "kms:Decrypt"
      ],
      "Resource": "*"
    }
  ]
}

第二步：选择密钥时注意区域

嗯，这里要注意。KMS 密钥是区域性的。跨区域追踪只能使用单区域密钥，多区域密钥会报错。我曾见过同事选了多区域密钥，结果追踪状态一直显示「失败」。

第三步：附加桶策略

SSE-KMS 的桶策略和 SSE-S3 不一样，除了写日志的权限，还得加上 kms:GenerateDataKey 和 kms:Decrypt。

避坑指南：我曾经配置完后能写日志，但日志文件始终是 0 字节。排查了半天才发现是 KMS 密钥没有给云监控的告警权限。

Bucket Policy 配置要点

不管选哪种加密，Bucket Policy 都要写对。我总结了一个三要素清单：

主体：通常是 cloudtrail.amazonaws.com
动作：s3:PutObject（写日志）
条件：检查加密头（可选但推荐）

下面是一个完整的桶策略示例：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "cloudtrail.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-cloudtrail-logs/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}

关键点：条件里指定 aws:kms 会强制 CloudTrail 使用 SSE-KMS 加密。如果你用 SSE-S3，这里就写 AES256。不写条件的话，CloudTrail 可能偷偷用不加密的方式写入。

常见加密故障与排查

你想想看，加密配置出问题最典型的症状是什么？日志不出现，或者出现 0 字节文件。

我整理了一个诊断流程：

检查 CloudTrail 追踪状态——是不是「失败」？
查看 S3 桶的权限——CloudTrail 服务有写权限吗？
检查 KMS 密钥策略——如果用了 SSE-KMS，密钥策略允许 cloudtrail.amazonaws.com 执行 GenerateDataKey 和 Decrypt 了吗？
验证桶策略的条件——是不是强制了错误的加密方式？
查看 CloudTrail 自身的日志——对，就是日志的日志，开启 CloudTrail 的日志验证功能。

曾经有个坑：客户说日志写不进去，我查了三天，最后发现是 KMS 密钥被删了。CloudTrail 不会自动告诉你密钥不见了，它只会默默把日志丢掉。所以，密钥生命周期管理一定要上心。

密钥轮换策略

SSE-KMS 支持自动轮换和手动轮换。自动轮换每年一次，新日志会用新密钥加密，但旧日志还保留在旧密钥下。

轮换方式	频率	注意点
自动轮换	每年一次	旧密钥必须保留，否则旧日志不可读
手动轮换	按需	需要自己创建新密钥并更新 CloudTrail 配置

我建议：除非你有特殊合规需求，否则用自动轮换就够了。手动轮换容易忘，一忘就出事。我上次手动轮换后忘了更新桶策略，结果日志停了整整一周才发现。

加密配置这事，一次配好，后面基本不动。但一旦出了问题，排查起来挺折腾的。我个人建议在配置完成后，务必做一次端到端验证——手动触发一条测试日志，确认它被正确加密写入，并且你能用正确的权限读取它。