📚 课程目录第4章密钥管理服务（KMS）

4、密钥管理服务（KMS）：三大云厂商的基本使用与轮换策略

说到密钥管理，我见过太多团队把密钥硬编码在代码里，或者放在配置文件里就上生产了。说实话，每次看到这种操作，我心里都咯噔一下。密钥管理服务（KMS）就是来解决这个问题的——它帮你把密钥锁在硬件安全模块（HSM）里，你只管用，不用管它怎么存。

这一章，咱们就聊聊 AWS KMS、Azure Key Vault 和阿里云 KMS 的基本用法。我会结合我自己的踩坑经历，把密钥创建、使用和轮换这些关键操作讲清楚。

4.1 为什么需要 KMS？

你想想看，如果密钥放在磁盘上，数据库被拖库了怎么办？如果密钥在内存里，被 dump 出来怎么办？KMS 的核心思路就是：密钥永远不离开 HSM。你只能通过 API 去「用」密钥，但拿不到密钥本身的明文。

KMS 的核心价值：

集中管理：所有密钥在一个地方创建、轮换、审计
硬件隔离：密钥存储在 FIPS 140-2 认证的 HSM 中
细粒度权限：谁可以用、什么时候用、用来做什么，都能控制
自动轮换：支持定期自动生成新密钥版本

我在一个金融项目里遇到过这种情况：开发人员为了方便，把数据库加密密钥写死在代码里。结果代码泄露到 GitHub 上，整个数据库的数据都暴露了。后来我们迁移到 KMS，密钥由安全团队统一管理，开发人员只拿到一个 Key ID，再也不用担心密钥泄露了。

4.2 AWS KMS 的基本使用

AWS KMS 是我用得最多的。它的设计很简洁——你创建密钥，然后通过 API 加密/解密数据。但要注意，KMS 直接加密的数据最大只有 4KB。超过这个大小，你得用信封加密。

4.2.1 创建对称密钥

我个人习惯用 AWS CLI 来创建密钥，这样方便自动化。当然，控制台操作也完全没问题。

# 创建对称密钥
aws kms create-key \
    --description "用于加密数据库连接字符串" \
    --key-usage ENCRYPT_DECRYPT \
    --origin AWS_KMS

# 创建别名，方便引用
aws kms create-alias \
    --alias-name alias/db-connection-key \
    --target-key-id <key-id>

嗯，这里要注意：--origin 参数决定了密钥是在 AWS 的 HSM 里生成，还是你导入自己的密钥材料。我建议默认用 AWS_KMS，除非你有合规要求必须用自己的密钥。

4.2.2 使用密钥加密数据

加密和解密操作很简单，但有个坑——加密时一定要指定加密上下文。加密上下文是个键值对，它会被用于验证解密请求的合法性。

# 加密
aws kms encrypt \
    --key-id alias/db-connection-key \
    --plaintext fileb://secret.txt \
    --encryption-context "department=finance,env=prod" \
    --output text \
    --query CiphertextBlob | base64 --decode > encrypted.txt

# 解密
aws kms decrypt \
    --ciphertext-blob fileb://encrypted.txt \
    --encryption-context "department=finance,env=prod" \
    --output text \
    --query Plaintext | base64 --decode

我曾经踩过的坑：解密时如果加密上下文不匹配，KMS 会直接拒绝请求。有一次我加密时写了 env=prod，解密时写成了 env=production，结果解密失败。所以加密上下文一定要标准化，最好用配置管理工具统一维护。

4.2.3 密钥轮换

AWS KMS 支持自动轮换，每年一次。我个人觉得这个频率对大多数场景来说够了。但如果合规要求更严格，你可以手动触发轮换。

# 启用自动轮换
aws kms enable-key-rotation --key-id <key-id>

# 手动创建新密钥版本（相当于手动轮换）
aws kms create-key --description "新版本密钥"

自动轮换的好处是：旧密钥版本仍然可以解密历史数据，但新加密操作会使用新版本。说白了，就是无缝过渡。

4.3 Azure Key Vault 的基本使用

Azure Key Vault 和 AWS KMS 的思路不太一样。它更像一个「保险箱」——不光存密钥，还能存证书和机密（比如数据库密码）。我刚开始用的时候觉得它功能太多，后来发现其实挺方便的。

4.3.1 创建密钥保管库和密钥

在 Azure 里，你得先有个 Key Vault 实例，然后在里面创建密钥。我习惯用 Azure CLI 操作：

# 创建资源组
az group create --name MyKeyVaultRG --location eastus

# 创建 Key Vault
az keyvault create \
    --name my-secure-vault \
    --resource-group MyKeyVaultRG \
    --location eastus \
    --sku premium

# 创建密钥
az keyvault key create \
    --vault-name my-secure-vault \
    --name my-encryption-key \
    --protection hsm \
    --kty RSA-HSM \
    --size 4096

注意 --sku premium 和 --protection hsm 这两个参数。只有 Premium 层才支持 HSM 保护，Standard 层用的是软件保护。我个人建议，生产环境一定要用 Premium + HSM。

4.3.2 使用密钥加密数据

