KMIP:工作原理、适用场景及Infisical的实现方式

infisical 发布于 2026-07-25 阅读 25

KMIP(密钥管理互操作协议)是一种开放标准,通过统一语言让不同厂商的系统集中管理密钥,避免碎片化。文章介绍了KMIP的工作原理(基于mTLS,端口5696)、核心操作(创建、获取、注册等),并与PKCS11进行了对比:PKCS11是单应用与HSM的本地接口,KMIP是网络级集中管理协议。适用场景包括多供应商基础设施、合规要求、摆脱供应商锁定和大量密钥管理;不适用单云环境和小团队。最后介绍了Infisical KMS如何以无状态代理方式实现KMIP,支持加密、签名、批量导入导出、CSR签名和K8s etcd加密,并提供了部署命令。

博客图片

轮换一个被泄露的密钥本应只需几分钟,但在企业级规模下,可能需要数天。密钥并非只存在于一个地方,而是分布在存储阵列、数据库、备份系统和对象存储中,每个系统由不同厂商管理,拥有不同的 API 和管理门户。因此,轮换一个密钥意味着要在四个不共享变更记录的系统里重复四次相同的工作。漏掉一个,要么留下一个已泄露的密钥继续存活,要么导致某个系统离线。当审计员要求提供所有密钥及其操作记录的单一清单时,没有人能拿得出来。

这正是密钥管理互操作协议(KMIP)旨在消除的痛点。KMIP 为每个系统提供了一种共同的语言来请求、创建和管理密钥,从而让一个统一的管理器能够服务于所有系统。

什么是 KMIP,它如何工作?

在 KMIP 出现之前,每个密钥管理厂商都有自己的 API,其他系统无法与之连接。如果你的存储阵列使用一家厂商的密钥管理器加密,而 Oracle 数据库使用另一家的,那么你就拥有了两个互不相通的独立密钥管理系统。没有一个统一控制台、统一的策略,也没有统一的谁访问了什么的记录。无法进行任何集中管理,因此每次密钥操作、轮换、审计、访问审查都必须做两次,每个系统一次。在大企业中,这个情况会成倍放大:几十个系统各自有孤立的密钥管理器,当审计员要求提供所有密钥及其接触记录的单一账目时,根本无法提供。

KMIP 是一个开放标准,为每个系统提供了一种共同的语言来请求、创建和管理密钥。如果双方都支持 KMIP,它们就能协同工作。两端的厂商就不再重要了。

没有 KMIP 时,每个系统自行管理密钥。有了 KMIP,它们共享同一个管理器。

图 1. 没有 KMIP 时,每个系统自行管理密钥。有了 KMIP,它们共享同一个管理器。

以一个常规任务为例:你的策略要求每个加密密钥每 90 天轮换一次。以下是双方各自的情况。

没有 KMIP 时,密钥在每个系统中独立存在。你登录存储阵列的控制台进行轮换,然后是数据库的,接着是备份系统的。三个系统,三个控制台,三次出错的机会。如果你轮换了两个却漏掉了第三个,那个系统将沿用旧密钥,而其他系统已经更新,并且没有任何机制告诉你它们已经脱节。只有当解密失败时你才会发现问题。

有了 KMIP,你只需在密钥管理器中设置一次轮换策略。它会将变更推送到所有支持该协议的系统。一次操作,在一个地方确认生效,一份日志记录下所有三个系统上的变更。90 天的轮换不再是三个系统的琐事,而只是一个配置项。

KMIP 如何工作

KMIP 的默认端口是 5696。它是一个基于 TCP 运行在该端口上的客户端-服务器协议,通过 mTLS(双向 TLS)确保安全。由于密钥是这条通道上传输的内容,两端都必须证明身份:服务器只为它信任的客户端提供服务,而每个客户端也必须确认正在连接的是真正的密钥管理器,而不是冒充者。普通 TLS 只认证服务器,mTLS 则双向认证,这正是此类服务间信任所必需的。

核心操作涵盖了密钥的完整生命周期:Create、Get、Register、Locate、Activate、Revoke、Destroy、Get Attributes 和 Query

操作 功能
Create 在服务器上生成新密钥并存储。
Register 将现有密钥纳入服务器的管理范围。
Locate 根据属性查找密钥,无需知道其 ID。
Get 检索密钥,或请求服务器代为加密/解密数据,使密钥永不离开服务器。
Activate 将密钥标记为可用,使其能够开始保护数据。
Revoke 将密钥从活跃使用中撤出,可能是为了退役或因为密钥已泄露。
Destroy 永久删除密钥材料。
Get Attributes 检索密钥的元数据,而不获取密钥材料本身。
Query 向服务器查询其支持的操作和能力。

