4、日志源识别：需要采集哪些系统的日志
说句大实话，PCI DSS审计里最容易翻车的就是日志源遗漏。我刚开始做合规项目时，总觉得日志采集就是装个Agent、配个转发就完事了。结果有一次内部预审，审计师拿着一张清单问我：”你们网络设备的NTP同步日志呢？数据库的DDL审计日志呢？“当时我就懵了——这些细节根本没在采集范围里。
日志源识别，说白了就是搞清楚一件事：到底哪些设备、哪些服务、哪些行为必须留下记录。PCI DSS标准里没给你列死清单，但它要求你能证明对所有”关键系统组件“的审计覆盖。嗯，这里面的坑可不少。
4.1 网络设备日志
网络设备是日志采集的第一道关口。防火墙、路由器、交换机的日志都跑不掉。我个人习惯先看三类设备：
- 边界防火墙——它控制着内外网通路，所有允许和拒绝的连接都要记
- 核心交换机——内部流量走向全靠它，审计需要知道谁连了谁
- VPN网关——远程访问的入口，登录/登出、会话建立都得有痕迹
我踩过的坑是：很多团队只配了防火墙的”拒绝“日志，忽略了”允许“日志。你想想看，如果攻击流量已经被放行了，你光看拒绝日志能发现什么？
- 登录/登出事件（SSH、Console、Web管理）
- 配置变更（ACL规则修改、路由策略调整）
- 连接建立/断开（Source IP、Dest IP、端口）
- 拒绝连接（ACL deny、黑名单触发）
- 时间同步（NTP状态变更、偏移量超限）
4.2 服务器与操作系统日志
服务器日志覆盖范围最广，也是最容易顾此失彼的地方。Linux服务器和Windows服务器的审计重点其实不一样，但底层逻辑相通。
Linux服务器：
/var/log/messages或/var/log/syslog——系统级事件/var/log/secure——认证与授权（SSH登录、sudo执行）/var/log/audit/audit.log——auditd审计日志/var/log/cron——计划任务执行记录
Windows服务器：
- 安全日志（Security）——登录成功/失败、权限提升、账户锁定
- 系统日志（System）——服务启停、驱动程序错误、系统关机
- 应用程序日志（Application）——IIS、SQL Server、自定义应用
这里有个容易漏的点：容器宿主机。Kubernetes节点和Docker主机的系统日志经常被归到”基础设施“范畴就没人管了，但PCI DSS审查的是所有存储、处理、传输持卡人数据的路径。宿主机逃不了。
4.3 数据库日志
数据库是持卡人数据最集中的地方，也是审计师最关心的组件。我建议从两个维度来想数据库日志：
- 连接层——谁在什么时候用什么账号连上了数据库
- 操作层——执行了什么SQL语句，影响了哪些数据
CREATE USER、ALTER TABLE、DROP TABLE这些操作必须记录。我见过太多只开DML审计、忽略DDL审计的案例了。
各数据库审计配置要点：
| 数据库类型 | 审计日志来源 | 必须开启的审计项 |
|---|---|---|
| Oracle | Fine-grained auditing (FGA) | LOGON/LOGOFF, DDL, DML on schema with cardholder data |
| MySQL | General log 或 audit plugin | CONNECT, QUERY with sensitive tables, GRANT/REVOKE |
| SQL Server | SQL Server Audit (Server-level & Database-level) | SUCCESSFUL_LOGIN_GROUP, USER_CHANGE_PASSWORD_GROUP, SCHEMA_OBJECT_ACCESS_GROUP |
| PostgreSQL | pgaudit extension | READ, WRITE, ROLE, DDL on sensitive columns |
4.4 应用系统日志
应用系统日志最容易被当成“业务日志”就扔掉了。但PCI DSS要求的是跟持卡人数据相关的所有应用行为都要可追溯。我个人习惯分三层来判断：
- 身份验证层——登录成功/失败、会话超时、密码重置
- 业务操作层——支付请求、退款操作、用户信息查询
- 管理操作层——权限分配、系统配置变更、API限流规则修改
举个例子：电商网站的付款页面。每一次点击“提交订单”背后可能产生API调用日志、应用服务器请求日志、数据库写入日志。这三者之间能不能对齐？审计师会抽查：某支付请求的应用日志ID和数据库日志里的关联ID是否一致。
用户ID、事件类型、日期时间戳、源IP地址、目标组件、事件状态（成功/失败/拒绝）
4.5 日志源识别的整体框架
讲到这里，你应该能感觉到：日志源识别不是简单拉个设备清单就完了。它需要你画出持卡人数据的流转路径，然后沿着路径把每个节点的关键日志源标出来。
下面这张图总结了PCI DSS日志源识别的核心逻辑：
4.6 常见的日志源遗漏陷阱
最后我把自己这些年踩过的坑列几个，你们配置的时候留意一下：
- 管理网络设备——带外管理口（BMC、iDRAC、IPMI）的日志很容易被忘掉
- 虚拟化平台——VMware vCenter、KVM宿主机、Hyper-V的管理日志
- 云服务组件——AWS CloudTrail、Azure Activity Log、GCP Audit Log
- 备份与恢复系统——备份作业启动/完成/失败、恢复日志
- 中间件——消息队列（Kafka、RabbitMQ）、负载均衡、反向代理
说白了，日志源识别的终点不是清单，而是覆盖证明。你需要拿出一张图和一份清单，告诉审计师：”这是CDE边界，这是边界内的所有系统组件，这是每个组件的日志源清单，每个源都开启了合规要求的审计项。“