📚 课程目录第3章常见云平台审计日志类型

3. 常见云平台审计日志类型：操作日志、访问日志、资源变更日志

做云平台审计，绕不开三种核心日志类型。我自己刚接触审计日志时，以为“只要是日志就一样”，结果被线上事故狠狠教训过——一次误操作删了数据库，却找不到是谁干的。

嗯，从那以后我逢人就说：分清日志类型，比单纯堆量重要得多。你想想看，不同类型的日志，在保留策略上差别非常大。操作日志要追责、访问日志要合规、资源变更日志要排查配置漂移。如果一刀切保留，要么浪费存储，要么关键信息提前过期。

下面我把这三种日志拆开讲，每类带点实际经验。

操作日志记录的是“谁在什么时间、通过什么渠道、干了什么”。比如用户登录控制台、创建一台虚拟机、修改安全组规则、删除负载均衡器——这些行为都会被记下来。

我个人习惯把操作日志的核心字段记成“五W”：

我在项目中遇到过这样一个坑：有一次交付审计系统，客户要求操作日志保存 365 天，结果三个月后存储就爆了。为什么？因为他们把每一条操作日志里的请求参数都原样保存，大的 JSON 体动辄几十 KB。后来我建议只保留关键字段，原始请求存到另一套归档系统，这才把单个日志体压缩到 1KB 以内。

我的建议：操作日志优先考虑可审计性。保留时间至少满足安全合规要求（如 SOC2、PCI-DSS 通常要求 1 年），但可以分层存储：前 90 天放在高速热库，后面的移到冷存储或归档。

访问日志记录的是“谁在什么时候访问了什么资源”。跟操作日志不同，访问日志更偏向读取和流量层面。比如对象存储的 GetObject 请求、API 网关的每一次调用、CDN 的边缘节点请求。

我记得有一次，某客户的网站被 DDoS 攻击，他们想通过日志溯源攻击 IP。结果发现访问日志只保留了最近 3 天的，攻击发生在一周前，日志早已过期。没办法，只能靠网络流量包重新分析。

访问日志典型的字段包括：

避坑提醒：访问日志可能包含敏感信息。比如 URL 里的、请求体中的用户数据。我曾经见过一个错误配置，把含有用户手机号的请求参数原样记入日志。这在 GDPR 环境下是严重违规。建议在记录前做脱敏（如正则替换、哈希化）。

访问日志的保留策略通常更短，因为量太大了。一个中等规模的 API 网关，一天可能产生几十 GB 日志。我个人常用的做法：

资源变更日志，说白了就是记录云上资产的“前世今生”。比如安全组规则从拒绝 22 端口变成了允许所有来源，或者是 RDS 实例的存储空间由 100GB 调整到 200GB。这些变更往往是配置漂移的源头。

有一次线上故障，客户说“我们没有改数据库白名单，为什么访问突然被拒了”。我查了资源变更日志，发现前一天夜里一条自动化脚本修改了安全组规则，把 3306 端口的来源 IP 段缩小了。没有变更日志，这种问题根本查不出来。

资源变更日志的核心字段：

⚠️ 注意：很多云平台默认只打开部分资源的变更日志，比如 AWS Config、Azure Resource Graph。我建议全量开启，因为微小的配置变更可能引发大问题。

保留策略建议：资源变更日志通常需要保留 至少 90 天，用于变更回溯。对于合规要求严格的企业（如金融、医疗），我建议保留 365 天以上，且禁止删除（仅可归档）。变更配置快照可能非常大，可以考虑只保留差异（diff），而非全量快照。

下面这张表能帮你快速区分三类日志的定位，我在做策略制定时经常用它做参考：

维度	操作日志	访问日志	资源变更日志
关注点	谁做了什么操作	谁访问了什么资源	资源配置是如何变化的
典型来源	CloudTrail、Activity Log	ELB Log、API Gateway Log、CDN Log	AWS Config、Azure Resource Graph、Terraform state
数据量级	中等（每操作一条）	极大（每个请求一条）	小（每次变更一条）
保留时长	1～7 年（合规）	7～90 天（采样可更长）	90～365 天
敏感内容	可能包含、请求参数	可能包含用户信息、	配置快照（一般无敏感数据）

注意：实际云厂商的命名可能不同，但本质都跑不出这三类。比如阿里云把操作日志叫“操作审计”，访问日志在 SLB 里叫“访问日志”，资源变更日志对应“配置审计”。

下面是三类日志在整体审计体系中的关系图，方便你理解它们是如何协同工作的：

看到这张图，你应该能直观理解：操作日志负责“谁动了”、访问日志负责“谁看了”、资源变更日志负责“变成了什么”。三个维度缺一不可。

最后分享一个我自己的选型思路。在做保留策略时，别只看存储成本。先问业务方三个问题：