审计日志基础:日志格式标准与采集存储

审计日志,说白了就是系统里“谁在什么时候干了什么”的完整记录。在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),不要只存解析后的字段,以便后续重新解析。

格式对比与选择

下面这张表我经常拿出来给团队成员培训,直接看着选。

维度SyslogCEFJSON
解析复杂度高(需要正则/模板)中等(字段固定)低(JSON解析器原生)
扩展性差(无标准字段)好(厂商自定义扩展)极好(可嵌套结构)
兼容性极高(所有网络设备)高(主流SIEM支持)中(云原生强)
适用场景原始收储、转发多厂商日志统一接入新项目、云环境
个人建议:新上线的DLP项目直接上JSON格式。你想想看,现在所有分析引擎几乎都原生支持JSON,没必要再花精力转格式。如果历史设备必须输出Syslog,用Logstash或Fluentd转换成JSON后再入湖。

最后,附一张我手绘的日志格式与采集存储流程简图。它帮你理清从终端产生日志到冷归档的完整链路。

DLP 日志格式 · 采集 · 存储链路 Syslog (RFC 5424) CEF (Common Event Format) JSON (Structured) 日志采集层 Agent 采集 | 网络抓包 | API 拉取 热存储 (7–30天) SSD / NVMe 集群 温存储 (1–6个月) SATA HDD / S3 对象存储 冷存储 (6月–3年) 磁带 / 低成本归档 下游使用:SIEM | 告警平台 | 司法取证
别忘了规划日志完整性校验。 我曾经在一家金融客户现场发现,日志被篡改了28条但没有任何记录。后来我们强制每5分钟对热存储日志做一次SHA256校验,并把校验值独立存储在另一存储系统里。这招虽然多占一点计算资源,但能让审计证据链坚不可摧。