山东 赵长林

基于云的补丁管理系统和应用可能不同于传统的内部程序。这些不同点将扩展到不同的部署类型，例如，对SaaS 部署的补丁相对直接而简单，因为消费者无法控制补丁过程。如果供应商不能实时地对软件和组件打补丁，就会带来巨大的风险。

企业对基于云的补丁管理的责任

所有的企业都应当验证其SaaS 或PaaS 供应商的补丁周期。服务供应商还应当将打补丁的方式传达给企业，从而使企业知道潜在的性能或可能性问题。

要确保供应商有能力快速地对所有设备、应用和系统的漏洞打上补丁。应考虑供应商是否与客户共享其基于风险的打补丁的时间。最终，企业应当寻求这样一种云服务供应商：其服务要与企业的内部管理实践和标准保持一致。

PaaS 基于云的补丁管理的最佳实践

对于PaaS 环境来说，企业将拥有对补丁和配置的更多控制，尤其是对于应用和开发环境的组件和库来说。企业应寻求将任何已用的平台（ASP .NET、PHP、Java 等）和运行在其上的应用程序都集成到现有的测试和质量保证周期中，将在同一时间或在相同的周期内实施的修复作为内部应用。

补丁管理是PaaS 环境中的一个巨大挑战。在应用这些补丁时，基础架构团队需要与开发和测试团队密切协作。改变窗口还需要提前计划，以适应云供应商的认可。如果要使用PaaS 的部署容器，容器的镜像在被部署到一个安全存储库之前，可以打上补丁和实施测试。

所有后端的基础架构，包括操作系统和网络组件，仍由供应商打补丁。针对SaaS环境所涉及的问题也应当适用于这种模型。

IaaS 基于云的补丁管理的最佳实践

对于IaaS 供应商，团队可以安装供应商的传统的补丁管理代理。这些代理可以向位于中央数据中心或位于相同的云基础架构中的补丁管理系统报告，当然，这要依赖部署的具体情况。

对于云负载来说，新的基于云的补丁管理选项正在出现，例如微软的Azure 更新管理服务。这些工具可能更加高效，并且在本地就可以与运行在云基础架构中的任何实例相集成。这些工具还包括脚本和调度等选择。

新的和正在出现的本地云服务使得修复云负载的过程更加便捷，但是还有一些企业仍选择使用已经拥有的工具实施IaaS 部署，用以简化运营管理。

激进的云工程团队和运营团队正从传统的补丁模型转移。开发运营团队不再花费需为应用程序打补丁以使系统运行的更长时间运行负载，而是转向可被应用到新系统镜像的补丁和更新。然后，推出这些补丁和更新，用以替换老旧的负载。

这就要求考虑到在部署过程中的大量测试。随着自动化配置管理工具的使用，补丁和配置被大量地自动化。通过配置模板和配置管理工具而应用补丁，团队就可以更容易地在负载镜像上部署补丁和测试结果，然后再将部署了所有更新的新镜像推送到生产云中。

或者，在“蓝绿部署”中，测试环境被验证，然后再投入生产，而老的生产环境成了测试区域。

不管所使用的云模式是什么，企业都应当正式地评估所有的供应商，以用于内部的补丁和漏洞管理控制。至少，供应商也应当能够提供独立的经验证的控制证明，例如，一份SSAE 18 SOC报告。