应用程序可以请求服务器代为加密或解密数据,而应用程序本身永远看不到密钥。

KMIP 与 PKCS#11 的对比

KMIP 并非该领域唯一的标准,有一个标准经常被提及,值得尽早澄清。如果你在研究 KMIP,几乎肯定会遇到 PKCS#11(公钥密码标准 #11),并且可能想知道是需要其中一个、另一个,还是两者都需要。它们解决的是不同层级的问题。

PKCS#11 是一个低级 API,单个应用程序用它来与加密设备(通常是 HSM,硬件安全模块)通信,通常在同一台机器或同一个网络内。它是一个你需要链接的库。它解决的是“一个应用程序如何与一个设备执行加密操作”的问题。

KMIP 则工作在不同的层级。它是一个网络协议,用于集中管理来自多个厂商的多个系统中的密钥。它解决的是“所有这些系统如何从一个地方获取和管理密钥”的问题。

在实践中,许多企业两者都运行。PKCS#11 处理特定应用程序或 HSM 内部的本地加密操作。KMIP 则处理整个集群的集中生命周期管理、分发和审计。它们是互补的,而非竞争关系。如果你发现自己需要在它们之间做选择,通常意味着问题本身就不对,因为它们处于同一技术栈的不同层级。

PKCS#11 是一个应用程序对一个设备,本地化。

KMIP 是多个系统对一个管理器,通过网络。

图 2. PKCS#11 是一个应用程序对一个设备,本地化。KMIP 是多个系统对一个管理器,通过网络。

何时使用 KMIP

KMIP 并非每个团队都需要。使用它意味着要运行一个支持该协议的密钥管理器,并将现有系统指向它,而不是指向每个厂商的内置工具。只有在以下几种特定条件下才值得这样做。

你的基础设施涉及多家厂商。

当你的存储阵列、数据库和备份系统各自拥有自己的密钥管理器时,每个常规任务(轮换、访问审查、撤销)都需要在每个系统中单独进行。将它们全部指向一个统一的 KMIP 密钥管理器,就能将三个工作流合并为一个。

合规要求迫使你这样做。

PCI-DSS、HIPAA、FedRAMP 和 FIPS 140-2 都要求有文档记录且可审计的密钥管理。当 PCI-DSS 的 QSA(合格安全评估师)要求提供轮换记录时,从一个密钥管理器导出单一日志远比从多个厂商门户导出并祈祷它们能对上要容易得多。

你希望摆脱对单一厂商产品的绑定。

大多数存储和数据库厂商既提供自己的密钥管理工具,也提供 KMIP 集成。使用 KMIP 可以让你将所有密钥管理集中到一个地方,而不是每个厂商都运行一个独立的密钥管理器。更换存储阵列或增加新系统时,密钥管理层保持不变。

你需要跟踪的密钥数量太多,无法手动管理。

少量系统上的几个密钥可以手动管理。当数量增长到数百个、分布在数十个系统上时,手动管理就不再可行。KMIP 密钥管理器为你提供了一个地方来查找任何密钥、查看其历史记录,并强制执行全局轮换。

何时不需要 KMIP

所有资源都在一个云平台上。

你的云提供商自身的原生密钥管理器与该平台上的所有服务原生集成,几乎不需要运维开销。它可能不支持 KMIP,但在单一云环境中你并不需要它,因为原生工具已经覆盖了所有与加密数据相关的内容。只有当某个提供商工具的覆盖范围结束,而你的其他基础设施(另一个云或你自己的数据中心)开始时,KMIP 才开始变得重要。

你是小团队,基础设施简单,没有合规负担。

如果你不需要在多个系统之间管理加密密钥,也没有 PCI-DSS、HIPAA 或 FedRAMP 的合规义务,那么 KMIP 很可能超出了你的需求。它的复杂性在跨混合基础设施的大规模部署和监管压力下才体现价值。没有这些条件,它就是一种负担。

KMIP 的复杂性在跨混合基础设施的大规模部署和监管压力下才体现价值。没有这些条件,它就是你不需要的额外协议。

Infisical 如何实现 KMIP

