📚 课程目录第2章 AWS KMS密钥类型

2、AWS KMS 密钥类型：对称与非对称

好，咱们来聊个核心概念。KMS 里的密钥分两种：对称密钥和非对称密钥。很多人一开始觉得这玩意儿偏理论，但我在项目中吃过亏——选错密钥类型，轻则性能翻车，重则架构推倒重来。搞懂它，比你想的更重要。

2.1 对称密钥（Symmetric KMS Key）

说白了，对称密钥就是“一把钥匙开一把锁”。加密和解密用同一个密钥材料。AWS KMS 默认创建的就是这种，也是 90% 场景下的首选。

我记得刚接手一个迁移项目时，对方非要全上非对称。我就问他：你的数据量有多大？他说每天几个 TB。我反问：你准备额外付多少 API 调用费？他沉默了。对称密钥在性能上有优势——加解密操作在 KMS 服务端完成，你拿不到明文密钥，安全性有保障。

关键点：对称密钥的加解密操作完全由 AWS KMS 执行。你的应用只通过 API 调用，传入密文或明文，KMS 帮你算完。密钥材料永远不会暴露给客户端。

支持的操作就那么几个：

Encrypt – 加密最多 64 KB 的数据
Decrypt – 解密最多 64 KB 的数据
GenerateDataKey – 生成数据密钥，用于大数据量的信封加密（这个最常用）
ReEncrypt – 数据在不同 KMS 密钥之间迁移

我的建议：S3 的 SSE-KMS、EBS 加密、RDS 加密，统统用对称密钥。不要想复杂了。KMS 和这些服务深度集成，你只要在控制台勾选就行。

2.2 非对称密钥（Asymmetric KMS Key）

非对称密钥嘛，听起来高大上，其实就是一对儿钥匙：一个公钥（Public Key），一个私钥（Private Key）。公钥谁都给，私钥自己捂好。

为什么会用到非对称？举个例子：你要跟第三方系统交换加密数据。对方不是 AWS 用户，没法直接调 KMS API。这时候对称密钥就尴尬了——你没法安全地把对称密钥传给对方。非对称就解决了：你把公钥丢给对方，他用公钥加密，你拿私钥解密。

避坑：我曾经帮一个团队排查问题，他们用非对称密钥做 S3 SSE-KMS 加密。结果发现 SSE-KMS 根本不支持非对称密钥！S3 服务端加密要求用对称密钥，因为只有对称才能支持高速的 GenerateDataKey 操作。嗯，这里要注意。

非对称密钥支持两种用途：

加密和解密（Encrypt/Decrypt） – 使用 RSA 密钥对，公钥加密，私钥解密
签名和验证（Sign/Verify） – 使用 ECC 或 RSA 密钥对，适合代码签名、文档签名场景

重要限制：非对称密钥不支持 GenerateDataKey！所以你不能用它做信封加密。单个 Encrypt 操作也只能处理 1 KB（RSA）或 256 字节（ECC）的数据。说白了，非对称密钥不是为了大规模数据加密设计的。

2.3 对称 vs 非对称：对比表格

我习惯把关键差异列成一张表，选型时扫一眼就知道该用哪个。

对比维度	对称密钥	非对称密钥
密钥材料	单密钥，加密和解密共用	公钥 + 私钥，成对出现
加解密性能	高（KMS 服务端处理）	低（受限于数学运算复杂度）
支持的操作	Encrypt, Decrypt, GenerateDataKey, ReEncrypt	Encrypt, Decrypt, Sign, Verify
最大加密数据量	64 KB（Encrypt API）/ 无限制（配合数据密钥）	1 KB（RSA）/ 256 字节（ECC）
外部访问	需要 KMS API 权限	公钥可自由导出，无需 API
典型场景	S3 加密、EBS、RDS、DynamoDB	跨账户加密、代码签名、文档验证
费用	便宜（月费 + API 调用费）	略贵（同上，但操作更耗资源）

2.4 选型决策指南

说白了，选型就三条：

如果是云内服务之间加密（S3、EBS、RDS 等）→ 无脑选对称密钥。KMS 集成做得滴水不漏，桶策略写起来也简单。
如果有外部用户/系统需要加密数据给你 → 非对称密钥。你把公钥放到你的网站或 CF 上，对方下载后加密，私钥只有你的人能看到。
如果需要签名和验签（CI/CD 流水线、软件发布）→ 非对称密钥。记得选 ECC 或 RSA 2048 以上。

小技巧：如果你不确定选哪种，可以先去 AWS 控制台创建一个密钥，创建过程会有向导。你只要回答几个问题（用途、访问者类型），它就会推荐正确的密钥类型。不过我还是建议你手动理解差异，别全交给 UI。

2.5 KMS 密钥的配置示例

虽然密钥类型在创建时就定死了，但创建过程没什么特别。我这儿贴一个用 AWS CLI 创建对称密钥的例子，你感受下：

# 创建对称加密密钥（默认）
aws kms create-key \
    --description "My Symmetric Key for S3 Encryption" \
    --key-usage ENCRYPT_DECRYPT \
    --origin AWS_KMS

# 创建非对称加密密钥（RSA）
aws kms create-key \
    --description "My Asymmetric Key for External Sharing" \
    --key-usage ENCRYPT_DECRYPT \
    --key-spec RSA_4096 \
    --origin AWS_KMS

# 创建非对称签名密钥（ECC）
aws kms create-key \
    --description "My Code Signing Key" \
    --key-usage SIGN_VERIFY \
    --key-spec ECC_NIST_P256 \
    --origin AWS_KMS

注意：key-usage 参数决定了密钥能干什么。ENCRYPT_DECRYPT 的密钥不能签名，SIGN_VERIFY 的密钥也不能加密。创建后就不能改了！我曾经手滑创建错了一次，只能删掉重新建。

创建完非对称密钥后，你可以导出公钥给对方：

# 获取公钥
aws kms get-public-key \
    --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
    --output text \
    --query PublicKey | base64 --decode > public_key.der

嗯，到这里你应该对这两种密钥类型心里有数了。对称密钥是日常主力，非对称密钥是特定场景的利器。记住这个区分，写桶策略的时候你就知道该引用哪种密钥了。