认识 Splunk 审计日志：你的第一道安全防线
说实话，很多刚接触 Splunk 的运维同学，上来就急着写搜索查日志。但有个东西被忽略了——审计日志。
我记得有一次帮一家金融客户做巡检，他们每天处理上亿条日志，但密钥相关的操作记录完全没被追踪。后来出了个内部事故，花了整整两周才定位到问题源头。从那以后，我养成了一个习惯：先搞清楚审计日志在哪、记什么、怎么用，再动手做巡检。
这一章我们就来聊聊审计日志是什么，Splunk 里有哪些审计事件，以及密钥审计到底要盯哪些场景。
什么是审计日志
审计日志，说白了就是系统里谁、在什么时间、通过哪个组件、做了什么操作的流水账。它和普通的应用日志不太一样——应用日志记录的是业务逻辑的运行结果，而审计日志记录的是人对系统的访问和操作行为。
你想想看，密钥管理系统的核心是私钥、证书、密码本。如果有人偷摸导出或者修改了这些敏感对象，没有审计日志，你根本不知道出了事。
核心特征：
- 不可篡改性（最起码有强校验）
- 时间戳精确到秒级
- 包含主体（谁做的）、客体（做了什么）、动作（操作类型）
- 必须保留足够长的周期（合规要求通常 1 年以上）
我在项目中见过不少人把审计日志和调试日志混在一起，结果合规审计时要找一条关键操作记录，翻了一个月的日志都没找到。嗯，这就是没做好分类归档的坑。
Splunk 中的审计事件类型
Splunk 内部有一套完善的审计机制。audittrail 索引收集了所有和 Splunk 平台本身相关的操作。我平时做密钥审计巡检，重点关注的子类型如下：
| 审计事件类型 | 对应 sourcetype | 典型场景 |
|---|---|---|
| 用户登录与退出 | audittrail | 谁在什么时间登录了 Splunk Web 或 API |
| 角色与权限变更 | audittrail | 管理员授予或撤销了某人的搜索、导出权限 |
| 对象操作（创建/修改/删除） | audittrail | 保存的搜索、数据模型、知识对象被编辑 |
| 数据导出与转发 | audittrail | 有人通过 REST API 导出大量日志或密钥信息 |
| 认证与 管理 | audittrail | 创建/吊销 API 、修改 LDAP/SSO 配置 |
| 系统配置变更 | audittrail | 修改 server.conf、limits.conf 等影响安全策略的文件 |
| 授权与委托 | audittrail | 将某搜索权限委托给另一个用户 |
经验之谈：很多人只看 action=failure 的记录，觉得只有失败操作才有问题。其实 action=success 的成功操作更需要关注——尤其是“导出”“删除”“修改密钥”这类高危动作。我曾经碰到过内部人员利用合法权限批量导出证书，成功日志里干干净净，但行为异常却没人发现。
密钥审计场景：我们到底要盯什么？
密钥审计不是泛泛地扫一遍所有 audit 日志。我个人的习惯是先画一个场景矩阵，从“谁、何时、哪里、做了什么、为什么”五个维度去卡控。
场景一：敏感对象的访问与导出
密钥文件一般存在 Splunk 的 passwords 存储或外部密钥管理系统中。通过 Splunk 的 REST API 访问 /services/storage/passwords 端点时，audittrail 会记录。如果你发现某个非管理员的账号在短时间内反复读取该端点，就要立刻拉警报。
index=audittrail sourcetype=audittrail action=access
uri_path="/services/storage/passwords/*"
| stats count by user, clientip, _time
| where count > 5
曾经踩过的坑：有一个客户的 Splunk 部署启用了 search head 集群，audittrail 日志分散在多个节点上，结果单节点查到的记录不全。正确做法是加 index=audittrail splunk_server_group=shc 才能看到完整的审计轨迹。这个细节不注意，你可能会漏掉一半的关键记录。
场景二：密钥配置的变更记录
密钥配置的变更往往出现在 splunk.secret 文件、加密种子（seed）的更新场景。Splunk 自身会用密钥加密存储敏感元数据，如果有人手动修改了这些文件，audittrail 里会有对应的配置更新事件。
index=audittrail sourcetype=audittrail
object="/opt/splunk/etc/auth/splunk.secret"
action=update
| table _time, user, action, result
场景三：非法或异常的认证行为
密钥审计还包含对认证系统本身的监控。比如，短时间内多次尝试用错误的 API 访问 /services/auth/login，可能是在尝试爆破密钥管理接口。
index=audittrail sourcetype=audittrail
action=failure
info="Authentication failed"
| timechart span=1m count by user
场景四：权限提升与委托异常
如果你发现一个只读用户突然被授予了 admin 角色，或者某个用户将自己的搜索权限委托给了外部账号，这些都属于高风险操作，必须纳入审计范围。
一张图看懂审计日志与密钥审计
下面这张图梳理了本章的核心知识结构：从 Splunk 审计日志的源头（audittrail 索引），到各类审计事件类型，再到密钥审计的四类典型场景。你读完这一章后，可以用它做快速参考。
总结一下本章要点
- 审计日志≠应用日志，它的核心是“谁在什么时间对什么做了什么”。
- Splunk 通过
audittrail索引收集所有平台操作，sourcetype=audittrail 是查询的起点。 - 密钥审计需要重点关注对象访问导出、配置变更、认证异常、权限委托四个场景。
- 写搜索时不要忘记考虑 splunk_server_group 字段，尤其在集群环境中。