Azure Key Vault 基础：核心概念、组件与工作原理
说到云上的密钥管理，Azure Key Vault 是我接触过最多的服务之一。说白了，它就是一个「云保险柜」——你把密钥、密码、证书这类敏感东西扔进去，剩下的访问控制、轮转、审计交给它来管。我最早用 Key Vault 是因为有个客户想统一管理几百个数据库连接字符串，手动配太容易出事了。
这一节我们就把 Key Vault 的核心概念、组件拆开聊聊。你想想看，一个保险柜最重要的是什么？锁、钥匙、谁有权限打开、开锁记录。Key Vault 也是这套逻辑。
核心概念：密钥、秘密、证书
Key Vault 里存三类东西，我习惯用一个类比来记：
- 密钥（Key）：纯粹的加密材料，比如 RSA、ECC 密钥对。用来做加密解密、签名验签。我在项目中经常用它来做应用程序级别的数据加密，而不是直接硬编码密钥。
- 秘密（Secret）：任何你不想让别人看到的字符串，比如数据库密码、API 、连接字符串。Key Vault 帮你加密存储，还能自动轮转。
- 证书（Certificate）：X.509 证书，包括公私钥对和证书链。Key Vault 可以自己签发证书，也可以导入已有证书。嗯，这里要注意：证书的生命周期管理比密钥和秘密复杂得多，我曾经因为证书过期没监控到，导致生产环境 TLS 握手失败……教训啊。
| 类型 | 典型用途 | 是否可导出 | 自动轮转支持 |
|---|---|---|---|
| 密钥 | 加密/解密、签名/验签 | 默认不可导出（HSM 保护） | 支持（手动或自动） |
| 秘密 | 存储敏感字符串 | 可以导出（需权限） | 仅限版本管理，非自动轮转 |
| 证书 | TLS/SSL、客户端认证 | 可以导出（含私钥需标记） | 支持（生命周期自动触发） |
Vault 是什么？
一个 Key Vault 就是一个独立的“保险柜”实例。每个 Vault 有自己的名称（全局唯一）、区域、SKU（Standard 或 Premium）。Premium 支持 HSM 硬件保护，密钥永远不会离开 HSM 边界。我的习惯是：生产环境必用 Premium，开发测试用 Standard，省钱也够用。
Vault 本身是个资源，你用 Azure 门户、CLI、PowerShell 或 Terraform 都能创建。创建完之后，它的访问入口是 https://<vault-name>.vault.azure.net/。
一个 Vault 能存多少东西？ 最多可以存 10,000 个对象（密钥+秘密+证书总和）。如果超过这个数，就需要规划多个 Vault。我在一个大客户那边就踩过这个数上限，后来按业务模块拆成多个 Vault 才解决。
组件架构：控制平面 vs 数据平面
Key Vault 架构我最想强调的就是「控制平面」和「数据平面」分开。你想想看，如果管理 Vault 的 API 和读写密钥的 API 混在一起，权限就很难控制。
- 控制平面：管理 Vault 本身的生命周期（创建、删除、更新属性）。走 Azure Resource Manager（ARM），身份认证用 Azure AD + RBAC。
- 数据平面：操作 Vault 里的密钥、秘密、证书（增删改查、加密解密）。直接走 Vault REST API，身份认证用 Azure AD 或 访问策略。
举个例子：我创建一个 Vault，这是控制平面操作。我把一个数据库密码存进去，这是数据平面操作。这两个平面的权限可以完全不同。
访问控制：两种授权模型
Key Vault 支持两种授权方式，我刚开始用的时候也很困惑，后来总结了一句话：RBAC 管“管理”，访问策略管“数据”。但 Azure 后来在数据平面也引入了 RBAC（叫 Key Vault RBAC），现在推荐统一用 RBAC。
| 特点 | Azure RBAC | Vault 访问策略 |
|---|---|---|
| 范围 | 控制平面 + 数据平面（预览） | 仅数据平面 |
| 管理方式 | ARM / Azure CLI / Portal | Vault 专属 UI / CLI |
| 粒度 | 粗粒度（管理、读、写等角色） | 细粒度（可精确到每个密钥/秘密的操作） |
| 建议 | 新项目首选 | 旧项目兼容，或需要极细粒度控制时 |
我的建议：尽量使用 RBAC 来控制数据平面，因为权限模型统一，审计日志也更清晰。但如果你有非常细粒度的需求（比如只允许 A 用户读某个特定密钥），访问策略仍然是最佳选择。
工作原理：创建、存储、检索、轮转
我们过一遍 Key Vault 的标准工作流。假设你用 Azure CLI 来操作。
1. 创建 Vault
az keyvault create \
--name "my-prod-vault" \
--resource-group "prod-rg" \
--location "eastus" \
--sku "Premium"这会创建一个 Premium SKU 的 Vault。注意名称全局唯一，而且一旦创建不能改名。
2. 存储一个秘密
az keyvault secret set \
--vault-name "my-prod-vault" \
--name "DbConnectionString" \
--value "Server=myserver;Database=mydb;User Id=sa;Password=..."秘密的最大尺寸是 25 KB。我见过有人把整张证书的 PEM 编码当做秘密存——可以的，但建议用证书类型更规范。
3. 检索秘密
az keyvault secret show \
--vault-name "my-prod-vault" \
--name "DbConnectionString" \
--query "value" \
--output tsv应用程序用托管身份（Managed Identity）来获取秘密，不需要硬编码任何凭证。这是我非常推荐的做法。
4. 密钥轮转
如果你用密钥而不是秘密，Key Vault 可以帮你自动生成新版本。举个例子，创建一个 RSA 密钥并启用自动轮转：
az keyvault key create \
--vault-name "my-prod-vault" \
--name "EncryptionKey" \
--kty "RSA" \
--size 4096 \
--rotation-policy '{"lifetimeActions":[{"trigger":{"timeAfterCreate":"P30D"},"action":{"type":"rotate"}}]}'这样 30 天后 Key Vault 会自动生成一个新版本。应用程序需要支持多版本密钥——我用过的大多数 SDK（比如 .NET 的 Azure.Security.KeyVault.Keys）默认支持。但如果你自己写加密逻辑，一定要测试你的代码是否能优雅地处理密钥版本切换。
避坑指南：我曾经在一个项目中，应用程序只缓存了第一个版本的密钥 ID，轮转后仍然用旧版本加密新数据，导致新数据无法被新版本解密。解决方案是：每次加密前都从 Key Vault 获取密钥的最新版本（不加版本号调用 API），或者使用 SDK 的自动版本解析。
日志与监控
Key Vault 所有操作都可以通过 Azure Monitor 和事件网格来记录。我每次上线 Key Vault 时一定会做两件事：
- 开启诊断设置，把所有操作日志（AuditEvent）发送到 Log Analytics 工作区。
- 设置告规则，比如「1 小时内 5 次密钥获取失败」就触发告警。
日志里你能看到谁、什么时候、通过哪个 IP、做了什么操作。这对合规审计非常重要。
知识结构总览
下面一张图把 Key Vault 的核心逻辑串起来。我自己经常拿这张图给团队新人讲「Key Vault 到底怎么用」。
图里分了两条主线：左边是控制平面和数据平面的活动，右边是 Vault 内部的对象。箭头标明了认证和调用路径。你会发现所有数据平面操作都绕不开 Azure AD 这一步——这也是 Key Vault 安全的核心。