第4章 系统组件日志：服务器、网络设备、数据库
各位好。这一章我们聊聊系统组件日志。说白了，就是那些跑业务、转流量、存数据的设备该记什么、怎么记、记多久。
PCI DSS要求很明确：所有系统组件都必须生成日志。什么是系统组件？服务器、路由器、交换机、防火墙、数据库，还有虚拟化平台、容器宿主机，全算在内。
我刚开始做合规项目时，客户总问：“我防火墙记了，服务器也记了，够了吧？”不够。每个组件都有自己的“证据链”，缺一环都可能在审计时被扣分。
核心原则：只要处理、存储或传输持卡人数据，或者能直接影响持卡人数据安全环境的组件，都必须纳入日志记录范围。
4.1 服务器日志：操作系统与应用的“体检报告”
服务器是持卡人数据的主要载体。日志记录必须涵盖三个层面：操作系统、应用、安全。
4.1.1 操作系统日志
- 登录事件：成功的、失败的，本地还是远程，谁在什么时间登录。
- 特权操作：sudo、su、权限变更、添加/删除用户。
- 系统服务启停：SSH、Web服务器、数据库进程何时启动或停止。
- 文件完整性变化：关键系统文件被修改（配合FIM工具）。
我记得有一次审计，对方只记录了登录成功，没记登录失败。结果一张暴力破解的告警根本查不到原始日志。嗯，这个坑别踩。
4.1.2 应用日志
应用日志要看具体业务。支付网关要记交易流水，Web应用要记HTTP请求。我建议至少包含以下字段：
| 字段 | 说明 | 示例 |
|---|---|---|
| 时间戳 | 精确到毫秒，统一时区 | 2025-03-21 14:30:05.123 UTC |
| 用户标识 | 账号、会话ID、源IP | user01 / 192.168.1.10 |
| 操作类型 | 增删改查、登录、支付 | POST /payment |
| 结果状态 | 成功/失败/拒绝 | 200 / 403 |
| 被访问对象 | URL、文件、记录ID | /api/charge?id=12345 |
实用技巧：应用日志最好带一个“请求跟踪ID”，方便把Web层、应用层、数据库层的日志串起来。我维护过一套支付系统，靠这个字段排查慢查询快了三倍。
4.2 网络设备日志：流量出入的“监控摄像头”
网络设备包括路由器、交换机、防火墙、入侵检测/防御系统（IDS/IPS）、VPN网关等。它们负责决定流量能不能过、过了记不记。
4.2.1 防火墙日志
- 会话建立与拆除：源IP、目的IP、端口、协议，允许还是拒绝。
- NAT转换：公网IP与内网IP的映射记录。
- 策略变更：谁在什么时间修改了防火墙规则。
我遇到过一家公司，防火墙日志只开了“拒绝”记录，没开“允许”记录。结果内部横向移动攻击完全没留下痕迹。后来他们补上了，但那段空白期已经没法溯源了。
4.2.2 交换机与路由器日志
- 接口状态变更：链路UP/DOWN，可能是物理故障也可能是入侵行为。
- STP / OSPF / BGP 邻居变化：拓扑变更，可能被中间人攻击。
- MAC地址表溢出：典型嗅探攻击特征
4.2.3 IDS/IPS日志
告警类型、攻击特征ID、原始流量载荷（谨慎记录，避免保存明文PAN）。我个人习惯保留告警摘要和源目IP，原始载荷在安全事件响应时再现场抓包。
注意：不要把所有网络设备的 debug 级日志都打开。流量密度大的环境，一秒钟成千上万条日志，存储和处理成本会爆炸。只记录安全相关的事件，并设置合理的日志量限制。
4.3 数据库日志：数据的“完整审计链条”
数据库必须记录谁、什么时间、用什么语句、操作了哪些数据。关键是：持卡人数据的访问必须可追溯。
4.3.1 数据库审计日志内容
- 登录成功/失败
- DDL（建表、删表、索引变更）
- DML（SELECT、INSERT、UPDATE、DELETE）——尤其是操作了包含PAN的列
- 权限变更（GRANT / REVOKE）
- 备份与恢复操作
我以前在MySQL里只开了general_log，结果三天把磁盘撑满了。后来改用audit plugin，精准记录指定表和操作的语句。Oracle可以用FGA（Fine-Grained Auditing），SQL Server有SQL Server Audit。各有千秋，但目标一致：不丢关键数据，不产生过载。
4.3.2 数据库日志字段建议
| 字段 | 必要性 | 说明 |
|---|---|---|
| 数据库用户名 | 必选 | 不要只记系统进程ID，要记应用账号 |
| 客户端IP | 必选 | 区分是应用服务器还是运维人员直连 |
| SQL语句（或语句指纹） | 可选 | 含敏感参数时可进行脱敏处理 |
| 执行时间 | 必选 | 配合慢查询分析 |
| 受影响行数 | 建议 | 发现大量数据批量导出时快速定位 |
小经验：运维人员直连数据库时，必须在跳板机统一认证，并记录跳板机到数据库的会话日志。我曾经在某次渗透测试中模拟内部人员，利用直连数据库的弱口令删了一张表，事后审计日志里只有一个“sa”账号，根本找不到是谁。后来加了跳板机审计才堵上。
4.4 三类组件日志的共性要求
不管服务器、网络设备还是数据库，PCI DSS 要求日志至少包含：
- 用户标识（账号、IP、设备名）
- 事件类型（登录、访问、修改、删除）
- 日期与时间（精确到秒，NTP同步）
- 成功或失败的指示
- 事件源（源IP、源设备）
- 受影响的组件或数据对象
另外，所有系统时钟必须同步。我见过两台服务器时间差了10分钟，不同组件的日志关联起来完全对不上。解决方案很简单——全域NTP，并且日志里要用UTC+偏移量记录，避免夏令时混乱。
重要：日志必须被保护不被篡改。使用WORM（一次写入多次读取）存储、加密传输、访问控制。PCI DSS里明确要求：日志文件只能追加，不能修改或删除。如果业务需要备份，备份也要加密，并设定与原始日志相同的留存期限（至少12个月，在线可查至少3个月）。
4.5 一张图看懂系统组件日志架构
下面这张SVG图把服务器、网络设备、数据库的日志流向和关键点串起来了。你可以把它当作本节的“脑图”。
如何使用这张图：每一个大色块代表一类组件的日志要点。当你规划日志采集方案时，可以对照图中的子项，逐条检查“我是不是都记了”。我个人习惯把它打印出来贴在工位旁边，每次合规检查前过一遍。
4.6 避坑指南与实施建议
说了这么多，最后整理几个我踩过或见过别人踩的坑：
- 日志量爆炸：全开 debug 层级的网络设备日志，一天几个TB。解决方案是设置合理的日志级别，并对高频事件做采样或限流。我曾经帮一个客户调整防火墙日志策略，从每天500GB降到30GB，关键事件一个都没丢。
- 存储容量规划不足：PCI DSS要求在线可查至少3个月，归档至少12个月。但很多公司只盯着3个月算，忘了业务增长和日志体积膨胀。我建议按当前速率的2倍预留，并启用日志压缩（例如用gzip压缩syslog文件，压缩比通常5:1）。
- 忽略虚拟化层：ESXi、Hyper-V、Docker宿主机的日志经常被遗漏。虚拟交换机、vCenter的操作事件同样属于系统组件。如果你没记，审计肯定提问题。
- 日志不聚合：单独每台设备自己记，查的时候一台一台登录。我见过被攻击后，分析团队花了两天手工拼接时间线——还不如一开始就上集中日志平台。
最后说一句：日志不是记了就完了。你必须定期检查日志记录是否正常、存储是否充足、时间是否同步。我每周都会写一个脚本检查最后一条日志的时间，如果超过5分钟没新日志，直接告警。这一步能帮你提前发现很多问题。
好，这一章就到这里。系统组件日志是PCI DSS审计中最基础也最容易被敷衍的部分。认真对待它，你的安全运维会少很多麻烦。