📚 课程目录第4章 CloudTrail记录Secrets事件

第4章：CloudTrail记录Secrets事件——哪些Secrets操作会被记录

好，我们进入正题。

很多人一开始接触CloudTrail和Secrets Manager的集成时，会觉得——“不就是记录一下谁调用了GetSecretValue吗？”

嗯，这个想法对，但不全对。

我在项目里见过不止一次，团队把审计范围缩得太小，结果出了安全问题才发现漏了关键事件。

这一章，咱们就彻底搞清楚：Secrets Manager的哪些操作会被CloudTrail记录？我把它们分成了几大类，方便你记忆和使用。

4.1 核心分类：读、写、管理、权限

我个人习惯把Secrets事件分为四类。你想想看，所有操作都离不开这四个维度：

事件类别	典型操作	安全敏感度	我是否建议重点监控
读取类	GetSecretValue, BatchGetSecretValue	极高	是，必须监控
写入类	PutSecretValue, UpdateSecret, RotateSecret	高	是，必须监控
管理类	CreateSecret, DeleteSecret, RestoreSecret	中高	建议监控
权限类	PutResourcePolicy, DeleteResourcePolicy	高	是，必须监控

我的经验：很多团队只盯着GetSecretValue，却漏掉了PutResourcePolicy。有人偷偷给外部账号加了读取权限，这比直接读取一次密钥还要危险。

4.2 逐一拆解：最重要的几个事件

咱们一个一个来看。我不会列所有API，那太枯燥了。我只挑你大概率会遇到的，并且说说我在实战中踩过的坑。

4.2.1 GetSecretValue —— 审计的第一道防线

这个不用多说，谁读了我的密钥？什么时候读的？从哪里读的？

CloudTrail会记录以下关键字段：

eventName: GetSecretValue
requestParameters.secretId: 被读取的密钥名称或ARN
sourceIPAddress: 调用方的IP
userIdentity.arn: 调用方身份
responseElements: 注意——这里不会包含密钥明文！

重点：CloudTrail不会记录GetSecretValue返回的明文值。它只记录“有人执行了这个操作”，但看不到具体内容。如果你需要知道泄露了什么……嗯，那已经晚了。所以预防和实时告警更重要。

我曾经遇到一个案例：某天半夜3点，一个Lambda函数开始疯狂调用GetSecretValue。CloudTrail日志里清晰记录了IP来自一个不该出现的地域。如果没有这个记录，我们根本发现不了。

4.2.2 PutSecretValue 和 UpdateSecret —— 密钥被改了，你知道吗？

这两个操作很相似，但有一个关键区别：

操作	场景	CloudTrail记录差异
`PutSecretValue`	创建新版本密钥	记录新的版本ID (`VersionId`)
`UpdateSecret`	更新密钥的描述或KMS密钥	记录更新前后的描述信息

我个人习惯：凡是PutSecretValue，必告警。因为这说明有人在主动写入一个新的密钥版本。如果是恶意操作，这很可能就是数据泄露的前奏。

4.2.3 RotateSecret —— 自动轮换不是你不管的理由

很多人觉得轮换是自动化操作，所以不用管。

错。

CloudTrail会记录RotateSecret事件。我建议你检查一下：

轮换是否成功？—— 如果有轮换失败，你要立刻处理
谁触发了轮换？—— 是Lambda？还是某个人手动点了一下？
轮换频率是否正常？—— 如果一天轮换10次，那有问题

  核心原则：不因为操作是“自动化”的就放弃审计。自动化操作也可能是被攻陷的账户在替你干活。

4.2.4 权限相关：PutResourcePolicy 和 DeleteResourcePolicy

这两个事件，几乎是所有安全工程师的噩梦。

PutResourcePolicy允许你给一个密钥直接附加资源策略。这意味着你可以跨账号授权。

我见过一次真实案例：有人在Secrets Manager上写了一条策略，允许另一个AWS账号读取该密钥。整个过程只用了3秒。CloudTrail留下了完整的记录——包括策略内容的主体部分。

{
  "eventVersion": "1.08",
  "eventName": "PutResourcePolicy",
  "requestParameters": {
    "secretId": "arn:aws:secretsmanager:us-east-1:111111111111:secret:prod-db-password-xxxxxx",
    "resourcePolicy": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Principal\":{\"AWS\":\"arn:aws:iam::222222222222:root\"},\"Action\":\"secretsmanager:GetSecretValue\",\"Resource\":\"*\"}]}"
  }
}

看到没有？策略里写的是让222222222222这个账号获取密钥。这就是一个非常典型的外部共享事件。

4.2.5 删除相关：DeleteSecret 和 RestoreSecret

删除操作需要特别关注。

CloudTrail会记录DeleteSecret事件，但要注意：Secrets Manager默认有30天的恢复窗口。也就是说，删除后你不会立刻丢失数据。但如果你不恢复，30天后数据就真的没了。

DeleteSecret：记录删除时间和恢复截止日期
RestoreSecret：记录恢复操作的时间

我的建议：DeleteSecret必须触发高优先级告警。哪怕是无意操作，你也要尽快恢复。

4.3 哪些操作不会被CloudTrail记录？

这个问题，很多人不关心。但我觉得很重要。

说白了，CloudTrail不是万能的。以下情况它不会记录：

VPC内流量：如果Secrets Manager通过VPC Endpoint访问，并且你启用了加密网络流量，CloudTrail只能记录API调用，不能记录网络包内容
密钥明文：再次强调，GetSecretValue的返回结果不会被记录
控制台页面操作：你在控制台上点“读取密钥”，底层调用的还是API，所以会记录。但如果你只是查看密钥列表，不打开具体内容，可能只有ListSecrets事件

我曾经被问过一个问题：“CloudTrail能挡住黑客吗？”

答案是不能。CloudTrail是事后审计，不是事前防护。它告诉你“谁来过”，但不阻止“谁来”。这一点要搞清楚。

4.4 我建议你重点关注的事件清单

这张表，建议你截图或者记下来。以后做告警规则的时候直接参考：

事件名称	风险等级	建议行为	我个人的经验
GetSecretValue	极高	实时告警+异常行为分析	一定要加频率检测，比如1分钟内超过5次就要报警
PutSecretValue	极高	实时告警	非预期的写入几乎都是问题
PutResourcePolicy	极高	实时告警+人工审批	跨账号授权一定要有流程
DeleteSecret	高	实时告警+自动恢复流程	可以写一个自动化恢复脚本
RotateSecret	中	监控轮换结果	轮换失败要立刻通知

4.5 本章知识结构

下面这张图，把Secrets事件的核心分类和关系画了出来。你可以看到读取、写入、管理、权限四大块是如何连接起来的。

4.6 一个小总结

到这，你应该清楚了：CloudTrail记录的Secrets事件，不是只有GetSecretValue那么简单。

写入、权限、管理——每个类别都有自己的“危险时刻”。

我个人经验是：先把PutResourcePolicy和PutSecretValue的告警做好。这两件事一旦发生恶意行为，损失往往比GetSecretValue更大。因为前者给你开了后门，后者改了密钥内容让所有人都无法正常工作。

下一件事，咱们得把这些日志用可视化工具展示出来。不然光看JSON，眼睛会瞎的。