3. 主流 KMS 产品横向对比：你该选哪家？
做密钥管理，最头疼的事儿就是选平台。
AWS、Azure、GCP、阿里云，每家都说自己好。但我个人习惯是，先别听厂商吹，咱得自己扒开看看底层逻辑。
说白了，这几家的 KMS 核心功能大差不差。但细节里藏着魔鬼。我来帮你捋一遍。
3.1 四巨头核心能力对比
先把最关键的几个维度拉一张表。这样你一眼就能看出差异。
| 维度 | AWS KMS | Azure Key Vault | GCP Cloud KMS | 阿里云 KMS |
|---|---|---|---|---|
| HSM 后盾 | CloudHSM（可选） | Managed HSM（专用） | Cloud HSM（Cavium 架构） | 硬件密码机（国密/国际） |
| 密钥自动轮转 | 每年一次（可配置） | 默认禁用，需手动开 | 自动轮转，周期可设 | 支持，但依赖 KMS 版本 |
| BYOK 导入 | 支持（带导入令牌） | 支持（RSA 密钥对） | 支持（对称/非对称） | 支持（信封加密方式） |
| 国密支持 | 无原生支持 | 无原生支持 | 无原生支持 | SM2/SM3/SM4 原生 |
| 加密粒度 | KMS Key（CMK） | Key Vault + 密钥软硬隔离 | Key Ring + CryptoKey | 用户主密钥 + CMK |
| 权限模型 | IAM + 密钥策略 | RBAC + 访问策略 | IAM + 权限角色 | RAM + 密钥策略 |
嗯，这里要注意，国密支持是阿里云的护城河。如果你在国内做等保，基本没得选。我在一个金融项目里就遇到过，甲方明确要求 SM4 加密，AWS 那边只能靠第三方插件，维护成本高得吓人。
3.2 AWS KMS：生态最全，但门槛不低
AWS KMS 是目前市场占有率最高的。它最大的优势是跟自家服务绑得死死的。比如 S3、RDS、Lambda，全都默认集成。
但有个坑，我[曾经]踩过：跨区域复制加密对象。
你如果想在美东加密数据，然后在美西解密，不能直接用一个 CMK。AWS KMS 的 CMK 是区域性的。你得在目标区域再创建一个 CMK，然后用 AWS 的加密 SDK 做信封加密。这个逻辑，我第一次做的时候绕了半天。
核心要点： AWS KMS 的密钥策略（Key Policy）与 IAM 策略是两套体系。写策略时务必同时照顾到。否则你会发现，IAM 给了权限，但 Key Policy 没放行，一样 Deny。
避坑： 不要把 CMK 的 Admin 权限直接给开发人员。我见过有人顺手把 `kms:ScheduleKeyDeletion` 加上去了，结果测试环境密钥被误删，虽然 7 天内能取消，但整条数据流水线全断了。
3.3 Azure Key Vault：跟微软生态深度绑定
Azure 的 Key Vault 分两种：Vault（标准）和 Managed HSM（专用）。
如果你只是存个数据库连接串，用 Vault 就够了。但要是管支付牌照的密钥，我建议上 Managed HSM。后者是真正的 FIPS 140-2 Level 3 硬件隔离，前者的“托管”是说微软帮你管软件，但硬件还是共享的。
我有个习惯：检查 Key Vault 的软删除（Soft Delete）是否开启。Azure 默认是打开的，但如果你在 ARM 模板里配置时手滑关了，删除密钥就直接销毁，没有后悔药。Azure 的回收站机制是 90 天内可恢复，过了就真没了。
运维技巧： 用 Azure Policy 强制所有 Key Vault 开启软删除和 purge protection。别依赖人肉检查。
3.4 GCP Cloud KMS：全球统一命名空间
GCP 的 Cloud KMS 有个很舒服的点：全局密钥环（Key Ring）。
你可以在 us-central1 创建密钥，然后在 europe-west1 解密。它不做区域强制绑定。AWS 那种区域限制，在 GCP 这里是不存在的。但这也会带来一个问题——延迟。跨区域调用 API 时，网络开销你得自己评估。
我记得在做 IoT 项目时，设备端上报的数据在东京加密，在北京存储。用 GCP 的 Cloud KMS，直接指定目标区域的 CryptoKey 就行，不用提前部署 CMK 副本。这个设计比其他几家都灵活。
3.5 阿里云 KMS：国密方案的主战场
国内厂商，阿里云 KMS 是绕不开的。它最大的差异化就是原生国密支持。
SM2 签名、SM4 对称加密、SM3 摘要，全都有。而且它提供信封加密 SDK，封装得很好了。我上次做政务云迁移，数据加密这块就靠阿里云 KMS 搞定，否则自己搞 SM4 的密码机对接，光联调就得一个月。
再提一个它比较独特的功能：自动轮转策略。你可以设置密钥的轮转周期，比如 90 天。但轮转只旋转“数据密钥”，不改变“用户主密钥”本身。这个逻辑跟 AWS 的 CMK 自动轮转类似，但阿里云把周期粒度调得更细。
提醒： 阿里云 KMS 的“自动轮转”需要手动开启，且创建 CMK 时就得选“支持自动轮转”。创建完后，再想改就没门了。所以创建密钥时就规划好，我[曾经]吃过这个亏，不得不重建 CMK。
3.6 一张图看懂四家架构本质
下面这张图，是我自己整理的。核心逻辑就一条：用户主密钥（CMK）是顶层，数据密钥（DEK）是干活的主力。
看看这张图。你会发现，不论哪家，底层的设计哲学是一样的。只不过有的在“区域隔离”上做文章，有的在“合规集成”上发力。你只要理解了 CMK 和 DEK 的关系，用哪家都是熟练工问题。
3.7 选择建议：结合场景做决策
最后，我直接给你一张决策表。别纠结，照着选就行。
- 如果你全栈在 AWS 上 —— 无脑 AWS KMS。集成的便利性比一切技术选型都重要。
- 如果客户要求国密 —— 只考虑阿里云 KMS。其他几家要实现国密，成本翻倍还不一定合规。
- 如果你做国际化，且跨区域频繁 —— GCP Cloud KMS 的全局密钥环能省掉你大量 CMK 复制工作。
- 如果你的重点是权限审计+软删除 —— Azure Key Vault 的 RBAC 和软删除回收机制是最完备的。
个人建议： 不管选哪家，BYOK（Bring Your Own Key） 一定要架构支持。哪怕你现在用托管密钥，未来合规收紧，你随时能导入自己的根密钥。这点在架构初期就要留好接口。