解决安全扩展性：MinIO 企业对象存储密钥管理服务器

在可靠且健壮的存储解决方案领域，MinIO 作为持久层脱颖而出，为组织提供安全、持久且可扩展的存储选项。MinIO 通常负责存储关键任务数据，在确保高可用性方面扮演着至关重要的角色，有时甚至是在全球范围内。所存储数据的性质，从金融和医疗记录到复杂的產品细节和前沿的 AI/ML 模型，不仅需要弹性，还需要严格的安全措施来防止未经授权的访问和泄露。

MinIO 通过其核心功能来解决这些安全问题，例如细粒度身份和访问管理、对象锁定以及端到端数据加密（静止状态和传输中）。为了保护静止状态下的数据，MinIO 与各种密钥管理系统 (KMS) 无缝集成，包括 HashiCorp Vault、Thales CipherTrust Manager、AWS KMS 和 SecretsManager 等知名选项。这些 KMS 解决方案充当加密密钥的守护者，将它们安全地存储在所保护数据的范围之外。

虽然 MinIO 支持的 KMS 解决方案已经证明了自己的价值，并且被广泛使用，但也出现了一些挑战，尤其是在处理 PB 级甚至 EB 级数据的超大规模存储基础设施的背景下。多年来观察到的局限性（部分由我们的 KES 项目缓解）揭示了集成和维护单独 KMS 解决方案的复杂性。

管理通用 KMS 会带来复杂性，因为它们通常是复杂的分布式系统。平衡安全、合规性和性能的要求将成为一项非凡的任务。另一方面，高性能存储基础设施的健壮性可能需要某些要求，特别是在可用性、响应时间和整体性能方面，而通用的 KMS 解决方案难以满足这些要求。即使它们能满足，也可能容易出现不可靠性、资源消耗过高或成本不断增加。

因此，认识到大规模、高可用性和高性能数据基础设施带来的独特挑战，我们投入了大量资源开发专门针对 MinIO 的 KMS，以满足这些特定需求。MinIO 的 KMS 功能专门提供给我们的 Enterprise Lite 和 Enterprise Plus 客户。

MinIO Enterprise 对象存储 KMS 是一个高可用性 KMS 实现，针对大型存储基础设施（尤其是 MinIO）进行了优化。其设计遵循以下关键目标：

• 可预测的行为：MinIO 的 Enterprise KMS 设计易于管理，使操作人员能够直观地了解其状态。由于其设计更简单，MinIO 的 Enterprise KMS 比类似的解决方案（依赖于更复杂的共识算法，例如 Raft 或 Paxos）更容易操作。
• 高可用性和容错性：在大规模系统的动态环境中，网络或节点故障是不可避免的。为维护而关闭集群很少可行。即使在遇到此类中断时，MinIO 的 Enterprise KMS 仍能确保不间断的可用性，从而减轻可能导致整个存储基础设施瘫痪的级联效应。对于常见的工作负载，KMS 提供尽可能高的可用性。具体来说，即使集群中除一个节点外所有节点都不可用，仍然可以处理任何加密、解密或数据密钥生成请求。
• 可扩展性：虽然数据量通常只会增加，但大型存储系统上的负载可能会随时间而发生显著变化。MinIO 的 Enterprise KMS 支持动态集群调整大小，并且可以在任何时候添加或删除节点，而不会造成停机。
• 一致性和高性能：在大规模存储基础设施上，数据始终处于写入和读取状态。Enterprise KMS 的响应能力直接影响存储系统的整体效率和速度。KMS 节点在处理存储系统发出的此类请求时无需协调。因此，KMS 集群的性能随着节点数量的增加而线性增长。此外，MinIO 的 Enterprise KMS 支持请求流水线，每秒每节点可以处理数十万个加密操作。
• 多租户：大型存储基础设施通常由整个组织中的许多应用程序和团队使用。将团队和组隔离到各自的命名空间是核心要求。MinIO 的 Enterprise KMS 支持以飞地的形式进行命名空间。每个租户可以分配自己的飞地，该飞地与 KMS 集群上的所有其他飞地完全独立且隔离。

