审计数据基础：审计日志格式、常见审计源
做 DSPM 审计联动，第一步不是配接口，而是搞明白你面对的数据长什么样。我刚开始接触这个领域时，以为审计日志就是一堆时间戳加用户名，结果被各种奇葩格式折腾得够呛。今天咱们就把这块硬骨头啃下来。
审计日志的核心要素
不管你从哪个源头拉日志，下面这几项几乎都会出现。记牢它们，后续解析才能不跑偏。
| 字段 | 说明 | 示例 |
|---|---|---|
| 时间戳 | 操作发生的精确时间，含时区 | 2025-02-18T09:23:45+08:00 |
| 主体 | 谁发起的操作（用户、服务账号） | app_user@example.com |
| 客体 | 被操作的对象（表、文件、API） | db01.orders.payment |
| 动作 | 具体操作类型 | SELECT, DROP, MODIFY |
| 结果 | 操作成功/失败，以及错误码 | SUCCESS 或 403 Forbidden |
| 上下文 | IP、客户端工具、会话ID等 | 192.168.1.10, JDBC |
我习惯拿到新日志源后，先提取这六个字段做个“格式映射表”。后面写联动规则时，哪项对应哪项，一目了然。
三大常见审计源
数据库审计日志
这是最常见、也是最重要的一类。MySQL、PostgreSQL、Oracle 都有各自的原生审计日志。说白了就是记录谁在什么时候对哪些表做了什么操作。
举个 MySQL 的例子，开启审计插件后，日志大致长这样：
2025-02-18T09:23:45 root[root] @ localhost [] QUERY testdb.orders 'SELECT * FROM orders WHERE amount > 1000' 0
2025-02-18T09:24:10 app_user[app_user] @ 192.168.1.10 [] QUERY testdb.users 'UPDATE users SET email = ...' 0
你会看到：时间戳、用户名、来源IP、数据库名、SQL语句、影响行数。我在项目中遇到过一个问题：公司生产库用的是 MariaDB，它默认的审计日志格式跟 MySQL 社区版不一样。当时我们写了个简单的格式化脚本才对齐。
系统审计日志
系统层级的审计，比如 Linux 的 auditd、Windows 的安全日志。这类日志主要记录文件访问、进程启动、权限变更等行为。对于 DSPM 来说，它们能帮你发现“非数据库操作”导致的数据泄漏，比如运维人员用 scp 直接把文件拷走了。
Linux auditd 的一条典型记录：
type=SYSCALL msg=audit(1708233825.123:456): arch=c000003e syscall=59 success=yes exit=0 a0=7ffe... a1=... a2=... a3=... items=2 ppid=1234 pid=5678 uid=1000 gid=1000 auid=1000 comm="scp" exe="/usr/bin/scp" key="data_transfer"
这里面你能提取出时间、进程名、用户ID、传输工具（scp）等关键信息。嗯，要特别注意那个 key 字段，很多公司会用它来做规则匹配的标签。
应用审计日志
应用层自己记录的日志，比如 Nginx 的 access_log、Spring Boot 的审计埋点。它们通常包含 HTTP 请求、API 调用、用户行为等。这类日志最灵活，但也最不规范。我曾经处理过一个客户案例：他们的自研 CRM 系统把审计日志写成了 JSON 数组，而且字段名隔几个月就改一次，那段时间我天天跟正则表达式较劲。
举个例子，一个标准的 Nginx 访问日志（经过自定义 JSON 格式化后）：
{"time":"2025-02-18T09:23:45+08:00","remote_addr":"10.0.0.5","request":"GET /api/export/users?format=csv","status":200,"body_bytes_sent":1048576,"http_user_agent":"Python-urllib/3.9"}
看到那个 1MB 的响应体大小没？这里有个坑——单次响应太大可能说明有人在批量拉数据。DSPM 联动时就要对这种模式打标记。
千万别假设所有审计日志的时间戳都是 UTC+8 或者带时区。我碰到过系统日志用 UTC 但应用日志用本地时间，导致关联分析时偏差了 8 小时，查了半天才发现。
日志格式的三大“派系”
你想想看，几十种源凑在一起，格式千差万别。但归类后其实就三大流派：
- 固定列文本日志：像上面 MySQL 审计日志，列之间用空格或制表符分隔。解析直接，但字段顺序一变就崩。
- 键值对/KV 日志：像 auditd 的输出，字段用 key=value 表示。灵活，但同一字段可能有多种拼写（比如 uid vs user_id）。
- 结构日志（JSON）：现代应用的主流。天然支持嵌套，但字段命名不统一，有的用驼峰有的用下划线。
我个人建议：能转 JSON 就转 JSON。结构化数据在后续的解析、聚合、规则匹配上都省力。实在转不了的，用 Logstash 或 Fluentd 的 filter 也能硬撸成统一格式。
知识地图：审计数据到联动配置
下面这张图把本章的核心串起来了。你顺着它，就能看清从日志源头到联动规则的完整链条。
记住这个脉络：采集源头 → 提取核心要素 → 归一化格式 → 配置联动规则。后面所有章节都是在这条线上深化。
实践建议：搭建审计日志采集的第一道坎
与其纸上谈兵，不如直接上手试。我建议你先挑一个最简单的源做通——比如 MySQL 开启审计日志，然后写一个 Python 脚本读一行、解析一行。不需要高大上的框架，先手动跑通，你才能真正理解字段映射的痛点。
最后提一句：审计数据本身也是敏感数据，别在日志里明文存密码或信用卡号。我曾经看过一个系统的审计日志里居然带着完整的三要素认证信息，那简直是把钥匙挂在门锁上了。