在云计算中对系统和应用程序进行补丁升级就如同一般的生产环境中进行相同的操作，这种想法对吗？也许答案并非如此。虽然从整体安全性和风险管理计划上来说，补丁升级的概念、重要性和实用性并没有发生变化，但是基于云计算的补丁升级管理的细节变化还是与传统的内部补丁管理大相径庭。

　　在本文中，我们将探讨云计算环境中补丁升级管理所带来的若干挑战，以及如何更有效地保证系统和应用程序能够升级至最新版本的一些想法。

　　基于云计算补丁升级管理的思考

　　与云计算中补丁升级工作相关的第一个思考就是云计算各类工作的中一个老问题，即：应该由谁来负责这项工作？与云计算中很多问题的回答相类似，这个问题的答案取决于云计算的交付模式。

　　对于软件即服务（SaaS）模式来说，消费者完全失去了对补丁升级过程的控制权。这种情况下，如果云计算供应商没有一个完备的补丁升级和配置管理流程，那么由此给消费者带的负面影响是可想而知的。例如在2010年，由于一次错误的补丁升级操作，博客平台WordPress就经历了一次严重的业务停用事件。对于所有使用SaaS或平台即服务（PaaS）服务的消费者，云计算安全联盟（CSA）建议他们的供应商们应当遵守其云计算控制矩阵（1.3版），具体要求如下：

　　应制定与漏洞和补丁升级相关的策略、程序和实施机制，从而确保及时评估应用程序、系统以及网络设备的漏洞，以基于风险的方法优先考虑关键补丁并及时做好供应商提供的安全补丁的升级工作。

　　在PaaS环境中，企业用户对补丁升级和配置可能拥有更多的控制权，尤其是应用程序和开发环境的组件与开发库等。把对所有使用的平台（如ASP.NET、PHP、Java等）和在该平台上运行的应用程序的补丁升级整合至现有的测试和QA周期，同时，并同时（或在相同的周期内）将其视作内部应用程序一样进行补丁升级。

　　在PaaS环境中，更大的挑战在于管理。目前，当实施补丁升级时，基础设施组甚至需要比以往更为紧密地与开发组和测试组协作。仍然由供应商负责所有包括操作系统和网络组件在内的后端基础设施的补丁升级任务，在SaaS环境中所提及的相同问题和关注点同样也适用于该模式。

　　对于基础设施即服务（IaaS）供应商来说，维护团队可以安装由诸如IBM公司和微软公司等供应商提供的传统补丁升级管理代理程序。这些代理程序可以向位于中央数据中心或甚至相同的云计算基础设施中的补丁升级管理系统报告，这取决于具体的部署场景。对于云计算服务器，还有一些新的基于云计算的补丁升级管理选项，例如来自于供应商ScaleXtreme的产品就包括了适用于内部和公共云计算系统（该云计算系统可由Amazon EC2和其它主要的云计算供应商托管），从而降低了在相同补丁升级任务中对两个系统进行评估和打补丁的难度。其它基于云计算的补丁升级管理选项还包括了Fiberlink通信公司的MaaS360和VMware公司的Go。

　　补丁升级的准备：云计算供应商应当提供的支持

　　除了实施针对你的基于云计算补丁升级管理任务的供应商模式，云计算安全联盟的一致性评估计划还建议向所有潜在的云计算服务供应商们（CSP）提出与补丁升级和漏洞管理相关的问题，具体如下：

　　• 按照行业最佳操作实务的规定，你是否定期进行网络层漏洞扫描？
　　• 按照行业最佳操作实务的规定，你是否定期进行应用层漏洞扫描？
　　• 按照行业最佳操作实务的规定，你是否定期进行本地操作系统层漏洞扫描？
　　• 如果你的用户要求，你是否会把漏洞扫描的结果提供给他们？
　　• 你是否有能力对你所有的计算机设备、应用程序以及系统执行快速补丁升级任务？
　　• 如果你的用户要求，你是否会向他们提供基于风险的系统补丁升级时间表？

　　归根结底，企业向云计算供应商寻求的支持应当是针对他们内部补丁升级管理实践和标准的一些调整。对于诸如Windows和Linux这样的标准操作系统，需要考虑的关键因素包括开放等级（系统的部署）、重要程度（系统的重要性）以及补丁程序的重要程度（如果不进行补丁升级，系统漏洞的危害程度）。相对开放的重要系统应当尽快地进行所有的关键补丁升级，建议在几天之内完成。尽管配套供应商可能不会透露他们补丁升级管理和变更控制的所有策略和程序，但是他们应当能够提供尽可能足够的细节信息和保证，以表明他们是否克尽职守。

　　准备进行一次新的补丁升级

　　在云计算环境中进行补丁升级操作为我们带来了新挑战，对于IaaS和PaaS环境来说，主要是协作和配置控制两方面。虽然所有的供应商都正式通过了内部的补丁升级和漏洞管理控制评估，同时他们也都能最低限度提供控件的一个独立认证证明（如一份SSAE 16报告），但是在PaaS和SaaS环境中审计和评估云计算供应商也被证明是存在着问题的，虽然不断出现的新产品可以让我们更容易地实现跨内外系统的补丁升级任务，虽然在同一云计算环境中的一个本地化补丁升级库和/或管理平台更为适用，但是大多数的企业仍然可能沿用IaaS部署时所使用的工具。