📚 课程目录第4章 SOC数据源接入工程

4. SOC数据源接入工程

SOC的检测能力上限，往往不由分析规则决定，而由数据源接入质量决定。一个告警能否被准确判定，取决于三件事：原始事件是否被完整采集、字段是否被正确解析、语义是否被统一归一化。本章围绕日志、EDR、NDR、SIEM、SOAR、资产库、漏洞库、身份系统八类数据源，讲清从采集到入湖的工程实现路径。

一、八类数据源的定位与接入特征

这八类数据源在SOC中承担不同角色，接入方式差异明显。日志类（防火墙、代理、DNS、Web、系统日志）是流量与行为的原始记录，通常以Syslog、文件或API方式推送，量大、格式杂。EDR提供终端进程、命令行、文件、注册表等遥测，字段丰富但厂商私有字段多。NDR输出网络会话、DNS、TLS指纹、流量元数据，适合发现横向移动与C2。SIEM本身是汇聚层，接入它意味着复用已有解析与关联结果。SOAR提供剧本执行记录与处置动作，用于闭环审计。资产库、漏洞库、身份系统属于“上下文数据源”，它们不产生安全事件，但决定告警能否被赋予业务含义。

接入前必须先明确每类源的“主键”和“时间语义”。例如EDR以agent_id+process_guid为主键，NDR以五元组+会话ID为主键，身份系统以user_id或UPN为主键。时间字段要区分事件发生时间（event_time）、采集时间（ingest_time）和入库时间（store_time），三者不一致会导致关联错位。

二、采集层：协议、频率与断点续传

采集层要解决“不丢、不重、可追溯”。Syslog类源使用TCP 514或TLS 6514，避免UDP丢包；API类源采用增量拉取，用游标（cursor）或时间窗口分页；文件类源用Filebeat/Fluent Bit做tail，记录inode与offset实现断点续传。以某企业代理日志为例，配置采集窗口为5分钟一批，每批携带batch_id与last_event_time，入库后写入采集水位表，下次从水位继续，避免重复消费。

# Fluent Bit 采集代理日志示例
[INPUT]
    Name              tail
    Path              /var/log/proxy/access.log
    Tag               proxy.access
    DB                /var/lib/flb/proxy.db
    Read_from_Head    false

[FILTER]
    Name              parser
    Match             proxy.access
    Key_Name          log
    Parser            proxy_json

[OUTPUT]
    Name              kafka
    Match             proxy.access
    Brokers           kafka01:9092
    Topics            raw.proxy.access

采集层还需处理背压。当Kafka分区写入延迟升高时，采集端应限速而非无限缓冲，否则重启后会产生大量重复事件。建议为每类源设置独立的topic与分区键，分区键优先选asset_id或user_id，保证同一实体的事件有序。

三、解析与归一化：从原始字段到统一语义

解析是把非结构化或半结构化文本转成字段，归一化是把不同厂商的同义字段映射到统一Schema。以“源IP”为例，防火墙可能叫src_ip，代理叫client_ip，EDR叫local_ip，归一化后统一为src_ip。归一化Schema建议参考OCSF或ECS，至少覆盖：时间、主体（user/process/device）、客体（target/file/url）、网络（src/dst/port/protocol）、动作（action/result）、上下文（asset_id、severity）。

解析失败要有兜底策略：字段缺失时保留原始raw字段并打上parse_status=partial，而不是直接丢弃。归一化映射表应版本化，每次变更记录mapping_version，便于回溯某条告警当时使用的映射规则。

归一化映射示例（片段）：

统一字段	防火墙	代理	EDR
src_ip	src_ip	client_ip	local_ip
dst_ip	dst_ip	server_ip	remote_ip
user	src_user	user_name	user_account
action	action	result	event_type

四、入湖策略：分层、分区与保留

入湖不是简单写库，而是按“原始层—归一化层—上下文层”分层。原始层保留raw事件，用于取证与重放；归一化层存统一Schema，供检测规则消费；上下文层存资产、漏洞、身份快照，供关联富化。分区建议按event_date+source_type，保留策略按合规与成本平衡：原始层热存7天、温存90天，归一化层热存30天、温存180天，上下文层按变更频率做全量+增量。

入湖后要建立数据质量看板，监控每类源的EPS、解析成功率、字段完整率、延迟P95。当解析成功率低于95%或延迟超过5分钟时触发告警，说明采集或解析链路出现异常。

五、上下文富化：让告警带上业务含义

仅有事件流不足以判定风险。一条“EDR检测到PowerShell下载”的告警，如果关联到资产库发现该主机是财务部核心服务器、关联漏洞库发现存在未修复的远程执行漏洞、关联身份系统发现当前登录用户是普通员工，风险等级会显著上升。富化通常在归一化层之后、检测规则之前完成，采用“事件驱动+定时快照”结合：资产与身份变更时推送增量，漏洞库每日全量刷新。

富化字段建议至少包含：asset_criticality（资产重要性）、owner_dept（归属部门）、vuln_count（未修复漏洞数）、user_privilege（用户权限级别）。这些字段进入归一化层后，检测规则可直接引用，无需在规则内重复查询外部系统。

实践建议：接入顺序建议先做资产库与身份系统，再做日志与EDR/NDR。因为上下文数据源体量小、变更慢，先接入能让后续事件流在入湖时即完成富化，避免事后补关联带来的性能开销。

常见坑：不要把所有源都塞进同一个topic或同一张宽表。不同源的EPS差异可达三个数量级，混在一起会导致分区倾斜和查询扫描放大。按source_type分topic、按event_date分区，是成本与性能平衡的基线做法。

六、验收标准与可观测指标

接入工程是否完成，不看“接了多少源”，而看四个指标：采集完整率（应达99.9%以上）、解析成功率（应达95%以上）、归一化字段完整率（关键字段应达98%以上）、端到端延迟P95（应控制在5分钟内）。每个源接入后，用一批已知样本做回放测试，比对原始事件数与入湖事件数，差值即为丢失量。只有四项指标同时达标，才认为该源具备进入检测规则消费的资格。