第3章 审计追踪的基本原则：谁、何时、何事、何变化

聊审计追踪，绕不开那个经典四问：谁、何时、何事、何变化。

这四个词看着简单，但能不能把它真正落实到位，直接决定了你的审计追踪是「救命稻草」还是「形式主义」。我见过太多系统，日志记录了，但记录的信息等于没记——字段配了一堆，关键信息却丢了。

这章我们就拆开揉碎了讲。四个要素，一个都不能少。

3.1 谁（Who）：操作的执行者

「谁」不是用户在页面上填了个名字就算数，要的是系统可追溯的用户身份。

我习惯把「谁」分成三个层次来确认：

• 系统账户：用户登录的账号，不能是共享账号，要唯一标识。
• 真实人身份：如果系统支持，最好关联到员工工号或真实姓名。
• 角色/权限组：记录操作发生时的角色，方便回溯权限是否合理。

举个例子，一个用户叫张三，他登录系统时用的是admin共享账号。结果发生了越权操作，你查日志只能看到admin，根本定位不到人。这就是典型的「谁没追到」。

所以啊，「谁」必须是操作系统级别的身份记录，不是表单里的「操作人」字段能糊弄的。

3.2 何时（When）：精确的时间戳

「何时」不只是记录一个时间，它要满足三点：

• 精确到秒或毫秒：依赖应用层的DateTime不一定靠谱，最好用数据库时间或专用时间戳服务。
• 时区统一：我建议全局统一用UTC存储，前端展示时再转换。避免跨时区系统时间混乱。
• 不可篡改：时间源要受保护，不能由客户端随意传入。

举个坑：有个项目，客户端直接把浏览器时间传给后端。结果用户改了本地时间，日志里「何时」就废了。

3.3 何事（What）：操作的具体内容

「何事」要记录的是用户到底干了什么。这不是一句「用户修改了订单」就能交代的。

我总结了一下，至少要覆盖这么几个维度：

说白了，日志里要能完整还原一个动作：谁在什么时间，对哪个对象，执行了什么操作，结果怎样。

3.4 何变化（What Changed）：变更前后的数据快照

这是审计追踪里最容易被忽视、却最有价值的要素。

为什么这么说？你想想看，光知道「谁修改了订单」有什么用？关键是你得知道订单里哪个字段变了，从什么值变成了什么值。

我个人习惯用JSON Diff或字段级对比来设计。核心思路是记录变更前后的完整快照，或者至少记录变更字段的旧值→新值对。

# 一个典型的字段级变化记录示例
{
  "字段": "订单金额",
  "旧值": "1000.00",
  "新值": "1500.00",
  "变更原因": "客户确认加急运费"
}

这里要特别注意：不能只记录变更前的完整对象，因为对象过大；也不能只记录变更后的，因为对比不出变化。平衡做法是记录变更字段的旧值和新值，配合变更的时间戳和操作者。

3.5 四个要素的协作关系

你可以把四个要素想象成一个链条：

谁（主体） 在 何时（时间点） 对 何事（目标对象） 执行了操作，并导致了 何变化（数据变动）。

缺一个，链条就断了。审计追踪就失去了闭环能力。

下面这张图能帮你更直观地理解它们的关系：

3.6 实战中的常见误区

做了这么多年审计追踪流程设计，我总结了几个最常见的坑：

1. 只记录操作结果，不记录操作过程 —— 改了啥不知道。
2. 时间戳依赖客户端 —— 时间不准，审计链一查就断。
3. 「谁」用共享账号或 —— 定位不到人。
4. 日志只记录增删改，不记录查询和导出 —— 敏感数据泄露了都不知道。
5. 变更记录只存新值，不存旧值 —— 回查无依据。

嗯，每一个坑我都踩过。尤其是第5个，曾经在做财务系统审计时，只记录了修改后的数据，结果第三方审计要求我们提供修改前的原始凭证，我们只好翻备份恢复，花了三天才搞定。从那以后，我设计的系统必须同时记录旧值和新值。

3.7 小结

审计追踪的基本逻辑，就是回答好四个问题：

• 谁：唯一身份标识，可溯源到具体人。
• 何时：精确、统一、不可篡改的时间戳。
• 何事：操作类型、对象、标识和结果。
• 何变化：变更前后的字段级数据快照。

这四个要素像四根柱子，少一根，审计追踪的大厦就不稳。后面章节我们会在具体的技术方案里一一落地这些原则。