《投资者信息保护》那篇提到"全量查看留痕"，留痕要发挥作用有个前提：没人能改它。审计日志的价值在事后争议时兑现——客户否认授权过某项业务、柜员否认改过某个字段、系统数据和凭证对不上——这时候拿出来的日志必须让双方都信。可信的前提是防篡改。这篇讲防篡改的哈希链方案，以及比链更基础的日志要素和写入架构。
哈希链：改动即断链
朴素做法是一条审计表，谁都能 UPDATE 和 DELETE，那它只防外人不防内鬼。哈希链的思路是把每条日志的完整性依赖前一条，构造序列：
$$ h_0 = \text{IV}, \qquad h_i = H\big(h_{i-1} \,\|\, t_i \,\|\, r_i\big) $$
其中 $t_i$ 是时间戳，$r_i$ 是日志记录的全部要素（谁、对什么、做了什么、改前改后的值），$H$ 用 SHA-256。每条日志落库时带上 $h_i$。验证时从头重算一遍，任何一条被改、被删、被插入，后面所有哈希都对不上——篡改者要么重算全链，要么留一个断点。
但重算全链恰恰是拥有数据库写权限的人能做到的事。所以链必须配合外部锚点（anchor）：定期（比如每五分钟或每 N 万条）把当前链尾哈希 $h_n$ 写到一个攻击者够不着的地方——另一台独立管理的机器、可信时间戳服务、甚至公证处存证。攻击者想改第 $i$ 条日志，得改库里的链、再改外部锚点里的历史快照，两个系统的写权限同时拿到，攻击成本才成立。锚点间隔决定了可篡改窗口：间隔内的日志理论上可被重写而不被发现，所以间隔要远小于日志的争议周期（交易日志保存二十年，五分钟窗口的残留风险可以接受）。
信任模型说清楚：哈希链防的是事后抵赖和悄悄修改，不是实时攻击——攻击者当场删掉整段日志的记录并同步删锚点，需要的是同时控制两个系统的长期权限，这已经属于"内控整体失效"的范畴，不是单点技术能防的。
日志要素：比防篡改更常见的短板
现场检查里出问题的日志，大多数没被篡改过，是根本没记全。一条合格的审计日志至少要回答六个问题：谁（操作人 ID，不是登录名，员工改名换号要能追溯）、什么时候（可信时间戳，来自 NTP 校时的服务器时钟，客户端时间不可信）、在哪台终端、对哪个对象、做了什么操作、改前是什么、改后是什么。
最后一对最容易缺。只记"柜员修改了客户手机号码"不记旧值新值，事后客户说"我没换号"，这条日志帮不上任何忙。变更前后值（before/after image）必须成对记录，且对高敏字段（上一篇的身份证、银行卡）要做脱敏或加密存储——审计日志本身也是泄露通道。
另一个常被忽视的点：操作者身份认证。共享工号、万能操作员是审计体系的地基裂缝。所有审计记录绑定的主体必须是可追溯的个人账号，代操作必须有正式的授权记录并同时记录授权人和实际操作人。没有这一条，日志记得再完整，"谁干的"这一步就断了。
写路径：日志系统不能信任被审计的系统
架构上最容易踩的坑是让被审计的应用同步写自己的审计表。问题是应用自己有写权限，出问题时（bug、被控、误删）第一件事往往就是日志跟着遭殃。稳妥的做法有几种：
- 数据库触发器/CDC：在库层捕获变更，应用无感知也无法绕过。代价是对库有额外压力，且只覆盖落库的操作（不落库的纯查询行为记不了）；
- 独立审计服务：应用通过只追加（append-only）接口上报，审计服务自己管理存储和链。应用侧故障不影响审计侧；缺点是应用不上报就等于没发生，需要框架级埋点保证覆盖率；
- 网关代理审计：操作请求统一过审计网关，网关记录请求与响应摘要。适合柜面、管理台这类有统一入口的系统。
实践里是组合使用：落库变更走 CDC（客观、绕不过），管理操作走审计网关（有入口可拦），再补关键业务事件的显式上报。三套来源会有重叠，重叠本身是好的——对不上的重叠才是问题，说明某条路径漏了。
查询与保存
保存期限按法规走（交易记录一般不少于二十年），这个量级下按月分表是必然。查询需求两头极端：按"某客户"查全部操作（客户服务争议）和按"某操作员"查全部操作（内部调查），两个方向都要建索引或双写索引表。链验证做成周期任务：每天凌晨重算前一天的分表链并与锚点核对，断链告警直接升级到安全值班——等检查时发现断链，和在自家系统里发现入侵痕迹一样尴尬。