📚 课程目录第3章日志采集要求

3、日志采集要求：PCI DSS Requirement 10详解——日志记录策略

谈到PCI DSS的日志采集，很多人第一反应就是“把服务器日志都收上来不就行了？”——其实远没那么简单。Requirement 10真正关心的，是你能不能追溯每一次“谁、在什么时候、从哪里、做了什么”，以及日志本身是否被篡改过。我当年第一次做PCI合规项目，就以为开了syslog转发就万事大吉，结果审计时被QSA问住：“你那些日志的时区统一了吗？保留够一年了吗？”——嗯，那之后我才老老实实啃完这一章。

10.1 为什么日志记录是审计的命脉

说白了，没有完整且可靠的日志，你根本没法证明自己合规。一旦发生数据泄露，日志就是唯一的破案线索。QSA要的不是你“开了日志”，而是你“按标准记录了该记的东西，并且没人能偷偷删掉它。”

我个人的习惯是：先搞清楚业务系统的日志源头在哪，再设计采集方案。别一上来就想买各种SIEM，先把基础要求摸透。

小技巧：在项目启动阶段，就让安全运维团队列出所有卡数据处理系统的清单，然后逐个确认日志是否开启。这一步做得越细，后面越省心。

10.2 到底要记哪些日志？——要求10.2详解

PCI DSS要求10.2列出了必须记录的审计线索，一共8类。我做了个表格，方便你对照检查：

编号	日志事件类型	说明
10.2.1	所有用户的个人用户访问	不仅是管理员，普通用户访问卡数据系统也得记
10.2.2	由特权账户执行的任何操作	root、admin、DBA的每一步动作都要留下痕迹
10.2.3	对所有审计线索的访问	谁看了日志、改过日志配置，都得记
10.2.4	无效的逻辑访问尝试	失败的登录、越权尝试，是攻击前兆
10.2.5	对标识和身份验证机制的修改	创建新用户、改密码策略、加sudoers等
10.2.6	审计日志本身的初始化、停止或暂停	谁停了日志？什么时候停的？这是重点
10.2.7	创建和删除系统级对象	比如安装/卸载软件、创建设备文件
10.2.8	分布式系统中的角色提升	普通用户提权到管理员，必须记录

你想想看，如果攻击者盗用了管理员账号，然后停机日志、删了记录，你就彻底瞎了。所以10.2.6和10.2.3这两条特别关键。

注意：很多企业在Linux上用auditd只配了默认规则，根本记不全10.2要求的全部事件。我去年帮一家支付机构做gap analysis，发现他们的syslog没转发10.2.4（失败登录），差点被QSA开finding。

10.3 每条日志得记哪些字段？——要求10.3

光记“谁干了什么”不够，还得有7个要素。我称之为“日志的7要素身份证”：

用户标识：是哪个用户ID操作的？
事件类型：操作的性质（登录、创建、删除等）
日期和时间：要求精确到秒，并且带时区
成功或失败标志：操作最后成功了没？
事件来源：来自哪个IP、哪个终端？
受影响的对象：操作了哪个文件、哪个数据库表？
事件描述：简要说明这次操作的上下文

记得有一次，一个团队把时区漏了，所有日志都用服务器本地时间。结果攻击事件跨了三个时区，取证时对不起来——这个坑我曾亲眼见过。

10.4 时间必须同步——要求10.4

如果你不搞定时间同步，日志再多也是废纸。PCI DSS明确要求：所有系统的时间都必须同步到一个统一的时间源，最好用NTP。而且时区也得统一，个人建议全部用UTC。

我习惯在每台服务器的定时任务里加一行NTP同步检查脚本，每天跑一次，发现偏差超过1秒就告警。这样审计时直接甩出时间同步记录，QSA没话说。

配置示例（NTP客户端）：

# /etc/ntp.conf
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
restrict default kod nomodify notrap nopeer noquery
restrict 127.0.0.1

10.5-10.6 日志要安全存放，不能被篡改

你采集了日志，但攻击者能进去删改，那等于白干。要求10.5说日志文件必须加以保护，防止修改和删除。要求10.6进一步要求日志文件要立即以标准格式转发到远程日志服务器（或者安全的集中存储）。

说白了，日志要具备“写一次，读多次，改不了”的特性。常见做法是：
- 使用syslog-ng或rsyslog将日志实时转发到独立的日志服务器。
- 日志服务器上启用文件权限控制，只允许日志管理服务写入。
- 有条件的企业可以上WORM（一次写入多次读取）存储设备，或者用区块链防篡改方案。

10.7 日志要留多久？——保留策略

PCI DSS要求日志至少保留12个月，其中最近3个月的日志必须能快速检索。注意区分：
- 近3个月：必须在线可查。
- 剩下9个月：可以归档存储，但需要能在合理时间内恢复。

我参与过的项目里，最大的坑是日志轮转策略。有些运维同事为了省磁盘，把轮转周期设成1天，只保留30天的日志。结果审计时发现3个月前的日志早就被cronjob删了——这个教训让我加了一条巡检规则：每个季度手动查一次日志保留天数。

避坑提醒：我曾经见过一个团队把日志归档到AWS S3 Glacier，但恢复一份日志要等12小时。QSA当场指出“恢复时间不合理”，最后他们不得不改为S3 Standard-IA。

日志记录策略总览图

下面这张SVG图梳理了从日志产生到销毁的全生命周期，以及每个环节对应PCI DSS的具体要求。你可以把它打印出来贴在运维墙上。

一点总结

Requirement 10的日志记录策略，核心就是六个字：全、准、稳、存、护、查。
全——所有该记的事件都要记；
准——时间、字段不能缺失；
稳——日志不能被篡改；
存——保留够12个月；
护——日志文件权限严格控制；
查——近3个月能快速检索。

把这些点一一落实，你的日志审计基础就扎实了。后面章节咱们再聊怎么高效采集和自动化巡检。