KMS权限控制与审计日志联动教程 - 第2节
KMS 密钥类型：对称密钥与非对称密钥
密钥的类型，说实话是每个用 KMS 的人最先要搞明白的事。你想想看，选错了密钥类型，后面权限控制和审计日志可能全白搭。我刚开始接触 AWS KMS 的时候，就被“对称”和“非对称”这两个词绕晕过——后来踩了几个坑才真正理解。
对称密钥：最简单也最常用
对称密钥，说白了就是加密和解密用同一把钥匙。你在本地用 KMS 的 Encrypt API 加密一段数据，得到密文；回头再用 Decrypt API 传同样的密钥 ID 进去，就能解出来。整个过程对应用程序来说是透明的。
个人心得： 我负责过的一个日志加密项目，每天几百万条日志用对称密钥加密，性能完全扛得住。对称密钥的加解密延迟通常在 1~2 毫秒内，适合大数据量场景。
对称密钥的典型场景有哪些？
- 静态数据加密（S3、EBS、RDS 等 AWS 服务集成）
- 数据库字段级加密（比如敏感个人信息）
- 应用程序本地缓存加密密钥的包装
非对称密钥：公开分享，私密解密
非对称密钥包含一对钥匙：公钥和私钥。公钥可以公开分发，私钥永远留在 KMS 里。你可以用公钥进行加密或签名验证，但只有私钥才能解密或签名。这个特性让它特别适合密钥交换和数字签名场景。
我记得有一次给客户做跨账号数据共享，对方要求不暴露任何加密密钥。用非对称密钥的 Encrypt（公钥加密）正好解决——对方拿到公钥后加密数据，我们这边用私钥解密，全程不需要传递私钥。
注意： 非对称密钥加解密性能远低于对称密钥（通常 5~20 毫秒），且密文大小会膨胀。你如果批量加密视频文件，用非对称会慢到怀疑人生。我在一个 IoT 项目中就吃过这个亏——后来改成对称密钥 + KMS 信封加密才解决问题。
对称 vs 非对称：一表看懂
| 对比维度 | 对称密钥 | 非对称密钥 |
|---|---|---|
| 密钥数量 | 单把密钥 | 公钥 + 私钥对 |
| 性能 | 高（~1ms） | 低（5~20ms） |
| 适用场景 | 大规模数据加密 | 密钥交换、数字签名 |
| 密钥分发 | 需要安全信道 | 公钥可公开 |
| AWS API 支持 | Encrypt / Decrypt | Encrypt / Decrypt / Sign / Verify |
AWS KMS Key Specs：密钥规格到底选哪个？
AWS 给 KMS 定义的密钥规格（Key Specs）很多人觉得复杂，其实核心就两个维度：算法族和密钥长度。
对称密钥规格
目前 AWS 只支持一种对称密钥算法：SYMMETRIC_DEFAULT，背后是 AES-256-GCM。你没看错，没得选。我刚开始也觉得限制太死，后来想明白了——统一算法可以简化审计和安全基线。反正 AES-256 在可预见的未来都够用。
非对称密钥规格
非对称就丰富一些了。下面是 AWS 目前支持的 Key Specs：
| KeySpec 值 | 算法 | 用途 | 密钥长度 |
|---|---|---|---|
| RSA_2048 | RSA | 加密 / 签名验证 | 2048 bit |
| RSA_3072 | RSA | 加密 / 签名验证 | 3072 bit |
| RSA_4096 | RSA | 加密 / 签名验证 | 4096 bit |
| ECC_NIST_P256 | ECDSA | 数字签名 | 256 bit |
| ECC_NIST_P384 | ECDSA | 数字签名 | 384 bit |
| ECC_NIST_P521 | ECDSA | 数字签名 | 521 bit |
| ECC_SECG_P256K1 | ECDSA | 区块链/DApp 签名 | 256 bit |
实战建议： 如果你只需要加解密，无脑选
SYMMETRIC_DEFAULT。如果要跟外系统做签名互通，优先 RSA_2048（兼容性最好）。ECC 性能好但很多老旧系统不支持，我一般在纯内部服务间用 ECC_NIST_P256。
管理密钥与客户管理密钥的区别
这是很多初学者最困惑的点。AWS KMS 里的密钥按谁来管分为两大类：
- AWS 托管密钥（AWS managed keys）：由 AWS 服务自动创建和管理，你不能手动轮换、删除、修改策略。
- 客户管理密钥（Customer managed keys）：你创建、你管。完全控制密钥策略、启用/禁用、轮换、标签、别名。
其实还有第三类——AWS 拥有的密钥（AWS owned keys），但那个你根本看不到，是 AWS 内部用的，本课程不展开。
区别在哪里？一张表说清楚
| 特性 | AWS 托管密钥 | 客户管理密钥 |
|---|---|---|
| 创建方式 | 由 AWS 服务自动创建（如 S3 SSE-KMS） | 用户手动创建（CreateKey API / 控制台） |
| 密钥策略 | 由 AWS 服务默认设置，不可修改 | 用户自定义，可写复杂权限 |
| 自动轮换 | 支持（每年一次，不可配置） | 支持（可配置为每年一次，可通过 CloudTrail 审计） |
| 手动轮换 | 不支持 | 支持（创建新密钥并更新别名） |
| 删除 | 不可手动删除（依赖服务清理） | 可计划删除（7~30 天等待期） |
| 费用 | 免费（仅 API 调用计费） | 每月 $1/Key + API 调用费 |
| 审计日志可见性 | CloudTrail 记录调用，但密钥 ID 可能是服务内部 ID | 完全可见，密钥 ID 和别名都对得上 |
我曾经踩过的坑： 在一个合规项目中，客户要求所有密钥必须能精确审计到谁在什么时候用过。我一开始图省事用了 AWS 托管密钥（S3 自动创建的），结果 CloudTrail 里只显示
AWS Internal 的密钥 ID，根本对不上业务用户。后来全部换成客户管理密钥，配合别名策略才搞定审计需求。
什么时候该选哪个？
我个人的原则很简单：
- 开发 / 测试环境：用 AWS 托管密钥就够了，省事且免费。
- 生产环境且无合规要求：客户管理密钥，至少能控制轮换。
- 需要精细权限控制 + 审计日志：必须客户管理密钥，否则你连
kms:Decrypt是哪个应用调的都查不到。
一句话总结： 选对称密钥处理大数据，非对称做签名和跨系统交互；日常生产用客户管理密钥并开启自动轮换；审计日志需求强烈时，千万别省那 $1/Key 的费用，否则查日志查到你怀疑人生。