第4章 _audit 索引详解：事件结构、字段说明、搜索语法基础
好，咱们今天聊点实在的。你在 Splunk 里做任何系统级别的审计，都绕不开一个东西——_audit 索引。说白了，这个索引就是 Splunk 自己的“黑匣子”，它记录了谁在什么时候做了什么操作。我刚开始接触 Splunk 审计时，第一反应是直接去翻系统的 syslog，后来才发现，真正该看的地方其实就是这个内置的 _audit 索引。
先把重点放在最前面：_audit 索引默认开启，不需要额外配置。你只需要有管理员权限，就能搜索它。我个人习惯一上来先跑一句：
index=_audit | head 10看看里面长什么样，心里就有数了。
4.1 _audit 索引的事件结构
_audit 里存的是什么？每个事件对应一次 Splunk 的内部操作。举个例子，用户登录、搜索执行、角色变更、数据输入重启、license 告警……这些都会被记录。每个事件包含一套标准字段，我称它为“审计事件骨架”。
这个骨架大致长这样：
| 字段类别 | 典型字段 | 说明 |
|---|---|---|
| 身份信息 | user, session_id, auth_type | 执行操作的用户身份和认证方式 |
| 时间戳 | _time, date_hour, date_wday | 操作发生时间（Splunk 内部时间） |
| 操作类型 | action, info, component | 具体操作名称，比如 search、login、edit |
| 目标对象 | object, object_category | 操作针对的资源，如角色名、数据输入名称 |
| 请求详情 | search_id, query, params | 如果是搜索事件，会包含具体的 SPL 语句 |
| 结果状态 | result_type, result_count, exec_time | 操作是否成功、返回了多少结果、耗时 |
嗯，这里要注意：action 字段的值不一定全是英文单词，例如用户登录可能是 login，但修改角色可能是 edit roles。我在项目中遇到过，有人直接用 action="login" 过滤，漏掉了别名的登录动作。建议先跑 index=_audit | stats count by action 看看都有哪些值。
4.2 核心字段深度说明
下面我把几个最常用的字段单独拎出来讲。你想想看，如果连这几个字段都不熟，做巡检就像闭着眼走路。
user 字段
记录发起操作的用户名。注意，它不只会出现 Splunk 本地账号，也可能是 LDAP、SAML 映射过来的用户名。我曾经遇到过一个坑：某个用户通过 SSO 登录后，user 字段显示的是 CN=张三,OU=Users,DC=example,DC=com 这种完整的 DN 字符串。后面做统计的时候，必须用 rex 提取才能分组合并。
action 字段
这个字段描述“做了什么”。常见的取值有：
login/logout— 用户登录/登出search— 用户发起搜索（包括实时和历史）edit— 修改配置（角色、数据输入、知识对象等）export— 导出结果delete— 删除数据或资源
我建议你一开始就建一个 action 的枚举表，贴在身边。巡检时一眼就能判断操作是否合规。
info 字段
这个字段提供额外的上下文。例如对于 search 操作，info 里可能包含 search job completed 或 search job failed。对于 edit 操作，它可能记录被修改的具体参数。处理这个字段时，我习惯用 eval 做条件分支：
index=_audit action=edit
| eval status=case(
like(info,"%error%"), "失败",
like(info,"%success%"), "成功",
1=1, "其他"
)object 与 object_category
这两个字段描述操作的目标。object_category 是分类，比如 roles、inputs、savedsearches；object 是具体名称。举个例子：管理员修改了“admin”角色的权限，那么 object_category=roles，object=admin。在做变更审计时，组合这两个字段能快速定位是哪个配置项被动了。
query 字段
只出现在 action=search 的事件中，记录用户实际输入的 SPL 语句。这是审计利器！你想想，如果有人偷偷搜索敏感数据，query 字段会原样记录下来。不过——注意，query 字段默认可能被截断（Splunk 设置中限制了最大长度）。我曾经查一个异常搜索时，只看到前半句“index=secret | table username,password”，后半段被截断了。解决方法是调大 maxsearchesperc 之类的限制，或者直接用 _raw 配合正则提取完整语句。
4.3 搜索语法基础
掌握了字段，就该上手搜了。_audit 索引的搜索语法跟普通索引一样，只是多了几个需要留意的点。我列几个最实用的模板，你直接套用就行。
4.3.1 查看用户登录活动
index=_audit action=login sourcetype=audittrail
| stats count by user, _time
| sort - _time这个查询能帮你列出每个用户最近的登录时间。注意 sourcetype=audittrail 是 _audit 索引的主要 sourcetype，不加也能搜到，但加了更精确。
4.3.2 追踪搜索敏感数据的行为
index=_audit action=search query=*password* OR query=*secret* OR query=**
| table _time, user, query, exec_time
| sort - _time小心！这个查询可能会返回大量的结果，尤其是在大型环境中。建议加上时间范围，比如 earliest=-7d。另外，query 字段内容如果包含敏感词，输出结果要注意脱敏处理，别在公共屏幕上直接展示。
4.3.3 统计管理员配置变更
index=_audit action=edit object_category=*
| top limit=20 object_category, object
| eval 变更次数 = count用 top 命令快速找出哪些配置被改得最频繁。我建议每周跑一次这个查询，重点关注 object_category=roles 和 object_category=authentication 的条目——权限和认证配置的变更，通常需要严格审核。
4.3.4 检查搜索性能异常
index=_audit action=search exec_time>600
| table _time, user, query, exec_time
| sort - exec_time查询执行时间超过600秒（10分钟）的搜索。这类“慢查询”可能消耗大量资源，甚至导致系统不稳定。我遇到过一次，某用户的仪表板每30分钟自动刷新一次全量索引，每次跑15分钟以上，直接影响了其他用户的并发搜索。
4.4 知识体系一览
下面用一张图把本章的核心结构串起来。看完之后你就能明白：_audit 索引里的事件通过不同的字段组合，可以覆盖用户行为、配置变更、搜索审计、性能监控四个维度的巡检。
4.5 快速上手：我的日常巡检片段
说了一大堆理论和字段，不如直接给个能抄的作业。下面是我个人每天上班第一件事会跑的一段 SPL，你可以直接复制到你的 Splunk 里试试：
index=_audit earliest=-1d
| stats count by action, user
| sort - count这条命令会列出过去24小时里每个用户执行了哪些操作、各多少次。我通常会先扫一眼 action=login 的分布，看看有没有深夜的异常登录。然后看 action=edit 的条目，确认昨天有没有人改了关键配置。
小技巧：把这段 SPL 保存成一个“审计每日概览”的仪表板面板，每天早上打开 Splunk 先刷新一下，心里就有底了。我习惯再搭配一个 action=delete 的时间线图，万一有人误删数据，能第一时间发现。
最后提一个调试方法——如果你对某个事件的结构不太确定，直接用 | spath 命令把嵌套字段展开：
index=_audit | head 1 | spath这样你就能看到事件里所有自动提取的字段和值。我在项目里调试 _audit 的搜索语法时，几乎每天都靠这条命令来确认字段名有没有拼错。
好了，这一章的内容就这些。核心就是三件事：理解事件结构、记住关键字段、把基础搜索模板练熟。做到这三点，_audit 索引对你来说就不再是黑盒子。接下来，放心大胆用它做审计就好。