一、审计日志基础概念

什么是审计日志

审计日志，说白了就是云平台里谁、在什么时候、对什么资源、做了什么操作的逐条记录。它不是普通的程序日志，而是带着严格格式的操作凭证。

我个人习惯把审计日志理解为云平台的“黑匣子”。飞机出事后大家查黑匣子，云上出问题时我们翻审计日志。有一次我排查一个权限泄漏事件，全靠审计日志追踪到某个运维人员深夜手动修改了安全组规则。要不是日志准确记录了源IP和操作时间，这个锅可能就甩给系统了。

审计日志有几个关键要素：

• 主体：谁操作的（用户ID、角色、服务账号）
• 客体：操作了什么（云服务器、存储桶、数据库等资源）
• 动作：做了什么（创建、修改、删除、读取）
• 上下文：在什么环境下做的（源IP、时间戳、用户代理）
• 结果：操作是否成功（成功、失败、拒绝）

每条审计日志就像一张证据照片。照片里必须同时拍到人、动作和结果。

审计日志的核心特征

你想想看，日志那么多，什么样的才配叫“审计日志”？我总结了四个特征：

审计日志的分类

嗯，这里要注意分类。不同场景下审计日志的侧重点完全不一样。我把它们分成三大类：

• 操作审计——谁做了什么
  • 创建、删除、修改云资源
  • 权限变更、角色绑定
  • 登录/登出行为
• 数据审计——数据怎么被访问了
  • 数据库查询记录
  • 对象存储文件读取/下载
  • 敏感信息访问日志
• 安全审计——有没有异常
  • 暴力破解尝试
  • 异常时间操作
  • 异常源IP请求

我建议你按照分类来管理保留策略。操作审计一般保留半年，数据审计最好保留一年，安全审计最短也要保留一年到两年。为什么？

原因很简单：安全事件的回溯周期往往比操作故障长得多。我曾经遇到一个攻击案例，攻击者在三个月前就偷偷建立了隐藏账号，直到第五个月才被安全审计发现。如果日志只保留三个月，这个案子永远破不了。

审计日志长什么样

拿AWS CloudTrail的一条日志举例：

{
  "eventVersion": "1.08",
  "userIdentity": {
    "type": "IAMUser",
    "arn": "arn:aws:iam::123456789012:user/admin",
    "accountId": "123456789012"
  },
  "eventTime": "2024-03-15T14:30:00Z",
  "eventSource": "ec2.amazonaws.com",
  "sourceIPAddress": "192.168.1.100",
  "eventName": "CreateInstance",
  "resources": [{
    "arn": "arn:aws:ec2:us-east-1:123456789012:instance/i-abc123"
  }],
  "responseElements": {
    "instancesSet": {
      "items": [{"instanceId": "i-abc123"}]
    }
  }
}

说白了，每一条都是结构化、可解析的JSON。你看这个结构：谁操作、什么时候、从哪来、干了什么、结果如何——完全对应我们之前说的五要素。

为什么审计日志这么重要

你可能会想：日志嘛，能记录就行了。我以前也这么觉得，直到一次客户环境被误删。

那次我记得特别清楚：凌晨三点，某运维手滑删了整个生产数据库。恢复数据花了八个小时。事后追责时，管理层要求提供“谁操作了销毁命令”的证据。审计日志就是唯一的救命稻草。没有它，连是谁干的都无法确认，更别说整改和追责了。

审计日志的价值体现在四个层面：

1. 合规要求——等保2.0、ISO 27001、SOC 2等标准都明确要求保留审计日志
2. 安全调查——发生入侵或数据泄露时，审计日志是第一手证据
3. 故障排查——谁做了什么导致系统挂了，审计日志能快速定位
4. 成本分析——通过操作日志分析资源利用率，优化云支出