1、Azure Key Vault 概述

什么是 Key Vault

说白了，Azure Key Vault 就是一个托管在云上的保险柜。专门用来存三类敏感信息：加密密钥、机密（比如数据库连接串、API ）和证书。你想想看，传统做法是把这些信息写在配置文件里，甚至硬编码到代码里——出过事的人都知道，一旦泄露就是灾难。

我个人习惯，只要项目上云，第一件事就是搭 Key Vault。它跟 Azure AD 深度集成，谁可以访问、能访问到什么级别，全用 RBAC 或访问策略控制。而且所有操作都有审计日志，出问题好追溯。

举个例子。我曾经遇到一个客户，他们把存储账户的密钥直接写在 App Service 的应用设置里。后来一个实习生不小心把设置导出到了公开的 GitHub 仓库…… 嗯，那周他们光轮换密钥就折腾了两天。要是用 Key Vault，只需一个引用 @Microsoft.KeyVault(SecretUri=...)，密钥根本不会出现在代码里。

Vault vs Managed HSM 核心区别

很多朋友刚开始分不清 Vault 和 Managed HSM。我直接说吧——它们都是 Key Vault 家族的，但定位完全不同。

对比维度	Key Vault (标准/Premium)	Managed HSM
硬件安全模块	软硬件混合 (HSA 1.0)	专用 FIPS 140-2 Level 3 硬件
密钥材质保护	软件层面加密 + 硬件辅助	全程在 HSM 内部生成、存储、运算
租户隔离	共享 HSM 分区	独占 HSM 分区，物理隔离
管理权限模型	基于 Azure AD + Vault 访问策略	内置 RBAC + 独立的安全域管理
计费方式	按事务量 + 存储量	按实例预留，价格高一个数量级
典型适用场景	应用配置、证书管理、通用加密	金融、政务、高合规要求的密钥生命周期管理

选哪个？我个人建议：除非有明确的合规要求（比如必须 FIPS 140-2 Level 3 物理隔离），否则优先用标准/Premium Vault。运维成本低得多，而且功能完全够用。Managed HSM 号称“密钥的保险柜中的保险柜”，但配置复杂，安全域一旦搞砸恢复起来极其痛苦——我有个同事曾经手误删了安全域，HSM 直接报废，里面的东西全没了。

典型应用场景

日常中，我见过最多的用法是这几类：

• 应用配置集中管理：数据库连接字符串、第三方 、加密密钥全部存在 Vault，应用在启动时通过托管标识（Managed Identity）拉取。不需要任何配置文件的密文。
• TLS/SSL 证书生命周期管理：Key Vault 可以直接签发证书（与内部 CA 或公共 CA 集成），到期前自动续签，然后推送到 Azure Front Door、App Gateway 或 CDN。我记得有个项目上线当天发现证书过期，就是因为没用这套自动流程，后来加班到凌晨三点手动换证书。
• 数据加密密钥轮换：对于存储服务加密或数据库 TDE，使用 Key Vault 中的密钥，通过 Azure Policy 强制每 90 天轮换一次。客户审计时拿出轮换记录，合规审查一次过。
• CI/CD 管道中的机密注入：在 Azure DevOps 或 GitHub Actions 里通过 Key Vault task 把机密注入到管道变量中，避免将敏感信息写进 YAML 文件。嗯，这里要小心——我曾经看到有人把机密泄露到流水线日志里，就是因为没启用“秘密变量”选项。

Key Vault 整体知识结构

下面这张图帮你理清 Key Vault 的核心概念与关系。

避坑与建议

用 Key Vault 几年下来，有几点我觉得值得特别提醒：

• 不要把 Vault 当作数据库存大量非机密数据。Key Vault 不是专门的高吞吐存储，单个 Vault 有请求速率限制（标准版每秒几千次，Premium 版也有限）。我曾经见过有人把业务配置项全塞进 secrets，一到高峰期就触发限流 429。正确的做法：只放真正的机密，其他配置项用 App Configuration 或 ConfigMap。
• 启用软删除和清除保护。这是默认关闭的。我遇到过一次意外删除整个 Vault 的 case，好在软删除开启后 90 天内可以恢复。如果你要在生产环境用，建议强制启用这两个特性——Azure Policy 可以帮上忙。
• Managed Identity 优先于服务主体。能用托管标识就别创建 SPN，省得管理密钥轮换和证书过期。尤其是在 AKS 或 App Service 上，托管身份那真的是开箱即用。