AWS Secrets Manager 与 KMS:理解两者的区别

infisical 发布于 2026-07-14 阅读 32

本文对比了AWS Secrets Manager和AWS KMS,解释了前者用于存储应用程序凭据(如API密钥、数据库密码),后者用于创建和管理加密密钥。文章指出两者在AWS中协同工作,Secrets Manager默认使用KMS加密。并讨论了何时单独使用各服务,以及何时需要同时使用,例如在合规或多账户环境中。最后,文章介绍了Infisical产品如何作为替代或增强方案,通过同步到Secrets Manager或集成KMS,提供跨云管理和高级功能。

AWS Secrets Manager 与 KMS:理解其区别

发布于 2026 年 7 月 12 日,星期日

博客图片

AWS Secrets Manager 和 AWS Key Management Service (KMS) 听起来相似,但实际截然不同:AWS Secrets Manager 保护应用程序机密,而 KMS 专为加密密钥而构建。

混淆源于这两项服务都旨在保护敏感值,并且对于任何保护 AWS 环境的人来说都是重要的工具。由于 API 密钥和加密密钥都需要保护,这让情况更加复杂。但它们在操作上有所不同。

API 密钥需要在配置文件中始终可用,以便应用程序进行身份验证。而加密密钥则从不离开其服务,用于加密和解密其他数据。AWS Secrets Manager 和 AWS KMS 是独立的服务,这是有原因的,但它们有重叠且相互关联。

AWS Secrets Manager 与 KMS 的区别

AWS Secrets Manager 存储 API 密钥、OAuth Token 以及工作负载用于相互认证的数据库凭证。AWS KMS 创建和管理用于加密其他数据的密钥,包括存储在 Secrets Manager 本身内部的数据。

其区别如下所示:

AWS Secrets Manager AWS KMS
是什么 应用程序凭证的托管存储 用于创建和控制加密密钥的托管服务
存储内容 机密值:数据库凭证、API 密钥 和 Token 用于加密和解密数据的加密密钥
轮换 频繁的定期或临时轮换 密钥不会轮换其保护的数据。AWS 可以按计划轮换密钥材料本身
访问模式 应用程序在运行时获取机密值 应用程序将数据发送到 KMS 进行加密或解密,它们从不获取密钥本身
典型用例 存储应用程序登录所用的数据库密码 加密静态的 S3 对象、EBS 卷或 Secrets Manager 中的机密

任何机密管理器都会加密机密以进行存储。该加密由受 KMS 保护的加密密钥提供支持。加密密钥是密钥管理的基础。如果加密密钥被泄露,其保护的任何机密也会被泄露。这就是加密密钥很少移动且 KMS 受到全面保护的原因。

Secrets Manager 和 KMS 默认已协同工作

Secrets Manager 中的每个机密都使用 KMS 密钥进行加密:默认使用 AWS 托管密钥,或者使用你自己指定的客户托管密钥。在底层,Secrets Manager 使用信封加密。KMS 为机密生成唯一的数据密钥,该数据密钥加密实际的机密值,只有小的、包装后的数据密钥才会通过 KMS API 调用。

何时使用 AWS KMS,何时使用 AWS Secrets Manager

将数据库凭证接入应用程序的工程师会在 Secrets Manager 中创建它,然后继续工作。底层的 KMS 层无需特别关注,因为 AWS 托管密钥会自动处理。大多数工程师从未接触过 KMS,并且对于大多数用例,他们也无需接触。

对于大多数场景和任务,如果你使用 AWS Secrets,可以忽略 AWS KMS,除非你属于负责它的平台/合规/安全/基础设施团队。当事情变得更加复杂时,你可能需要手动操作 KMS:

  • 你需要加密位于 Secrets Manager 之外的对象(S3 存储桶、配置 blob、EBS 卷)
  • 在自己的应用程序代码中构建信封加密。
  • 一项合规要求摆在你面前,表明 AWS 托管密钥不够用,你需要带有自己策略的客户托管密钥。

这意味着问题向下移动了一层,从“安全存储此凭证”转变为“精确控制哪个密钥加密什么内容,以及谁被允许使用它”。

何时单独使用每个服务,以及何时有意同时使用两者

