📚 课程目录第3章 Azure Key Vault基础

Azure Key Vault 基础：密钥保管库原理与操作归纳总结

说实话，刚开始接触 Azure 密钥保管库时，我以为它就是个“放钥匙的网盘”。后来踩了几次坑才明白——它更像是一个 硬件安全模块（HSM）托管的、带审计的保险柜。下面我把核心原理和实操逻辑掰开揉碎了讲。

密钥保管库是什么？

Azure Key Vault 是微软提供的云上密钥管理服务。它底层依赖 FIPS 140-2 Level 2 验证的 HSM（如果你选 Premium 层，则是 Level 3）。说白了，你的密钥不会以明文出现在任何磁盘上——就算 Azure 内部人员也读不到。

我个人习惯把 Key Vault 看作三层结构：

管理平面：管理 Vault 本身的生命周期（创建、删除、配置网络 ACL）——走 Azure Resource Manager。
数据平面：读写密钥、机密、证书——走 vault.azure.net 专用端点。
日志平面：所有操作都会被记录到 Azure Monitor / Event Hub / Storage Account，这就是咱们后续对比 KMS 日志的重点。

  关键点：管理平面和数据平面用的是不同的 API 版本和认证方式。你在 Portal 上看到的“访问策略”只影响数据平面，而 RBAC 角色（比如“Key Vault 参与者”）管的是管理平面。很多新手搞混这两个，导致权限永远配不对。

三种存储对象：密钥、机密、证书

Key Vault 不只存密钥。它里面塞了三类东西，我用一个表格帮你理清：

类型	典型用途	是否支持 HSM 保护	生命周期管理
密钥（Key）	非对称加密、签名、密钥封装	是（Premium SKU）	支持自动轮换、版本化
机密（Secret）	数据库连接串、API 、密码	否（只是用 AES-256 加密存储）	可手动设过期时间，无自动轮换
证书（Certificate）	SSL/TLS 证书、客户端证书	部分（私钥由 Key Vault Key 保护）	自动签发、续期、吊销

注意了，机密本质上还是存在 Key Vault 的“保险柜”里，但它的保护强度不如 RSA 或 EC 密钥——因为它不支持 HSM 硬件保护。我在项目中经常提醒团队：非对称密钥必须用 Key 类型，别图省事塞进 Secret。

访问控制：策略 vs RBAC

我问过不少同行：“你给 Key Vault 配权限时，用访问策略还是 RBAC？” 答案几乎全是“访问策略”。为什么会这样？因为从 2016 年 Key Vault 推出开始，访问策略就是默认模式。但 2020 年后，微软强烈推荐用 RBAC 授权模型（Azure RBAC for Key Vault data plane）。

两者区别如下：

访问策略：直接在 Key Vault 资源上配置，主体粒度是 Azure AD 用户/组/服务主体，权限粒度到 get/list/decrypt/sign 等独立操作。最大问题是——不能继承资源组级别的 RBAC 角色。
RBAC：通过内置角色（如“Key Vault Crypto Officer”、“Key Vault Secrets User”）来控制，权限可以沿资源组 / 订阅继承。我个人更倾向 RBAC，因为团队规模一大，访问策略的管理成本会指数级上涨。

我的习惯：新建 Key Vault 时直接选 RBAC 授权模型。如果你已经用了访问策略，可以通过 Portal 的“访问配置”切到 RBAC——但需要注意，切换后原有策略会被清空，只保留 RBAC 分配。我建议先在非生产环境测试一遍。

操作流程：从创建到开启日志

好，咱们走一遍完整的操作流程。我假设你用的是 Azure CLI（因为我比较喜欢用命令行，不像 Portal 那样点来点去）。

# 1. 创建资源组（如果还没有）
az group create --name MyKeyVaultRG --location eastus

# 2. 创建 Key Vault（启用软删除和保护，这是生产必备）
az keyvault create \
  --name my-demo-vault-2024 \
  --resource-group MyKeyVaultRG \
  --location eastus \
  --sku premium \
  --enable-soft-delete true \
  --enable-purge-protection true

# 3. 创建 RSA 密钥（未来用于签名）
az keyvault key create \
  --vault-name my-demo-vault-2024 \
  --name MySigningKey \
  --kty RSA \
  --size 4096 \
  --protection hsm

# 4. 存储一个数据库连接字符串（机密）
az keyvault secret set \
  --vault-name my-demo-vault-2024 \
  --name "DbConnectionString" \
  --value "Server=demo.database.windows.net;Database=orders;..."

# 5. 开启诊断日志（输出到 Log Analytics，这也是日志分析的基础）
az monitor diagnostic-settings create \
  --resource $(az keyvault show --name my-demo-vault-2024 --query id -o tsv) \
  --name "VaultAuditLogs" \
  --workspace "/subscriptions/<sub>/resourcegroups/MyLogRG/providers/microsoft.operationalinsights/workspaces/MyLogs" \
  --logs '[
    {"category": "AuditEvent", "enabled": true, "retention-policy": {"enabled": true, "days": 365}},
    {"category": "AzurePolicyEvaluationDetails", "enabled": false}
  ]' \
  --metrics '[]'

我曾经历过一次事故：创建 Key Vault 时没开软删除，后来不小心删除了一个密钥，结果连恢复的机会都没有。所以上面 --enable-soft-delete 和 --enable-purge-protection 我几乎是肌肉记忆了。

日志类别：关注 AuditEvent

对于后续对比 AWS KMS 日志，Key Vault 有一个核心日志类别叫 AuditEvent。所有对数据平面的操作（GetSecret、Decrypt、Sign、WrapKey 等）都会落在这里。每个日志条目包含：

CallerIpAddress：发起请求的客户端 IP
PrincipalId：请求主体的 OID（用户或服务主体）
OperationName：比如 SecretGet、KeySign
ResultSignature：HTTP 状态码（200 表示成功，403 表示权限拒绝）
Id：Vault 的资源 ID

注意：AuditEvent 日志默认不记录请求的 payload（比如你获取的密钥值或机密明文）。这是出于隐私考虑。如果你需要审计具体的被访问内容，可以启用 Azure Policy 的 Key Vault 诊断设置，但那会额外增加存储成本。我一般只在合规审计时临时开启。

核心知识体系：一张图看懂

下面这张 SVG 图概括了 Key Vault 的内部逻辑和日志流向。你把它打印出来贴在工位上都行。

避坑指南：我亲身经历过的三个坑

讲完理论，我分享三个实操里最容易翻车的地方：

网络 ACL 没配白名单：默认 Key Vault 允许所有公网访问。如果你开启“防火墙和虚拟网络”，却忘了把自家应用所在的 VNet 加上——应用会报 403。我曾有一次把生产环境的缓存服务搞得宕机 20 分钟，就是因为在更新网络规则时误删了允许的 IP 段。
密钥轮换后忘记更新应用：Key Vault 支持密钥的版本化。如果你创建新密钥版本，旧版本依然存在但默认不再使用。但应用如果写死了 key identifier 不带版本号，它会自动指向最新版本——这通常没问题。但如果你用 az keyvault key show --id 拿到的 URL 里包含了版本号，那密钥轮换后应用就会突然找不到密钥。我记得有个同事就是因为这个 bug，半夜被 on-call 叫起来。
诊断日志的保留策略忘了设：AuditEvent 日志如果不配置保留天数，默认会无限留存 Log Analytics 的工作区（按 GB 付费）。长此以往成本会失控。我习惯设 365 天，满足合规审计需求的同时控制成本。