迪康终端行为审计的数据链路：从内核事件到秒级溯源查询

几千台终端每秒产生海量行为事件，怎么采、怎么传、怎么存、怎么查？审计系统烂尾的项目，十个里有八个死在数据链路上，而不是死在功能上。

1. 先看一组让人清醒的数字

设计之前先算账一台办公终端一天产生的可审计行为：粗算下来，单终端日均 10 万级事件很常见。一千台终端就是日均上亿条，存储一年是百亿级行。而等保和行业规范还要求日志留存不少于 6 个月。

更矛盾的是访问模式：写入是持续的洪流，读取是稀疏但要求极快的精确查询——"3 号下午，财务部的张三往外拷了什么"，这种查询必须秒级返回，因为用它的人正站在领导面前。

数据链路设计的所有取舍，都从这两个事实出发。

2. 链路总览：五段式管道

[终端]                    [平台]
内核事件源 → Agent 聚合 → 传输通道 → 接入层 → 存储/索引 → 查询服务
───────  写入侧优化  ───────┬────── 读取侧优化  ───────

写入侧的目标是"扛住、不丢、省带宽"；读取侧的目标是"任意维度秒级命中"。两端优化方向相反，中间的每一环都要明确自己站在哪一边。

3. 采集层：先定义好事件模型，再谈采集

很多项目的隐性成本来自没有统一事件模型——文件审计一套字段、外设审计一套字段、打印又一套，最后查询层被迫做多源关联，性能不可能好。

统一 Schema 的关键字段建议：

{
  "event_id": "uuid",
  "ts_agent": 1728600000123,     // 终端本地时间，毫秒
  "ts_server": 1728600000456,    // 服务端接收时间（两者都要，后面解释）
  "device": {"id": "hw-fp-xxx", "name": "FIN-PC-023"},
  "user": {"sid": "S-1-5-21-...", "account": "zhangsan"},
  "type": "usb.file.write",    // 事件类型，点分层级
  "subject": {"path": "D:/患者名单.xlsx", "size": 204800},
  "object": {"usb_sn": "A123456", "vendor": "SanDisk"},
  "result": "allow",           // allow / deny / alert
  "policy_id": "P-USB-007"     // 命中的策略，审计与策略要闭环
}

几个设计要点：

• ts_agent 和 ts_server 双时间戳：终端时钟漂移在千台规模下是常态（见过慢了 40 分钟的财务电脑），只靠本地时间会拼出混乱时间线。服务端接收时间做兜底，同时 Agent 定期校时（NTP），漂移超阈值告警；
• 设备用硬件指纹而非 IP/MAC：MAC 可改、DHCP 会变，硬件指纹组合稳定；
• 用户用 SID 而非用户名：改名不丢审计历史。

采集源本身：文件事件来自 minifilter 的 PostCreate/PostWrite 回调，外设来自 USB 过滤驱动，进程来自 PsSetCreateProcessNotifyRoutine 或 ETW（用户态回退），登录事件订阅 Windows 安全日志。注意事件字段在驱动层就规范化，别指望服务端替你做清洗——每条事件在内核多待 1 微秒，乘以十万级日事件就是可感知的开销。

4. 边缘聚合：Agent 是第一道也是最重要的减压阀

原始事件直接上报，链路必死。Agent 侧要做四层处理：

1. 过滤：按策略丢弃不需要审计的噪声（系统进程对系统目录的常规读写），采集之前先定义"采什么"，默认收敛；
2. 去重：杀软扫盘这类行为一秒钟对同一文件产生成百上千次访问，按"进程+文件+操作类型"做滑动窗口合并，计数器记录次数；
3. 聚合：同一会话内的连续文件操作可折叠成会话事件（谁在什么时间用哪个 U 盘拷了 N 个文件，共 X MB），明细本地保留、上报聚合态；
4. 批量缓冲：本地持久化队列（断电不丢）+ 按大小/时间双阈值批量上报。

实际效果：原始 10 万条/天/终端，经过边缘聚合后上报量能压掉 70%~90%，且信息无损——这直接决定你的带宽和存储成本。

5. 传输与接入：可靠性和时钟一样不能丢