当你使用 AWS Secrets Manager 时,你始终在使用某个版本的 AWS KMS,但你可能很少与之直接交互。但是,当你专门使用它们时,情况有所不同:

  • 仅使用 Secrets Manager 是在你不需要自行管理底层加密时存储和轮换凭证的默认选择。
  • 仅使用 KMS 适用于你正在加密自己的应用程序数据或 Secrets Manager 之外的对象(例如像 Infisical 这样的中心化机密管理器)、在自定义代码中构建信封加密,且无需凭证存储或轮换的情况。
  • 有意同时使用两者是受监管或多账户环境的最终选择:每个环境或每个团队的客户托管密钥、必须与机密的资源策略对齐以进行跨账户访问的密钥策略,以及自身需要权限才能使用 KMS 密钥的基于 Lambda 的轮换函数。

使用趋势往往与组织规模相关:

小型团队默认依赖 AWS 托管密钥,很少打开 KMS 控制台。随着团队成长,客户希望管理自己的密钥以获得更清晰的审计跟踪。对于大型受监管组织,密钥策略和授权成为其自己的治理领域,由专门团队负责。

在机密方面,初创团队通常从在 AWS Secrets Manager 中单独存储静态机密开始。随着工程组织的发展,平台/基础设施/DevOps 团队可能会更深入地使用机密管理器及其功能来管理高级功能和工作流程。

这两个工具都遵循相同的生命周期:它们最初是用户很少花时间在上的必要小工具,最终成为专门团队或工程师的核心工具。

Secrets Manager 和 KMS 都是强大的工具,但它们也有局限性。

当 AWS 原生工具不足时

Secrets Manager 和 KMS 都能很好地解决其各自问题的 AWS 原生版本,但一旦你扩展到 AWS 之外或需要这些云原生服务不提供的特定功能时,两者都会变得不那么理想。一些触发因素会反复出现:

  • 跨越多个云或包含本地系统的基础设施——这与比较 Secrets Manager 与 Parameter Store 时显示的 AWS 原生差距相同。
  • 安全或合规团队希望有一个统一的治理层,而不是每个环境都有单独的工具。
  • 复杂的安防措施,如密钥管理互操作协议 (KMIP)。一旦组织标准化使用 KMIP 进行密钥基础设施,AWS 自身的工具就无法提供完整解决方案,因为 AWS KMS 不支持 KMIP。

AWS 的原生服务也无法提供专用工具的深度功能。AWS Secrets Manager 为机密轮换提供 Lambda 模板,但这些并非 Secrets Manager 原生功能。更高级的功能(如动态机密)需要从头开始构建。

在像 Infisical 这样的工具中,安全不仅仅是另一个服务,而是产品的全部目的。这意味着高级功能开箱即用,它可以运行在任何基础设施上并与任何系统集成。

Infisical 的定位

Infisical 的功能超越了 AWS 自身的服务,提供了更好的开发人员体验和更多功能。它不仅可以替代 AWS Secrets Manager/KMS,而且如果你不想迁移,它甚至可以运行在其之上。

AWS Secrets Manager 同步

Infisical 的 AWS Secrets Manager 同步 允许你将 Infisical 作为机密的真实来源,并自动将它们镜像到 AWS Secrets Manager。当你希望跨多个云(而不仅仅是 AWS)拥有一个统一的地方来管理、审计和轮换机密,同时仍然将值放入 Secrets Manager 以供期望原生读取的服务使用时,可以使用此功能。

AWS KMS 作为外部密钥提供者

Infisical 的企业版拥有自己的内部 KMS,用于加密其存储的数据,但项目可以将该工作交给 AWS KMS 处理,并使用假定角色或访问密钥进行身份验证。这将使该项目的每个加密和解密操作都针对对称的 AWS KMS 密钥运行。

当组织已将其密钥策略标准化为 AWS KMS,并希望 Infisical 受相同的密钥策略和授权管理,且无需创建并行基础设施时,这值得一做。如果不存在现有的 AWS KMS,Infisical 自身的系统更简单,并且无需额外配置。外部 KMS 支持,连同 HSMKMIP,是企业版的功能。

简要总结

对于应用程序用于认证的任何内容,默认使用 Secrets Manager。当你自己加密某些内容时,请使用 KMS。将客户托管密钥、HSM 支持和 KMIP 视为在密钥托管成为明确要求(而非假设)时才会使用的层级。

Finn 头像

Finn

Infisical 技术内容营销人员

linkedin

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

相关文章

0 条评论