SH

Soloharness

概念 · 辨析 · Agent

← 返回概念辨析

Concept Contrast Fable

防篡改和能查账,两本不同的账本

不可篡改日志确保写入后不可修改或删除,解决的是信任取证问题。审计日志记录谁在什么时间做了什么操作,解决的是行为追溯和合规审查问题。两种日志常常在同一个系统里并存,但一个防改、一个能查——把防改的当能查的用,会在合规审计时漏掉关键字段。

寓言

衙门有两个账房,一个锁柜子,一个贴标签

县衙的库房里雇了两个账房先生。老赵管铁皮柜——所有银两进出记录写在一本厚厚的册子上,写完了就锁进铁皮柜。柜子有三把锁,钥匙分别在三个人手里,开柜登记、关柜签封条。老钱管的是贴在每笔账目上的便签——哪一天、谁经手、批了多少钱、用在哪一项开支上。便签按日期排好,巡按来查时可以顺着时间翻。

有一年,库房短了八百两银子,巡按派人来查。查账的人先找老赵开柜,验了封条没动过,柜里的记录跟入库单对得上——但记录只写了收多少支多少,没说谁签的字、谁批的条。查不出是谁经手的。又找老钱的便签,发现三张便签被撕掉重写过——日期对不上,经手人和批条人也不一致。

两边的账本都没帮上忙。老赵的柜子虽封条完好,但记录太粗,缺了谁经手这笔钱。老钱的便签虽详细,却被动了手脚。县令把两人叫到一起,问了一个问题:库房的账,到底该防有人改,还是该帮巡按查?老赵说我的柜子防改,老钱说我的便签帮查。两个人答的不是同一个问题。

县令后来做了一个决定:老赵继续锁柜子,但把每笔记录加上经手人和批条人的字段。老钱继续贴便签,但贴上之后跟老赵的记录做一次交叉编号——便签上的编号必须对得上铁柜记录里的行号。这样一来,想改便签就得先开柜子改编号,想改柜子就得同时撕掉便签再重编号。

新的麻烦出现在两年后。库房升级了银库管理系统,每一笔银两进出都自动生成日志。系统设计的人只做了老赵那部分——日志写进去就锁死,不可删改。但没有做老钱那部分——没有谁在什么时间做了什么操作的详细字段。巡按再来查时,发现日志是防改了,但查不出哪笔操作是失误、哪笔是故意。

系统设计的人后来加了一个审计模块,从防改日志里提取行为维度——操作时间、操作人、操作类型、操作对象——生成一套按时间轴排列的审计视图。他写在设计文档里:防改解决证据可信,审计解决行为可查。一个系统应该同时做两件事,但两件事的字段设计起点不同。

库房的门上后来贴了一张纸:进库先分清你要找的是防改的凭证,还是能查的行为记录。要凭证的找铁皮柜,要记录的找便签。拿错账本,不算查了账。

不可篡改日志

利用哈希链、数字签名或只追加存储等技术确保日志写入后不可修改、不可删除。解决证据完整性和取证可信度问题,不天然包含审计查询能力。

审计日志

记录谁在什么时间做了什么操作、操作了哪个对象、操作前后的状态变化。面向行为追溯和合规审查,字段设计关注操作语义,防篡改能力取决于底层存储。

故事对应

  • 老赵的铁皮柜:不可篡改日志,写入后不可修改,解决证据可信
  • 老钱的便签:审计日志,记录谁在什么时间做了什么,解决行为追溯
  • 封条完好但缺经手人:防改不天然携带审计所需的行为字段
  • 便签被撕掉重写:审计日志依赖底层存储的防篡改能力
  • 交叉编号:工程中需要把防改和审计链路绑定
  • 新系统只做了防改部分:生产环境中常见的设计短板

落到安全日志系统设计

设计日志系统时把防篡改和审计字段分开规划。防改部分关注存储层的不可变性——哈希链、签名、只追加写入。审计部分关注字段设计——至少要覆盖操作时间、操作人、操作类型、操作对象和操作前后状态。两个层面的交叉点在于:审计字段写进防改存储后,防改能保证审计字段的可信度。合规审计时,先确认日志是否防改,再确认审计字段是否完整。