2、审计日志基础：什么是审计日志，常见格式、行业合规性要求
审计日志这东西，说白了就是系统里发生的「大事记」。谁、在什么时候、通过什么方式、干了什么事、结果怎样——全都按时间顺序记下来。我刚开始做运维那会儿，觉得日志嘛，能搜到异常就行。直到有一次被合规部门追着要三个月的登录记录，发现之前根本没开审计……嗯，从那以后我再也不敢小看这个环节了。
2.1 什么是审计日志
审计日志（Audit Log）是一组不可篡改的、按时间排序的事件记录。它区别于普通应用日志的地方在于：审计日志关注的是「谁做了什么」，而不是「程序哪里报错」。
核心特征
- 不可否认性：记录必须防篡改，通常配合哈希链或签名
- 时间精确：事件时间戳精度建议到毫秒，且集群内统一同步
- 结构化：便于后续检索、统计和告警
- 可追溯：能从一条记录反向追踪到完整的操作链路
我记得有一次客户排查内部数据泄露，全靠审计日志里的一条“非工作时间从内网下载敏感文件”记录，才锁定了嫌疑账号。如果没有审计日志，这种案子基本破不了。
2.2 常见审计日志格式
不同厂商、不同类型的设备输出审计日志的格式不一样。我在ELK项目中遇到过三种主流格式，这里逐个说清楚。
2.2.1 JSON 格式
现代系统和云平台（比如AWS CloudTrail、Azure Monitor）最爱用JSON。它的好处是结构清晰，Elasticsearch天然支持JSON嵌套解析，接入ELK基本零成本。
{
"timestamp": "2025-03-21T14:32:10.123Z",
"user": "wangwei",
"action": "DELETE",
"resource": "/api/v2/orders/10086",
"source_ip": "10.0.1.5",
"result": "success"
}我个人习惯在ELK的filebeat配置里直接把JSON字段映射到target字段，省去额外的grok解析，性能能提升30%左右。
避坑指南：我曾经遇到一个项目，业务方把大段嵌套JSON扔进message字段，导致ES mapping爆炸。建议在logstash里用json { source => "message" }先展开，再丢弃原始message。
2.2.2 Syslog 格式
传统网络设备、Linux系统日志输出常用Syslog（RFC 5424 / RFC 3164）。它的优点是轻量、兼容广，缺点是字段不够丰富，解析起来需要写正则。
<14>1 2025-03-21T14:32:10.123Z host01 sshd 1234 - [timeQuality tzKnown="1"] Failed password for root from 192.168.1.100 port 22 ssh2你看，这个例子里的用户、源IP、端口都混在一条文本里。在ELK里我一般先用grok过滤器拆成结构化字段，再做告警。你想想看，如果直接拿原始文本去搜索，后面想做“统计失败登录次数”就得吃大亏。
注意时区：Syslog默认不含时区信息时，Elasticsearch可能会按UTC存储，导致查询时偏移。我建议在日志发送端就强制带上timeQuality或统一配置NTP。
2.2.3 CEF 格式
CEF（Common Event Format）是ArcSight提出的一种安全事件格式，在SIEM领域特别常见。它的字段依靠“竖线|”分隔，头固定，后面是键值对扩展。
CEF:0|Security|Firewall|1.0|100|Login Failed|5|src=10.0.0.2 dst=192.168.1.1 dhost=webserver01我刚接触CEF时觉得这格式反人类，但后来发现它在合规审计场景里很好用——因为它强制要求设备厂商把严重等级、事件类型、源/目标都标准化。
三种格式对比
| 特性 | JSON | Syslog | CEF |
|---|---|---|---|
| 可读性 | 优 | 中（需要解析） | 中（分隔符明确） |
| ELK接入难度 | 极低（原生支持） | 较高（需grok） | 中（可用KV） |
| 扩展字段 | 自由嵌套 | 自定义标签 | 固定扩展键值对 |
| 典型场景 | 云平台、微服务 | 网络设备、Linux | 防火墙、IDS/IPS |
2.3 行业合规性要求
很多同学觉得审计日志只是“给老板看的”，其实不然。PCI-DSS和SOX这两个合规标准，直接决定了你的审计日志必须存什么、存多久、谁能改。我之前参与过一个支付系统的审计整改，差点被罚款。
2.3.1 PCI-DSS（支付卡行业数据安全标准）
如果系统里涉及信用卡数据（卡号、有效期、CVV），必须符合PCI-DSS。它明确要求：
- 记录所有对持卡人数据的访问（谁、何时、访问了哪些字段）
- 记录所有管理操作（添加用户、更改权限等）
- 审计日志保留至少12个月，其中最近3个月必须可即时检索
- 日志文件必须防篡改——我在项目里用ELK的ILM+冻结索引，再配合文件指纹校验来实现
个人经验：PCI-DSS的日志审查官很喜欢检查“是否有未授权的日志删除操作”。我们当时在ELK里对delete API做了唯一白名单，并给所有删除行为单独写了一条审计日志，这才过关。
2.3.2 SOX（萨班斯-奥克斯利法案）
上市公司（尤其是财务系统）必须遵守SOX。它不规定具体格式，但要求：
- 能够重建完整的事件流（从登录到操作到退出）
- 日志不能被中间人篡改
- 审计系统本身也要被审计（你记录了我的修改，那谁记录了你的记录？）
说白了，SOX要的是一个可信任的审计链路。我在ELK里采用的办法是：每条审计日志都写入一个独立的、只追加的索引，并定期对索引做sha256快照。这样即使有人改了索引数据，快照对比也能暴露。
曾经有个坑：我一直以为SOX只要求日志保留3年，结果发现不同交易所（纽约所、纳斯达克）的要求不一样。后来我统一把ELK的冷数据层放到对象存储，保留7年，既不违反任何标准，存储成本也压下来了。
2.4 总结一下核心关系
下面这张图概括了审计日志从产生到合规归档的整个脉络，方便你装进脑子里。
说实话，审计日志这件事看起来简单，但真正把它做成一个自动化、合规、可追溯的系统，需要考量的细节非常多。后面我们会一步步拆解如何在ELK里搭出这样一套基础设施。