宣布推出 AWS KMS External Key Store (XKS)



我很高兴地宣布推出 AWS Key Management Service (AWS KMS) External Key Store。根据监管要求而在本地或 AWS 云之外存储和使用加密密钥的客户现在可以如此操作。这项新功能允许您将 AWS KMS 客户托管密钥存储在于本地或任何所选位置运行的硬件安全模块 (HSM) 上。

在较高的层面上，AWS KMS 会转发 API 调用以安全地与您的 HSM 通信。您的密钥材料永远不会离开 HSM。此解决方案允许您针对支持 AWS KMS 客户托管密钥的绝大多数 AWS 服务使用外部密钥加密数据，这些服务包括 Amazon EBS、AWS Lambda、Amazon S3、Amazon DynamoDB 以及其他 100 多项服务。无需更改现有 AWS 服务的配置参数或代码。

这可以帮助您解锁一小部分受监管工作负载的使用案例，在这些工作负载中，加密密钥应存储在 AWS 数据中心之外并予以使用。但是，这是您运营基于云的基础设施的重大方式变更，也是责任共担模式的重大转变。我们预计只有一小部分客户能够启用此功能。在大多数情况下，AWS KMS External Key Store 对受保护数据可用性、性能和低延迟操作带来的额外运营负担和更严重风险将超过其形成的安全优势。

接下来深入探究细节。

密钥管理和加密的简要回顾
配置 AWS 服务以加密静态数据时，该服务会向 AWS KMS 请求唯一的加密密钥。我们称之为数据加密密钥。为了保护数据加密密钥，该服务还请求 AWS KMS 使用特定的 KMS 客户托管密钥（也称为根密钥）对该密钥进行加密。一旦加密，数据密钥就可以安全地与它们保护的数据一起存储。这种模式称为信封加密。可以想象一个信封，其中既包含加密数据，又包含用于加密这些数据的加密密钥。

但是，我们如何保护根密钥呢？ 保护根密钥至关重要，因为它可对其加密的所有数据密钥进行解密。

根密钥材料安全地生成并存储在硬件安全模块中，硬件安全模块是专为存储机密而设计的硬件。它具有防篡改功能，其设计使密钥材料永远不会以纯文本形式离开安全硬件。AWS KMS 使用经过 NIST 140-2 加密模块认证计划认证的 HSM。

您可以选择创建与数据分类相关的根密钥，或者创建唯一的根密钥来保护不同的 AWS 服务，还可以按项目标签创建或与每个数据所有者相关联的根密钥，并且每个根密钥对于每个 AWS 区域都是唯一的。

当您亲自创建和管理根密钥时，AWS KMS 就会将根密钥称为客户托管密钥。当这些密钥是代表加密数据的 AWS 服务创建时，它们称为 AWS 托管式密钥，这些服务包括 Amazon Elastic Block Store (Amazon EBS)、Amazon Simple Storage Service (Amazon S3)、Amazon Relational Database Service (RDS) 或 Amazon DynamoDB。为简单起见，我们将它们称为 KMS 密钥。这些是根密钥，它们永远不会离开安全的 HSM 环境。所有 KMS 加密和解密操作都在 HSM 的安全环境中进行。

XKS 代理解决方案
配置 AWS KMS External Key Store (XKS) 时，您要用新的外部信任根替换 KMS 密钥层次结构。所有根密钥现在均生成并存储在您提供和操作的 HSM 中。当 AWS KMS 需要加密或解密数据密钥时，它会将请求转发到供应商特定的 HSM。

所有 AWS KMS 与外部 HSM 的交互均由外部密钥库代理（XKS 代理）调解，该代理由您提供并由您管理。代理将通用 AWS KMS 请求转换为供应商特定 HSM 可以理解的格式。

XKS 与之通信的 HSM 不位于 AWS 数据中心。

为了向客户提供广泛的外部密钥管理器选项，AWS KMS 根据多家 HSM、密钥管理和集成服务提供商（包括Atos、Entrust、Fortanix、HashiCorp、Salesforce、Thales 和 T-Systems）的反馈制定了 XKS 规格。有关可用性、定价以及如何将 XKS 与这些供应商的解决方案结合使用的信息，请直接咨询供应商。

此外，我们还将提供可与 SoftHSM 或任何支持 PKCS #11 接口的 HSM 结合使用的 XKS 代理参考实现。此参考实现 XKS 代理可以作为容器运行，在 Rust 中构建，并将在未来几周内通过 GitHub 提供。

