如何设计一个可追溯多年的审计日志（audit log）？

Question

IT Interview Practice · Accepted Answer

让它**只追加且不可变**，用**哈希（hash）**把每条记录链接到前一条，使篡改可被检测，**按时间分区**使旧数据能廉价地老化淘汰，并按保留策略把封存的 partition 归档到 **WORM 对象存储**（write-once，一次写入）——绝不允许对活动记录执行 `UPDATE`/`DELETE`。

```text
service ──emit event──▶ append-only writer
                             │  hash = H(prev_hash || payload)
                             ▼
                     audit_2026_07 (hot partition)  ◀── query by actor/time
                             │ month sealed
                             ▼
                     WORM object store (S3 Object Lock)  ── retention: 7y
                             │
                     periodic anchor: publish latest hash externally
```

## 只追加与防篡改证据

审计日志的全部价值在于你**日后能信任它**，因此 schema 必须禁止变更。只授予应用 `INSERT` 权限——不给 `UPDATE`/`DELETE`——并在 DB 角色级别强制执行，而不仅仅在代码里。在此之上，构建一条**哈希链（hash chain）**：每一行存储 `hash = SHA256(prev_hash || this_row)`。改动任何历史行，其后的每个 hash 都会断裂，因此即便是拥有 DB 访问权限的人，篡改也*可被检测*。定期把最新的 hash **锚定（anchor）**到你无法控制的地方（一个公证机构、一个公共账本、一封签名邮件），这样即使一个管理员重写了整条链，也无法与锚定的值匹配。

## 时间分区与保留

多年的日志会无界增长，因此要**按时间分区**（例如按月的 range partition）。好处：查询可按 partition 过滤，且淘汰旧数据是一次元数据级的 `DETACH`/`DROP PARTITION`——瞬时完成，而非一次让表膨胀的巨型 `DELETE`。封存的 partition 移到 **WORM 存储**——处于*合规模式（compliance mode）*的 S3 Object Lock 在保留日期之前从物理上阻止删除，满足 SOX/HIPAA 等法规。把近几个月热存于 Postgres 以便快速查询；更旧的一切冷存于对象存储，按需查询。

## 面试视角

考察点在于你是否理解"审计日志"意味着**不可变性和可证明性**，而不只是"一张带时间戳的表"。好：只追加的表。出色：*由 DB 角色强制执行*的只追加、带外部锚定的哈希链、用于保留的时间分区、用于合规的 WORM。常见陷阱：把审计行存储在同一张可变的应用表里（一个 bug 或一个恶意 DBA 可以悄悄重写历史）——审计人员会拒绝它。

## 权衡与故障模式

- **哈希链使写入串行化**——每条记录都需要前一个 hash，因此朴素的设计会成为瓶颈。把记录批处理，或按 shard 分别成链并定期交叉链接（cross-link）。
- **存储永远增长**；如果不做分区 + 分层到廉价对象存储，成本和查询 latency 会爆炸。
- **WORM 合规模式不可逆**——一个错误的保留设置会锁死数据（或让它过期）而无法撤销；先在治理模式（governance mode）下测试。
- **时钟偏移 / 乱序事件**会破坏基于时间的推理——同时记录事件时间和摄取时间，且绝不信任客户端时钟来排序。

只追加与防篡改证据

时间分区与保留

面试视角

权衡与故障模式

相关问题