KMS 可以通过 Enterprise Console 或命令行进行配置。

现在，让我们深入了解 KMS 的高级概述，首先考察其基本安全模型，然后深入了解集群架构和管理，最后介绍其与 MinIO 的无缝集成。

安全模型

KMS 将其基本信任建立在（硬件）安全模块 (HSM) 上，该模块在密封和解除密封 KMS 根加密密钥中起着至关重要的作用。HSM 的职责扩展到保护 KMS 的完整性，允许解除密封其加密的磁盘状态，并促进 KMS 集群内节点之间的通信。

但是，HSM 更多是一个概念，而不一定是实际的硬件设备。例如，可以使用云 HSM（例如 AWS CloudHSM）或软件 HSM 来代替物理设备。KMS 实施了自己的软件 HSM，优先考虑用户友好的实施和操作的简单性。

在每个 MinIO KMS 服务器上设置单个环境变量就足以开始使用。例如：

export MINIO_KMS_HSM_KEY=hsm:aes256:vZ0DeGvwlb/KHwIfi8+c7/8ZHjweHKVL0WNrRc3+FxQ=

在单个 KMS 服务器上，所有数据都驻留在内存中或加密存储在磁盘上。但是，在运行分布式 KMS 集群时，节点必须交换消息。为了确保安全的节点间通信，KMS 使用相互 TLS，使用直接从 HSM 派生的密钥。因此，只有能够访问相同 HSM 的节点（例如，共享相同的软件 HSM 密钥）才能通过节点间 API 建立通信。这样，HSM 同时充当整个系统的信任守护者和建立节点间通信信任的基础。

集群管理

KMS 集群是一个分布式系统，它使用单领导者同步复制将状态更改传播到所有集群节点，并根据投票选举领导者。从概念上讲，它与 Raft 共识协议非常相似，但并不完全相同。它仍然是严格一致的，并为所有事件提供线性化。

但是，通过查看几个例子，可能更容易理解 KMS 的工作原理。操作 KMS 集群不需要密码学或分布式系统的专业知识。

因此，让我们更加实际地操作一下，感受一下 KMS 集群的行为。在最简单的情况下，KMS 集群由单个节点组成。启动新的 KMS 服务器时，它会自动创建一个新的单节点集群。例如：

export MINIO_KMS_HSM_KEY=hsm:aes256:vZ0DeGvwlb/KHwIfi8+c7/8ZHjweHKVL0WNrRc3+FxQ=

=

minkms server --addr :7373 /tmp/kms0

我们可以使用自动生成的 API 密钥以集群管理员身份对集群进行身份验证，并列出其所有节点。

export MINIO_KMS_API_KEY=k1:ThyYZWXUjlSOL-l5hldSgO49oQPWZezVZFU4aiejVoU

minkms ls

现在，我们已经启动并运行了第一个 KMS 集群，让我们创建一个新的飞地，用于存放将来要使用的主密钥。如前所述，飞地实现命名空间。一个飞地中的所有密钥都与其他飞地中的所有其他密钥完全隔离。

minkms add-enclave enclave-1

在飞地内，我们可以创建第一个主密钥并检查其状态。

minkms add-key --enclave enclave-1 key-1

minkms stat-key --enclave enclave-1 key-1

到目前为止，我们只在操作一台 KMS 服务器。现在，让我们将单节点集群从一个节点扩展到三个节点。为此，我们将启动另外两台 KMS 服务器，为简单起见，它们位于同一台机器上。

首先是第 2 台服务器：

export MINIO_KMS_HSM_KEY=hsm:aes256:vZ0DeGvwlb/KHwIfi8+c7/8ZHjweHKVL0WNrRc3+FxQ=minkms server --addr :7374 /tmp/kms1

然后是第 3 台服务器：

export MINIO_KMS_HSM_KEY=hsm:aes256:vZ0DeGvwlb/KHwIfi8+c7/8ZHjweHKVL0WNrRc3+FxQ=minkms server --addr :7375 /tmp/kms2

