审计日志基础
什么是审计日志？
审计日志，说白了就是系统里的一本“黑账”。
它记的是谁、在什么时间、干了什么事、结果怎么样。
我刚开始接触安全领域的时候，总觉得日志就是调试用的。
后来在一次内部渗透测试里，攻击者删了关键配置，团队翻了两天的 Syslog 才定位到是谁的 泄露了。
从那以后，我才真正明白——审计日志不是调试工具，是安全最后一道防线。
审计日志的作用
你可以把它理解成飞行记录仪。平时没什么用，一出事就是救命稻草。
具体来说，它干这三件事：
- 追溯 —— 出事后能贴着时间线回放操作，找到“第一滴血”
- 问责 —— 谁滥用权限、谁误操作，一条日志就是证据
- 合规 —— PCI-DSS、SOX、GDPR 都要求保留特定粒度的审计记录
我在给一家金融客户做 RBAC 改造时，对方的合规审计直接要求：
“所有角色分配和权限变更，必须记入不可篡改的审计日志，保留至少 6 个月。”
当时我们就用 JSON 格式把每次 RoleAssignment 事件完整记录下来，一年后真派上了用场——监管部门抽查，15 分钟就导出了全部合规证据。
典型字段：一句话记全一件事
一条审计日志要想“可追溯、可定性”，至少得包含下面这些字段。我按重要程度排了个序：
| 字段 | 含义 | 示例值 |
|---|---|---|
| Timestamp | 事件发生的精确时间 | 2025-03-21T14:23:10.542Z |
| User | 操作主体（人或系统账号） | zhang_san / api_svc_01 |
| Action | 执行的操作 | DELETE /api/v1/roles/admin |
| Resource | 被操作的对象 | role:admin |
| Result | 成功/失败/拒绝 | SUCCESS / FAILURE / DENIED |
| SourceIP | 来源地址 | 10.0.1.100 |
| SessionID | 关联同一次会话 | abc123def456 |
我的习惯： 除了标准字段，我还会加一个 trace_id 或 correlation_id。尤其在微服务架构里，靠它把跨服务的审计日志串起来，比翻时间戳靠谱得多。
常见格式：Syslog 与 JSON
你想想看，日志格式要是五花八门，安全分析工具根本没法统一解析。目前业界主流就两套：Syslog 和 JSON。
Syslog —— 老派但广泛
Syslog 起源于 Unix 系统，是 RFC 5424 定义的标准。
它的结构很简单：<优先级>时间戳 主机名 进程[PID]: 消息内容
我在早期项目中见过生产环境的网络设备、防火墙几乎清一色都在吐 Syslog。优点是兼容性好，缺点嘛……字段太松散，想解析一个自定义字段经常要靠正则硬啃。
<13>Mar 21 14:23:10 srv-web01 sshd[12345]: Failed password for zhang_san from 10.0.1.100 port 22 ssh2上面这条日志，“Failed password”这种关键信息是嵌在消息体里的，没有结构化字段。你得写正则才能把 zhang_san 和 10.0.1.100 抠出来。
JSON —— 现代可编程
JSON 格式是云原生和 RESTful 时代的新宠。每条日志就是一个完整的 JSON 对象，所有字段都清晰标好 key。
解析起来？只要一行 json.loads()。这也是我个人的首选格式。
{
"timestamp": "2025-03-21T14:23:10.542Z",
"user": "zhang_san",
"action": "assume_role",
"resource": "role:auditor",
"result": "SUCCESS",
"source_ip": "10.0.1.100",
"session_id": "abc123def456",
"trace_id": "7a8b9c0d1e2f"
}Syslog vs JSON：怎么选？
不是所有场景都适合 JSON。举个例子，你处理的是嵌入式防火墙、老旧交换机的日志——那根本没得选，只能接 Syslog。但如果你在搭一套 RBAC 审计中心，那我建议你从第一天就用 JSON。
| 对比项 | Syslog | JSON |
|---|---|---|
| 结构化程度 | 低（靠约定） | 高（自带 schema） |
| 解析难度 | 需要正则 / 模板 | 直接反序列化 |
| 可扩展性 | 往消息体里塞 | 加新字段无侵入 |
| 工具生态 | Rsyslog、syslog-ng | ELK、Splunk、Datadog |
| 性能 | 低开销（纯文本） | 略高（序列化/反序列化） |
我曾经踩过一个坑： 早期用 Syslog 记 RBAC 日志，日志消息体里写了 user=zhang_san action=delete 这种 key=value 格式。结果后来换了日志采集工具，新工具默认分隔符不一样，所有日志解析都乱了。从那以后，我自己的项目里统一用 JSON，哪怕只是一个字段也给我写成 JSON 对象。
一条审计日志的完整构成
下面这张图把上面的知识点串起来了——从事件发生到日志成型，字段如何填充，最终输出成什么格式：
你可以看到，无论选 Syslog 还是 JSON，核心字段来源是一样的。
真正拉开差距的，是解析效率和扩展性。我见过很多团队上线半年后因为字段不全、格式混乱，不得不花两周把老日志重新清洗一遍——太痛苦了。
实践建议： 刚开项目时，哪怕只输出这七字段（时间戳、用户、操作、资源、结果、源IP、会话ID），也已经能满足 90% 的安全审计需求。后续再加字段，JSON 格式里直接 append 就行，零耦合。
小结
审计日志不是什么高深概念，但要做好真不容易。
记住：
- 字段要全且一致，不要一边记一边改结构
- 格式选 JSON 更方便后续处理，除非你跑在嵌入式设备上
- 每条日志必须能唯一追溯到一次用户操作，否则等于没记