1. 审计日志基础
1.1 什么是审计日志？
审计日志，说白了就是记录“谁在什么时候干了什么”的证据链。它不仅记录操作成功，还记录失败——甚至包括谁尝试访问了什么。
我刚开始接触这个概念时，觉得它不过是普通的运行日志。后来在一次合规审查中，我才真正明白它们的区别。运行日志帮我们排查Bug，而审计日志是给监管机构看的“案发现场记录”。
审计日志 vs 普通日志的核心差异：
- 不可篡改性——写入后不能删改，这是硬性要求。
- 完整性——所有敏感操作必须记录，不能漏项。
- 关联性——单条日志能串联到用户、时间和操作上下文。
1.2 审计日志到底有什么用？
我记得在某次线上故障复盘时，团队争论了半天“到底是谁改了数据库配置”。最后靠审计日志精准定位到某个实习生误操作。你说这东西重不重要？
- 安全监控——检测异常行为，比如深夜批量下载数据。
- 合规审计——满足GDPR、SOX、PCI DSS等法规的检查要求。
- 事故溯源——出问题时快速定位责任人。
- 责任认定——内部或法律纠纷中提供证据。
我曾见过一个团队，日志全部保存在本地磁盘。结果服务器被入侵，日志也一起被删了。那叫一个尴尬。所以审计日志的存储和防护，你想想看，是不是同样关键？
1.3 绕不开的法规要求
做云上审计日志，最头疼的就是法规。我整理一下最常见的三个，你大概先混个脸熟。
| 法规 | 核心要求 | 影响 |
|---|---|---|
| GDPR | 记录数据处理活动，用户可要求删除日志 | 日志保留策略必须支持删除请求，不能永久保留 |
| SOX | 财务系统操作记录不可篡改，保留7年 | 日志必须加密存储，定期归档到冷存储 |
| PCI DSS | 记录所有访问持卡人数据的行为 | 日志必须实时采集，并监控异常访问 |
避坑指南：
我曾经在项目中只关注了数据加密，忽略了日志的保留时长要求。审计时被罚了一笔。记住——法规要求你“删”的时候，你就不能“留”。
1.4 一条审计日志长什么样？
嗯，这里要注意。一条标准的审计日志至少包含以下字段：
{
"timestamp": "2025-03-21T14:32:00Z",
"user_id": "u-7h8k9a0",
"action": "DELETE",
"resource": "oss://prod-db-backup/2025-03-20.sql",
"source_ip": "10.0.1.42",
"status": "success",
"session_id": "sess-abc123"
}
光有结构还不够，我建议在实际采集时附加一层环境标签（env: production），方便后期做多租户隔离或按环境进行成本拆分。否则所有日志混在一起，你查起来会疯掉。
个人习惯小技巧：
每条日志加一个唯一ID（UUID），方便做引用和去重。我在分布式系统中吃过重复日志写入的亏，搞了整整两个通宵才定位到。
1.5 知识体系框架
为了让你看得更清楚，我把这章的核心逻辑画成了一张图。你可以跟着这张图，理解审计日志的完整链条。
1.6 你还没有意识到的坑
讲到这里，我得泼一盆冷水。很多团队在初期觉得“存日志很简单”，结果在合规审查时跪得很难看。你记住三个痛点：
- 日志孤岛——不同系统各存一份，没法做全局关联分析。
- 保留策略缺失——日志越积越多，成本爆炸，还不一定能满足合规要求。
- 篡改风险——明文存储的日志，黑客拿到的第一时间就能改掉。
我在一次红蓝对抗演练中，攻方就是通过篡改日志掩盖了自己的渗透痕迹。从那以后，我对审计日志的存储和加密格外上心。
我的建议：
刚起步时，先把“记录什么”和“存多久”这两个问题定死。后续的加密、采集、归档才有根可循。
嗯，这一章的基础框架就这样。后面我们会一步步拆解，让这些概念真正落地到代码和架构中去。