📚 课程目录第2章 Splunk架构与安全数据管道

2. Splunk架构与安全数据管道

在安全运营中，Splunk 的价值不在于“装好就能查”，而在于把分散在防火墙、终端、域控、代理、云审计和 EDR 里的日志，按可控的路径汇聚成可检索、可告警、可追溯的数据资产。要做到这一点，必须先理解 Splunk 各角色的分工，以及一条安全事件数据从产生到被搜索命中的完整链路。本节围绕“角色—链路—判断依据”展开，帮助你在设计或排障时知道每一步该看什么。

一、核心角色：谁负责什么

Splunk 企业部署通常由以下几类角色构成，它们各司其职，不能互相替代：

转发器（Forwarder）：部署在数据源主机上，负责采集本地日志并转发。分为通用转发器（UF）和重型转发器（HF）。UF 只做采集与转发，资源占用低；HF 可做本地解析、过滤和缓冲，适合数据量大或需要预处理的主机。
索引器（Indexer）：接收转发器送来的数据，完成解析、索引和存储。它决定数据进入哪个索引、如何切分字段、保留多久。索引器是数据“落地”的地方，也是搜索时真正读取数据的地方。
搜索头（Search Head）：用户提交搜索、运行告警、使用仪表盘和应用的入口。搜索头本身通常不长期存储原始数据，而是把搜索任务分发到索引器，再汇总结果返回给用户。
部署服务器（Deployment Server）：集中管理转发器的配置，例如 outputs.conf、inputs.conf、props.conf 等。它让成百上千台转发器不必逐台登录修改，而是通过“服务器类”批量下发。
集群（Indexer Cluster）：由多个索引器组成，通过复制因子和搜索因子保证数据高可用与搜索能力。主节点（Cluster Manager）负责协调，对等节点（Peer）存储数据，搜索头可接入集群进行搜索。
云服务（Splunk Cloud / 云转发器）：在云环境中，索引与搜索由 Splunk 托管，用户侧通常只需部署云转发器或使用 HTTP Event Collector（HEC）把数据送入云平台。

理解这些角色的关键，是记住一条原则：采集在转发器，存储在索引器，搜索在搜索头，配置在部署服务器，高可用靠集群，云上则把存储与搜索托管出去。

二、安全数据从采集到搜索的完整链路

下面以一条“终端登录失败”日志为例，说明数据从产生到被搜索命中的过程。假设某台 Windows 主机产生事件 ID 4625，转发器采集后送入索引器，安全分析师在搜索头中查询。

数据产生：Windows 安全日志写入本地 Event Log，事件 ID 4625，账户名为 test\admin，来源 IP 为 10.20.30.40。
采集与转发：通用转发器通过 inputs.conf 监控该日志通道，读取新事件，按 outputs.conf 指向索引器 10.10.1.20:9997，通过 Splunk 专用端口发送。
接收与解析：索引器收到数据后，依据 props.conf 和 transforms.conf 决定来源类型（sourcetype=WinEventLog:Security）、时间戳解析方式和字段提取规则。
索引与存储：数据写入指定索引（如 index=wineventlog），按时间分桶存储，并受保留策略约束。若启用集群，数据同时复制到多个对等节点。
搜索与命中：搜索头接收查询 index=wineventlog EventCode=4625，把任务分发到相关索引器，索引器返回匹配事件，搜索头汇总后展示结果。
告警与响应：若配置了关联搜索或告警规则，命中后可触发告警、写入风险索引或调用响应流程。

这条链路中，任何一环出问题都会导致“数据查不到”。例如转发器未启动、outputs.conf 指向错误、索引器未监听 9997、props.conf 时间戳解析错误、搜索头未连接到集群、搜索时间范围不对等。排障时应按链路顺序逐段确认，而不是直接怀疑搜索语句。

三、关键配置与参数关系

要让链路真正跑通，需要关注几个关键配置。转发器侧，inputs.conf 决定“采什么”，outputs.conf 决定“送到哪”。例如：

[monitor://C:\Windows\System32\winevt\Logs\Security.evtx]
disabled = false
sourcetype = WinEventLog:Security
index = wineventlog

[tcpout]
defaultGroup = primary_indexers

[tcpout:primary_indexers]
server = 10.10.1.20:9997,10.10.1.21:9997
useACK = true

索引器侧，props.conf 决定“怎么解析”，transforms.conf 决定“怎么提取字段”。例如为 Windows 安全日志设置时间戳识别和字段提取：

[WinEventLog:Security]
SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]+)
TIME_PREFIX = SystemTime=
TIME_FORMAT = %Y-%m-%dT%H:%M:%S.%6N%Z
MAX_TIMESTAMP_LOOKAHEAD = 32
TRANSFORMS-security = extract_account, extract_src_ip

集群侧，复制因子（replication factor）决定每份数据存几份，搜索因子（search factor）决定可搜索的副本数。例如 3 个对等节点、复制因子 2、搜索因子 1，表示每份数据存 2 份，至少 1 份可搜索。若复制因子为 3，则允许 1 个节点故障而不丢数据；若搜索因子为 2，则允许 1 个节点故障仍可搜索。这两个参数直接影响可用性与存储成本，需要根据安全日志的重要程度权衡。

四、云环境下的差异

在 Splunk Cloud 中，索引器和搜索头由 Splunk 托管，用户不再直接管理底层索引器集群。数据进入云平台通常有两种方式：一是部署云转发器，把本地或云主机日志转发到云上的 HEC 端点；二是直接使用 HTTP Event Collector，让应用通过 HTTPS 发送事件。此时用户仍需负责转发器配置、HEC 令牌管理、索引与保留策略申请，以及搜索与告警规则的设计。换句话说，云服务把“存储与搜索”托管了，但“采集与治理”仍在用户侧。

排障时建议按链路顺序检查：数据源是否产生日志 → 转发器是否运行且 inputs.conf 生效 → outputs.conf 是否指向正确索引器 → 索引器是否监听 9997 且索引存在 → props.conf 时间戳与字段是否正确 → 搜索头是否连接到索引器或集群 → 搜索时间范围与字段名是否匹配。逐段确认，比反复修改搜索语句更有效。

五、小结与判断依据

Splunk 安全数据管道的本质，是把“采集—转发—解析—索引—搜索—告警”串成一条可观测、可排障的链路。转发器负责采集，索引器负责存储与解析，搜索头负责查询与告警，部署服务器负责批量配置，集群负责高可用，云服务负责托管存储与搜索。判断链路是否正常，最直接的方法是：在搜索头中执行一条最小查询，例如 index=wineventlog | head 1，若能返回事件，说明采集、转发、索引、搜索基本贯通；若无结果，再按链路逐段定位。掌握这条链路，才能在安全运营中快速判断“数据为什么没来”和“告警为什么没触发”。