📚 课程目录第1章 Secrets Manager审计概览

1. Secrets Manager 审计概览：什么是审计字段，为什么重要

大家好，我是这次课程的主讲。今天我们来聊聊 AWS Secrets Manager 的审计字段——老实说，这个主题在圈子里聊得不多，但一旦出问题，你会后悔没早点搞清楚。

先说说我的经历。几年前我负责一个金融系统的秘密管理迁移，当时我们只是把密钥存进 Secrets Manager，觉得万事大吉。直到合规审计找上门，问我们「上周三凌晨 2:47 谁读了这个数据库凭证？」我整个人都傻了——日志里只有一串看不懂的 ID，根本没法追溯。那时候我才意识到，审计字段不是「锦上添花」，而是保命的东西。

1.1 到底什么是审计字段？

说白了，审计字段就是 Secrets Manager 留给你的「现场脚印」。每次你在 Secrets Manager 上做操作——不管是创建密钥、轮换密码、还是某台 EC2 读取了密钥——AWS 都会自动记录下这次行为。这些记录里藏着操作的时间、发起人的身份、来源 IP、用的 API 名称等等。

我习惯把这些字段分成三类：

分类	包含内容	举个实际例子
身份字段	谁干的？	userIdentity.arn = arn:aws:iam::123456789012:user/zhangsan
行为字段	干了什么？	eventName = GetSecretValue, requestParameters.secretId
环境字段	啥时候、从哪儿干的？	eventTime, sourceIPAddress, userAgent

嗯，你可能已经注意到了——这些字段不是 Secrets Manager 自己「发明」的。它们其实是 AWS CloudTrail 帮我们捕获的。CloudTrail 就像 AWS 的「行车记录仪」，所有 API 调用都清晰记录。而 Secrets Manager 的审计字段，正是从 CloudTrail 事件里提取的核心信息。

一个常见的误区： 很多人以为 Secrets Manager 控制台里有内置的审计日志。其实是错误的。你所有 Secrets Manager 操作的审计数据都存储在 CloudTrail 中，需要主动开启 CloudTrail 跟踪才能捕获。默认只保留 90 天的事件历史（在 Event history 里），但那是不可导出的。我建议你至少创建一个持续写入 S3 的跟踪，长期存储审计字段。

1.2 为什么审计字段如此重要？

你可能觉得，密钥存进 Secrets Manager 不就好了？审计字段有没有无所谓。但你想想看——万一出现下面这些场景：

安全事件响应：某天你的数据库被删了，怀疑是密钥泄露。你怎么判断有谁、在什么时候读过那个数据库密码？审计字段就是最直接的证据。
内部合规检查：金融、医疗行业通常要求「最小权限」和「不可否认性」。审计字段能证明某个操作确实是某个 IAM 用户发起的，而不是被别人冒用。
成本与异常洞察：我曾经在项目中通过审计字段发现，某台测试环境的 EC2 每小时调用 GetSecretValue 超过 2000 次——直接导致 Secrets Manager API 调用费用暴涨。如果没有审计字段，这种异常根本抓不住。

说白了，审计字段让你在出事后「看得清、追得到、说得明」。没有它，你的 Secrets Manager 就是黑箱。

1.3 审计字段的核心知识体系

为了让这节课更清晰，我画了张图，把整个审计字段的知识结构串起来。记住这张图的脉络，后面每一章我们都会展开细讲。

从这张图可以看出，整个审计体系其实就三根支柱——身份、行为、环境。后面的章节我们会逐一攻破每个字段到底是什么结构、怎么解析、怎么用。

1.4 一个快速感受审计字段的机会

你不用急着打开控制台。我先带你看看一个真实的 CloudTrail 事件片段。比如用户读取密钥：

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "IAMUser",
    "arn": "arn:aws:iam::123456789012:user/deploy-bot",
    "accountId": "123456789012"
  },
  "eventTime": "2024-05-20T14:03:12Z",
  "eventSource": "secretsmanager.amazonaws.com",
  "eventName": "GetSecretValue",
  "sourceIPAddress": "203.0.113.42",
  "requestParameters": {
    "secretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:MyApp/DB-Password-3a2b1c"
  },
  "responseElements": null,
  "readOnly": true
}

看到了吗？这里包含了谁（deploy-bot 用户）、什么操作（读取秘密值）、啥时候、从哪个IP。这就是最基本的审计字段组合。

注意： CloudTrail 中 Secrets Manager 的 GetSecretValue 事件不会记录返回的秘密值明文。这是设计上的安全限制——你无法从审计日志里直接看到别人读走了什么内容。但你可以通过 responseElements 字段里的 versionId 和 versionStage 来追踪被读取的版本。

1.5 我的一些经验与建议

做审计字段分析几年下来，我有几条觉得特别重要的提醒：

第一时间开启 CloudTrail 跟踪。默认的 90 天事件历史很容易过期，对于敏感的秘密操作，你应该保存至少 1 年以上的审计字段到 S3 或 CloudWatch Logs。
关注「只读」操作。GetSecretValue 不会修改任何东西，但却是最敏感的操作。我在项目中遇到过有人偷偷用 GetSecretValue 把全部秘密读出来——只靠审计字段才发现次数异常。
别忽略 IAM 角色委派的情况。当你看到 userIdentity.type 是 AssumedRole 时，说明是通过 EC2 或 Lambda 的角色来读取的。这时候要额外查 sessionContext.sessionIssuer 才能找到真正的源头。

嗯，如果你现在还觉得审计字段只是个理论概念，不用担心。从第 2 章开始，我们就会详细讲解每个字段的 JSON 路径、含义、常见陷阱，以及如何配合 Athena 或 QuickSight 做自动化分析。

先记住这个核心观念：没有审计字段，Secrets Manager 就是个黑盒；有了它，你才能掌控全局。