📚 课程目录第4章密钥轮换策略与自动轮换配置

4. 密钥轮换策略与自动轮换配置

密钥轮换这事儿，说简单也简单，说复杂也挺折腾。我在项目里见过不少团队，要么完全忘了轮换这回事，要么手动轮换到一半把自己搞晕了。

说白了，密钥轮换的核心目的就一个：缩短密钥的暴露窗口。你想想看，一个加密密钥用了一年，跟用一个月的风险能一样吗？

我个人习惯是，每个加密场景都要明确回答三个问题：多久换一次？谁负责换？换了之后旧密钥怎么办？

4.1 为什么需要轮换？

有些朋友觉得密钥轮换麻烦，不换也没出事。嗯，这种心态我特别理解，但有几个场景会让你不得不换：

合规要求：很多行业标准（比如PCI DSS、SOC2）明确要求定期轮换加密密钥
密钥泄露风险：员工离职、代码泄露、日志误暴露，这些事每天都在发生
密码学算法退化：随着计算能力提升，旧算法的安全强度可能不够了

我曾经碰到一个客户，S3桶里存了三年多的敏感数据，密钥从来没换过。后来发现一个离职员工的笔记本里有旧密钥的备份。嗯，数据全得重新加密——那工作量，简直噩梦。

4.2 关键轮换参数

轮换策略里，有四个参数你得清楚：

参数	含义	我的建议值
轮换周期	两次轮换之间的时间间隔	180天（生产环境）
保留期	旧密钥版本保留多久	至少365天（考虑数据解密）
同步窗口	旧密钥彻底失效前的过渡期	72小时（应用程序切换时间）
告警阈值	距离下次轮换多少天触发告警	30天（给自己留缓冲）

我记得有一次，一个团队把轮换周期设成了30天。结果每个月要协调所有业务系统更新密钥引用，运维压力巨大。后来我建议改成180天+自动化，立马轻松多了。

4.3 AWS KMS 自动轮换配置

AWS KMS 提供了两种轮换方式，我分开讲：

4.3.1 启用自动轮换

这个最简单，KMS 托管密钥直接支持一键开启。配置步骤：

打开 KMS 控制台，选择目标密钥
进入"密钥轮换"标签页
点击"启用自动轮换"
确认（默认周期365天，不可修改）

用 CLI 也方便：

# 启用自动轮换
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

# 返回示例
{
    "KeyRotationEnabled": true
}

注意：自动轮换只适用于对称加密的 KMS 托管密钥（kms 密钥）。自定义密钥（自定义密钥存储）和不对称密钥无法使用自动轮换，得自己写脚本。

4.3.2 自动轮换的原理

你可能会问：轮换之后，旧密钥加密的数据还能解密吗？

答案是：能。KMS 的轮换不是销毁旧密钥，而是生成新的密钥版本。加密时默认使用最新的密钥版本，解密时根据数据中存储的密钥 ID 自动匹配对应版本。

这也是为什么我特别强调密钥版本管理。说白了，KMS 的自动轮换只是帮你生成新版本，不会自动重新加密已有数据。

4.4 自动轮换的最佳实践

我在实践中总结了几条必须遵守的原则：

先测试再启用：先在非生产环境跑一个轮换周期，确认所有依赖服务都正常
监控密钥版本数量：KMS 密钥版本超过100个会影响性能，建议定期清理旧版本
结合 CloudTrail 审计：每次轮换都会产生事件，用来做合规审计特别好使

4.3.3 自定义轮换周期

自动轮换的365天不能满足所有需求？我理解。比如金融行业要求90天轮换一次。这时候可以自己写 Lambda 函数手动触发：

import boto3
import datetime

kms = boto3.client('kms')

def lambda_handler(event, context):
    # 获取所有客户管理密钥
    paginator = kms.get_paginator('list_keys')
    for page in paginator.paginate():
        for key in page['Keys']:
            # 获取密钥轮换状态
            status = kms.get_key_rotation_status(KeyId=key['KeyId'])
            if not status['KeyRotationEnabled']:
                # 检查上次轮换时间
                response = kms.describe_key(KeyId=key['KeyId'])
                key_metadata = response['KeyMetadata']
                last_rotation = key_metadata.get('LastRotationDate')
                
                if last_rotation:
                    days_since_rotation = (datetime.datetime.now() - last_rotation.replace(tzinfo=None)).days
                    # 如果超过90天未轮换，触发轮换
                    if days_since_rotation >= 90:
                        kms.rotate_key_on_demand(KeyId=key['KeyId'])
                        print(f"已轮换密钥: {key['KeyId']}")
                else:
                    # 从未轮换过的密钥，立即轮换
                    kms.rotate_key_on_demand(KeyId=key['KeyId'])
                    print(f"首次轮换密钥: {key['KeyId']}")

我自己最常用的方案是：开启自动轮换 + 自定义监控告警。自动轮换保证基础合规，监控告警在轮换失败时及时通知我。两边互补，基本不出问题。

4.5 验证轮换配置是否生效

配置完之后，怎么确认轮换真的在跑？我习惯用三步验证法：

查看 CloudTrail 事件：搜索 RotateKey 事件，看有没有定时出现
列出密钥版本：用 list-key-versions 看版本数变化
发一次测试请求：加密一条小数据，确认新版本被用于加密

# 查看密钥版本
aws kms list-key-rotations --key-id 1234abcd-12ab-34cd-56ef-1234567890ab

# 测试加密
aws kms encrypt \
    --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
    --plaintext fileb://test.txt \
    --output text \
    --query CiphertextBlob | base64 --decode > encrypted.enc

我记得有一次，一个客户说自动轮换已经开启了，但 CloudTrail 里始终没有轮换事件。查了半天发现——密钥创建时间还不到365天，刚开启了还没到轮换窗口。嗯，AWS 自动轮换是从创建密钥那天开始算的，不是从开启那天算的。

4.6 轮换策略的核心逻辑图

下面这张图，我把整个轮换策略的决策流程和生命周期画了出来，你看看就明白了：

4.7 轮换失败的典型场景

我再跟你分享几个轮换翻车案例：

权限不足：Lambda 执行角色没有 kms:RotateKeyOnDemand 权限，轮换静默失败
版本超限：密钥版本超过100个后，新轮换会失败（我建议定期清理120天前的版本）
依赖旧版本ID：有些应用程序写死了密钥版本 ID，轮换后直接解密失败

我曾经碰到一个开发团队，他们用 KMS 加密数据库连接字符串，代码里直接写了密钥的旧版本 ARN。轮换一跑，应用全挂了，连不上数据库。从那以后，我再三强调：永远不要依赖具体密钥版本 ID，用别名或者自动指向最新版本。

4.8 最终的配置建议

说了这么多，我给你一个最实际的方案：

所有生产密钥开启自动轮换（默认365天，够一般场景用）
Lambda 脚本做补充：90天强制轮换一次，满足更高合规要求
CloudTrail + SNS 告警：轮换失败时立即通知
季度审计：检查密钥版本数量和轮换日志

这套组合拳，我在好几个项目里都验证过，基本没出过问题。你可以直接拿来用。