OpenStack Barbican 部署选项如何保护您的云

您的密钥是否安全?选择合适的 OpenStack Barbican 部署选项,以保护您云的隐私和完整性。
307 位读者喜欢这篇文章。
tools in the cloud with security

Opensource.com

无论您是遵循内部信息安全策略,还是试图满足 GDPR、ANSSI、PCI DSS、HIPAA 或 NIST 等法规要求,您都可能在寻找保护您的数据和软件的隐私和完整性的方法。该解决方案可以在加密中找到。OpenStack 提供了部署隐私和完整性解决方案所需的所有要素,但这取决于运营商是否安全地部署它们。 这需要一个密钥管理解决方案 (KMS) 来管理和保护加密密钥。

Barbican 是 OpenStack 服务,允许运营商和用户安全地管理和存储密钥。它由一个 OpenStack API 组成,该 API 提供 keystone 身份验证oslo.policy 和配额,以及存储密钥的后端。但是密钥的安全性仅与 Barbican 后端部署的存储后端一样安全。本文将讨论 Barbican 部署选项,并探讨每种选项如何影响您云的安全性。

用户配置文件、威胁和需求

在评估密钥管理选项时,有许多因素需要考虑。根据用例的不同,不同的标准具有不同的权重。

第一个标准是解决方案的安全性。应该有一个访问策略,以便只有授权用户才能访问密钥和相关的审计跟踪。应该了解密钥(以及保护它们的主密钥)的安全性。某些选择将被认证为符合不同的标准,例如 FIPS,而另一些可能不会。必须防止篡改和窃听。

其次,KMS 应该能够在压力或故障面前执行。应考虑密钥存储的可用性、持久性和可扩展性。理想情况下,即使在硬件、软件或连接故障期间,密钥材料仍然可用。

最后,还有业务因素需要考虑,包括总价、易用性以及与现有基础设施的兼容性。

考虑到所有这些因素,让我们比较一下不同的 Barbican 部署选项。

架构

第一个部署考虑因素是 Barbican 的架构。与其他 OpenStack 服务一样,Barbican 由 API 服务器、数据库和可通过可配置插件访问的后端组成。一个重要的设计目标是最小权限原则。密钥管理管理员应具有与存储或计算管理员不同的访问权限。将加密和签名的数据和软件与加密密钥分离可以实现此目标,并提高云的安全性。虽然在 OpenStack 服务之间共置 API 服务并共享通用数据库是很常见的做法,但最佳实践是将 Barbican 与使用它的服务分开。

安全存储选项

密钥存储插件允许 Barbican 与后端交互以存储、生成和检索密钥。主要有两种类型。

第一种允许 Barbican 与外部 KMS(如 Hashicorp Vault 或 Dogtag 密钥恢复机构)交互以存储密钥。对于 Barbican 而言,外部 KMS 本质上是一个安全的黑盒。Barbican 使用 KMS 的 API 和提供的凭据与 KMS 交互,并在 Barbican 数据库中存储额外信息(如引用 ID),使其以后能够访问密钥。

这些插件提供逻辑和权限分离,因为密钥存储在完全独立的应用程序中,通常在专用网络上的单独服务器上。此外,整个系统可能更容易通过 Common Criteria 等标准的合规性认证,因为您可以限制评估目标 (TOE)。

加密插件是第二种密钥存储插件类型。它们加密密钥并将它们直接存储在 Barbican 数据库中。它们可以提供性能优势,因为它们不需要 Barbican 访问外部 KMS。只要数据库管理员无权访问加密密钥,加密插件就可以提供权限分离。

让我们更详细地了解一些可用的插件。

4 个加密插件

简单加密插件

简单加密是最简单的插件,也是在上游 gates 中使用 devstack 测试的插件。它也是默认的、开箱即用的密钥存储插件。所有密钥都由 AES-256 位密钥(密钥加密密钥 (KEK))加密,该密钥存储在 Barbican 配置文件中。

该插件不仅是最简单的,而且也可能是性能最高的。另一方面,它也有明显的缺点。首先,由于单个密钥用于所有加密,如果该 KEK 泄露,则数据库中所有租户的所有密钥都处于风险之中。此外,如果不重新加密所有现有密钥,就无法轮换此密钥。

PKCS#11 插件 + HSM

PKCS#11 是最通用的插件之一。它与硬件安全模块 (HSM) 通信 PKCS#11,例如来自 Yubikey、Thales、Safenet 或 ATOS 的 HSM。

虽然简单加密插件使用单个密钥,但 PKCS#11 使用多个密钥。HSM 存储两个主密钥:主加密密钥 (MKEK) 和主 HMAC 签名密钥。然后,HSM 使用这些密钥来加密和签名各个租户密钥加密密钥 (pKEK)。pKEK 用于加密每个租户的密钥。最后,这些加密值存储在 Barbican 数据库中。