完成 XKS 代理和 HSM 的设置后，即可在 KMS 中创建相应的外部密钥库资源。您可以在 HSM 中创建密钥并将这些密钥映射到 KMS 中的外部密钥库资源。然后，可以将这些密钥用于支持客户密钥的 AWS 服务或自己的应用程序以加密您的数据。

AWS KMS 向 XKS 代理发出的每个请求都包含元数据，例如调用 KMS API 的 AWS 主体和 KMS 密钥 ARN。除了 AWS 账户中的 IAM 策略已经提供的授权控制之外，这还可让您在 XKS 代理级别上额外创建一层授权控制。

XKS 代理实际上是由您控制的终止开关。关闭 XKS 代理后，所有使用 XKS 密钥的新加密和解密操作都将停止运行。已经为您的某个资源在内存中预置数据密钥的 AWS 服务将继续正常运行，直到您停用该资源或服务密钥缓存到期为止。例如，启用存储桶密钥后，Amazon S3 会将数据密钥缓存几分钟。

责任共担的转变
根据标准云操作程序，AWS 负责维护云基础设施的运营状态。这包括但不限于修补系统、监控网络、设计高可用性系统等。

当您选择使用 XKS 时，责任共担模型就发生了根本性的转变。在此模型下，您负责保持 XKS 代理和 HSM 的运营状态。它们不仅必须安全且高度可用，还必须调整规模以维持预期的 AWS KMS 请求数量。这适用于所有涉及的组件：实体设施、电源、冷却系统、网络、服务器、操作系统等。

根据您的工作负载，AWS KMS 操作对于运营需要加密云中静态数据的服务可能至关重要。依赖 AWS KMS 正常运营的典型服务包括 Amazon Elastic Block Store (Amazon EBS)、Lambda、Amazon S3、Amazon RDS、DynamoDB 等。换句话说，这意味着当您负责的基础设施部分不可用或长时间延迟（通常超过 250 毫秒）时，AWS KMS 将无法运营，从而导致您向其他 AWS 服务提出的请求失败。您将无法启动 EC2 实例，调用 Lambda 函数，从 S3 存储或检索对象，也无法连接到您的 RDS 或 DynamoDB 数据库或任何其他依赖存储在所管理基础设施中的 AWS KMS XKS 密钥的服务。

正如在准备这篇博客文章时参与 XKS 设计的一位产品经理告诉我的那样，“您正在通过一条非常脆弱的道路铺设自己的氧气隧道。”

我们建议您仅在有需要于 AWS 数据中心之外维护加密密钥的监管或合规需求时，才使用此功能。仅为支持最关键工作负载的根密钥启用 XKS。并非所有数据分类类别都需要在外部存储根密钥。将 XKS 保护的数据集保持在最低限度以满足您的监管要求，其余数据则继续使用 AWS KMS 客户托管密钥（完全在您的控制之下）。

一些外部密钥库不满足合规性要求的客户过去也曾要求使用此功能，但是当这些客户意识到类似 XKS 的解决方案所带来的安全优势并未超过其产生的运营成本负担之后，他们最终都接受了基于云的密钥存储和使用的现有 AWS KMS 选项之一。

有哪些变化，哪些方面又保持不变？
我试着为您总结这些变化。

开放规格
对于严格监管的工作负载，我们正在开发具有开放的互操作性规格的 XKS。我们不仅与之前提到的主要供应商合作，还开设了一个包含以下材料的 GitHub 存储库：

• XKS 代理 API 规格。其中描述了 KMS 发送给 XKS 代理的通用请求的格式及其期望的响应。任何 HSM 供应商都可以使用该规格为其 HSM 创建 XKS 代理。
• 实现该规格的 XKS 代理的参考实现。HSM 供应商可以调整此代码，为其 HSM 创建代理。
• XKS 代理测试客户端，该客户端可用于检查 XKS 代理是否符合 XKS 代理 API 规格的要求。

其他供应商，例如 SalesForce，宣布了自己的 XKS 解决方案，可让客户选择自己的密钥管理解决方案并将其插入选择的解决方案中，包括 SalesForce。

定价和可用性
在 AWS KMS 之上免费提供外部密钥库。无论密钥材料存储在 KMS、CloudHSM 上，还是存储在您自己的本地 HSM 上，AWS KMS 每月都会对每个根密钥收取 1 USD 的费用。

有关当前可用 AWS KMS XKS 的区域的完整列表，请访问我们的技术文档。

如果您认为 XKS 可以协助满足监管要求，请查看技术文档和 XKS 常见问题。

— seb