打了最新补丁，认证反而失效

一句话总结

在经过认证的配置中，漏洞响应经常无法通过升级完成，而要以缓解措施和文档记录收尾；如果没有文档，下一次审计就会把它视为放任不管。

为什么需要这些知识

商业环境收到漏洞公告时，我们通常只做一件事：升级。既然有流水线、测试和回滚机制，升级总是成本最低的选择。

国防和公共部门的国防环境还多一个条件：系统配置必须经过认证才能运行。认证文档会写明每个组件采用的版本，按照这份清单运行正是系统获准使用的依据。因此，一旦修改版本，该配置就不再是通过认证的那套配置。重新认证可能需要数月。

刚进入这一领域的工程师最困惑的时刻也由此出现：收到高风险漏洞公告，确认修复版本，然后说“必须立即升级”，得到的回答却是“不能升级”。

它是如何运作的

不能升级并不等于什么都不做，而是要完成三类工作。

第一，影响判定。 发布公告不代表所有环境都会受到影响。需要比较已安装版本和修复版本，判断漏洞是否实际适用。这里最常见的事故是把版本当作字符串比较。以字符串方式比较 16.2 和 16.10 时，16.2 看起来反而更大，真正受影响的项目会在此刻被悄然标为“不适用”。反方向的错误也存在：以字符串比较已安装的 3.12.3 和修复后的 3.9.20，会误以为存在影响，把响应人力浪费在本来正常的项目上。版本号必须按句点拆分，再以数字比较。

边界值也经常判断错误。如果修复版本是 1.24.0，已安装版本同样是 1.24.0，说明漏洞已经修复。此外，针对根本没有安装的组件发布的公告不会产生影响——无法对清单中不存在的组件采取措施。

第二，区分处置方式。 将受影响项目分成两类。认证配置之外的应用程序可以升级，因此应采用补丁修复。被认证配置锁定的组件则采用缓解措施。缓解的含义是消除漏洞成立所需的条件：如果漏洞只在外部输入路径上成立，就阻断外部输入路径；如果只在加载扩展模块时成立，就不安装该扩展，并撤销安装权限。

第三，形成文档。 这是最常遗漏、也最容易引发严重问题的一步。缓解措施没有显眼的交付成果。版本号保持不变，外部观察时无法区分采取过措施和什么都没做。因此，留下已经作出判断的事实，本身就是工作。 哪些项目受影响、为什么不能升级（认证编号）、通过什么措施消除了成立条件、何时重新评估——每条记录都必须包含这四项信息，下一次审计才能把它理解为“经过判断”，而不是“放任不管”。

在实际工作中会是什么样

必须保护配置清单本身。 最糟糕的情况是，经过认证的清单在无人察觉的情况下发生了变化。如果没有记录谁在何时、为何修改了什么，就没有人能回答当前运行的系统是否仍是那套获准认证的配置。因此，要单独记录清单文件的哈希。清单变化时哈希也会变化，任何变化都能立即暴露。

没有重新评估时间的缓解措施，不算真正的缓解。 如果只写“目前先这样阻断”，这项缓解就会永久留存。必须同时注明下一轮重新认证的时间，以及届时准备如何处理该项目，缓解措施才有明确终点。

不要把无需处置的项目放入处置表。 如果连判定为不受影响的项目也列入处置表，表格会越来越长，真正需要处理的项目反而被淹没。判定依据应单独留存，处置表中只列需要采取行动的项目。

接下来要阅读什么

到这里，我们讲完了如何保护无法变更的配置。紧接着的文章将介绍如何设计记录“谁在何时做了什么”的机制，以及如何把这套设计交给下一位负责人。审计轨迹不是事故发生后再寻找，而是要在工作开始前就设计成自然留下；交接文档则是让这套设计得以延续的通道。在随后的实操中，你将一次亲手完成这两篇文章涉及的内容。