• 传输格式用二进制（Protobuf/FlatBuffers），JSON 在这种量级的带宽和解析成本下不划算；
• 接入层无状态化：Agent 连接任何接入节点都行，会话态在 Redis/网关层，扩容只加机器；
• 接收即确认、失败重传：接入层落 Kafka 之后才回 ack，Agent 未收到 ack 重发，消费端按 event_id 幂等去重——"至少一次投递 + 消费幂等"是这个场景的标准答案；
• 背压机制：平台存储抖动时接入层要能顶住洪峰，Kafka 就是干这个的；Agent 侧检测到发送失败指数退避，防止断网恢复后几千台终端同时补发形成日志风暴。

6. 存储与索引：写入放大是主要敌人

选型上，这个 workload 的典型特征是写多读少、查询维度固定、时间范围强相关。务实路线：

• 热数据用列式存储（ClickHouse 或同类）：按时间分区，按"事件类型 + 设备 + 用户"排序建稀疏索引。列存对"只查某几列"的审计查询天然友好，压缩率通常是行存的 5~10 倍；
• 冷数据分层：30~90 天热库，之后转对象存储（Parquet + 列索引），查询走外表联邦，成本降一个数量级；
• 留存策略自动化：到期删除做成 TTL 任务，别让磁盘某天早上写满——审计系统自身故障是最讽刺的事故。

关于"为什么不用 ES 一把梭"：ES 全文检索强，但纯行为审计没有全文需求，倒排索引的存储开销在小字段低基数字段上是浪费。ClickHouse 这类列库在百亿行规模下的扫描性能与成本明显更优，架构上把全文检索留给少数场景（如文件路径模糊匹配）单独做即可。

7. 查询层：一次溯源查询的完整路径

用户提的需求："10 月 8 日下午，儿科门诊的所有电脑，谁往外拷了文件？"

SELECT ts_agent, user.account, device.name, subject.path, object.usb_sn
FROM audit_events
WHERE type = 'usb.file.write'
  AND device.group = '儿科门诊'
  AND ts_agent BETWEEN '2026-10-08 12:00' AND '2026-10-08 18:00'
ORDER BY ts_agent;

这条查询的性能关键：类型过滤走稀疏索引，时间范围走分区裁剪，设备分组在入库时打标签冗余存储（避免查询时 join 资产表）。在合理建模下，亿级表秒级返回是正常表现。

再进一步，把"人"作为线索的跨类型查询（张三当天全部行为时间线）需要统一排序键支持——这又回到了第 3 节的双时间戳与统一 Schema，查询体验在采集设计的那一刻就已经决定了。

8. 踩坑实录

1. 时钟漂移毁掉时间线：两台终端时钟差半小时，攻击/操作顺序完全颠倒。对策就是双时间戳 + 校时告警，前文已述，这里再强调一遍，因为它真的会让你在事件复盘会上社死；
2. 日志风暴打爆接入层：平台重启后几千台 Agent 同时补发积压数据。必须做 Agent 侧限速 + 服务端按租户隔离配额；
3. 聚合过度导致溯源断链：为了省流量把文件事件折叠得太狠，客户要求调出"某个文件被打开过几次"时发现次数有了、时间分布丢了。聚合粒度要和合规要求对齐，宁可多上报，不要欠证据；
4. 隐私合规反噬：终端审计可能采集到聊天工具内容、网页记录，触碰《个人信息保护法》红线。工程上要做采集范围可配置、敏感字段脱敏存储、查询操作本身也记审计——审计系统必须自己能被审计；
5. 策略与审计脱节：审计日志不带 policy_id，出现 deny 事件时说不清是哪条规则拦的，排查全靠猜。

9. 一体化数据底座的价值在哪

把视角拉回到产品形态：上面整条链路，如果资产、外设、加密、审计各做各的，就要建四套管道、四个数据模型、四种查询界面——成本翻四倍，跨域溯源仍然做不到。

以迪康端点安全一体化管理系统为参照，一体化的数据意义在于：所有模块的事件从同一 Agent、同一 Schema、同一管道进入同一存储，"设备+用户+时间+事件"四维检索是全局能力而不是某模块特权。对客户来说，这决定了"出事后十分钟内给出结论"还是"三天后还在导 Excel"。

10. 总结

终端审计数据链路的设计心法：

• 先算账再选型，写入放大是头号敌人；
• Agent 边缘聚合是性价比最高的投资，能压掉八九成流量；
• 统一事件模型 + 双时间戳，查询体验在采集时注定；
• 列存 + 冷热分层，让 6 个月留存不再肉疼；
• 审计系统自身也要合规、可审计。

链路无小事——功能演示十分钟，数据链路跑三年。