审计日志数据源的三大支柱
做密钥审计巡检，第一步不是写 SPL 查询，而是搞清楚日志从哪来。这个问题我问过很多刚接触 Splunk 的同事，他们往往只知道搜 `index=*`。嗯，这显然不行。审计可不是大海捞针。
我个人习惯把密钥相关的日志源分成三类：系统日志、应用日志、以及 Splunk 自家的 _audit 索引。这三类数据就像三根柱子，少一根，你的审计结果就可能是漏的。我曾在一个客户现场发现，他们的密钥轮换告警一直不触发，查到最后——原来是应用日志根本没接入 Splunk。白白浪费了两周排查时间。
系统日志——基础设施的"心电图"
系统日志管的是底层。谁登录了服务器？哪个进程改动了 `/etc/ssh/` 下的文件？谁在凌晨三点执行了 `scp`？这些信息都在系统日志里。
- Linux syslog/rsyslog：重点关注 `auth`, `authpriv`, `cron`, `daemon` 等 facility。密钥相关的 SSH 登录、sudo 提权都会落在这里。
- Windows Event Log：Security 日志里的 4624（登录成功）、4634（注销）、4648（显式凭据登录），还有 4670（对象权限修改）——这些 event ID 我建议你记牢。
- 关键字段：user, src_ip, host, process_id, object_name, access_mask
我记得有一次排查私钥泄露事件，就是靠 `/var/log/secure` 里的一条 `Failed password for root from 10.0.0.5` 和时间戳，锁定了爆破源。系统日志虽然嘈杂，但它是硬证据。你想想看，应用日志可以造假，系统日志几乎没法绕过去。
应用日志——看清业务操作全貌
系统日志告诉你"谁动了服务器"，应用日志告诉你"谁用密钥干了什么业务操作"。说白了，业务视角全靠应用日志补齐。
举个例子。一个微服务调用另一个微服务，用的是 TLS 双向认证。你从系统日志里只能看到客户端 IP 和端口，但应用日志会记录：哪个服务名、哪个 API、用了哪张证书、证书序列号是什么。这些信息才是审计员真正关心的。
- 常见应用类型：Nginx/IIS（TLS 握手日志）、Java 应用（框架日志）、数据库审计日志（PG 日志、MySQL audit log）
- 关键字段：certificate_serial, tls_version, cipher_suite, service_name, api_endpoint, client_dn, server_dn
- 推荐索引策略：单独建立 `index=app_tls` 或 `index=app_key_audit`，避免和业务性日志混在一起
Splunk 内部审计日志——_audit 索引
这部分容易被忽略，但它恰恰是最关键的补充。_audit 索引记录的是 Splunk 自己干了什么。谁在 Splunk 里搜索了哪个索引？谁改了 Knowledge Object？谁导出了 search results？这些行为直接反映 Splunk 用户是否合规，也能间接暴露密钥信息的访问情况。
我建议你至少关注 _audit 索引里的这些 eventtype：
- search：记录了每次搜索的 SPL 字符串。如果有人搜了 `index=* password*` 或 `index=* key`，这里会留下痕迹。
- user_login / user_logout：Splunk 用户登录登出记录。
- role_update / user_update：权限变更操作。
- export_results：导出结果的记录，往往伴随敏感信息外泄。
# 查询最近7天谁访问了包含"key"的索引
index=_audit action=search search='*key*'
| stats count by user, search, _time
| sort -_time三种数据源的对比与协同
单独看任何一个都很难还原全貌。系统日志给底层证据，应用日志给业务证据，_audit 索引给操作监管证据。我一般用这张表来给团队做培训：
| 数据源 | 典型来源 | 关键字段示例 | 用途 | 注意点 |
|---|---|---|---|---|
| 系统日志 | /var/log/secure, Windows Security.evtx | user, src_ip, process_id, event_id | 基础设施访问与密钥文件操作 | 日志量巨大，需做好 field extraction |
| 应用日志 | Nginx error.log, Java log4j | serial, tls_version, cipher, dn | 业务层面密钥使用详情 | 日志格式不统一，需 parse |
| Splunk _audit | _audit 索引 | user, action, search, object | 审计操作合规性检查 | 默认保留时间较短，注意调大 |
实际巡检的时候，我会把这三种数据源串起来。比如：先在 _audit 里发现某用户在非工作时间做了大量 search，然后去系统日志里查这个用户的登录 IP，最后去应用日志里确认他查的证书是否被导出。三条线交叉验证，漏洞无处可藏。
下面这张图把三类数据源到审计巡检的流程画清楚了：