一、审计追踪与筛选流程概述

1.1 为什么需要审计追踪？

审计追踪，说白了就是给系统的每一次操作都留下一个“指纹”。

我刚开始做对接筛选项目的时候，总觉得这东西是给别人看的。后来线上出过一次数据异常，查了半天不知道是谁改了什么参数……嗯，从那以后，我再也不敢不做审计追踪了。

一个完整的审计追踪，至少需要回答三个问题：

• 谁（Who）—— 哪个用户或系统触发了操作？
• 什么时候（When）—— 精确的时间戳，最好到毫秒级。
• 做了什么（What）—— 操作前后的数据变化是什么？

1.2 筛选流程的典型环节

对接筛选流程，你可以想象成一套流水线。原料进来，经过一道道工序，最后输出合格品。每个环节都可能出问题，所以每个环节都需要记录。

常见的筛选流程包含以下几个阶段：

你想想看，如果中间某个环节的日志丢了，整个链条就断了。这就是审计追踪设计的核心——保证链条的完整性。

1.3 审计追踪设计的基本原则

我总结了五条铁律，你在设计任何一个筛选流程的审计系统时，都可以拿它来检验：

1. 不可抵赖性：记录一旦生成，就不能被修改或删除（哪怕是管理员）。
2. 完整性：每个环节都要有日志，不能断点。
3. 可读性：日志不仅是给机器看的，也要让人能快速读懂。我曾经见过一个系统，日志全是十六进制编码……根本没法用。
4. 时效性：时间戳必须统一标准，建议全部使用UTC时间。
5. 安全性：日志的存储和传输必须加密，防止篡改。

1.4 一个简单的审计日志格式示例

下面是一个我在项目中常用的事件日志结构，用 JSON 表示：

{
  "event_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "timestamp": "2025-01-15T08:30:00.123Z",
  "user_id": "system_screener_01",
  "action": "RULE_MATCH",
  "resource": {
    "type": "transaction",
    "id": "TXN2025011508001"
  },
  "details": {
    "rule_id": "RULE_0042",
    "rule_name": "高频交易检测",
    "matched_value": 15,
    "threshold": 10,
    "result": "FLAGGED"
  },
  "checksum": "sha256:...",
  "source_ip": "10.0.1.100"
}

checksum 字段是关键。你可以对整条日志的前面所有字段计算哈希，然后存进去。下次读取时重新算一遍，如果不一致，说明日志被改过了。

1.5 筛选流程与审计追踪的融合点

不是所有操作都需要记录。我个人倾向于遵循“三看原则”：

• 看数据变化：数据被创建、修改、删除时，必须记录。
• 看权限变化：任何用户角色、权限的变更，必须记录。
• 看关键决策：筛选结果的判定、人工复核的通过/驳回，必须记录。

下面这张图，帮你把整个知识体系串起来：

1.6 开始动手前，你要想清楚的事

在进入后续章节之前，我建议你先问自己三个问题：

• 这个筛选流程的合规要求是什么？金融、医疗还是普通业务？合规等级直接决定审计的颗粒度。
• 日志的存储周期是多久？3个月、1年还是永久？这会影响存储方案的选择。
• 有没有实时审计的需求？有些场景需要秒级告警，有些只要事后查账就行。