Infisical 提供了支持 KMIP 的专用 KMS:一个完整的密钥管理系统,涵盖:

  • 加密/解密操作:用于应用程序数据,如数据库字段或文件,这些数据需要在静态状态下保持加密,而应用程序无需直接处理密钥。
  • 签名/验证数据:用于代码签名或文档签名等场景,需要证明内容未被篡改。
  • 批量导入和导出密钥:用于从其他系统迁移现有密钥材料,或导出用于备份和灾难恢复。
  • 基于 CSR(证书签名请求)的 KMIP 客户端签名:用于签发 mTLS 客户端证书,KMIP 客户端(存储阵列、数据库、如 iDRAC 管理的服务器等硬件设备)需要使用这些证书向服务器进行身份验证。
  • 加密 Kubernetes etcd 中的静态数据:使得 Kubernetes Secrets 在写入集群的数据存储之前就被加密,而不是以明文形式存储。

如果你的安全策略要求,你可以使用自己的 HSM 来存储根密钥。Infisical 的核心是开源的,代码库可在 GitHub 上获取并可审计,受监管行业的团队可以自行托管整个平台,无需依赖 Infisical 的云服务。

具体来说,KMIP 支持是自托管核心之上的企业版许可功能,因此使用它仍需要购买许可,但部署本身(包括 KMIP 服务器)完全保留在你的基础设施内。对于有数据主权要求的用户来说,这就是可用工具与不可行方案之间的区别。

从机制上看,KMIP 分为客户端和服务器两个角色。客户端是使用密钥的系统:存储阵列、MySQL 和 MongoDB 等数据库、备份平台以及虚拟机管理程序。Infisical 充当服务器:它通过 Infisical CLI 将 KMIP 部署为轻量级、无状态代理。该代理位于你的基础设施上,监听端口 5696,并将密钥操作转发给后端的 Infisical KMS,由后者处理完整的密钥生命周期。代理本身不保存任何密钥,只转发请求,不干涉实际处理。

Infisical 将 KMIP 作为无状态代理运行。客户端通过 mTLS 连接,代理将请求转发给 KMS。密钥不保存在代理上。

图 4. Infisical 将 KMIP 作为无状态代理运行。客户端通过 mTLS 连接,代理将请求转发给 KMS。密钥不保存在代理上。

在开始之前,需要打开两条网络路径:KMIP 客户端到服务器(端口 5696),以及服务器到你的 Infisical 实例(通过 HTTPS,端口 443)。

如果你已经在使用 Infisical 管理密钥或证书,那么 KMIP 只是同一平台上的另一个功能:同一个登录入口,相同的访问控制,相同的审计日志,无需搭建新系统。它也可以在你已有的基础设施之上运行,可对接你自己的 HSM,或与现有的兼容 KMIP 的密钥管理器并存,因此采用它不一定意味着要替换你当前的配置。

入门指南

在 Infisical 仪表板的 Infisical KMS > KMIP Servers 下创建一个 KMIP 服务器。创建后,Infisical 会为你生成一个部署命令。

在 Infisical 仪表板中创建 KMIP 服务器

安装 CLI,在任何能访问你 Infisical 实例的机器上运行该命令,服务器即可启动:

infisical kmip start my-kmip-server \
  --enroll-method=token \
  --token=<enrollment-token> \
  --listen-address="0.0.0.0:5696" \
  --domain=https://app.infisical.com

在生产环境的 Linux 上,将其安装为 systemd 服务,使其随系统启动:

sudo infisical kmip systemd install my-kmip-server \
  --enroll-method=token \
  --token=<enrollment-token> \
  --listen-address="0.0.0.0:5696" \
  --domain=https://app.infisical.com

sudo systemctl start infisical-kmip

然后,在 Infisical 仪表板中注册你的 KMIP 客户端,并为每个客户端生成证书。

在 Infisical 仪表板中注册 KMIP 客户端并生成证书

你的客户端应用程序使用这些证书在端口 5696 上进行连接。

总结

KMIP 通过为每个系统提供一种共同的语言来请求和管理密钥,从而解决了密钥管理碎片化的问题。

Infisical KMS 是一个完整的、专用且支持 KMIP 的密钥管理系统,自带加密、签名、批量密钥操作以及 KMIP 服务器本身,可在数分钟内完成部署。如果你已经在使用 Infisical 管理密钥或证书,那么它只是同一平台上的另一个功能,而不是需要单独搭建的独立产品,但这一切都不依赖于这一点。

如果你的加密系统涉及多个厂商,或者你受到要求中心化、可审计密钥管理的法规约束,或者你想脱离厂商自有的密钥工具,那么 KMIP 是正确的选择,而 Infisical 是运行它的途径之一。

Finn

Infisical 技术内容营销人员

LinkedIn

  • 原文链接: infisical.com/blog/kmip...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论