第1章：PCI DSS概述与日志留存的重要性

各位好，我是老张。做安全合规差不多十年了，经手过不少PCI DSS的评审项目。今天咱们聊一个看似基础，却经常把人坑进去的话题——日志留存。

我记得早年做合规，很多公司觉得这就是走个过场。系统装完了，日志开着就行。但后来真出了事，才知道日志这东西，平时不起眼，关键时刻就是救命稻草。

说白了，PCI DSS 就是支付行业的“安全驾照”。你要处理卡号、交易数据，就得遵守这套规则。而日志留存和监控，是这套规则里最硬、也最容易被忽视的一块。

1.1 什么是PCI DSS？

PCI DSS是支付卡行业数据安全标准的缩写。它不看你公司规模多大，不看你的系统多先进，只看你是不是真的保护好了持卡人数据。

整套标准有六项控制目标，具体分了12大项要求。我们今天聚焦的，是第10项要求：“跟踪和监控对网络资源和持卡人数据的访问”。

为什么会单独拿一个章节讲日志？因为一旦出了事，日志就是你唯一能回放的“黑匣子”。没有日志，你根本不知道攻击者从哪里进来的、做了什么、带走了什么。

1.2 日志留存为什么是重中之重？

我习惯把日志比作一个“监控录像”。你想想看，银行大厅里没摄像头，你敢去存钱吗？同样的道理，核心交易系统没有完整的日志，QSA（审核员）凭什么相信你是安全的？

日志留存的核心价值，主要体现在三个方面：

• 事后溯源： 出了安全事件，第一步就是查日志。谁在什么时间、从哪个IP、执行了什么指令。日志不全，调查直接卡壳。
• 异常检测： 光存着不看也没用。你得有机制去发现“反常行为”，比如凌晨三点有人批量导出数据，或者连续输错密码。
• 合规举证： 这是最现实的。每年QSA来审计，会直接抽检日志配置和留存情况。留存天数不够、时间戳没对齐、日志被篡改，这些都是严重不合规项。

我曾经接手过一个救火项目。攻击者都进内网一个星期了，结果安全团队去找日志，发现系统日志只留了3天，而且好几个核心服务器的NTP没配，时间错乱了整整五个小时。你想想，这怎么溯源？怎么定位损失范围？最后只能吃哑巴亏。

1.3 日志流转的核心工作流

这里我画了一张图，展示我个人比较推荐的一条日志管控链路。从生成到最后销毁，每个环节都有明确的管控点。

这个流程其实很好理解：

1. 数据源生成（节点1）： 数据库、Web服务器、防火墙，这些设备必须按规范把日志吐出来。我个人习惯要求所有设备开启Debug级别以上的审计日志，特别是DDL和DML操作。
2. 集中采集（节点2）： 日志不能散落在各台机器上。需要有一个集中平台（比如Syslog或ELK）把它们收拢起来。嗯，这里要注意，采集链路必须加密，防止日志在传输过程中被截获。
3. 安全存储（节点3）： 日志存进来之后，要设置严格的权限。普通运维人员只给读权限，不能让任何人随意停服务或删索引。
4. 实时监控（节点4）： 光存着等审计是没用的。我在项目中遇到过一家公司，日志存了两年，结果没人看，攻击者跑了一个月的扫描都没被发现。必须对接告警规则。
5. 合规留存（节点5）： 按照PCI DSS要求，日志必须保留至少12个月。我建议把“在线查询”和“离线归档”分开。热数据存高性能存储，冷数据存廉价存储。
6. 调查取证（节点6）： 这是最终目的。一旦发生事件，能通过这个完整的链条，快速还原攻击路径。

1.4 避坑指南与实施建议

聊几个这些年我见过最常见的坑。大家可以在自己项目里对照一下。

• 时间戳不同步： 同一个机房，A服务器时间比B服务器快了5分钟。这在做关联分析的时候就是灾难。我习惯第一件事就是去统一NTP源，并且每小时做一次对时检查。
• 日志格式不统一： 有的系统用JSON，有的用Syslog，有的干脆自由格式。采集端解析起来会非常痛苦。建议提前做标准化模板，最好对接审计的同学一起定格式。
• 留存周期变短： 磁盘不够了就去删旧日志，这是大忌。我曾经见过因为日志爆盘，DBA直接把分片删掉的案例。合理的做法是做日志轮转，设定好水位线。

最后说一点。日志留存这件事，说难不难，说简单也不简单。难就难在它贯穿了安全、运维、开发多个部门。很多公司合规过不去，不是因为技术做不到，而是流程没跑通。