审计日志基础:日志格式标准与采集存储
审计日志,说白了就是系统里“谁在什么时候干了什么”的完整记录。在DLP场景下,它更是排查数据泄露事件的唯一线索链。我做过不少安全运营项目,发现很多团队日志格式没统一、采集有盲区,出事时根本拼不出完整画面。这一节咱们把日志格式标准和采集存储策略彻底讲透。
三大日志格式标准
目前业界最通用的审计日志格式就三个:Syslog、CEF、JSON。选哪个,取决于你的设备能力和下游分析平台的偏好。
Syslog(RFC 5424)
Syslog是历史最悠久的日志协议,几乎所有网络设备都支持。它的格式很简单:时间戳、主机名、进程、消息内容。但字段没有标准化,说白了就是“大家往里面塞自己想塞的内容”。
<14>1 2025-07-10T14:30:00+08:00 dlp-gateway-01 dpaudit 1234 - - User 'zhangsan' downloaded file 'salary_2025.xlsx' to USB
我在项目中遇到过,直接用Syslog接上游SIEM时,同一个厂商的不同版本,字段顺序都可能不一样。你想想看,后续解析规则得写一堆正则,维护成本居高不下。所以Syslog适合原始原始收储,不太适合直接做结构化解析。
CEF(Common Event Format)
CEF是ArcSight搞出来的标准,算是Syslog的增强版。它在Syslog头部之外固定用键值对定义事件字段。字段名是约定好的,比如src、duser、filePath。
CEF:0|DLP|DataGuard|1.0|100|File Copied to USB|5|src=192.168.1.10 duser=zhangsan filePath=/data/salary_2025.xlsx fsize=204800 msg=USB write detected
这里面最核心的是“扩展字段”部分,厂商可以自由添加。嗯,这里要注意:CEF每个字段的语义虽然统一了,但不同的DLP产品对同一个事件类型(比如“文件拷贝”)定义的扩展字段数量可能不同。我建议在接入CMDB或UBA平台前,先拉一张字段映射表,避免下游解析失败。
JSON(结构化日志)
JSON现在是主流选择,尤其是云原生环境。它的层次结构清晰,解析成本低,也能直接整合进ELK这类平台。
{
"timestamp": "2025-07-10T14:30:00+08:00",
"eventType": "FILE_COPY",
"severity": "high",
"user": "zhangsan",
"sourceIP": "192.168.1.10",
"destination": "USB",
"file": {
"path": "/data/salary_2025.xlsx",
"size": 204800,
"hash": "e99a18c428cb38d5f260853678922e03"
},
"policy": "USB禁止拷贝机密文档"
}
我曾经遇到一个坑:某些DLP网关输出的JSON字段名大小写不统一,有的写filePath,有的写file_path。解析规则必须做字段归一化。这点在设计采集链路时就要考虑进去。
日志采集策略
采集层要解决两个问题:一是“采得到”,二是“采全了”。下面是我个人习惯的三种部署方式。
- 集中式采集(Agent + 中央收集器):每台终端装Agent,日志通过加密通道发送给中央Syslog/HTTP接收器。优点是控制力强,能采集缓存、脱机数据。缺点是Agent维护量大。
- 网络日志抓取(Port Mirror/Span):在核心交换机旁路镜像DLP网关流量,不侵入终端。适合纯监控场景,但看不到终端侧的本地日志(比如USB写入被策略拦截前的用户行为)。
- API拉取(云DLP场景):通过SaaS DLP的REST API定时批量拉取审计日志。注意控制重试和分页,避免漏单。
避坑指南:我曾经在部署集中式采集时,忘记给Agent配置本地缓存队列。网络闪断后,日志直接丢了40%。后来强制所有采集代理至少保留10MB的磁盘缓冲,并且生产环境一定要做链路冗余。
存储策略
大量的审计日志——尤其是DLP的——每天可能几百GB。存多少、存哪里、怎么查,直接影响事故响应速度。
| 存储层 | 保留周期 | 典型介质 | 用途 |
|---|---|---|---|
| 热存储 | 7–30天 | SSD/NVMe集群 | 实时查询、告警回溯 |
| 温存储 | 1–6个月 | SATA HDD / 对象存储(S3) | 月度分析、合规审计 |
| 冷存储 | 6个月–3年 | 磁带/低成本对象存储归档 | 司法取证、监管要求 |
我建议至少热存储保留30天。为什么?我见过一些攻击在月初渗漏数据,月底才被发现。如果只存7天,关键证据早被覆盖了。另外,存储时务必保留原始格式(原样JSON或CEF),不要只存解析后的字段,以便后续重新解析。
格式对比与选择
下面这张表我经常拿出来给团队成员培训,直接看着选。
| 维度 | Syslog | CEF | JSON |
|---|---|---|---|
| 解析复杂度 | 高(需要正则/模板) | 中等(字段固定) | 低(JSON解析器原生) |
| 扩展性 | 差(无标准字段) | 好(厂商自定义扩展) | 极好(可嵌套结构) |
| 兼容性 | 极高(所有网络设备) | 高(主流SIEM支持) | 中(云原生强) |
| 适用场景 | 原始收储、转发 | 多厂商日志统一接入 | 新项目、云环境 |
最后,附一张我手绘的日志格式与采集存储流程简图。它帮你理清从终端产生日志到冷归档的完整链路。