Azure Key Vault 的加密操作和 AWS 类似，但有个区别——它支持密钥标识符的概念。你可以通过版本号引用特定版本的密钥。

# 加密
az keyvault key encrypt \
    --vault-name my-secure-vault \
    --name my-encryption-key \
    --algorithm RSA-OAEP \
    --value "敏感数据" \
    --data-type plaintext

# 解密
az keyvault key decrypt \
    --vault-name my-secure-vault \
    --name my-encryption-key \
    --algorithm RSA-OAEP \
    --value "加密后的数据" \
    --data-type base64

小技巧：Azure Key Vault 支持软删除和清除保护。开启后，删除的密钥会保留 90 天，防止误删。我建议所有生产环境的 Key Vault 都开启这两个功能。

4.3.3 密钥轮换

Azure Key Vault 的自动轮换需要自己写逻辑。官方推荐用 Event Grid 监听密钥过期事件，然后触发 Azure Function 来创建新密钥。说白了，就是半自动。

我自己的做法是：用 Azure DevOps Pipeline 定期执行轮换脚本，每次轮换后更新密钥版本，然后通知相关应用重新加载配置。

4.4 阿里云 KMS 的基本使用

阿里云 KMS 和 AWS KMS 非常像，都是基于 HSM 的。如果你用过 AWS，上手阿里云会很快。但有几个细节不一样，我重点说一下。

4.4.1 创建密钥

阿里云 KMS 的密钥分为「默认密钥」和「用户主密钥」。默认密钥是阿里云服务（如 OSS、RDS）自动创建的，用户主密钥是你自己创建的。

# 使用阿里云 CLI 创建密钥
aliyun kms CreateKey \
    --KeySpec AES_256 \
    --KeyUsage ENCRYPT_DECRYPT \
    --Origin Aliyun_KMS \
    --Description "用于加密应用配置"

这里有个坑：阿里云 KMS 的 KeySpec 参数决定了密钥类型。AES_256 是对称密钥，RSA_2048 是非对称密钥。我建议大部分场景用 AES_256，性能更好。

4.4.2 使用密钥加密数据

阿里云 KMS 的加密操作和 AWS 几乎一样，也是用信封加密。但它的 SDK 封装得更好，你不需要手动处理数据密钥。

# 加密
aliyun kms Encrypt \
    --KeyId <key-id> \
    --Plaintext "敏感数据" \
    --EncryptionContext '{"department":"finance"}'

# 解密
aliyun kms Decrypt \
    --CiphertextBlob "加密后的数据" \
    --EncryptionContext '{"department":"finance"}'

阿里云 KMS 的独特功能：

BYOK（Bring Your Own Key）：你可以导入自己的密钥材料到 HSM 中
密钥标签：支持给密钥打标签，方便成本分摊和权限管理
密钥托管：可以授权其他阿里云账号使用你的密钥

4.4.3 密钥轮换

阿里云 KMS 支持自动轮换，但需要手动开启。轮换周期可以设置为 365 天、180 天或 90 天。

# 开启自动轮换，周期 180 天
aliyun kms SetKeyRotationPolicy \
    --KeyId <key-id> \
    --EnableAutomaticRotation true \
    --RotationInterval 180

我个人建议，如果合规要求不严格，用 365 天就够了。但如果涉及金融或医疗数据，最好用 90 天。

4.5 三大云厂商 KMS 对比

为了方便你选择，我整理了一个对比表格：

特性	AWS KMS	Azure Key Vault	阿里云 KMS
HSM 支持	默认 HSM	Premium 层支持	默认 HSM
自动轮换	支持（每年一次）	需自定义	支持（可配置周期）
加密上下文	支持	不支持	支持
BYOK	支持	支持	支持
最大加密数据量	4KB	无限制（通过 SDK）	4KB
密钥别名	支持	不支持	支持

4.6 密钥轮换策略的最佳实践

密钥轮换是个老生常谈的话题，但真正做好的团队不多。我总结了几条经验：

自动轮换优于手动轮换：人总会忘，机器不会。能用自动轮换就别手动。
轮换周期要合理：太频繁影响性能，太稀疏增加风险。我一般建议 180 天。
旧密钥不要立即删除：保留至少一个轮换周期，确保历史数据都能解密。
轮换后更新依赖：如果应用缓存了密钥版本，轮换后要通知它们刷新。
审计轮换操作：每次轮换都要记录日志，方便事后追溯。

我曾经犯过的错：有一次我手动轮换了 AWS KMS 密钥，但忘了更新 Lambda 函数的权限。结果 Lambda 还在用旧密钥的权限，新密钥没有授权，导致线上服务中断了 10 分钟。从那以后，我每次轮换都会先检查权限策略，确保新旧密钥都有对应的授权。

4.7 本章知识体系

下面这张图总结了三大云厂商 KMS 的核心流程和轮换策略：

从这张图可以看出，三大云厂商的 KMS 流程基本一致：创建密钥 → 使用密钥加密/解密 → 定期轮换 → 审计监控。区别主要在于轮换的实现方式和自动化程度。

好了，这一章的内容就到这里。密钥管理是个细活，但只要你用好 KMS，就能把大部分风险挡在门外。记住：密钥不在你手里，才是最安全的。