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

Azure Key Vault 基础：Vault 创建、密钥与机密存储、访问策略、RBAC

聊到云上 Secrets 管理，Azure Key Vault 是个绕不开的角色。我个人觉得，它就像是给敏感信息配了个专属保险柜——密码、证书、数据库连接串这些，统统可以往里扔。

说白了，Key Vault 的核心就三件事：安全存、精细管、方便用。今天我们就来拆解这三点，看看在实际项目中怎么落地。

  一句话总结：Key Vault 帮你把“密钥是怎么保管的”这个头疼的问题，从一个点分散到整个平台。你不需要自己操心加密算法、硬件安全模块这些底层细节。

创建你的第一个 Vault

创建一个 Key Vault 本身并不复杂，但里面的选项值得留意。我在项目里踩过一个坑：创建时选了“软删除”启用，后来想彻底删掉一个测试 Vault，发现还得等 90 天……

创建过程大体分几步：

基础设置：选订阅、资源组、区域。这里要注意，Vault 的区域决定了它的物理位置，跨区域访问会有网络延迟。我建议把 Vault 和应用放在同一个区域。
定价层级：标准版（Standard）和高级版（Premium）。标准版用软件加密，高级版用 HSM（硬件安全模块）加密。你想想看，生产环境的根密钥，用 HSM 显然更踏实。
恢复选项：软删除（Soft Delete）和清除保护（Purge Protection）。前者让你误删后还能恢复，后者直接禁止彻底删除——这两个选项我建议默认都开着，尤其在生产环境。

我的习惯：创建 Vault 时，名字要取成全局唯一的。Key Vault 的名字是 DNS 的一部分，假设你取了个 myvault，很可能已经被别人占了。我一般用 项目名-环境-vault-序号 的格式，比如 payment-prod-vault-01。

用 Azure CLI 创建的命令大致是这样：

az keyvault create \
  --name "payment-prod-vault-01" \
  --resource-group "rg-payment-prod" \
  --location "eastasia" \
  --sku "Premium" \
  --enable-soft-delete true \
  --enable-purge-protection true

嗯，这里要注意：--enable-purge-protection 必须在软删除启用后才能设置。我刚开始做的时候踩过这个顺序坑，当时 CLI 报错我还找了半天原因。

密钥与机密：两种“秘密”，两种用法

Key Vault 里存的东西，主要分成两类：密钥（Keys） 和 机密（Secrets）。它们有什么区别？说白了，密钥是用来做加密运算的，而机密是纯粹的字符串数据。

维度	密钥（Key）	机密（Secret）
本质	一个加密材料（RSA、EC 等）	一段字符串（密码、连接串）
操作类型	加密、解密、签名、验证	获取、设置
典型场景	数据加密、TLS 证书	数据库密码、API
版本管理	自动分版本（V1、V2...）	自动分版本（V1、V2...）

为什么会这样设计？你想，密钥直接暴露出来是巨大的安全隐患。所以 Azure 提供了在 Key Vault 内部做加密/解密的 API，你的应用根本不需要接触密钥的原始材料——你只管把要加密的数据传过去，Key Vault 用密钥算好结果返回给你。

机密存储的实际操作

举个例子，把数据库连接串存进去：

az keyvault secret set \
  --vault-name "payment-prod-vault-01" \
  --name "db-connection-string" \
  --value "Server=myserver;Database=mydb;User Id=user;Password=pass;"

应用运行时，通过 SDK 或 REST API 把这个 secret 取出来用。我之前维护过一个老系统，密码硬编码在配置文件里，每次密码轮转都得重新部署——改到 Key Vault 后，直接在 Vault 里更新版本，应用重启一次就生效了。

避坑指南：我曾经遇到过一个问题——存了机密之后，应用总是拿到旧版本。原因是 SDK 没有指定版本号，默认拿到的不是最新版本。后来我在代码里设置 SecretClientOptions 中的 ChallengeBasedAuthentication 并总是获取最新版本，问题才解决。记住：机密有版本概念，一定要确认你拿的是哪个版本。

