审计问的不是你做了什么，而是你如何证明

一句话总结

审计应对中真正卡住的，不是没做的事，而是做过的事与证明它的文件之间没有连起来。把每一条要求所依据的文件的哪一部分，预先绑定好（证据索引），才是应对的主体，而且这份索引必须连依据文件的哈希也一并包含，日后才不会自己说谎。

为什么需要它

交付之后的第一次审计，最常见的场景是这样的：读出一条需求，询问依据。经办人回答“这个我们在做”。接着对方追问在哪里可以看到，这时才登录服务器、打开配置、翻找日志。20 分钟过去，这个项目被跳过，记录中留下“依据未提交”。不是因为没做，而是因为做过的事与文件之间的路，没有人事先铺好。

铺这条路的工作，在审计前一天是做不了的。因为依据会随时间改变。配置文件会在下一次变更时被覆盖，日志会因轮转而消失，检查结果会被下一次检查覆盖。所以索引只写路径是没有用的，必须同时固定当时那个文件是什么样的。哈希就是放在这个位置的。文件一旦变了，索引会自己暴露出来，暴露出来就重新收集即可。不暴露出来，才是问题。

公开标准也以同样的结构为前提。NIST SP 800-171 Rev 3 把对合作方所处理数据的保护要求归为若干系列，NIST SP 800-53 Rev 5 则规定了范围大得多的控制项清单及其选择方法。无论哪一种，文档规定的都是“必须满足什么”，而不是“要用哪个文件来证明”。连接这两者之间的表，必须由各个现场自己来做，不做的话，每次就只能靠人的记忆来应付。把日志用作依据时需要管理什么，NIST SP 800-92 另有论述。

工作原理

第一，让依据自己说明自己。如果把哪个文件是哪条要求的依据，放在人的脑子里或另外的 Excel 里，很快就会错位。如果在依据文件本身加上头部，写明它覆盖什么，那么建立索引就变成了扫描目录。格式各不相同是无法避免的。配置文件以注释行的形式附上，检查结果 JSON 则以最上层的键附上。读取的一方把两种情况都处理好就行了。

第二，把哈希放进索引。仅有路径和收集时间，指向的只是“现在那个文件”。一旦放入哈希，索引就指向当时的那个文件，验证器也就能统计三件事：指向不存在文件的条目，哈希不一致的条目，以及没有任何依据的需求。这三个数字概括了应对的状态。

第三，区分依据的强度。配置文件和策略文档说明的是“就是这样设置的”。日志和检查结果说明的是“确实是这样运行的”。二者不能互相替代。访问限制写在了配置里，并不能说明该配置确实已被应用并运行；反过来，只凭日志，也无法知道那是有意设定的规则还是偶然。为每条需求事先规定需要哪一种，就会暴露出“有依据却仍不够”的位置。这个位置就是下个季度要做的事。

第四，重新运行一次收集。把同一个脚本再运行一遍，除了收集时间之外，应当得出完全一样的索引。如果得不出来，就说明这份索引里混入了像顺序或时间这样与判定无关的东西，那样的话，两次的结果就无法比较。无法比较的数据，也就说不清下个季度有什么变化。

第五，导出时再次审查。依据文件是为内部使用而收集的，里面混有不能原样发出去的东西。例如内部地址、认证手段、个人联系方式。遮盖之后文件内容会改变，所以哈希也会改变。这里经常出的事故是：放入的是遮盖后的副本，而索引却保留着原件的哈希就发了出去。接收方一验证，全部都是哈希不一致，这个包会被整个怀疑。遮盖后的副本必须附上遮盖后副本自己的哈希。

在现场相遇的样子

在一个现场，曾经想把上个季度提交过的索引原样再交一次，结果被卡住了。照原样验证了一下，发现有四个条目断开了。其中两个是文件在整理工作中丢失了，另外两个是内容被改变了。被改变的那两个更糟糕。文件还在原位，人眼看上去毫无问题，内容却已不是当时作为依据的那一份。如果没有哈希，我们就会原样提交，而监理方打开看到的内容，会与我们所解释的不同。

另一种常见的情况是有依据却不够的位置。典型例子是：事故响应流程文档写得很好，却没有任何一条实际演练或应对的记录。只看索引的话，附了一份依据，是绿灯，但这条要求问的不是流程是否存在，而是这个流程有没有在运转。如果把依据按强度区分开，这样的位置就会以清单形式出现，而这份清单就是下个季度的计划。

下一项实验要做什么

你将用 12 条合成需求和 14 个依据文件建立证据索引，固定哈希，并用索引验证器统计三种断开的位置。把依据分为设计和运行两类，判定每条需求缺少什么，再重新运行同样的收集，确认除了收集时间之外是否完全相同。最后按导出审查规则制作遮盖副本，并用遮盖副本的哈希重新封存索引，使验证器只看这个包就能说没有断开的位置。剩下的空白不隐瞒，原样写在目录中。