DSPM与审计日志联动分析实战 - 第4节
4.1 日志采集——一切分析的基础
讲DSPM与审计日志联动，第一步不是分析，而是采集。
说白了吧，数据都不全，你分析个啥？
我做数据安全这些年，见过太多团队花大价钱买分析平台，结果日志采集没做好，最后全是白搭。嗯，这里要注意：采集质量直接决定了分析的准确率。
4.2 Syslog——Unix/Linux世界的日志老大哥
4.2.1 Syslog是什么
Syslog诞生很早，早在80年代就跟着Sendmail一起出来了。它原本是个简单的日志传输协议，后来逐渐演变成了事实标准。
我个人习惯把Syslog看作“日志的快递服务”——有标准的信封格式，有固定的收发地址，至于里面装的是什么，快递员不管。
4.2.2 Syslog的核心要素
| 要素 | 说明 | 常见值举例 |
|---|---|---|
| Facility（设施） | 标识日志来源的程序类型 | auth、authpriv、daemon、kern、local0-local7 |
| Severity（严重级别） | 标识日志的紧急程度 | 0-Emerg、1-Alert、2-Crit、3-Err、4-Warning、5-Notice、6-Info、7-Debug |
| Timestamp（时间戳） | 日志产生的时间 | Oct 12 14:30:22 |
| Hostname（主机名） | 产生日志的设备名称 | db-srv-01、webserver-prod |
| Message（消息体） | 具体的日志内容 | Failed password for root from 10.0.0.1 port 22 ssh2 |
我的小建议：可以用 local0 到 local7 这几个自定义设施来标记你的业务系统日志，方便后续的过滤和分类。
4.2.3 Syslog的传输方式
Syslog支持三种传输模式，我个人特别看重这个选择，因为它直接影响数据完整性。
- UDP（514端口）：速度快，但不保证送达。适合内部网络、非关键日志。
- TCP（默认也用514）：可靠传输，有确认机制。适合跨网络传输。
- REL（Reliable Event Logging Protocol）：带应用层确认的TCP，最可靠。适合合规要求高的场景。
避坑指南：我曾经在一个金融项目中，客户把所有核心审计日志都走UDP Syslog发送。结果网络抖动一次，丢了30%的日志，审计直接过不了。后来全改成TLS加密的TCP Syslog，才解决问题。
4.2.4 Syslog格式演变
最早是RFC 3164定义的BSD Syslog格式，说白了就是“自由格式”。后来RFC 5424推出了结构化Syslog，带了更多的元数据。
我在项目中遇到过这样的事：不同设备发来的Syslog格式五花八门，解析器写了一个月还没搞定。后来统一对端设备配置，全部走RFC 5424格式才解决问题。
4.3 Windows Event Log——微软生态的日志基石
4.3.1 从Event Log到Event Tracing
Windows的日志体系比Unix复杂很多。早期是Event Log（经典日志），后来演进到Event Tracing for Windows（ETW）。
你想想看，Windows每天产生海量事件，如果没有高效的采集机制，光I/O就炸了。ETW的厉害之处在于它是内核级的，性能开销极小。
4.3.2 Windows Event Log的核心通道
Windows把日志分成了几个分类通道：
- Application：应用程序产生的日志
- Security：安全相关事件（登录、权限变更等）
- System：系统组件产生的事件
- Setup：安装和配置事件
- Forwarded Events：从其他机器收集来的事件
重点记住：DSPM分析中最常关注的是Security通道。比如4624（登录成功）、4625（登录失败）、4672（管理员登录）、4648（使用显式凭据登录）。
4.3.3 常用的Windows日志采集方式
我建议根据企业规模选不同的方案：
| 方式 | 原理 | 适用场景 | 我踩过的坑 |
|---|---|---|---|
| WMI | 通过Windows Management Instrumentation远程查询 | 小规模（几十台） | 权限问题多，查询效率不稳定 |
| WinRM + WecUtil | Windows Remote Management + 事件转发 | 中规模（几百台） | 防火墙端口配置容易漏 |
| ETW | 事件跟踪框架，内核级采集 | 大规模（千台以上） | 配置复杂，需要熟悉Provider GUID |
| Agent采集 | 安装第三方Agent（如Winlogbeat） | 混合环境 | Agent版本兼容性问题 |
4.4 Syslog vs Windows Event Log——核心差异
很多人问我说，这两个到底选哪个？
我的答案是：成年人全都要。但需要理解它们的本质区别。
| 对比维度 | Syslog | Windows Event Log |
|---|---|---|
| 原生平台 | Unix/Linux/网络设备 | Windows Server/Client |
| 消息格式 | 纯文本为主，RFC 5424有结构 | XML结构化EventData |
| 采集方式 | 网络监听（514端口） | WMI/WinRM/ETW/Agent |
| 性能开销 | 低（特别UDP模式） | 中等（ETW较低，WMI较高） |
| 事件ID | 无标准ID，靠Facility+Severity归类 | 有固定Event ID（如4624、5152、4688） |
| 批量传输 | 单条发送 | 支持事件批处理 |
4.5 实战中的采集架构——全局视角
下面这张图是我在项目中常用的审计日志采集架构，你可以看到Syslog和Event Log在其中的位置。
4.6 采集接错与避坑
最后这部分，我把自己实战中总结的一些经验直接列出来，你以后做采集的时候可以拿来参考。
4.6.1 时间同步问题
这个我吃过亏。日志的时间戳不对齐，后续做关联分析完全是错的。
- 所有设备必须统一使用NTP服务
- 我建议把同一机房的设备同步到同一台NTP服务器
- 采集网关收到日志时，额外记录一下接收时间戳
4.6.2 日志丢失与重复
避坑指南：我曾经接手过一套系统，每天采集到2亿条日志，但实际应该是3亿。找了一个星期才发现，采集网关的UDP接收缓冲区太小，大量日志在操作系统层面就被丢弃了。解决方案：启用TCP模式，必要时加一层Kafka做缓冲。
4.6.3 格式兼容性
这个说起来简单做起来头疼。不同厂商的设备，Syslog字段名都不一样。
- Cisco的Syslog和华为的Syslog，同一个"认证失败"事件，字段名完全不同
- 我建议在采集网关层做一个“事件归一化引擎”，把不同来源的同一类型事件映射成统一格式
- 归一化之后，DSPM的关联规则才能跨设备生效
4.6.4 权限与安全
日志采集本身不能成为新的安全风险点。我个人经验是：
- Syslog走TLS加密，不传明文
- Windows用WinRM自带Kerberos认证，别用明文HTTP
- 采集账号用最小权限，只读不写
- 采集链路的证书定期轮换
4.7 小结
审计日志采集，说白了就一句话：把有意义的日志，用可靠的方式，送到该去的地方。
Syslog和Event Log是两套体系，但最终在DSPM平台上都会被归一化处理。我个人经验是：先跑通一条链路，再逐步扩展。别想着一步到位，先让数据流起来再说。