修补程序管理阶段 3 – 评估和计划
本页内容
 | 本模块内容 |
| 目标 |
| 适用范围 |
| 如何使用本模块 |
| 概述 |
| 确定相应的响应措施 |
| 规划发布过程 |
| 生成发布版本 |
| 验收测试 |
| 总结 |
| 移交到部署阶段 |
本模块内容
本模块描述修补程序管理过程（该过程共分为四个阶段）的第三阶段“评估与计划”。评估与计划阶段的主要内容包括：决定是否部署更新、确定部署更新所需的内容，以及在类似生产环境的环境下对软件更新进行测试以确认软件更新不会对关键业务系统和应用程序带来不良影响。
本模块旨在说明修补程序管理过程中的评估与计划阶段的原则，并介绍有关任务类型，利用 Microsoft® Software Update Services (SUS) 和 Microsoft Systems Management Server (SMS) 并执行这些任务可完成评估与计划过程。
通过评估与计划过程，您将制定出一套明确的、有助于确定是否要部署更新的标准，您还会了解部署更新所需的内容。此外，通过该过程，您还可以制定出用于生成可靠的、经过完善测试的发布版软件的过程。
目标
使用本模块可以：
| • | 确定是否确实需要部署更新。 |
| • | 制定软件更新发布计划。 |
| • | 生成发布版本。 |
| • | 执行发布版本验收测试。 |
适用范围
本模块适用于 Microsoft 的所有产品和技术。
如何使用本模块
本模块说明使用 SUS 和 SMS 执行评估与计划时所需完成的基本任务，您可以在下面的“如何”模块中找到更为详细的说明。
要充分利用本模块，应当：
| • | 阅读修补程序管理过程模块。此模块提供了有关修补程序管理过程的每个阶段（共四个阶段）的概述，并对在 Microsoft Windows® 操作系统环境下支持修补程序管理的可用工具进行了说明， | ||||
| • | 阅读以下模块：
|
概述
评估与计划阶段是修补程序管理过程的第三阶段，如图 1 所示。
图 1
修补程序管理过程
在此第三阶段需对软件更新进行评估，并假定将更新部署到生产环境的计划已获批准。
评估与计划阶段首先要处理的是那些已确认与生产环境有关的软件更新的变更请求 (RFC)。
在评估与计划阶段结束时，应已完成下列工作：确定是否将变更请求列为“紧急”请求，完成请求的复查与审批工作，以及确定在生产中部署已批准的变更所需完成的任务。此外，还应在类似生产环境的环境下对软件更新进行测试，以确认软件更新不会对关键业务系统和应用程序带来不良影响。
本模块将着重描述评估与计划的主要要求，以便：
| • | 确定相应的响应措施。 |
| • | 制定软件更新发布计划。 |
| • | 生成发布版本。 |
| • | 执行发布版本验收测试。 |
确定相应的响应措施
RFC 确定了生产环境所需的变更类别（如部署软件更新和/或应用减轻漏洞的对策），并针对所需变更进行了说明，供他人执行使用。
评估与计划的第一步是复查 RFC 并确定针对软件漏洞或威胁的、最为适当的响应措施。具体工作包括：
| • | 确定请求优先级并对其进行分类。 |
| • | 获取部署软件更新的授权。 |
确定软件更新请求优先级并对其进行分类。
在授权软件更新请求之前，需确定其优先级和类别。尽管优先级和类别最初由变更发起人进行分配并包含在 RFC 中，仍需复查这些分配结果，并且只有在同意或修改分配结果后，方可授权变更请求。
确定软件更新优先级
优先级非常重要，因为它决定着软件更新在变更过程中的执行速度。以下因素有助于确定软件更新的优先级：
| • | 关键业务资产有哪些？在安装软件更新前这些资产是否会受到潜在安全漏洞和系统不稳定的威胁？应根据是否修补高值资产带来的影响来确定变更请求的优先级。 |
| • | 软件更新是否应用于运行关键业务服务（如业务线 (LOB) 应用程序）的系统？在过去该系统一直是攻击者的目标。这是提升变更请求优先级的主要原因。 |
| • | 是否已经部署相应对策将特定安全漏洞带来的威胁降至最小？这样会降低变更请求的优先级，但是仍然能达到通过部署软件更新来消除漏洞的目的。 |
| • | 上述漏洞对生产环境有哪些威胁？许多安全公告和相关软件更新可能只适用于您的环境中的少数计算机。如果漏洞威胁很小，可能会降低请求的优先级。 |
下面的表格可帮助您评估某一请求相对于其他请求的优先级。表 1 给出了优先级与推荐时间范围和推荐最小时间范围的映射。
表 1：更新优先级和推荐部署时间范围
| 优先级 | 推荐时间范围 | 推荐最小时间范围 |
紧急 | 24 小时之内 | 2 周内 |
高 | 1 个月内 | 2 个月内 |
中 | 根据可用性在 4 个月内部署一个新的 Service Pack 或一个包含此漏洞修补程序的更新汇总。 | 在 6 个月内部署软件更新 |
低 | 根据可用性在 1 年内部署一个新的 Service Pack 或一个包含此漏洞修补程序的更新汇总。 | 在 1 年内部署软件更新或选择不予部署。 |
表 2 给出了导致优先级提高或降低的因素的示例。
表 2：影响更新优先级的因素
| 环境/组织因素 | 优先级调整 |
受影响的高值资产和高暴露资产。 | 提高 |
以前就成为攻击目标的资产。 | 提高 |
存在减轻威胁的因素，如使威胁最小化的对策。 | 降低 |
受影响的低值资产和低曝光资产。 | 降低 |
紧急变更请求
如果安全更新针对的漏洞正在被利用或将要被利用，或者更新程序纠正了生产环境中面临的系统不稳定性，此时必须将请求级别定为“紧急”，使其优先级高于生产环境中的所有其他变更。
软件更新分类
软件更新的类别非常重要，因为它有助于检查变更对生产环境内的系统和服务的影响。确定变更请求的类别（或影响）需要确定以下几个方面：
| • | 需要安装软件更新的机器以及这些机器充当的角色（业务关键性）。 |
| • | 是否需要附加变更以支持软件更新的部署。 |
| • | 软件更新一旦安装是否还可以卸载。 |
| • | 对网络基础结构的可能影响。 |
| • | 安装期间是否需要停止、中断或关闭某些服务。 |
有关设置变更请求的优先级和类别的详细信息，请参阅位于 http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/msm/smf/smfovrvw.asp 的“Change Management service management function (SMF)”（英文）。
获取部署软件更新的授权。
设置变更请求的优先级和类别之后，需要对其进行检查和授权，然后才能将软件更新部署到生产中。要获取变更请求的授权，需要进行以下工作：
| • | 确定参与决策制定过程的人选。 |
| • | 检查变更请求，对部署软件更新的风险和后果进行评估，并选择最合适的操作方式。 |
| • | 确定负责在所有受影响系统上部署软件更新的人选。 |
确定需要参与的人选
确定对软件更新进行检查和授权的人选非常重要。对于非紧急更新，可以由变更顾问委员会 (CAB) 进行检查和授权，CAB 主要由所有受影响的业务领域的代表组成。
CAB 中应有一些成员具备部署更新时使用的特定技术和服务的经验，还应包括来自业务、网络、安全、服务台和技术支持小组的代表。
有关 CAB 及其组建过程的详细信息，请参阅可在 http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/msm/smf/smfovrvw.asp 上下载的“Change Management SMF”（英文）。
紧急变更请求
需要对关键请求作出快速决策时（如旨在堵住安全漏洞或避免关键系统故障），应由 CAB 紧急委员会 (CAB/EC) 做出授权。
CAB/EC 的成员应具备批准紧急变更的权限，且能够迅速作出决策。有关 CAB/EC 的详细信息，请参阅可在 http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/msm/smf/smfovrvw.asp 上下载的“Change Management SMF”（英文）。
检查变更请求
一旦安排好合适的人员之后，接下来需评估软件更新对生产环境的威胁和影响，并确定是否需部署软件更新。在决策时，需对下列问题进行讨论：
| • | 生产环境中发生的其他事件是什么？ |
| • | 应用软件更新与否所带来的影响是什么？ |
| • | 部署软件更新与否所需的预期成本是多少？ |
| • | 在部署软件更新时，可以采取哪些步骤（如果有）来减轻安全漏洞和系统不稳定所带来的威胁？ |
| • | 计算机停机时间的影响是什么？需对软件更新延期所带来的风险和部署软件更新导致的计算机停机所带来的风险进行比较。 |
| • | 部署软件更新的最佳和最有效机制是什么？ |
| • | 软件更新是否有已知问题或副作用，以及是否需要重新启动系统？ |
| • | 是否有足够的资源来部署软件更新或处理部署过程中发生的问题？ |
| • | 在部署软件更新之前，如何解决需满足的从属条件或前提条件？ |
尽管针对软件漏洞的最佳应对策略是部署可解决此漏洞的软件更新，但某些情况下，最好在将软件更新部署到生产环境中的系统上的同时，部署一个短期应对措施，例如关闭网络端口或关闭外部对系统的访问。应用对策有以下几个好处：
| • | 大多数软件更新要求重新启动目标计算机，之后才能完成安装和保护计算机。如果因计算机重新启动仅限于特定维护窗口，而不能将软件更新立即部署到环境中，则实施建议对策可有效保护计算机，直至部署软件更新。或者，有时也可以部署安全更新并禁止自动重启。在这种情况下，可在正常工作时间内安装安全更新，然后计算机在某个维护窗口的某一时间重新启动。 |
| • | 应对策略与软件更新自身相比，风险更低，应用更快，所需测试更少。应对策略执行起来更加简便，例如，将网络端口禁用，或关闭暴露了特定安全漏洞的服务或系统，以后再应用软件更新。 |
实施强化计算机的对策通常可以保护计算机免受常见安全漏洞的影响。封堵特定网络端口和禁用不使用的服务是其中的两个对策，实施这两个对策可有效地保护计算机。有关强化计算机的对策的详细信息，请参阅：http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=1b6acf93-147a-4481-9346-f93a4081eea8（英文）
注意：即使已经部署了一些对策来减轻安全漏洞的影响，安全更新仍然要在部署计划之列。
例如，如果系统没有安装修补程序并且已感染蠕虫或病毒的计算机被引入到网络中，则所有不受保护的系统会迅速被感染。部署对策只是降低变更请求的优先级，而不是不再需要软件更新。
确定谁来部署软件更新
就部署软件更新和使用任何对策（如果合适）达成一致意见后，就需要确定谁来负责这些变更的实施。该人员的工作内容包括：
| • | 制定一个实施所需变更的计划。 |
| • | 确定和获取所需资源。 |
| • | 安排部署变更所需的所有必要脚本、工具和文档。 |
| • | 确保进行了充分的测试 |
| • | 确保变更已部署到生产中。 |
| • | 评估部署成败与否 |
如果没有指定人员负责监视以上活动，则存在软件更新可能无法部署的风险。指定的负责人通常是版本管理员，请参阅位于 http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/msm/smf/smfovrvw.asp 的“Release Management SMF”（英文）。
规划发布过程
规划发布过程是确定如何将软件更新发布到生产环境中的过程。规划新软件更新的发布一般包括三个阶段：
| • | 确定需要修补的对象 |
| • | 确定关键问题和约束条件 |
| • | 构建发布计划 |
确定要修补的对象
确定修补对象需要对环境的当前状况有一个准确的了解。
在 SUS 环境中，管理员需要用 Microsoft Baseline Security Analyzer (MBSA) 重新扫描以确定哪些系统需要软件更新。如果已部署 SMS，可利用清单工具和客户端代理检索到的信息来确定需安装更新的机器。
有关这些工具的详细信息，请参阅模块如何使用 SUS 执行修补程序管理和如何使用 SMS 执行修补程序管理。
确定关键问题和约束条件
有很多问题和约束条件可用来确定将软件更新全面部署到生产中时必须完成的步骤。例如，部署软件更新时，需要考虑下列问题：
| • | 在自动安装软件更新之前需要给用户多少时间？允许的时间取决于很多因素，包括用户角色和责任、系统不稳定性情况或软件更新所针对的安全漏洞。  图 2 |
| • | 某些软件更新要求在所安装的计算机上具有管理员权限。大多数最终用户没有本地管理员权限，因此安装软件更新的工具需获得较高的权限和授权才能在客户端计算机上安装软件更新。 |
| • | 如果软件更新的安装需要一定的硬盘空间，或软件更新在安装之前被缓存在本地，则需要在每一个客户端计算机上检查可用硬盘空间。 |
| • | 如果软件更新太大，例如几兆，那么移动客户端下载的时候需要一些时间。如果没有将软件更新的类别设为“紧急”，则可以在这些客户端上延期安装，直到它们物理连接到网络上。 |
| • | 负责关键业务的计算机可能只在特定时间内允许变更和重启计算机（停歇窗口）。软件更新的部署和所需的任何系统重启都需要在这些停歇窗口中进行。 |
| • | 如果通过特定的组策略设置对客户端计算机进行了锁定，可能会影响软件更新的正确安装。 |
| • | 如果要进行修补的产品是用 Windows Installer 部署的，则 Windows Installer 可能要求访问原始安装文件。如果您采用无人值守安装模式，则这些文件需位于产品最初安装时所在的位置。如果产品最初是从物理介质（如 CD 驱动器）上安装的，Windows Installer 将会在当前插入的 CD 上查找原始文件。 |
| • | 如果最初安装 Microsoft Office 产品时使用了管理映像，则需执行软件更新映像的管理安装，而不是直接将它应用于客户端。有关修补管理映像问题的详细信息，请参阅 http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sms/deploy/depopt/smsoffxp.asp（英文）。 |
| • | 如果某些应用程序是针对每个用户单独安装的，而不是以计算机为单位为所有用户安装，则需为每个计算机重新安装应用程序，然后将软件更新应用到新安装上。 |
如果使用 SUS 并希望避免在停歇窗口外进行部署，则需使用组策略对象 (GPO) 来指定下载更新，但不进行安装。更新下载完毕之后，应登录到每个关键业务服务器，然后在允许的停歇窗口内开始安装。对于工作站而言，还要有一个 GPO 设置来确保错过预定安装的计算机（例如因客户端计算机关闭而没有安装）在启动后运行自动更新服务来自动重排安装计划。有关在评估与计划阶段使用 SUS 的详细信息，请参阅模块如何使用 SUS 执行修补程序管理；有关如何使用 SMS 来计划部署的详细信息，请参阅模块如何使用 SMS 执行修补程序管理。
紧急变更请求
如果变更请求指明软件更新是紧急更新，则需考虑下列因素：
| • | 需在比常规时间更短的时间内部署软件更新。例如在批准变更请求后 24 小时内可能要进行全面部署。  图 3 |
| • | 停歇窗口控制着某些关键业务系统开始程序修补或重启的时间，因此需将其覆盖，以允许软件更新在许可的时间范围内部署。 |
| • | 需要将软件更新应用到所有受影响的系统上，不管它们是否连接到网络上。 |
如果使用 SUS，则可以使用组策略强制客户端在常规维护窗口前安装软件更新。进行此操作之前，还需确保在任何子 SUS 服务器上进行强制复制，它们通常设置为使用 SUS Server Administration 页面中的“Synchronize Now”（立即同步）选项在网络停止时间内同步更新。有关在评估与计划阶段使用 SUS 的详细信息，请参阅模块如何使用 SUS 执行修补程序管理。
在 SMS 环境中，应对 SMS 站点间发送程序进行配置，以允许在全天所有时间复制高优先级包/广告事务。高优先级设置只能用于软件更新包和广告，这一点很重要。有关在评估与计划阶段使用 SMS 的详细信息，请参阅模块如何使用 SMS 执行修补程序管理。
构建发布计划
在这一步，您需要计划和确定在生产环境中的计算机上部署软件更新的次序。以下是构建发布计划时需要考虑的问题：
| • | 如果软件更新应用于生产环境中所有的服务器，则运行 SMS、SUS 或监视工具的系统是否需要首先进行程序修补？ |
| • | 生产环境中的一部分要在另一部分之前进行修补，是否有业务上的原因？ |
| • | 站点之间的现有网络带宽对展示次序有什么影响？ |
最后，需要确定将软件更新的相关信息（严重性、影响以及需采取的部署步骤）通知用户、企业和服务台的时间及方式。
紧急变更请求
在紧急变更请求的情况下，应考虑以下方面：
| • | 如果管理体系结构组件（如 Microsoft Operations Manager (MOM)、SUS 和 SMS 2003 站点服务器）也需要进行修补，合适的做法是通过本地管理员对其进行手动修补，这样可确保将软件更新部署到生产环境中的其他计算机时这些服务器不会重启。 |
| • | 如果某个站点或一组计算机已经受到软件更新所针对的安全漏洞或系统不稳定性的影响，则应首先在这些计算机上部署软件更新。 |
生成发布版本
发布计划到位之后，下一步就是开发脚本、工具和操作程序，管理员将通过它们将软件更新部署到生产环境中。此处需执行的任务和活动主要取决于是否可以使用 SMS 2003 或 SUS 部署软件更新。
如果使用 SUS，请注意更新是从公共 Windows Update 服务器上直接下载的，并打包成可执行文件 (.exe) 格式，所以不必进行其他操作即可将它们重新打包以进行部署。有关在评估与计划阶段使用 SUS 的详细信息，请参阅模块如何使用 SUS 执行修补程序管理。
如果使用 SMS，并且更新是通过 SMS 2003 Distribute Software Updates Wizard 来部署的，则构建发布版本最为简单。此向导可自动创建 SMS 包以及分发和安装软件更新所需的程序。所有应用于特定产品和 Service Pack 组合的安全更新都可以合并到一个安全汇总包中，这简化了管理过程，同时在很大程度上减小了重启计算机的次数。对于不能用 SMS 2003 Distribute Software Updates Wizard 部署的更新，需使用标准 SMS 软件分发程序来创建包和广告，并指定将在客户端计算机上运行的批处理文件、Microsoft Installer (MSI) 文件或可执行文件，如果更新不提供可执行安装文件，则需通过 MSI 授权工具创建一个可执行文件。有关在评估与计划阶段使用 SMS 的详细信息，请参阅模块如何使用 SMS 执行修补程序管理。
验收测试
在这一步骤，测试的目的是为了确认软件更新和发布的包在开发环境内工作正常。
验收测试允许开发人员和业务代表检查更新在类似生产环境的环境中是否运行正常，以及软件更新部署之后关键业务系统是否仍能继续成功运行。管理员和业务代表应草拟一套针对关键业务软件更新进行的测试，此外还要草拟一套更为详尽的测试，在低优先级的软件更新中使用。
但是不管软件更新的关键程度如何，都要实施一个最低级别的测试，以反应如下情况：
| • | 一旦安装完成，计算机将根据设计要求重新启动。 |
| • | 如果要应用软件更新的计算机是通过速度较慢或不可靠的网络连接的，可以通过这些链路下载；下载完成之后就能成功安装。 |
| • | 软件更新提供卸载程序，以用于软件更新的成功删除。 |
| • | 软件更新安装之后，关键业务系统和服务仍能继续运行。 |
在将软件更新部署到生产中之前，应搜集有关测试中将使用的故障排除步骤、过程和工具的信息，然后将它们提供给服务台技术支持人员和操作组，这一点十分重要。
还要预见到测试会生成以下内容：
| • | 内部知识库 (Internal Knowledge Base) 文章，这些文章说明标准故障排除步骤和所有相关解决方案。 |
| • | 联系人列表和升级路径 |
| • | 脚本、规则和一些信息（如计数器、事件和阈值），这使操作人员可以有效监视生产中的发布版本。 |
不管测试如何执行，将软件更新部署到生产中经常会产生一些在实验室环境中难以预计或再现的影响。为避免潜在故障对大多数客户端计算机造成影响，管理员应考虑将软件更新应用到一小部分有代表性的计算机中，确认关键业务系统和应用能继续运行后，再将其部署到整个组织。
总结
以下是评估与计划阶段需牢记的关键内容：
| • | 需有一个正式的过程来确定部署软件更新能否达到业务利益最大化。 |
| • | 需有一个确定的软件更新负责人来负责部署。 |
| • | 批准软件更新之后，需要制定计划将它应用到生产中。 |
| • | 需在实验室对软件包进行测试，如果需要，可在生产环境中对其进行先导测试，以确定它不会影响 LOB 应用程序。 |
移交到部署阶段
移交到修补程序管理过程的部署阶段的触发因素是：
| • | 程序包已准备好，可部署到生产中 |
| • | 得到将软件更新部署到生产环境中的许可 |
有关部署阶段的详细信息，请参阅模块修补程序管理阶段 4 － 部署。