访问策略 vs. RBAC：两种权限模型

这就到了 Key Vault 里最让人容易混淆的地方——权限控制。为什么会有两套模型？我刚开始接触时也挺困惑。

访问策略（Access Policies）：这是 Key Vault 的“传统”权限模型，直接在 Vault 级别为每个用户或应用分配权限。你可以精细控制某个人能不能读密钥、能不能写机密。
RBAC（基于角色的访问控制）：这是 Azure 的通用权限模型，通过角色定义权限，然后把角色分配给用户、组或服务主体。Key Vault 在 2020 年加入了对 RBAC 的支持。

怎么选？

我个人习惯：新项目直接用 RBAC，因为统一、好管理。老项目如果已经用了访问策略，迁移成本高的话，继续用也行。但要注意，两套模型是互斥的——你需要为 Key Vault 指定用哪一种。

# 开启 RBAC 授权
az keyvault update \
  --name "payment-prod-vault-01" \
  --enable-rbac-authorization true

开启之后，原来的访问策略会失效，权限完全由 Azure RBAC 控制。

小建议：我见过不少团队在同一个 Vault 里混用两套模型，结果权限排查时一团乱。要么全用访问策略，要么全用 RBAC，别搞混搭。

RBAC 的常用角色

Azure 为 Key Vault 定义了几个内置角色，我挑三个最常用的说说：

角色名称	作用范围	典型使用场景
Key Vault Administrator	所有数据平面操作	运维人员、DevOps
Key Vault Secrets User	读取机密	应用程序、只读监控
Key Vault Crypto User	执行加密操作	需要加密/解密的应用

你想想看，假如你的 Web 应用只需要读数据库连接串，给它分配 Key Vault Secrets User 就够了。没必要给它完整的 Admin 权限，对吧？

一张图理清 Key Vault 核心概念

下面这张图，我画的是 Key Vault 的基本结构。从左到右，展示了权限、存储对象和访问入口之间的关系。

图上把权限控制放在最前面，这很关键。你喂，无论存什么，首先得搞清楚谁有权访问。

实战中的一些体会

最后聊点实战中的细节。

关于最小权限：我记得有一次排查安全漏洞，发现某个应用使用的服务主体被赋予了整个 Key Vault 的 Get/List 权限。其实它只需要读一个机密。这就是典型的权限过宽。改成只给那个 specific secret 的读权限后，攻击面缩小了很多。

关于托管标识（Managed Identity）：这是我最喜欢的一个特性。你不需要操心凭证怎么轮转——Azure 自动帮你管。我通常的做法是：给 App Service 或 AKS 启用系统托管标识，然后把那个标识加到 Key Vault 的访问策略或 RBAC 角色里。这样应用代码里甚至不需要出现连接字符串，直接通过 DefaultAzureCredential 就能拿到机密。

关于监控和告警：打开 Key Vault 的诊断日志（Diagnostic Settings），把日志输出到 Log Analytics。我见过一个案例，有个应用每天凌晨会疯狂调用 Key Vault，导致请求被限流。通过日志发现后，给应用加了缓存，问题才解决。

特别注意：Key Vault 有请求限速（Throttling）。官方文档说每秒最多 2000 次请求（取决于 Vault 类型），但实际我遇到过更低的阈值。千万不要让应用每次都去 Key Vault 取机密——你想想，几万个请求同时打过来，KV 直接返回 429。正确的做法是：在应用本地缓存机密，设置合理的过期时间（比如 30 分钟），过期后再去 KV 刷新。

嗯，今天就先讲到这。Key Vault 的基础概念和操作逻辑，你自己动手试一试，应该很快就能掌握。下回我们再聊点更进阶的——比如用 Terraform 管理 Key Vault，或者跨区域灾备的方案。