需求10核心要求解析：日志记录范围归纳总结
需求10，说白了就是一句话——谁、在什么时候、从哪、干了什么、结果怎样，你都得记下来。但真到落地的时候，很多人就懵了：「到底哪些要记？记到什么粒度？边界在哪？」
我带过的团队里，有把鼠标点击都记下来的，也有漏掉核心系统登录的。两种都走偏了。今天我就把需求10的日志范围给你拆开揉碎，讲清楚。
一、需求10到底要我们记什么？
其实PCI DSS的原文写得挺清楚，但读起来确实枯燥。我习惯把它归纳成「五大维度」，你照着这个框架去对，基本不会漏。
- 用户活动 — 谁登录了？谁退出了？谁访问了敏感数据？
- 特权操作 — 管理员干了什么？权限变更、配置修改、审计日志操作。
- 系统变更 — 软件装了啥？配置改了哪？补丁打了没有？
- 网络活动 — 数据从哪来、到哪去？防火墙、IDS/IPS的告警。
- 异常事件 — 登录失败、越权访问、批量导出、非工作时间操作。
核心原则：所有涉及持卡人数据（CDE）的访问、处理、传输，必须留下痕迹。这条红线不能碰。
这五个维度不是各自孤立的。你想想看，一个攻击行为往往会在多个维度留下脚印。比如一个黑客通过弱口令登录了数据库（用户活动），然后提权（特权操作），再导出一批卡号（异常事件）。少了任何一环，你都没法溯源。
这张图我建议你存一份。每次做新系统接入、老系统改造的时候，拿出来对照一下，五个维度各写一条日志就够了？不够。重点是每个维度下还有具体的事件类型。
二、用户活动追踪 — 谁在什么时候做了什么
这是最基础、也最容易出问题的一块。我在项目中遇到过不少团队，登录日志记了，但登出没记。结果审计的时候发现某个用户一直「在线」，其实人早下班了。
我的经验：用户活动的日志至少覆盖以下7个事件——
登录成功、登录失败、登出、会话超时断开、密码变更、权限变更、访问持卡人数据。
有些团队觉得「访问持卡人数据」这个太难界定。其实标准很简单：只要应用程序或数据库返回了完整的PAN（主账号），就得记。掩码过的？一般不用，但你要跟QSAC确认清楚。
三、特权操作监控 — 管理员的一举一动
嗯，这里要注意。特权账户是攻击者的首选目标，也是内部威胁的高发地带。需求10对特权操作的日志要求比普通用户严格得多。
| 操作类型 | 必须记录的内容 | 常见遗漏点 |
|---|---|---|
| 特权登录/登出 | 用户ID、源IP、时间戳、会话ID | 登出事件、并发会话数 |
| 权限提升/降级 | 操作前角色、操作后角色、审批人 | 临时提权未记录 |
| 审计日志操作 | 停止、清空、修改、导出审计日志 | 轮转策略触发的自动清空 |
| 系统配置变更 | 变更内容、变更时间、变更人 | 回滚操作未记录 |
我曾经遇到一个案例：某公司的DBA用root账号直连数据库，导出了一批生产数据去做测试。审计日志里只记了「root登录成功」，完全没有记录后续的查询和导出操作。结果数据泄露了，花了两周才定位到人。后来他们加上了audit_trail=db,extended，所有DDL和DML都跑了审计。
注意：特权账户的日志不能由特权账户自己管理。职责分离是硬性要求。我见过不少小团队，root自己配了日志，自己删日志，等于没记。
四、系统变更记录 — 改了啥，谁改的
系统变更的范围比你想象的大。不只是代码发布和补丁安装，还包括：
- 配置文件修改 — 比如
/etc/ssh/sshd_config、web.xml、redis.conf - 服务启停 — 关了iptables？停了auditd？这些都得记。
- 软件安装/卸载 — 用yum、apt、pip装了啥？版本号是多少？
- 网络设备变更 — 防火墙规则增删、路由表修改、ACL变更。
我个人的做法是：在CDE环境里统一部署一个配置变更监控 agent，比如 Osquery 或 Wazuh，所有变更事件集中上报。别靠人工去翻 .bash_history，那个太容易造假了。
一个实用技巧：对关键配置文件做校验和（如 SHA-256），每次变更触发告警并记录。这样即使日志被删，你还能从文件系统层面发现异常。
五、网络活动日志 — 数据流向哪里
网络层的日志容易被忽略，但其实是溯源链里非常关键的一环。需求10要求记录所有进入和离开CDE的网络连接。
说白了，你要能回答这三个问题：
- 谁连了谁？ — 源IP、源端口、目标IP、目标端口、协议。
- 连了多少？ — 流量大小、会话时长、数据包数量。
- 结果如何？ — 连接被允许、被拒绝、还是被丢弃了？
避坑指南：我曾经遇到一家公司，防火墙的deny日志记了，但allow日志没开。结果攻击者在内网横向移动了三个月，他们完全看不到。记住——allow日志比deny日志更重要，因为攻击流量通常是从allow通道走的。
六、异常事件捕获 — 不寻常的信号
异常事件不是独立于前四个维度的新类别，而是它们的子集。但需求10单独强调了它，因为异常事件直接关系到入侵检测和响应时效。
哪些算异常？我列个清单供你参考：
- 连续登录失败（比如5分钟内5次以上）
- 非工作时间的管理员登录
- 从未知IP或地理位置访问CDE
- 批量导出大量记录（阈值自己定义，我一般设100条/分钟）
- 同时多地点登录同一个账户
- 审计日志服务突然停止
嗯，这里有个关键点。异常事件的日志要能触发告警，但告警和日志是两回事。需求10要的是日志必须包含异常标记，方便事后检索和分析。你不能只记一条普通登录日志，然后在告警系统里说「这个登录是异常的」。日志本身要能体现异常特征。
再强调一次：所有日志必须包含时间戳（精确到秒）、用户身份、源IP、操作类型、结果状态。缺任何一项，这条日志在审计时就等于废的。
七、一张表总结：什么该记，什么不该记
最后我用自己的方式给你梳理一下。这是我在每个项目开始时都会发给团队的《日志范围速查表》，你直接拿去用：
| 维度 | 必须记录 | 可以不记录 | 备注 |
|---|---|---|---|
| 用户活动 | 登录、登出、访问PAN、密码变更 | 页面浏览行为（不涉及数据） | API调用必须记 |
| 特权操作 | 所有操作（包括查询、变更、导出） | 无 | 特权账户无豁免 |
| 系统变更 | 配置修改、软件安装、服务启停 | 日常备份作业（成功时） | 备份失败必须记 |
| 网络活动 | 所有连接请求（允许+拒绝） | 内部健康检查流量 | 去重后存储 |
| 异常事件 | 登录失败、越权、批量操作、审计中断 | 单次偶然错误（如网络重传） | 阈值需合理配置 |
你看，其实范围没有你想象的那么无边无际。关键是抓大放小，守住底线。底线就是：所有涉及持卡人数据的访问路径，必须有日志覆盖。其他外围系统，可以根据风险等级适当放宽。
我个人的习惯是，每季度做一次日志覆盖范围审计。拿一张CDE架构图，从数据存储层往上画，每个访问路径都标注「已覆盖」或「未覆盖」，未覆盖的必须在下一季度补上。这样坚持两年，整个团队的日志意识就上来了。
好，需求10的日志范围就讲到这里。记住那五个维度，记住时间戳+用户+源IP+操作+结果这五个字段，你的日志体系就不会差到哪去。