补丁管理政策模板

为什么书面政策很重要

未打补丁的软件仍然是勒索软件（ransomware）和数据泄露最常见的入口之一。问题很少出在缺少工具上——大多数环境已经拥有 RMM（远程监控与管理）、端点管理平台，或至少内置的更新机制。问题在于不一致：关键修复等待维护窗口一等就是数周，服务器无人认领，已停止支持的系统悄悄地在角落里运行。

政策把打补丁从一种习惯变成一种义务。它为技术人员提供明确的服务等级目标，为管理者提供衡量合规性的方法，并在保险公司、审计师或客户询问漏洞如何处理时，为领导层提供站得住脚的答复。如果您正在准备续保，我们关于网络保险问卷的指南展示了补丁证据是如何被反复问及的。

对 MSP 而言，书面政策有双重作用：它既在服务协议中设定了客户预期，也能在客户拒绝某个补丁、之后又遭入侵时保护您。

第 1 节：目的、范围与资产覆盖

政策应以一段简短的目的声明开篇——用一两句话说明组织将保持软件为最新版本，以降低安全风险并维持系统稳定性。然后精确定义范围。这里的含糊之处正是补丁计划出现漏洞的地方。

• 操作系统：工作站和服务器上的 Windows、macOS、各 Linux 发行版
• 第三方应用程序：浏览器、PDF 阅读器、办公套件、业务线应用
• 固件与网络设备：防火墙、交换机、无线接入点、虚拟化管理程序（hypervisor）、存储阵列
• 云与 SaaS：明确哪些更新由供应商负责，哪些（例如虚拟机镜像和容器基础镜像）仍由您负责
• 明确的排除项：任何不在范围内的内容，并记录原因

将范围与一份持续更新的资产清单挂钩。看不见的东西就无法打补丁，而与现实脱节的清单正是事件发生时最先暴露的缺口。

第 2 节：角色与职责

每一个未打补丁的系统背后都有一个归属问题。政策应明确流程中每个环节的负责人：

• 政策负责人：维护该文件并至少每年审查一次的人（通常是 IT 经理、安全负责人或 vCIO）
• 补丁管理员：负责审批、排期和部署补丁的人
• 系统所有者：为服务器和业务关键应用的维护窗口签字批准的人
• 例外审批人：当补丁被推迟时能够接受相应风险的人——且不应与提出推迟申请的是同一个人

MSP 应在每份客户协议中映射这一结构：客户负责业务审批与风险接受；MSP 负责执行与报告。

第 3 节：严重性分级与补丁 SLA

并非每个更新都值得同样的紧急程度。政策应定义严重性等级以及每个等级允许的最长修复时间。确定严重性时不要只看供应商的标签——还要权衡可利用性、该漏洞是否正在被积极利用，以及受影响系统的暴露程度。

下表是一个站得住脚的起点。可以根据您的风险偏好调整时间线，但要保持足够的进取性，绝不能让一个严重的、面向互联网的漏洞等待按月执行的补丁周期。关于设定更紧目标背后的理由，请参阅关键漏洞应以多快的速度打补丁。

第 4 节：测试与部署环

一次性给所有设备打补丁，一个有问题的更新就可能让整个机群瘫痪；而在补丁被“证明可靠”之前什么都不打，漏洞就会滞留数月之久。政策应描述一种在两种风险之间取得平衡的分阶段推出方式：

• 试点环（pilot ring）：一小组有代表性的测试机和容忍度较高的用户；首先在这里部署
• 广泛环（broad ring）：整个机群，在试点未出现重大问题之后——通常晚几天
• 关键系统环：服务器与生产系统，在计划维护窗口内打补丁，并备好回滚方案

明确补丁在试点环中最多可停留多久才升级推广、“无重大问题”具体指什么（崩溃率、应用故障、服务台工单量），以及由谁批准推广。同时还要定义回滚程序：卸载步骤、系统还原点，或虚拟机的快照回退。

现代端点工具可以将其中大部分工作自动化。如果您正在评估各类平台，我们关于 RMM 与端点管理的对比解释了自动化边界在哪里，而自主端点管理则介绍了整个流程在多大程度上可以无需人工干预地运行。

第 5 节：紧急与带外补丁

有些漏洞等不到下一个部署环。您的政策需要一条紧急通道：什么情况下触发（漏洞正被积极利用、供应商发布带外公告、面向互联网的系统出现严重缺陷）、谁有权启动，以及可以省略哪些环节——通常是缩简测试并仅向受影响系统立即部署。

补偿性控制措施也要写下来。如果应用某个紧急补丁本身风险很高，应记录在准备好经过测试的修复之前的临时缓解措施，例如禁用易受攻击的功能、限制网络访问，或添加检测规则。一个只存在于人们头脑中的紧急流程，在假期周末的凌晨两点是不会起作用的。

第 6 节：例外与风险接受

总会有一些系统无法按计划打补丁：一更新就会出故障的遗留应用、经供应商认证的配置、接近生命周期终点的硬件。错误的做法是让这些系统悄无声息地拖下去。政策应要求对每一个系统办理正式的例外手续：

• 涉及的系统、被推迟的补丁，以及业务原因
• 已落实的补偿性控制措施（隔离、网络分段、额外监控）
• 一位具名且级别适当的风险接受人
• 一个到期日——例外必须重新审批，而不是永久有效
• 一份整改计划，例如针对已停止支持软件的升级或更换时间表

第 7 节：度量与报告

没有指标的政策只是一厢情愿。明确合规性将如何度量和报告：补丁覆盖率（在 SLA 内保持最新的设备占比）、按严重性统计的平均修复时间、未关闭例外的数量与存续时长，以及补丁失败率。设定报告节奏——运营层面每月一次，领导层每季度一次——并明确报告的接收人。

想深入了解哪些数字才能真正证明计划有效，请阅读我们关于衡量补丁合规性的指南。您还可以使用我们的安全评分计算器对整体安全状况进行基准评估。

为 MSP 改编模板

MSP 需要一份主政策，外加每个客户一份简短的面向客户的附件。附件记录该客户的维护窗口、审批联系人、被排除的系统，以及已签署的风险接受文件。主政策在所有客户之间保持一致，让技术人员遵循同一套操作手册；只有附件因客户而异。

有两条条款在每份客户协议中都物有所值：

• 拒绝补丁条款：如果客户拒绝或一再推迟某个关键补丁，该拒绝将被记录在案，相应风险转移给客户承担
• 生命周期终止条款：超出供应商支持期限的系统可被排除在补丁 SLA 之外，或以额外费用加装补偿性控制措施

让政策保持生命力

至少每年审查一次政策，并在任何与补丁有关的事件之后进行审查——无论是漏打的补丁导致了事件，还是快速响应遏制了事件。随着威胁形势的变化重新审视 SLA 目标，清理那些悄然变成永久状态的例外，并核实资产清单仍然与现实相符。

上述模板各节——目的与范围、角色、严重性 SLA、部署环、紧急流程、例外以及度量——就是一份站得住脚的补丁管理政策所需的全部内容。把它写下来、获得签署，然后让工具承担繁重的工作。SmashByte Security（安全）事业部围绕的正是这种运营模式，提供安全领域的补丁管理与漏洞管理解决方案。