2. 主流云平台 KMS 服务介绍
做密钥托管，你迟早要跟这三家打交道：AWS KMS、Azure Key Vault、Google Cloud KMS。它们各有各的设计哲学，没有哪一家能一招通吃。这一章我带你把三个平台的核心能力捋一遍，看看各自适合什么场景。
2.1 AWS KMS — 老牌选手，生态最完整
AWS KMS 是最早的云密钥管理服务之一，也是我接触最多的。它的核心是 CMK（Customer Master Key），存储在 FIPS 140-2 Level 2/3 的 HSM 里。说白了，你的主子密钥在硬件里待着，谁都拿不走。
关键概念其实不多，你记住这几个就行：
- CMK 类型：对称密钥、非对称密钥、HMAC 密钥。我用得最多的是对称 CMK，做 envelope encryption 非常方便。
- 密钥存储：CMK 本身存在 HSM 里，但你也可以导入自己的密钥材料（BYOK）。
- 自动轮转：每年自动轮转一次，可以自己配。我个人习惯把轮转周期改成 180 天，合规要求更严的项目会用到。
- 审计集成：所有 KMS 操作都记在 CloudTrail 里，谁用了哪个密钥一目了然。
下面这个命令，是创建对称 CMK 的标准姿势：
aws kms create-key \
--description "生产环境主密钥" \
--key-spec SYMMETRIC_DEFAULT \
--tags TagKey=Env,TagValue=Prod创建完记得用 aws kms list-keys 确认一下。我吃过一次亏——命令执行成功但没注意 Region，结果密钥在香港区，业务跑在新加坡，白白浪费时间排查。
2.2 Azure Key Vault — 不止管密钥，连证书一起管
Azure Key Vault 跟 AWS KMS 不太一样，它更像一个统一的 secrets 保险箱。密钥、机密、证书全放一起管。为什么会这样？因为 Azure 的客户很多是 .NET 企业，需要一把搞定证书和连接字符串。
核心概念：
- 密钥（Key）：RSA、EC、对称密钥。支持 BYOK，也可以通过 HSM 保护。
- 机密（Secret）：密码、连接字符串、API 。说白了就是存敏感文本的。
- 证书（Certificate）：支持自动续期和签发。我记得有一次帮客户迁移证书，Key Vault 的自动续期帮了大忙，省掉了写 cron job 的麻烦。
- 访问策略：有两种模式，老式的 Access Policy 和新的 RBAC。我建议用 RBAC，更灵活也更好审计。
创建密钥的命令长这样：
az keyvault key create \
--vault-name my-prod-vault \
--name data-protection-key \
--protection hsm \
--kty RSA-HSM \
--size 4096注意 --protection hsm 参数。选 "software" 便宜但安全等级低，选 "hsm" 得先创建 Premium 层 vault。预算够的话直接上 HSM，别省那个钱。
2.3 Google Cloud KMS — 全局设计，天生多云
Google Cloud KMS 的设计强调「全局性」。它的核心组织单位是 Key Ring（密钥环），密钥环可以跨 Region 绑定，实现全球统一管理。这个思路跟你想象中的多云架构天然契合。
核心概念：
- 密钥环：密钥的逻辑分组。一个密钥环可以包含多个密钥版本。
- 密钥版本：不可变。每次轮转就生成一个新版本，旧版本只用来解密已加密数据。
- 自动轮转：按时间窗口配置，比如每 90 天轮一次。我个人习惯设 180 天，跟 AWS 保持一致，方便内部审计统一口径。
- 审计集成：所有操作记入 Cloud Audit Logs，跟 Cloud Logging 原生打通。
创建密钥的命令：
gcloud kms keys create my-app-key \
--keyring my-prod-ring \
--location global \
--purpose encryption \
--rotation-period 180d \
--next-rotation-time 2025-12-01T00:00:00Z这里有个细节：--location global 让密钥在全球所有 Region 都可访问。如果你的业务有数据驻留要求，记得指定具体 Region，比如 asia-east1。
2.4 三平台核心对比
光说概念不过瘾，咱们直接上表格。我挑了几个你最关心的维度：
| 维度 | AWS KMS | Azure Key Vault | Google Cloud KMS |
|---|---|---|---|
| 密钥类型 | 对称 / 非对称 / HMAC | 密钥 / 机密 / 证书 | 对称 / 非对称 |
| HSM 等级 | FIPS 140-2 Level 2/3 | FIPS 140-2 Level 2 | FIPS 140-2 Level 3 |
| 自动轮转 | 支持（可自定义周期） | 支持（需单独配置） | 支持（按时间窗口） |
| 审计集成 | CloudTrail | Azure Monitor | Cloud Audit Logs |
| 定价模式 | 按月 / API 调用次数 | 按操作量 / 存储量 | 按密钥版本 / API 调用 |
| CLI 入口 | aws kms |
az keyvault |
gcloud kms |
看完表格，你大概心里有数了。但光有表格还不够，我用一张图把三个平台的架构关系画出来，方便你建立整体认知。
2.5 选型建议：到底用哪个？
很多同学问我：三个平台到底选哪个？我的回答永远是——看你主账号在哪。
- 主力在 AWS：别犹豫，直接上 AWS KMS。CloudTrail + Lambda + KMS 的自动化链路太成熟了，社区资料也最多。
- 主力在 Azure：用 Key Vault，尤其如果你有证书管理需求。它的一键续期和 RBAC 策略比另外两家顺手。
- 主力在 GCP：Cloud KMS 的全局密钥环设计很适合多云架构。我手头有个项目就是用 GCP KMS 统一管理 AWS 和 Azure 的密钥——当然，这是通过 Cloud External Key Manager 做的。
这一章我们走马观花看了三个平台的 KMS 能力。记住了：没有完美的平台，只有适合你当前架构的工具。实操的时候，每个平台都有一些小脾气——比如 Azure Key Vault 的 RBAC 传播延迟、AWS KMS 的跨账号策略写法、GCP KMS 的密钥环命名限制——这些在后面的章节里我会逐一拆解。