PDF企业补丁
各种规模的组织都在花费大量精力来正确管理补丁——他们的业务依赖于此。
GEORGE BRANDMAN，摩根士丹利
软件补丁管理已经发展成为一个业务关键问题——从风险和财务管理角度来看都是如此。根据Aberdeen Group最近的一项研究，企业在2002年在操作系统补丁管理上花费了超过20亿美元。1 Gartner研究进一步指出，管理良好的PC的运营成本每年比未管理的PC少约2000美元。2 您可能会认为，随着临界质量和更复杂的工具的出现，大型组织中每个端点的管理成本会更低，但实际上可能并非如此。本文的目的是提供一些基于企业经验的理论依据，将这些观察结果置于背景中，并提出一些可能有助于应对这种趋势的方法。
有几个主要主题值得注意。第一个也是可能最重要的主题是，补丁管理是一项团队工作。在一个大型企业中，许多部门需要协同工作，以通过补丁正确评估和修复软件漏洞。良好的工具可以提供帮助，但企业如果不能在各个相关团队之间建立完善的流程和良好的沟通，就无法取得成功。
第二个重要主题是，没有一种工具可以解决所有问题。对于拥有数万个端点（例如，台式机、笔记本电脑、服务器）的公司来说，需要互补的系统才能有效地管理补丁过程。根据内部网络的复杂性，供应商开发的工具可能无法完全或完全满足所有需求，因此需要进行一些自定义开发。
补丁管理是被动的，良好的安全实践是主动的。这似乎是显而易见的，但很容易陷入应用一波又一波补丁的困境，而没有抽出时间来设计工具和配置，这些工具和配置可以在某些漏洞被利用之前减少或消除它们。
我们今天的状况
大多数企业级补丁管理系统都遵循一些相同的基本流程。简而言之，首先从供应商的安全网站将补丁和用于确定其适用性的策略下载到企业内部网络。接下来，在预定的时间或与系统事件（如用户登录）同时，将计算机定向为接收包含补丁和相应策略的软件包。然后，策略确定补丁是否适用于计算机，如果适用则安装它。最后，计算机通常需要重新启动才能完成补丁安装，然后它会向中央存储库报告补丁已成功安装。简化的典型架构如图1所示。
企业级系统的主要优势包括复杂的定向、计划、报告和清单功能。当处理大量计算机和数千个已安装的应用程序时，所有这些都是必不可少的。
定向通常涉及使用组织内的一些有意义的分组来选择一组特定的计算机来接收软件包。这最初可能是一两个楼层由友好的部门占用，然后扩展到整个业务部门或园区。良好的补丁管理工具提供灵活的定向机制。这可以从LDAP查询到Active Directory以获取组织单位或邮件组，到查看有关计算机硬件或软件的特定清单记录，从连接到内置或外部数据库。
一旦补丁交付到目标计算机，就可以使用各种自动化机制来确定其适用性。最常见的方法是查找由文件、DLL版本和/或注册表设置组成的预定特征。例如，Microsoft通过其Windows Update和MBSA（Microsoft Baseline Security Analyzer）实用程序提供此功能。但是，在某些情况下，这些工具无法涵盖。此外，这些实用程序仅适用于某些Microsoft软件产品，而不适用于其他供应商的产品，例如Adobe Acrobat或Mozilla Firefox。在本文后面的“正确执行”部分中，我们将更详细地讨论其中的一些注意事项。
计划确定应用更新的必要时间和系统条件。在最基本的形式中，作业将被赋予日历日期和时间来运行。虽然这可能满足较小组织的需求，但对于拥有许多业务部门的全球金融服务公司来说，这是行不通的，每个业务部门都有独特且时间敏感的需求。对于这种类型的组织，需要额外的功能，包括以下内容
• 支持可选和强制窗口以应用补丁。
• 检测当前用户和系统状态（例如，用户是否空闲？）。
• 确定是否以及何时重新启动的能力。
• 用户在某些情况下推迟或拒绝更新的灵活性。
良好的补丁管理系统还应支持分层计划的概念，其中可以为不同类别的补丁创建独特的部署周期。例如，放置在关键存储桶中的补丁可以每周（或更频繁）应用一次，而其他补丁则每月应用一次。
从受管理计算机及时准确地向中央存储库报告是补丁管理过程的关键部分。当处理大量端点时，数据收集过程可能会变得繁重。分层扇入架构可以帮助保护中央存储库免受数千台计算机尝试同时报告状态的冲击。这也是无代理补丁管理系统（即，在受管理计算机上没有本地服务运行的系统）最终可能会在中央服务器上完成不成比例的工作量来收集和处理结果的领域。
端点清单（包括受管理和未受管理端点）是对企业网络上的计算机进行编目的持续过程。它包括跟踪重要的硬件、应用程序和操作系统特性，并用于定向补丁和维护整体系统健康状况。该过程可能资源密集型，因此需要保持平衡：收集足够的信息以适当管理环境，但又不会过多以至于最终用户体验受到负面影响或重要数据丢失在茂密的草丛中。还应提供某种机制来收集有关未受管理端点的信息，以采取措施减轻它们对企业网络的风险。
关键挑战
企业补丁管理的成本和精力可能会随着目标环境的规模和复杂性而成比例地增加。适用于较小组织的不太复杂的工具和流程可能不适用于更大和更异构的环境。本节讨论的几个因素也可能对维护健康和安全环境所需的总体工作量产生重大影响。
重启中断
及时打补丁的最大障碍之一仍然是所需的重启。这发生在多个供应商的产品中，包括Windows操作系统补丁、Internet Explorer以及在内核空间中运行的其他产品和设备驱动程序。一些补丁管理系统提供安装补丁的功能，同时将重启推迟到稍后的时间。虽然对最终用户的干扰较小，但这种做法可能会使系统处于不一致的状态。
补丁发布频率
更新之间需要重启可能会使大型组织的补丁计划看起来像一块瑞士奶酪。每个业务部门可能对何时何地可以重启用户的机器有不同的考虑。有些可能会限制工作日重启，另一些可能需要考虑关键的每周或每月处理。服务器带来了它们自己独特的问题，因为许多业务线应用程序都是24/7全天候运行的，没有维护窗口的机会。
补丁管理系统——一种尺寸不适合所有情况
当今的一些企业补丁管理系统可能为复杂场景提供不完整或不一致的策略定义功能。大型组织必须对日期和时间要求、补丁关键性、网络连接和机器状态保持敏感。
移动用户使问题复杂化
日益增长的移动用户群和由DMZ（非军事区）、远程笔记本电脑以及锁定的最终用户和服务器环境组成的企业复杂网络，都为保持系统补丁更新带来了独特的挑战。补丁包和交付系统必须针对持久性和灵活性进行设计，以适应连接性和各种安全配置。
正确执行
在大型金融服务环境中，推出关键更新所需的时间过长可能会使企业容易受到攻击。话虽如此，部署时测试不足可能会导致，例如，在市场交易时间内交易大厅的业务线应用程序崩溃。
正确执行是在极短的时间内应用补丁，同时最大限度地减少因重启中断和持续的更新流对用户造成的影响之间取得平衡。需要来自多个不同学科的代表组成的良好协调的团队才能有效地执行
• 运营团队可能是打包、集中测试和部署更新的人员。
• 工程师将其集成到构建和补丁管理系统中。
• 业务线支持团队确保业务关键型应用程序不受影响。
• 安全团队评估关键性，设置整体部署计划，并可能规定防御措施（例如，关闭企业防火墙上的端口）。
所有这些都需要时间。有些补丁可能需要重新打包才能在企业网络中正确安装和配置。在全面全球企业推广之前，可能会安排一次或多次测试部署，以逐步证明补丁的兼容性和用于安装补丁的软件包的合理性。在每次迭代之后，都会评估结果，以查看是否存在更大的问题迹象，这些问题可能会随着部署范围的扩大而显现出来。这可能包括不可预见的最终用户影响或与其他产品的隐藏的相互依赖性。然后可能需要修改软件包，以检测先前版本的不兼容软件，并卸载它们或安装适用于检测到的版本的不同组件。
管理重启注意事项
由于一些供应商每月发布补丁，因此最大限度地减少用户影响的一种方法是创建一个包含多个必需热修复程序的软件包。其中一个或多个补丁可能需要重启。用于将热修复程序链接在一起的工具可用于最大限度地减少这种中断以及在将多个补丁安装到单个最终重启时对多次重启的需求，尽管可能仍然存在需要在补丁之间重启的更新。
在延迟重启的场景中，某些文件被覆盖到其新版本，而其他文件（如系统DLL）则被暂存并等待下一次重启以激活。组织需要权衡这种“打补丁并稍后重启”策略的风险与系统重启对最终用户的影响。使用前者可以更快地部署已打补丁版本的二进制文件和库，这可能会让人感觉端点风险已得到缓解，但如果某些组件正在等待系统重启才能激活，则实际上可能并非如此。
扣动扳机
在集中式和最终用户测试、试点部署以及结果验证完成后，在某个时候，就该进行全球推广了。通常，除非存在直接威胁，例如SQL Slammer病毒的情况，否则可以在周末启动推广，以最大限度地减少用户影响。
定义应用补丁（或补丁包）的具体细节的策略通常在考虑以下因素后实施
• 端点的工作时间。
• 是否允许用户推迟安装或重启，如果允许，推迟多长时间。
• 应用补丁时适当的用户或机器状态。
跨越多个时区将可接受的补丁窗口时间表拼凑在一起通常很困难。在确定是否允许用户推迟更新时，还应考虑补丁的关键性。
图2显示了一个示例流程，包括笔记本电脑补丁策略中可能包含的一些决策点。
结果整理过程在最初的大规模企业推广完成后不久开始。数万个端点将通过补丁后验证过程报告回中央存储库。这通常包括与安装补丁之前执行的用于确定适用性的文件版本或注册表项类似的检查。
然后可以安排自动清理周期来处理最初未成功打补丁的剩余机器。在最初计划部署时，存在健康问题的机器或脱机的机器可能会导致初始成功率降低。端点上无法运行的补丁管理代理等问题可能特别麻烦，因为它们可能需要现场访问才能解决导致安装失败的问题。
维护明确定义的通用基本构建并最大限度地减少最终用户配置之间的偏差可以帮助减少具有健康问题的机器总数，并证明良好的主动安全实践。尽可能多地删除最终用户的本地管理员权限（对于开发人员的机器而言，这通常更难实现）以及实施策略以始终如一地停用较旧且问题较多的产品版本，也可以帮助企业朝着这些目标迈进。
解决远程和移动用户的需求
补丁的关键性可能相对于最终用户环境进行考虑，在最终用户环境中，必须解决远程连接和移动用户的需求。某些补丁可能被视为LAN连接用户的强制性补丁，但对于远程或移动用户来说是可选的。端点可能基于标准企业基本构建和配置，也可能是开箱即用的供应商操作系统安装。在任何一种情况下，VPN连接的端点都可能限制某些协议，例如SMB（服务器消息块）。分发工具还应支持基本Internet连接常用的协议，包括HTTP/S和FTP。
推送与拉取
当前的许多软件分发产品都能够进行基于推送的软件分发和基于拉取的软件补丁更新轮询。这两种方法都在企业级软件分发系统中占有一席之地。
基于推送的部署旨在确保特定补丁在同一时间部署到大量机器。这非常适合紧急补丁和满足某些部署窗口限制。推送方法的缺点是目标机器必须在网络上可访问，或者具有复杂的重试逻辑来补偿。
基于拉取的部署通常不需要端点通过企业网络可访问即可接收补丁。简单的轮询算法、LAN端口链路状态和系统重启都可能导致发生拉取事件。这使在网络上可用的机器能够立即轮询分发服务器，以查看它们可能需要什么才能成为最新的。基于拉取的技术的另一个好处是，它可以作为端点最初将自己注册为补丁管理系统客户端的机制。拉取方法的缺点是，所有机器都必须到达其轮询间隔，才能确保已部署补丁。
最强大的软件分发系统将这两种概念与细粒度的端点定向控制相结合。部署包可供所有符合某些明确定义的清单标准或组关联的系统使用。然后，对所有匹配的客户端发起“推送”，要求每个客户端“立即拉取”。不在网络上的目标机器将在其下一个轮询间隔拉取所需的任何内容，并在当时使用适当的连接选项。
跨组织优先考虑工具
能力
对于补丁管理系统来说，为多样化的计算环境维护合理的健康和安全状态可能是一项具有挑战性的任务。单一工具可能难以经济高效地满足每个组织的挑战。影响因素可能包括目标端点的类型和数量以及现有内部开发的基础设施的功能。有些工具可能具有出色的报告和定向功能。另一些工具可能擅长通过Internet或与企业软件存储库集成来安全传输更新。
每个企业都可以根据其规模和连接需求来优先考虑产品的某些功能。大型组织可能拥有内部开发的内容复制和软件部署基础设施，因此更注重文档完善的供应商API和集成功能。较小的组织可能会从完全交钥匙的解决方案中获得更多价值。专注于易于安装和部署且服务器要求最低的无代理产品可能非常适合这些企业。全球组织通常创建地理层次结构，用于集中管理基础设施，其中包含一个或多个“根”层次结构以及区域或园区范围的子层次结构。当前的产品架构支持内容和策略源与目标端点之间的扇入/扇出功能，可能非常适合这种类型的管理。支持策略的继承和覆盖（包括在层次结构的所有级别进行定向）也非常有价值。最终，企业可能需要考虑几个同类最佳产品，以最好地满足所需的多样化功能集。
保持补丁更新
有时，新版本的供应商产品可能会将通用组件降级到低于最新补丁版本的级别。企业可以通过集中的软件打包团队或标准化工具来解决此问题，这些工具将软件包与目标最终用户环境的基本构建配置的当前版本进行比较。
持续的清单和报告也可以有效地确保端点保持补丁更新。供应商产品、操作系统和硬件级别都存在执行全面清单的机制。WMI（Windows Management Instrumentation）使用DMTF CIM（分布式管理任务组通用信息模型）规范公开OEM存储的清单和管理信息。企业可以使用这些API，以及在适当情况下直接查询硬件，以收集所需的系统清单信息。除了在初始补丁部署后立即进行的过程之外，检查机器注册表和文件系统信息以验证补丁签名并在中央存储库中更新此信息也应是一个持续的过程。
对于最近一些快速传播的病毒，防止新构建的机器在自动构建过程应用当前补丁之前被感染可能是一个挑战。一种可能的缓解方法是将更新的组件滑流或直接注入到构建过程中，以便将它们作为自动基本构建的一部分安装，而不是在顶部应用。不幸的是，此过程可能会大大增加维护基本构建的成本，并且不一定适用于所有类型的补丁。
虚拟机技术通常提供检查点功能，这对于测试人员和开发人员非常有用。用户可以拍摄系统状态的快照，然后在命令下快速将虚拟机回滚到此状态。一个有问题的不良影响是，如果管理不当，用户实际上可以通过此操作取消企业网络上的机器的补丁。可能需要工程努力来确保可以安全地启用此功能。
下一步是什么？
大型企业和当前一代补丁管理系统在对所有类型的机器（包括笔记本电脑、台式机和服务器）应用补丁方面变得非常复杂。正如整篇文章所讨论的那样，通过使用自动构建和配置管理系统，还可以最大限度地降低保持机器补丁更新和健康的成本。
因此，有了这项已经到位技术，在成本、可靠性和管理企业环境的速度方面，还可以做些什么来取得重大改进？一种可能的答案可能在于我们思考管理端点方式的根本性改变。如果企业能够有效地从网络文件系统运行其所有业务应用程序和机器操作系统的大部分，会怎么样？在这种模型中，可执行文件和配置信息将来自网络上的只读区域，然后在端点上的内存中本地运行。
将更新部署到数百台文件服务器比在数万台机器上物理安装相同的更新要省时省力得多，并且不易出错。这将需要抽象有状态安装的新方法，以及在网络命名空间中管理不同操作系统和应用程序配置的机制。这可能无法在某些情况下减轻重启以激活配置更改的需求，但好处是相当可观的。
补丁不是通过将一块软件物理安装到每个系统上来打，而是只需在网络命名空间中安装和测试补丁，然后将目标机器指向新配置即可。在这种环境中，在少数最终用户配置上测试更新将对结果提供更大的信心，因为目标机器上的配置偏差将降至绝对最低。可以通过基于策略的功能来完成管理端点上剩余的本地配置偏差，这些功能会在关键设置和文件被更改或删除时主动恢复它们。如有必要，全球推广和回滚可以在当今所需时间的一小部分内完成。
运行时环境和本地缓存
Java和Microsoft .NET开发技术旨在解决从网络运行的注意事项。较旧的Microsoft技术（如COM）是可能的，但更难以抽象到此模型。从系统级别来看，Posix风格的操作系统提供某些功能，使应用程序和操作系统从网络运行的场景更可行。
虽然台式机或服务器通常可以依靠可靠的宽带连接来检索其应用程序软件和操作系统配置，但笔记本电脑通常处于脱机状态，即使在断开连接时也需要对其最终用户保持功能。对于这些场景，需要某种形式的智能缓存，在断开连接时提供本地功能，但在企业网络可用时自动更新缓存。
笔记本电脑需要在各种类型和质量的网络连接（包括LAN、VPN或仅限Internet连接）上进行补丁更新的能力。所有这些都需要与机器上的本地缓存管理集成，并对最终用户来说是无缝的。
其他管理可能性
企业网络本身可以在补丁管理中发挥作用。除了文件服务器之外，路由器或网关等网络节点还可以主动与台式机或服务器等端点协同工作，以检测和修复安全或其他类型的问题。此外，一些供应商开始提供管理功能，这些功能在某些领域提供更精细、集中的安全配置控制。
对于许多企业最终用户来说，并非明确需要高性能台式机。对于这些用户，通过终端仿真提供对VM（虚拟机）或终端服务器的瘦客户端访问可以大大减少要管理的端点数量。后端VM或终端服务器仍然可以利用通过从网络运行模型提供的所有先前描述的功能。此模型的另一个好处是，与最终用户的台式机相比，这些服务器到网络文件服务器的连接通常具有更高的带宽。
将所有内容整合在一起
当今可用的技术和即将出现的技术将继续简化补丁和系统管理。自动化安全实践的持续集成最终将无缝地融入这些工具中。网络和平台技术领域的供应商已经开始共同努力朝着这个目标前进。可能需要新的方法来重新思考大型企业计算网络的配置方式和变更管理方式，以实现最大的规模效率。无论使用哪种方法，务实的风险管理平衡仍将是需要组织内各学科进行周到协调的关键要素。
参考文献
1. Schwartz, K. D. 补丁管理成熟。2004年6月3日。The Channel Insider； http://channelzone.ziffdavis.com。
2. Silver, M. 和 Pescatore, J. 2004年10月14日。安全漏洞增加了Windows客户端的TCO。Gartner研究报告； http://www.gartner.com。
喜欢还是讨厌？请告诉我们
[email protected] 或 www.acmqueue.com/forums
GEORGE BRANDMAN 是摩根士丹利机构证券信息技术部门的执行董事。
© 2005 1542-7730/05/0300 $5.00
最初发表于Queue vol. 3, no. 2—
在数字图书馆中评论本文
更多相关文章
Emery D. Berger - 软件需要安全带和安全气囊
就像死亡和税收一样，代码错误是生活中不幸的事实。几乎每个程序都附带已知的错误，并且可能所有程序最终都会出现仅在部署后才发现的错误。造成这种可悲状况的原因有很多。
Alex E. Bell - UML热：诊断和恢复
传染病研究所最近发表的研究证实，多种多样的UML热1继续在全球范围内蔓延，不分青红皂白地感染软件分析师、工程师和经理。据观察，这种热病最严重的副作用之一是开发软件产品的成本和持续时间都显着增加。这种增加在很大程度上归因于因患病者将时间和精力投入到对生产可交付产品几乎没有价值的活动中而导致的生产力下降。例如，开放环路热病的患者继续为未知的利益相关者创建UML（统一建模语言）图。
Joseph Dadzie - 了解软件补丁
随着软件运行的卷、复杂性和配置数量的显着增长，软件补丁已成为当今计算环境中日益重要的方面。软件架构师和开发人员尽一切努力构建安全、无错误的软件产品。为确保质量，开发团队利用他们可支配的所有工具和技术。例如，软件架构师将安全威胁模型纳入其设计中，QA工程师开发了自动化测试套件，其中包括复杂的代码缺陷分析工具。
© 保留所有权利。