持续系统管理

云系统总是存在漏洞。其中一些将是安全问题。因此,准备应用安全更新和常规软件更新至关重要。这涉及智能地使用配置管理工具,如下文所述。这也涉及了解何时需要升级。

漏洞管理

有关安全相关变更的公告,请订阅 OpenStack Announce 邮件列表。安全通知也会通过下游软件包发布,例如,您可能订阅的 Linux 发行版中的软件包更新。

OpenStack 组件只是云中的软件的一小部分。保持所有这些其他组件的最新状态也很重要。虽然某些数据源将取决于部署,但云管理员必须订阅必要的邮件列表,以便接收到适用于组织环境的任何安全更新的通知。通常,这就像跟踪上游 Linux 发行版一样简单。

注意

OpenStack 通过两个渠道发布安全信息。

  • OpenStack 安全公告 (OSSA) 由 OpenStack 漏洞管理团队 (VMT) 创建。它们涉及核心 OpenStack 服务中的安全漏洞。有关 VMT 的更多信息,请参阅 漏洞管理流程

  • OpenStack 安全说明 (OSSN) 由 OpenStack 安全组 (OSSG) 创建,以支持 VMT 的工作。OSSN 解决支持软件和常见部署配置中的问题。它们在本指南中被引用。安全说明存档在 OSSN

分级处理

在收到安全更新通知后,下一步是确定此更新对给定云部署的关键程度。在这种情况下,拥有预定义的策略很有用。现有的漏洞评级系统,例如通用漏洞评分系统 (CVSS),并不能正确地考虑云部署。

在此示例中,我们引入了一个评分矩阵,将漏洞分为三类:权限提升、拒绝服务和信息泄露。了解漏洞的类型以及它在您的基础设施中的位置将使您能够做出合理的响应决策。

权限提升描述了用户以系统中的其他用户的权限行事的能力,绕过适当的授权检查。访客用户执行的操作允许他们以管理员的权限进行未经授权的操作,这是此类漏洞的一个例子。

拒绝服务是指可能导致服务或系统中断的漏洞。这包括旨在压垮网络资源的分布式攻击,以及通常由资源分配错误或输入引起的系统故障缺陷引起的单用户攻击。

信息泄露漏洞会泄露有关您的系统或操作的信息。这些漏洞范围从调试信息泄露到暴露关键安全数据,例如身份验证凭据和密码。

攻击者位置 / 权限级别

外部

云用户

云管理员

控制平面

权限提升(3 个级别)

关键

不适用

不适用

不适用

权限提升(2 个级别)

关键

关键

不适用

不适用

权限提升(1 个级别)

关键

关键

关键

不适用

拒绝服务

信息泄露

关键 / 高

关键 / 高

中 / 低

此表说明了一种通用的方法,用于根据漏洞在您的部署中发生的位置和影响来衡量其影响。例如,在 Compute API 节点上进行单级权限提升,可能会允许 API 的标准用户升级为拥有节点上的 root 用户相同的权限。

我们建议云管理员使用此表作为模型,以帮助定义针对各种安全级别的操作。例如,关键级别的安全更新可能需要快速升级云,而低级别的更新可能需要更长时间才能完成。

测试更新

您应该在将其部署到生产环境之前测试任何更新。通常,这需要设置一个单独的测试云,该云首先接收更新。该云在软件和硬件方面应尽可能接近生产云。应从性能影响、稳定性、应用程序影响等方面对更新进行全面测试。尤其重要的是,要验证理论上由更新解决的问题(例如,特定的漏洞)是否已得到修复。

部署更新

一旦更新经过全面测试,就可以将其部署到生产环境。此部署应使用下面描述的配置管理工具完全自动化。

配置管理

高质量的生产云应始终使用工具来自动化配置和部署。这消除了人为错误,并允许云更快地扩展。自动化还有助于持续集成和测试。

在构建 OpenStack 云时,强烈建议您在考虑配置管理工具或框架的情况下进行设计和实施。配置管理使您能够避免构建、管理和维护像 OpenStack 这样复杂的基础设施所固有的许多陷阱。通过生成配置管理实用程序所需的清单、食谱或模板,您可以满足许多文档和法规报告要求。此外,配置管理还可以作为您的业务连续性计划 (BCP) 和数据恢复 (DR) 计划的一部分,您可以在 DR 事件或发生泄露时将节点或服务恢复到已知状态。

此外,与 Git 或 SVN 等版本控制系统结合使用时,您可以跟踪环境随时间的变化并修复可能发生的未经授权的更改。例如,如果 nova.conf 文件或其他配置文件不符合您的标准,则您的配置管理工具可以还原或替换该文件并将您的配置恢复到已知状态。最后,配置管理工具还可以用于部署更新;简化安全补丁流程。这些工具具有广泛的功能,在这一领域非常有用。保护您的云的关键是选择一个配置管理工具并使用它。

有许多配置管理解决方案;在撰写本文时,市场上存在两种对 OpenStack 环境提供强大支持的解决方案:Ansible 和 Puppet。下面提供了一个非详尽的工具列表

  • Puppet

  • OpenStack-Ansible

  • Kolla-Ansible

策略变更

每当策略或配置管理发生变化时,记录活动并备份新集合是一个好的做法。通常,这些策略和配置存储在版本控制存储库中,例如 Git。

安全备份和恢复

在整体系统安全计划中包含备份程序和策略非常重要。有关 OpenStack 的备份和恢复功能和程序的良好概述,请参阅 OpenStack Operations Guide on backup and recovery

  • 确保只有经过身份验证的用户和备份客户端才能访问备份服务器。

  • 对备份的存储和传输使用数据加密选项。

  • 使用专用且安全的备份服务器。备份服务器的日志必须每天监控,并且只能由少数人访问。

  • 定期测试数据恢复选项。可以从安全备份中恢复的一件事是镜像。如果发生泄露,最佳做法是立即终止正在运行的实例,然后从安全备份存储库中的镜像重新启动实例。

安全审计工具

安全审计工具可以补充配置管理工具。安全审计工具可自动化验证给定系统配置满足大量安全控制的过程。这些工具有助于弥合安全配置指南文档(例如 STIG 和 NSA 指南)与特定系统安装之间的差距。例如,SCAP 可以将正在运行的系统与预定义的配置文件进行比较。SCAP 输出一份报告,详细说明配置文件中的哪些控制得到了满足,哪些失败了,以及哪些未被检查。

将配置管理和安全审计工具结合使用可以创建强大的组合。审计工具将突出显示部署问题。配置管理工具简化了更改每个系统以解决审计问题。以这种方式一起使用,这些工具有助于维护满足从基本加固到合规性验证的安全要求的云。

配置管理和安全审计工具将为云引入另一层复杂性。这种复杂性带来了额外的安全问题。我们认为这是一个可接受的风险权衡,考虑到它们的安全性益处。保护这些工具的运行使用范围超出了本指南的范围。