审计日志来源：CloudTrail 与 Secrets Manager 自身日志
很多团队刚开始做 Secrets Manager 审计时，第一反应就是「去 CloudTrail 查一下」。这没错，但你仔细想想，CloudTrail 记录的是管理事件，而 Secrets Manager 内部其实还有一层更细粒度的日志——也就是 Secrets Manager 自身的审计日志。这两者有什么区别？什么时候该用哪个？
我在这章就帮你把这两个来源彻底拆开，看看各自能记什么、不能记什么，以及在实际落地时怎么搭配使用。
CloudTrail 能记录什么
CloudTrail 是 AWS 的审计基础设施，几乎所有 API 调用都能被它抓到。对于 Secrets Manager，CloudTrail 主要记录的是管理平面（Control Plane）操作。说白了，就是谁在什么时间、从哪个 IP、调用了哪个 API，结果成功还是失败。
具体来说，CloudTrail 能记录的操作包括：
CreateSecret— 创建密钥UpdateSecret— 更新密钥DeleteSecret— 删除密钥RotateSecret— 轮换密钥PutSecretValue— 写入密钥值GetSecretValue— 读取密钥值（注意：这是数据平面操作）DescribeSecret— 查看密钥元数据ListSecrets— 列出密钥TagResource/UntagResource— 打标签RestoreSecret— 恢复已标记删除的密钥
嗯，这里要注意：GetSecretValue 虽然属于数据平面操作，但 CloudTrail 默认也会记录它（只要开启）。所以很多安全团队靠 CloudTrail 来追踪谁读了哪些密钥。
我遇到过不少客户，以为 CloudTrail 只记管理事件，结果把 GetSecretValue 的审计漏了。好在 AWS 早就把这个包含进去了。但有个坑：CloudTrail 不记录密钥的明文值，只记录请求参数和响应大小。换句话说，你知道某人在 10:32 调用了 GetSecretValue，但你不知道他读到的密码具体是什么——除非你自己把响应内容存下来。
Secrets Manager 自身日志有什么不同
Secrets Manager 自身日志，其实指的是通过 AWS CloudTrail 的“数据事件”来捕获的，或者通过 Secrets Manager 的“审计日志”功能（也就是将日志发送到 CloudWatch Logs 或 S3）。
事实上，纯正的“Secrets Manager 自身日志”并不存在——AWS 并没有提供一个独立的日志系统叫“Secrets Manager 审计日志”。但大家口头上说的“自身日志”，通常指以下两种更细粒度的记录：
- CloudTrail 数据事件：可以单独开启对
GetSecretValue等数据操作的记录。注意：默认 CloudTrail 只记录管理事件，数据事件需要额外付费配置。 - Secrets Manager 的 CloudWatch Logs 集成：你可以让 Secrets Manager 在密钥轮换、版本创建等事件发生时，直接向 CloudWatch 发送日志。这是 API 调用日志之外的业务事件日志。
我个人的习惯是：把 CloudTrail 当作主干，把 CloudWatch Logs 集成当作补充。为什么呢？因为 CloudTrail 记录的是“谁调用了什么 API”，而 CloudWatch 日志能记录“密钥轮换时发生了哪些内部步骤”。
来看一个具体的对比表格：
| 对比维度 | CloudTrail（管理事件） | CloudTrail（数据事件） | Secrets Manager → CloudWatch 日志 |
|---|---|---|---|
| 是否默认开启 | 是（默认开启 Trail） | 否，需手动启用并付费 | 否，需手动配置事件订阅 |
| 记录内容 | API 名称、调用者、时间、源IP、请求参数 | 同上，但仅针对指定的数据操作（如 GetSecretValue） | 密钥版本变化、轮换开始/结束、轮换失败原因等内部事件 |
| 是否记录密钥明文 | 否 | 否 | 否（仅记录元数据） |
| 支持的密钥操作范围 | 管理操作（创建/删除/更新/轮换等） | 数据操作（读取/写入） | 轮换生命周期、版本管理 |
| 主要用途 | 变更审计、权限异常分析 | 读取频率分析、异常访问检测 | 轮换失败排查、密钥合规监控 |
| 成本考量 | 免费额度内（管理事件一般免费100MB） | 按数据事件量计费，高频读取可能成本较高 | 按 CloudWatch 日志写入量计费，一般较低 |
从表格能看出，三个来源覆盖的视角完全不同。我曾在一次事故复盘中发现，CloudTrail 管理事件完美记录了某人删除了一个密钥，但是删除的原因（误操作还是自动轮换脚本的 bug）完全看不出来。后来靠 Secrets Manager 的 CloudWatch 日志才定位到是轮换 Lambda 函数抛出异常导致自动删除了旧版本。
实际落地：如何搭配使用
我个人推荐三层的审计日志架构：
- 第一层：CloudTrail 管理事件 —— 必开。记录所有密钥的管理变更，这是合规审计的底线。
- 第二层：CloudTrail 数据事件 —— 按需开启。如果密钥敏感度高（比如数据库密码），建议开启对
GetSecretValue的数据事件审计，用于检测异常读取。 - 第三层：Secrets Manager 事件 → CloudWatch Logs —— 建议开。主要用于监控轮换健康状态，以及密钥版本的非标准操作。
我曾经遇到过这样的场景：某个密钥被反复轮换，导致下游服务频繁断开连接。CloudTrail 只记录了一堆 RotateSecret 调用，看不出问题出在哪。但 Secrets Manager 的 CloudWatch 日志里明确写了“轮换 Lambda 执行超时—重试中”。你看，这就是第三层的价值。
那些容易忽略的细节
再讲几个我踩过的坑：
- CloudTrail 数据事件需要指定资源类型 — 如果你只开启了数据事件，但没选择 Secrets Manager 作为资源类型，那么
GetSecretValue并不会被记录。别问我怎么知道的…… - Secrets Manager 的 CloudWatch 日志不是实时 — 通常有几分钟的延迟，紧急排查时要注意。
- 不要在两个来源中重复记录相同信息 — CloudTrail 数据事件已经记录了
GetSecretValue的调用时间和调用者，你再通过 CloudWatch 日志去记同样的 API 调用就浪费钱了。 - 轮换事件在 CloudTrail 中只显示“RotateSecret”调用 — 但轮换过程中的实际步骤（比如生成新版本、测试新版本）只会出现在 CloudWatch 日志里。
知识结构总览
为了让这些关系更直观，我画了一张图。你可以看到三个日志来源与 Secrets Manager 的交互关系：
从这张图你也可以看出，三个来源彼此独立，但又互补。没有哪个来源能覆盖所有场景，所以别偷懒只开一个。我刚开始做审计方案时也想过“CloudTrail 管理事件不就够了吗”，后来发现连轮换失败的具体原因都看不到，才老老实实把三层都搭起来。
总结几个实用建议
- 最低配置：至少开启 CloudTrail 管理事件，这是合规底线。
- 标准配置：管理事件 + Secrets Manager 到 CloudWatch 的日志（用于轮换监控）。
- 增强配置：在上面基础上，对高敏感密钥开启 CloudTrail 数据事件，专门追踪
GetSecretValue。 - 别忘了标签：在密钥上打标签（如 Environment=Production, Compliance=SOC2），然后在 CloudTrail 或 CloudWatch 日志中基于标签做过滤查询，会省很多事。
好了，关于审计日志来源，该说的我都说了。你下次配置 Secrets Manager 审计时，记得把这层结构记在心里。别只盯着 CloudTrail 一个来源，多一层日志，就多一分安全感。