2. 金融行业监管要求：PCI-DSS、SOX、BASEL 的日志硬约束

聊到金融行业的审计日志，绕不开几座大山。

PCI-DSS、SOX、BASEL。这三套法规，就像三把悬在头顶的剑。

你可能觉得它们离咱们运维太远，那是合规部门的事。我以前也这么想，直到有一次项目验收，客户的安全审计直接翻出我们的日志文件，指着一条记录说：“这行的完整性校验值呢？”

嗯，那场面，真叫一个尴尬。

说白了，这些法规不是让你去背条文，而是告诉你：日志该怎么存、怎么保、怎么查。

2.1 PCI-DSS：你真的知道谁碰了卡号数据吗？

PCI-DSS，全称支付卡行业数据安全标准。

只要你的系统跟信用卡、借记卡打交道，就得过这关。它最核心的一条：日志必须记录所有对持卡人数据的访问。

我个人习惯把它的日志要求总结成四个字：谁、时、做、果。

• 谁：用户ID、来源IP、服务端标识。不能只有个IP，得能追溯到自然人。
• 时：精确到秒的时间戳，而且时间源必须是统一授时的。我在项目里见过不同机器时间差出5分钟的，那日志根本没法串联。
• 做：操作类型。读、写、删、改、导出。不能是“用户执行了操作”这种废话，得具体到“用户18923导出了表CARD_PAN”。
• 果：结果状态。成功还是失败？失败原因是什么？

你看，最后一条直接要求了完整性保护。这可不是打印出来锁柜子里就行。

数字世界的完整性，靠的是哈希链或数字签名。每次写入新的日志，得带上前一条日志的哈希值。谁要是偷偷改了一条，链子就断了。

我曾经在一个POS机项目中，帮他们做日志改造。原来的日志就是纯文本文件，谁都能打开改两笔。改成哈希链后，审计那边才点头。

2.2 SOX：财务数据的“痕迹不可抵赖”

SOX法案，全称萨班斯-奥克斯利法案。它针对的是上市公司的财务数据。

财务系统里，每一笔账目的增删改，都得留下不可抵赖的证据。这就是所谓的 审计轨迹。

SOX 日志要求	具体含义
原始数据完整	日志不能是摘要，必须是原始的操作记录。比如“用户A将金额从100改为150”，而不是“用户A修改了金额”。
时间序列完整	不能有时间断层。如果某段时间日志丢了，合规就会出问题。
防篡改与防删除	日志文件必须做加密和完整性校验。归档后的日志，也禁止任何人直接删除。

为什么必须加密？

你想想看，如果日志明文传输，中间人改掉怎么办？如果磁盘被盗，里面的日志谁都能读，那“不可抵赖”就成了一句空话。

2.3 Basel II/III：风险数据的“可审计性”

Basel 协议（巴塞尔协议）主要管的是银行的风险管理。

它对日志的要求，偏向于 可审计性 和 可重现性。

• 可审计性：风险模型算出来的结果，每一步操作都能追回来。模型参数是谁改的？数据源是从哪拉的？计算逻辑是谁部署的？都得有日志。
• 可重现性：监管来了，说“你把上个月3号的风险敞口给我重算一遍”。你的系统和日志得支持你回到那个时间点，用同样的数据和参数，算出同样的结果。

这就要求日志不仅要记录结果，还要记录 输入数据版本、代码版本、算法版本。

说白了，金融行业的日志，已经不是单纯的排错工具了。它是法律证据，是合规红线，是监管罚单的避雷针。

没有加密，日志就是一张随时可以被改写的白纸。没有完整性校验，你提交给审计的报告就是一堆数字游戏。

2.4 三条法规的综合对比

这三条法规，侧重点不同，但核心逻辑是一致的。

法规	核心约束对象	日志留存期	对加密/完整性的核心要求
PCI-DSS	持卡人数据访问	至少 1 年	日志文件完整性保护（哈希链）
SOX	财务数据变更	至少 7 年（视公司政策）	加密存储 + 数据不可抵赖（数字签名）
Basel II/III	风险模型与计算	持续，无固定下限	输入输出完整性 + 版本控制可审计性

看到这里，你应该明白了。

加密和完整性保护，不是锦上添花，而是合规的硬门槛。没有这两项，你的巡检系统做得再花哨，在审计眼里也等于零。

2.5 合规视角下的日志安全架构

下面这张图，是我在项目中梳理出来的合规日志工作流。

这个流程你看明白了吗？

日志从产生的那一刻起，就必须被“锁住”。先做完整性校验，再做加密存储。而这三条法规，共同指向一个目标：你不能轻易修改日志，即使修改了，也必须能被发现。

这就是我们做加密审计日志巡检的底层逻辑。