现在，我们可以返回到最初的 KMS 单节点集群，并通过将另外两台服务器添加到其中来扩展它。为此，我们将使用服务器的 IP 地址和端口号（或 DNS 名称和端口号）。这里使用的是 192.168.188.79，但在您的机器上可能有所不同。请使用服务器在启动时在控制台上打印的 IP 和端口号。

minkms add 192.168.188.79:7374

minkms add 192.168.188.79:7375

当我们再次查询 KMS 集群的状态时，它会告诉我们它包含三个节点 - 初始服务器以及我们刚刚添加的另外两个服务器。

minkms ls

现在，我们已经将多个节点加入了一个集群，所有节点是否都具有相同的状态？例如，节点 1 是否也能提供关于我们之前在飞地 enclave-1 中创建的密钥 key-1 的状态信息？我们可以直接询问节点以找出答案。此步骤再次取决于您本地网络中使用的 IP 地址。请根据实际情况进行调整。

MINIO_KMS_SERVER=192.168.188.79:7374 minkms stat-key --enclave enclave-1 key-1

当节点加入集群时，它们会接收整个 KMS 状态，并且只有在同步后才会被视为集群的一部分。因此，集群中的所有节点都是彼此的副本，并且保存相同的数据。不存在部分状态，也不存在后台的静默同步。这是 KMS 集群高度可预测的原因之一。它们不会不同步。

例如，我们可以关闭三台 KMS 服务器中的两台。从技术上讲，我们可以关闭任意两台，但我们关闭节点 1 和节点 2。因此，我们不需要调整 MINIO_KMS_SERVER，以确保我们与剩余的节点进行通信。完成后，我们可以再次列出集群节点。

minkms ls

正如预期的那样，三个节点中有两个不可用。但是，我们仍然可以查询剩余节点上的密钥 key-1 的状态。

minkms stat-key --enclave enclave-1 key-1

您可能不会感到惊讶，服务器响应了预期的输出。但是，其他 KMS 实现，例如使用 Raft 作为底层共识算法的实现，将无法响应，至少在不容忍陈旧数据并放弃强一致性的情况下是无法响应的。一个由三个节点组成的 Raft 集群，其中两个节点处于停机状态，通常被认为不可用，无法处理**任何**请求。关键区别在于，KMS 可以在不削弱一致性保证的情况下，对所有**读取**请求保持可用。幸运的是，大多数大型存储系统使用的 KMS 操作不需要对 KMS 集群进行状态更改，因此可以被认为是“只读”操作。因此，KMS 容错模型与大型存储系统对高可用性和可靠性 KMS 的期望相匹配。这不是巧合。

但是，KMS 无法绕过 CAP 定理，也不会绕过 CAP 定理。尝试更改剩余节点的状态，例如创建第二个密钥，将失败。服务器无法接受写入操作，因为这可能会导致数据不同步。因此，我们必须恢复剩余的两个节点才能创建新的主密钥。

尽管如此，重要的是要认识到，KMS 在 CAP 定理的范围内运行，并且无法绕过其固有的原则。任何尝试更改剩余节点的状态，例如创建第二个密钥，都将失败。服务器本质上被限制接受写入操作，以防止潜在的差异和状态不一致。在实践中，这意味着在创建新的主密钥之前，必须重新启动剩余的两个节点以在集群中建立写入仲裁。

摘要

此新功能同时提供给我们的企业版和企业版 Lite 客户，它减少了攻击面，同时解决了与数十亿个加密密钥相关的性能挑战。MinIO 企业版对象存储 KMS 即使在每个节点每秒数十万次加密操作的规模下也能提供可预测的行为，同时提供高可用性和容错能力。此外，KMS 还支持多租户，使每个租户都可以被分配到自己的独立区域，该区域与 KMS 集群上的所有其他区域完全独立且隔离。

如果您想深入了解任何企业功能，请发送电子邮件至 hello@min.io.