📚 课程目录第3章密钥的创建与管理

密钥的创建与管理

好，我们正式开始讲密钥。嗯，密钥是KMS的核心资产。你所有的加密操作，最终都绕不开它。跨账号共享，本质上也是共享某个密钥的使用权。所以，怎么创建、怎么管，决定了后续流程是否顺滑。

我个人习惯把KMS的密钥分成两种看：一种是“默认钥匙”，也就是AWS托管密钥；另一种是“自备钥匙”，也就是我们说的客户主密钥（CMK）。跨账号共享只能用CMK，这是第一条规矩。

1. 密钥类型：对称 vs 非对称

CMK又分对称和非对称。咱们先看一个对比表，这样更直观。

特性	对称密钥（SYMMETRIC_DEFAULT）	非对称密钥（RSA / ECC）
加密/解密	同一个密钥，既加密也解密	公钥加密，私钥解密
密钥材质	256位AES	RSA 2048/4096 或 ECC 曲线
跨账号共享	支持（通过密钥策略）	支持（通过密钥策略）
适用场景	S3加密、EBS加密、RDS加密	数字签名、公钥分发、加密通信
API调用	Encrypt / Decrypt	Sign / Verify 或 Encrypt / Decrypt（私钥）

你想想看，对于大多数跨账号共享场景——比如把加密过的S3对象分享给另一个账号——对称密钥就够了。对称密钥快，而且KMS对它的支持最成熟。

我的建议：除非你明确需要数字签名或公钥加密，否则一律用对称密钥。我在项目中遇到过有人硬上非对称密钥，结果为了管理私钥翻了好几倍的复杂度。得不偿失。

2. 创建密钥：控制台 vs CLI

创建CMK有两种路子。控制台适合初学者，CLI适合集成到自动化脚本里。我一般用CLI，因为方便回放和审计。

2.1 控制台创建

步骤很简单：

打开KMS控制台，点击「创建密钥」。
选择密钥类型：对称。
填写别名（Alias），比如 production/s3-shared-key。
添加标签（Tags），比如 Environment=Production。
定义密钥管理员（谁可以管理这把钥匙）。
定义密钥使用者（谁可以用这把钥匙做加密/解密操作）。

这里有个坑——控制台默认会给你生成一个密钥策略。这个策略通常只允许当前账号使用。你要跨账号共享，后面必须手动修改策略。

2.2 CLI创建（推荐）

# 创建对称CMK
aws kms create-key \
    --origin AWS_KMS \
    --key-spec SYMMETRIC_DEFAULT \
    --description "Shared key for cross-account S3 encryption" \
    --tags TagKey=Environment,TagValue=Production \
    --region us-east-1

# 创建成功后，你会得到一个KeyId（比如 1234abcd-12ab-34cd-56ef-1234567890ab）
# 立刻创建别名，方便后续引用
aws kms create-alias \
    --alias-name alias/production/s3-shared-key \
    --target-key-id 1234abcd-12ab-34cd-56ef-1234567890ab

    关键点：创建时别忘记加 --origin AWS_KMS。如果你用 EXTERNAL，密钥材质在你手里，KMS没法自动轮转，跨账号共享也会多一层麻烦。

我个人习惯在创建完密钥后，立刻设置别名和标签。为什么？因为KeyId是一长串UUID，根本记不住。别名就像人类可读的名字。我在项目中遇到过团队更新别名后没通知下游，结果别人用旧别名调用失败……后来我们强制规定：别名一旦确定，只增加版本号，不删不改。

3. 密钥轮转：自动 vs 手动

密钥轮转是个老话题。AWS KMS对对称密钥支持自动年度轮转。非对称不支持自动轮转。

你可以在创建时或者在密钥详情页开启自动轮转：

# 开启自动轮转（每年一次）
aws kms enable-key-rotation --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

# 查询轮转状态
aws kms get-key-rotation-status --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

注意：自动轮转只会产生新的密钥材质用于加密新数据。已经用旧材质加密的数据，依然可以用旧的密钥版本解密。KMS会帮你管理所有历史版本。你不需要关心历史密钥的存储。

我曾经犯过一个低级错误：开启自动轮转后，以为再也不用手动更新。结果合规审计要求每季度轮转一次，自动化扫描工具直接报警。所以，如果你需要更短的轮转周期，必须自己写脚本做手动轮转。

手动轮转的方法：

创建新的CMK（新KeyId）。
更新别名，指向新密钥。
重新加密关键数据（如果需要）。
保留旧密钥一段时间，确保解密兼容。

4. 密钥的别名、标签和描述

这三个东西看似简单，但管不好会出乱子。

属性	作用	我的建议
别名（Alias）	人类可读的名称，用于调用API	用层级命名，如 `env/team/app`
标签（Tag）	分类、成本分配、访问控制	至少加 `Environment` `Owner` `CostCenter`
描述（Description）	方便人理解密钥用途	写清楚用途、创建人、预期轮转周期

避坑指南：我曾经见过有人直接在别名栏里敲了个空格，结果整个团队用别名调用API全部失败。KMS别名不能包含空格和特殊字符，只能用字母、数字、下划线和连字符。另外，别名在整个账号内必须唯一。

5. 密钥状态的生命周期

密钥不是创建完就完事了。它有状态变化。你作为管理员，必须理解这些状态。

Enabled：正常工作，可以加密/解密。
Disabled：无法使用，但数据还在，密钥材质还在。
PendingDeletion：等待删除，有等待期（默认7-30天）。
PendingReplicaDeletion：多区域副本删除中。

你为什么要把密钥禁用？嗯，最常见的原因是误操作或者安全事件。比如你怀疑某个密钥泄露了，可以立刻禁用，然后再评估后续动作。

删除密钥是不可逆的！所以KMS强制你有一个等待期。在等待期内，你可以取消删除。一旦过了等待期，密钥材质永久销毁，用该密钥加密的数据将永远无法解密。

血泪教训：我曾经在测试环境误删了一把密钥，导致几十个测试用例的密文瞬间变成废数据。虽然只是测试环境，但重跑所有自动化测试花了我整整一个周末。所以，我的铁律是——生产环境密钥必须开启自动备份，同时设置标签 Protect=Critical，并且在删除前至少请另一个人复核。

6. 知识体系框架图

看，我把本章的核心逻辑画成了一张图。密钥从创建到退役，每一步都绕不开状态管理、命名规范和权限控制。

你看到了吧？密钥的“生老病死”都在这个流程里。跨账号共享的核心步骤——配置密钥策略和授权——我会在下一部分详细展开。但首先，你得先把密钥创建好，把基础打稳。

    总结一句话：创建密钥时，选对称、配别名、加标签、开轮转。这套组合拳打完，你的密钥管理基础就算打好了。