Azure Key Vault 核心概念

说实话，刚开始从 AWS KMS 切到 Azure Key Vault 的时候，我最大的困惑就是——怎么概念名字全变了？

KMS 里一个 CMK 就解决了大部分密钥操作，Azure 这边呢，保管库、HSM、权限模型……一套新术语。

但我用了一段时间后发现，Azure 的结构其实更贴近企业级安全架构。你只要能把这几个核心概念理清，迁移的坑就能提前绕开大半。

我个人习惯把 Azure Key Vault 理解成「一个安全的玻璃柜」。柜子本身是保管库，柜子里放的是密钥和机密，谁可以开门、能拿哪把钥匙，由 RBAC 决定。至于严格程度，你可以选普通柜还是防爆柜——对应标准 Key Vault 和托管 HSM。

密钥保管库（Key Vault）

Azure Key Vault 本质上是一个租户级的托管密钥服务。每个保管库（Vault）就是一个独立的安全容器，里面保存三类东西：密钥（Key）、机密（Secret）、证书（Certificate）。

和 AWS KMS 的 CMK 相比有什么区别？KMS 中你创建的是主密钥（CMK），所有加密操作都依赖它。Azure 这边，保管库更像是 CMK 的「家」——密钥本身还是密钥，但保管库决定了这个家在哪里、怎么保护、谁有权进门。

举个例子：我在项目中遇到过客户把生产密钥和测试密钥塞到同一个保管库，理由是方便管理。结果上线时 RBAC 配置出错，测试人员误删了生产密钥。我后来强烈建议：每个环境独立建一个保管库，不要图省事。

关键特性几个：

• 软删除：删除操作不是立刻销毁，密钥进入软删除状态，可恢复。默认保留 90 天。
• 清除保护：一旦开启，即使软删除期间也无法强制清除，必须等保留期结束。
• 网络隔离：支持 VNet 服务端点和私有端点，可以完全在专有网络内访问。

托管 HSM（Managed HSM）

标准 Key Vault 已经够用了？不一定。如果你的合规要求是 FIPS 140-2 Level 3，或者你需要硬件隔离的 HSMs，那就得上托管 HSM。

托管 HSM 本质上是一个单租户、FIPS 140-2 Level 3 验证的硬件安全模块池。你完全控制 HSM 的管理权限，Azure 管理员都无法访问你的密钥材料。

和 AWS 对比：你可以把标准 Key Vault 看作 KMS，托管 HSM 相当于 AWS CloudHSM + KMS 自定义密钥存储 的结合体。区别在于 CloudHSM 你得自己管理 HSMs，Azure 的托管 HSM 是 Azure 负责硬件维护，但你还是拥有所有密钥的完整控制权。

我记得有一次金融客户过 PCI DSS 审计，审计方要求密钥必须在专用硬件中产生且不允许云厂商介入。当时标准 Key Vault 不能满足，我就推荐了托管 HSM。配置完成后审计一次通过。

使用注意：

• 托管 HSM 的 SLA 是 99.99%，但成本是标准 Key Vault 的几倍。
• 每个托管 HSM 实例自带一个内置的 RBAC 模型，权限和标准 Key Vault 的 RBAC 是分开管理的。
• 密钥操作性能更高，因为所有加密都在专用 HSM 芯片内完成。

密钥版本管理

在 Azure Key Vault 里，每个密钥实际上是一个逻辑实体，背后可以有多个版本。每当你更新一个密钥（比如轮换），就会自动创建新版本，旧版本仍然保留。

这和 AWS KMS 的自动轮换机制有点像，但 Azure 更显式。KMS 允许你自动轮换 CMK 并自动使用新版本；Azure 则要求你在应用里通过版本 ID 主动引用最新版本，或者用 KeyIdentifier 的 Latest 标记。

版本 ID 格式：https://myvault.vault.azure.net/keys/mykey/{version}。如果你不指定版本，默认会用最新启用版本。

# PowerShell 示例：获取所有版本
Get-AzKeyVaultKey -VaultName 'myvault' -Name 'mykey' -IncludeVersions

避坑来了——我曾经在生产环境犯过一个低级错误：我把密钥的旧版本手动禁用了，以为不影响新版本。结果发现有个后台服务硬编码了旧版本的完整 URL，直接挂了半小时。所以迁移时一定检查应用里是不是写死了版本 ID，强烈建议用 Latest 再结合定期轮换。

版本管理的几个要点：

• 每个版本可以有独立的状态：启用、禁用、过期。
• 可以设置过期日期，自动让密钥到期作废。
• 版本数量没有硬限制，但建议定期清理过期版本，避免存储开销。

RBAC 权限

Azure Key Vault 有两种权限模型：Vault 访问策略（经典）和 Azure RBAC（推荐）。

Vault 访问策略是从早期版本继承下来的，你在保管库级别为每个用户/服务主体单独设置密钥、机密、证书的权限。管理起来比较繁琐，尤其是当你跨多个保管库时。

RBAC 是 Azure 统一的授权模型，你可以在订阅、资源组或保管库级别分配角色。权限粒度更细，而且和 Azure 其他服务的权限管理一致。

我个人倾向直接用 RBAC。为什么？因为审计方便。有一次客户需要做权限合规审查，我用 RBAC 导出角色分配 CSV，几分钟就搞定了。如果用 Vault 访问策略，得一个个保管库里翻，头大。

关键的内置角色：

角色名称	作用域	典型用途
Key Vault Administrator	管理控制平面	创建/删除保管库，配置网络防火墙
Key Vault Crypto Officer	数据平面（密钥）	创建、轮换、导入密钥
Key Vault Crypto User	数据平面（密钥）	只使用密钥进行加密/解密
Key Vault Secrets Officer	数据平面（机密）	管理机密（读写）
Key Vault Secrets User	数据平面（机密）	只读机密

迁移时要注意：KMS 的权限是 IAM 策略直接附着在密钥上；Azure 这边则是通过 RBAC 角色分配在保管库或资源组上。你需要把每个 IAM 策略里的 key 操作映射到对应的 RBAC 角色上。