2. 多云KMS基础
在多云环境中做统一密钥治理，第一步不是写策略，而是把各云厂商KMS的“对象模型”和“边界”对齐。四家主流KMS表面上都提供“创建密钥、加密解密、轮换、授权”能力，但底层抽象、密钥层级、权限模型、计费与合规边界差异很大。如果把这些差异忽略，后续统一密钥管理就会出现“同一把密钥在A云可轮换、在B云不可轮换”“同一份策略在A云生效、在B云被拒绝”等问题。
一、四家KMS的核心对象模型
AWS KMS的核心对象是KMS Key（CMK），分为对称密钥（AES-256-GCM）和非对称密钥（RSA、ECC）。对称密钥又分“客户托管密钥”和“AWS托管密钥”。KMS Key本身不直接暴露密钥材料，所有加解密通过API完成。AWS KMS还提供Data Key机制：调用GenerateDataKey返回明文数据密钥和密文数据密钥，业务用明文密钥本地加密大数据，密文密钥随数据存储，实现信封加密。
Azure Key Vault的核心对象是Key，但Key Vault同时管理密钥、机密（Secret）和证书（Certificate），三者共用一套访问控制。Key Vault的密钥支持HSM保护（Premium层）和软件保护（Standard层）。与AWS不同，Azure Key Vault的密钥操作通过REST API或SDK完成，密钥版本以kid标识，轮换时生成新版本，旧版本仍可解密。
GCP KMS的对象层级最清晰：KeyRing → CryptoKey → CryptoKeyVersion。KeyRing是逻辑分组，CryptoKey定义用途（ENCRYPT_DECRYPT、ASYMMETRIC_SIGN等），CryptoKeyVersion才是实际密钥材料。轮换时新增Version，旧Version可设为DISABLED或DESTROYED。GCP KMS的密钥材料默认由Google管理，也可选择HSM或外部密钥管理（EKM）。
阿里云KMS的对象是CMK（Customer Master Key），分为“默认密钥”和“用户主密钥”。用户主密钥支持软件密钥和硬件密钥（HSM）。阿里云KMS同样提供数据密钥接口GenerateDataKey，并支持凭据管家（Secrets Manager）和证书管家。阿里云KMS的密钥版本管理通过“密钥版本”实现，轮换时自动生成新版本。
二、关键差异对比
把四家KMS放在一起看，差异集中在五个维度：密钥层级、权限模型、轮换机制、HSM支持、计费方式。
| 维度 | AWS KMS | Azure Key Vault | GCP KMS | 阿里云 KMS |
|---|---|---|---|---|
| 密钥层级 | CMK → Data Key | Key → Version (kid) | KeyRing → CryptoKey → Version | CMK → 数据密钥 → 版本 |
| 权限模型 | Key Policy + IAM + Grants | RBAC + Access Policy | Cloud IAM | RAM + KMS授权 |
| 轮换 | 自动轮换（可选，默认关闭） | 自动轮换策略 | 新增Version，旧Version可禁用 | 自动轮换周期 |
| HSM | CloudHSM 自定义密钥库 | Premium层 HSM | HSM / EKM | 硬件密钥 |
| 计费 | 按密钥数 + API调用 | 按操作数 + 密钥数 | 按密钥版本 + 操作数 | 按密钥数 + API调用 |
三、统一治理视角下的对齐要点
如果目标是“统一密钥治理”，不能只比较功能，而要把四家KMS映射到同一套抽象层。建议建立三层映射：密钥标识层、策略层、生命周期层。
密钥标识层：AWS用KeyId（UUID或别名）、Azure用kid（URL）、GCP用projects/…/cryptoKeys/…、阿里云用KeyId。统一治理时，应给每把密钥分配一个跨云唯一标识，例如cloud:region:keyid，并在CMDB中记录其原生ID、别名、用途、所属应用。
策略层：AWS的Key Policy是资源策略，IAM是身份策略，两者叠加；Azure的RBAC和Access Policy是两套并行模型；GCP只有IAM；阿里云是RAM加KMS授权。统一策略时，应把“谁可以加密、谁可以解密、谁可以轮换、谁可以禁用”抽象为四个动作，再分别映射到各云的原生策略语法。
生命周期层：四家都支持创建、启用、禁用、轮换、删除（或计划删除）。差异在于删除保护：AWS有7-30天等待期，Azure有软删除和清除保护，GCP有Destroy计划，阿里云有删除保护。统一治理时，应强制开启删除保护，并把轮换周期统一为90天或180天，再按云能力落地。
四、一个可落地的对齐示例
假设某应用需要跨AWS和阿里云使用同一业务密钥。在AWS侧创建对称CMK，别名为alias/app-payment-prod，开启自动轮换，周期设为90天；在阿里云侧创建用户主密钥，描述为app-payment-prod，开启自动轮换，周期90天。两侧都通过GenerateDataKey生成数据密钥，业务侧用明文数据密钥加密数据，密文数据密钥随数据存储。
权限上，AWS侧Key Policy允许角色arn:aws:iam::123456789012:role/app-payment执行kms:Encrypt、kms:Decrypt、kms:GenerateDataKey；阿里云侧RAM策略允许角色acs:ram::123456789012:role/app-payment执行kms:Encrypt、kms:Decrypt、kms:GenerateDataKey。两侧都禁止kms:ScheduleKeyDeletion和kms:DeleteKey，只允许通过审批流触发删除。
这样，同一业务在两家云上使用独立密钥材料，但密钥用途、轮换周期、授权主体、删除保护策略保持一致。统一治理平台只需维护一份“逻辑密钥”记录，分别同步到两家KMS的原生对象，就能实现“逻辑统一、物理隔离”。
五、选型与治理的初步判断
如果业务已经深度绑定AWS，优先用AWS KMS，配合CloudHSM做自定义密钥库；如果企业以Azure AD为核心身份体系，Azure Key Vault的RBAC和Managed Identity集成更顺；如果使用GCP的BigQuery、GKE等，GCP KMS的KeyRing层级和IAM更自然；如果业务在国内且需要合规，阿里云KMS的RAM和KMS授权更贴近国内审计要求。
但无论选哪家，统一治理的起点都是一样的：先把密钥对象、权限动作、轮换周期、删除保护四件事对齐，再谈自动化。否则，多云KMS只会变成多个孤岛，而不是一套治理体系。