这比简单加密的安全性要好得多。首先,不同的租户使用不同的 pKEK 来加密他们的密钥,因此一个租户的 pKEK 的泄露不会影响其他租户。此外,密钥轮换比简单加密要简单得多。当 MKEK 轮换时,只需要重新加密 pKEK,而不是每个密钥。

其次,所有加密操作都在加密设备的内存中进行,因为 pKEK 都由 MKEK 加密,而 MKEK 永远不会从 HSM 中提取出来。物理 HSM 提供审计、篡改检测和防篡改功能,并具有足够随机的熵源来生成密钥。它们通常还限制加密算法和密钥,以满足 Common Criteria、FIPS 140-2 或其他标准。

但是它们可能很昂贵,并且可能需要进行调整以获得最佳性能。如果您可以接受较低的性能或安全保证,则 Yubikey 或基于软件的 HSM 可能是成本较低的选择。

PKCS#11 + 软件 HSM

基于软件的 HSM 最初是 DNSSEC 组的一个项目,它是使用 PKCS#11 通信的加密设备的软件实现。与基于硬件的 HSM 一样,它使用多密钥方法。这包括主密钥和密钥加密密钥,密钥加密密钥由主密钥解密。加密密钥和其他工件存储在文件系统中的文件中。

将 PKCS#11 插件与软件 HSM 结合使用,不提供硬件 HSM 的审计、篡改保护和安全认证。但是,它确实比简单加密提供了显着的改进,因为它允许更轻松的密钥轮换和每个项目的 KEK。

OpenStack Stein 周期(现在正在开发中)计划在上游持续集成 (CI) 中包含此配置的测试门。

SGX

Intel SGX 是一项新的处理器技术,允许应用程序在内存中创建称为飞地的安全区域。这些飞地为应用程序提供了一个可信的执行环境,其中飞地内部任何代码和数据的机密性和完整性都在 CPU 封装边界内受到保护。

英特尔已提议创建一个 Barbican 加密插件,该插件可以在该安全边界内执行密钥加密操作,并将加密的密钥存储在 Barbican 数据库中。

这种安全功能和相对较低的成本将使此插件成为一个有吸引力的解决方案。但是,Barbican 插件的代码和对 Barbican API 的更改尚未提交给开源 Barbican 项目。

3 个外部 KMS 插件

KMIP

与 PKCS#11 插件一样,KMIP 插件使用 HSM 来帮助保护密钥。不同之处在于 KMIP 插件的加密密钥直接存储在 HSM 上。这提供了更强的安全态势,同时可能会降低性能和可扩展性并增加成本。

Hashicorp Vault

Vault 是 Hashicorp 赞助的开源密钥管理工具。由于其简单的开发设置和灵活的配置,它在过去几年中变得流行起来。存在多个身份验证插件(尽管不适用于 keystone 令牌)以及多个存储后端。

Barbican vault 插件是在 OpenStack Rocky 周期(2018 年 8 月)中引入的,并在 Barbican 上游 gate 中进行例行测试。它允许 Barbican 将其密钥存储在 Vault 内部。Vault 主密钥用于加密密钥,并且易于进行密钥轮换。

但是,该插件尚未完全准备好用于生产环境。最大的缺陷是身份验证是使用 Vault 根用户完成的(这不是推荐的安全实践),并且所有密钥都未分类地存储在顶层。Stein 正在努力解决这些缺陷。

Dogtag

Dogtag 密钥恢复机构 (KRA) 是 FreeIPA 的一个组件,用于存储密钥,主密钥位于 NSS 数据库或 HSM 中。Barbican 将密钥直接存储在 Dogtag KRA 中。Dogtag 提供 FIPS 和其他认证,对于已经部署 FreeIPA 的部署者来说,可能是一个不错的选择。

选择正确密钥存储的技巧

选择 Barbican 后端的密钥存储是一个重要的决定,它将影响您的密钥管理系统的安全性、性能、可扩展性和成本。有许多因素需要考虑,这些因素将特定于您的需求。

具有法规要求或现有 HSM 的用户将倾向于 KMIP 或 PKCS#11 插件。预算紧张的用户将密切关注纯软件选项。那些有高性能需求的人将关注加密插件。

幸运的是,Barbican 支持多个插件,如果您的需求在以后发生变化,这可能会很有用。它还可以允许具有不同要求的不同密钥由不同的插件存储。 


Ade Lee 和 Dave McCowan 将在 11 月 13 日至 15 日在柏林举行的 OpenStack 峰会上展示 您的密钥是否安全?

User profile image.
Ade 在 Red Hat 工作,多年来一直参与各种安全和 OpenStack 项目(Dogtag、FreeIPA、Barbican、TripleO)。他是现任 Barbican PTL。

评论已关闭。

© . All rights reserved.