一、Azure Key Vault 概述：什么是Key Vault，核心功能与使用场景
1.1 我眼中的Key Vault
说白了，Azure Key Vault就是一个云上保险柜。
我第一次接触它，是在给一个金融客户做微服务改造的时候。那时候他们把所有数据库密码、都写在配置文件里，明文存储。我至今记得那个运维总监的表情——「万一源码泄露，我们是不是就完了？」嗯，那之后我们就上了Key Vault。
它帮你集中管理三类敏感数据：
- 密钥（Key）：加密用的对称或非对称密钥
- 机密（Secret）：连接串、密码、证书私钥等
- 证书（Certificate）：SSL/TLS证书及其完整生命周期
你想想看，一个系统里有多少个密码？数据库、Redis、消息队列、第三方API……几十个算少的。过去大家都是「记文档→存文件→写代码里」，出一次安全审计就手忙脚乱。
Key Vault把这些统一收拢，用一套权限模型来控制谁能看到什么、能做什么。这个权限模型，就是我们这门课要深挖的核心。
1.2 核心功能拆解
1.2.1 机密管理（Secret Management）
这是最常用的功能。把数据库密码、存储账户密钥、API 存进去，运行时通过SDK或REST API读取。
为什么不能直接存文件里？
- 文件可能被误提交到Git
- 运维人员登录服务器就能看到
- 更换密码时要重启服务或重新部署
Key Vault提供了版本管理——你更新一下Secret，应用端几乎无感上线。我在项目中遇到过一家企业，他们每月轮换一次数据库密码，过去是运维手动改配置、发邮件通知、再重启服务。改用Key Vault后，整个过程自动化，再也没有「密码过期导致凌晨3点宕机」的告警电话。
1.2.2 密钥管理（Key Management）
这里说的「密钥」是指加密运算用的密钥。Key Vault支持：
- HSM保护密钥：硬件安全模块（Hardware Security Module）背书，密钥永远不会离开HSM边界
- 软件保护密钥：成本更低，适用于非生产环境或低敏感场景
- BYOK（Bring Your Own Key）：把你本地HSM生成的密钥导入Key Vault
| 功能维度 | 标准层（Standard） | 高级层（Premium） |
|---|---|---|
| 密钥存储 | 软件保护 | HSM保护 |
| 加密操作 | 支持基本加解密 | 支持签名、验证、包装密钥 |
| 合规认证 | FIPS 140-2 Level 1 | FIPS 140-2 Level 2/3 |
| 成本 | 较低 | 较高（按操作量计费） |
1.2.3 证书管理（Certificate Management）
SSL证书的申请、续期、分发，听起来简单，实际做起来很痛苦。我团队之前维护过200多个域名证书，全靠人工检查到期日、手动替换。有一次漏了一张通配符证书，导致电商平台「安全证书无效」的红屏持续了整整6小时。
Key Vault的证书管理可以：
- 自动签发：通过内置CA或对接Let's Encrypt，自动创建证书
- 自动续期：到期前自动刷新，无需人工干预
- 与App Service、Application Gateway集成：证书一变，负载均衡器自动拉取新版
1.2.4 访问控制与审计
这是本课程的核心。Key Vault的权限模型主要基于两种机制：
- 访问策略（Access Policy）：针对每个用户/应用，细粒度控制「能读哪些Secret」「能用哪些密钥」「能做哪些操作」
- RBAC（Role-Based Access Control）：通过Azure RBAC角色控制对Key Vault管理平面的权限
⚠️ 这里有个容易搞混的地方。我花了三天才理清楚：
访问策略控制的是数据平面的权限——也就是你能不能真的拿到Secret或者用Key做加密。
RBAC控制的是管理平面的权限——比如你能不能新建一个Key Vault、能不能修改它的防火墙设置。
你在实际工作中，两者需要配合使用。后面会有专门章节详细拆解这一块。
1.2.5 监控与日志
Key Vault默认会记录所有操作到Azure Monitor和Azure Activity Log。我能看到：谁在什么时间、从哪个IP、读取了哪个Secret。这些日志可以用来做安全事件响应，也可以对接SIEM系统。
- 密钥/机密被列出（List）——可能有人正在扫你
- 密钥/机密被读取（Get）——来自不常见IP
- 密钥/机密被删除（Delete）——必须确认是运维操作
1.3 使用场景举例
举几个我在项目中实际用过的场景你就明白了。
场景一：微服务配置中心
某个电商平台有40多个微服务。每个服务都需要数据库密码、Redis密码、消息队列密码。之前用App Configuration存明文，出了安全问题后被推翻重做。
我们用Key Vault + Managed Identity的方式解决：每个微服务分配一个Azure AD上的托管标识，然后给这个标识授予对应Key Vault的「Get Secret」权限。服务启动时自动拉取，无需任何连接字符串保存在容器镜像或环境变量里。
场景二：加密密钥的集中管理
一家SaaS公司需要为每个租户生成AES-256密钥，用来加密他们的业务数据。传统做法是每个应用服务器自己生成并存入数据库。但我们发现密钥可能被DBA直接读取。
我们改用Key Vault：租户入驻时，通过API在Key Vault中创建一个密钥。加解密操作都通过Key Vault的「加密/解密」API完成，应用服务器只持有「使用权限」，拿不到明文密钥。这使得运维人员即使能访问数据库，也读不到加密后的数据。
场景三：证书自动续期
前面提到的那家电商平台后来把所有域名证书都迁到了Key Vault。配置好自动续期后，再也没有「证书到期」的告警。前端App Service通过自带集成自动拉取最新证书，重启都不需要。
1.4 Key Vault知识体系框架
下面这张图总结了我们这一章讲到的核心内容，也是整个课程的知识骨架。你可以对照着看，后面每个章节其实就是在填充这个框架里的具体细节。
1.5 为什么专门讲「权限模型」？
原因很简单：Key Vault的权限模型是整个产品的安全基石。
功能做得再好，如果权限配置不当，照样出事。我在社区里见过一个典型案例：某团队给所有微服务都分配了「所有密钥的全部权限」，结果一个被攻破的服务直接删除了生产环境的所有加密密钥——数据恢复用了整整两周。
Key Vault的权限模型有三层逻辑需要你掌握：
- Azure AD身份层面：谁来认证？（用户？服务主体？托管标识？）
- 管理平面（RBAC）：谁能创建/删除/移动Key Vault本身？
- 数据平面（Access Policy）：谁能读取Secret？谁能用Key加密？谁能删除证书？
这三层交织在一起，稍有不慎就会出现「你以为权限够，实际却不够」或者「你以为别人看不到，实际却能访问」的问题。后面我们会用将近30章的篇幅，一层一层剥开这些权限模型。
嗯，这一章我们先到这里。基础概念建立了，后面就好讲了。