4. 多源安全数据接入实践
安全治理平台的价值，首先取决于它“看得见什么”。日志、流量、资产、漏洞、威胁情报这五类数据源，分别回答“发生了什么”“正在发生什么”“保护对象是什么”“薄弱点在哪里”“对手是谁”五个问题。它们的数据形态、采集方式、协议和更新节奏差异极大，如果接入时不做统一规范，后续的关联分析、告警降噪和处置闭环都会建立在不可靠的数据之上。本节围绕这五类数据源，讲清采集方式、协议适配和接入规范三个层面的实际做法。
一、五类数据源的采集方式与协议适配
日志类数据是接入量最大、格式最杂的一类。常见采集方式有三种：一是通过 Syslog（UDP/TCP 514、TLS 6514）接收网络设备、防火墙、Linux 主机的日志；二是通过 Agent 或 Filebeat 采集应用服务器上的文本日志文件；三是通过 API 拉取云平台、SaaS 服务的操作日志。协议适配的关键在于：Syslog 要区分 RFC 3164 与 RFC 5424 两种格式，前者时间戳无年份、后者带结构化数据；文本日志要先用正则或 Grok 做字段抽取，再统一为 JSON。例如一条防火墙日志经解析后应至少得到 src_ip、dst_ip、dst_port、action、event_time 五个字段，否则后续无法与资产、情报做关联。
流量类数据通常不采集原始报文，而是采集流记录或元数据。主流方式是 NetFlow v5/v9、IPFIX、sFlow，由交换机、路由器或探针输出；需要深度检测时，再用全流量探针做协议还原并输出会话日志。协议适配要点是：NetFlow v9 和 IPFIX 使用模板（Template）描述字段，采集端必须先收模板再解析数据记录，否则会得到乱码；sFlow 是抽样流，适合大流量场景但存在漏检，需在接入规范中标注“抽样比”字段，避免把抽样结果当作全量结论。
资产类数据来源包括 CMDB 导出、主机 Agent 上报、主动扫描发现和云平台 API。采集方式以定时全量 + 增量变更为主，协议多为 REST API、数据库直连或 CSV 文件导入。适配重点是字段映射：不同来源对“主机名”可能叫 hostname、host_name、device_name，必须映射到统一资产模型的 asset_name，并用 asset_id 作为全局唯一标识，否则同一台机器会被重复计数。
漏洞类数据来自漏扫系统（如 Nessus、OpenVAS、国内主流扫描器）和人工渗透报告。采集方式多为 API 拉取或报告文件解析，协议以 REST/JSON、XML 为主。适配难点是漏洞编号不统一：同一漏洞可能同时有 CVE、CNNVD、厂商内部编号，接入时应以 CVE 为主键，其余编号作为别名存入映射表，并保留 scan_time、asset_id、severity、solution 字段。
威胁情报类数据来自商业情报源、开源情报（如 STIX/TAXII 格式）和内部沉淀的 IOC。采集方式以订阅推送和定时拉取为主，协议常见 TAXII over HTTPS、REST API、STIX 2.1 JSON。适配要点是 IOC 类型区分：IP、域名、URL、文件哈希的匹配方式不同，且情报有 valid_from、valid_until 有效期，过期情报必须停止匹配，否则会产生大量误报。
二、接入规范：让五类数据“说同一种语言”
采集方式解决“拿得到”，接入规范解决“对得上”。规范的核心是统一数据模型和统一质量约束，具体包括四项。
统一时间戳。所有数据源的时间字段必须转换为 UTC 时间并保留毫秒精度，字段名统一为 event_time。日志中的本地时间、流量中的采集时间、漏洞中的扫描时间，如果不做时区归一，关联分析会出现“告警发生在漏洞扫描之前”这类逻辑错误。建议在采集层完成转换，平台侧只接受 UTC。
统一标识。资产用 asset_id，事件用 event_id，情报用 ioc_id。IP 地址不能作为资产唯一标识，因为一台主机可能有多个 IP、IP 也可能被回收再分配。资产接入时应以 CMDB 的资产编号或 Agent 的机器指纹为主键，IP 只作为属性字段。
字段命名与枚举。字段名统一使用 snake_case，避免同一含义出现多种写法。枚举值要收敛，例如日志的 action 只允许 allow、deny、drop、reset 四种，漏洞的 severity 只允许 critical、high、medium、low、info 五级。枚举不统一会导致统计口径混乱。
质量校验与异常处理。每条数据进入平台前应经过必填字段检查、类型检查、范围检查。例如 dst_port 必须在 0–65535 之间，event_time 不能晚于当前时间 5 分钟。校验失败的数据不应静默丢弃，而应写入异常队列并触发告警，便于定位是采集端配置错误还是数据源本身异常。
三、接入登记：可追溯的最小管理动作
五类数据源接入后，必须有一份接入登记表，记录每个数据源的来源系统、采集方式、协议、字段映射版本、更新频率、责任人和最近一次成功采集时间。这份登记表不是形式文档，而是排障时的第一手依据：当某类数据突然断流，先查登记表确认采集方式和频率，再查采集端日志，能快速区分是源端停止发送、网络不通还是解析规则失效。
实际接入时，建议按“先通后优”的节奏推进：先用最小字段集打通一条日志从采集到入库的链路，验证时间戳、标识和字段映射是否正确；再逐步增加数据源类型和字段丰富度。每接入一类数据源，都应在测试环境用一批已知样本验证解析结果，确认关键字段无缺失、枚举值在允许范围内、时间戳已归一为 UTC，然后再切换到生产采集。这样可以把格式适配问题控制在接入阶段，而不是留到关联分析阶段才暴露。