1. Secrets 审计日志概述
什么是 Secrets 审计日志
说白了，Secrets 审计日志就是记录「谁、在什么时候、通过什么方式、访问或修改了哪些敏感凭证」的系统日志。这里的 Secrets 可以简单理解成密码、密钥、令牌、证书——任何能够帮你验证身份或解锁权限的东西。
我刚开始接触这个概念时，以为它跟普通访问日志差不多。后来踩过一次坑才明白：普通日志丢了最多查不了谁上了网页，Secrets 日志丢了，就等于把保险柜钥匙落在了公共走廊。
Secrets 审计日志 ≠ 普通系统日志。它专门追踪凭证生命周期：创建、存储、使用、轮换、吊销。
为什么 Secrets 审计日志如此重要
你想想看，一个数据库连接串泄露，可能让整张用户表暴露。一个 被滥用，云账单能一夜爆表。这些都是真实发生过的事。
Secrets 审计日志的核心价值有三个：
- 溯源：凭证泄露后，能快速定位泄露链——是从哪个 CI/CD 环节流出的，还是某台服务器被入侵。
- 合规：很多行业标准（如 SOC 2、PCI DSS、ISO 27001）都明确要求记录 Secrets 访问行为。审计官来检查时，拿不出一份完整的 Secrets 操作历史，直接判定不合格。
- 异常检测：某个从没用过的 SSH 密钥突然在凌晨三点发起连接，这就是报警信号。没有审计日志，你根本不会发现。
我见过一家创业公司把所有 写死在代码里，出事之后根本查不到谁改过那些密钥。最后只能全量轮换，还把生产环境停了两小时。别让自己成为这样的案例。
常见的 Secrets 来源
实际工作中，Secrets 散落在各个角落。我按来源类型归纳了一下：
| 类别 | 典型 Secrets | 常见存放位置 | 审计风险点 |
|---|---|---|---|
| 数据库凭证 | 用户名/密码、连接字符串、SSL 证书 | 应用配置文件、环境变量、密钥管理服务（如 AWS Secrets Manager） | 硬编码在代码库、明文存储在日志文件、未定期轮换 |
| 第三方服务 、云服务 Access Key/Secret Key | CI/CD 变量、部署配置、移动端和应用端嵌入 | 未限制权限范围、长期未轮换、通过 HTTP 传输 | |
| SSH 密钥 | 私钥（RSA/ECDSA/Ed25519）、跳板机证书 | ~/.ssh 目录、配置管理工具（Ansible、Chef）、堡垒机 | 私钥权限错误、未添加口令、离职人员密钥未回收 |
| 认证 | JWT、OAuth 的 Bearer 、Session ID | 内存、Redis、Web 服务器 Session 存储 | 泄露后无签名校验、过期时间过长、未记录颁发记录 |
| 加密密钥和证书 | TLS 证书、对称加密密钥、PGP 密钥 | HSM、密钥服务器、文件系统 | 私钥备份缺失、证书链验证失败、密钥版本管理混乱 |
Secrets 审计日志知识体系
下面这张图帮你理清本章的核心脉络。我把 Secrets 的来源、审计动作、产出数据、最终价值串成了一根线。
我的经验：别等出事再开始采集 Secrets 日志。把三个来源（数据库、API、SSH）作为最小集，用 Splunk 先收起来，之后再慢慢补其他类型。
为什么用 Splunk 来采集
你可能已经猜到了——Secrets 审计日志来源多样、格式各异。数据库操作日志写的是 CSV，云 API 回的是 JSON，SSH 守护进程又是 syslog。Splunk 的强项就在这：无需提前统一格式，直接采集原始数据，靠字段提取和搜索能力把线索串起来。
举个例子，我记得有一次帮客户排查密钥泄露，数据库审计日志里有一条“unknown user”登录失败的记录，同时 API 网关日志里有同一个 IP 的异常调用。普通日志系统根本联想不到一起，但 Splunk 的关联搜索十分钟就定位到了攻击入口。
你需要关注的关键字段
不管 Secrets 从哪里来，最终进入 Splunk 时，我建议你至少保证下面这些字段不要缺失：
- timestamp：精确到毫秒的操作时间
- user / account：实际执行操作的人或服务账号
- resource：操作了哪个密钥、哪张证书
- action：create / read / update / delete / rotate / revoke
- source_ip：发起操作的客户端 IP
- result：成功 / 失败 / 拒绝
我踩过的另一个坑：当初只收了成功操作日志，没记录失败尝试。结果攻击者试了三千次密码枚举，Splunk 里一条记录都没有。记住——失败操作往往是真正的危险信号。