4、密钥轮换策略：轮换触发条件、轮换频率设计、轮换安全窗口

密钥轮换这件事，说白了就是给设备换一把新锁。但什么时候换、多久换一次、换的时候怎么保证业务不中断——这三个问题没想清楚，轮换方案就是纸上谈兵。我在好几个项目里都见过“轮换脚本写好了，一上线就把设备全部踢下线”的惨案。嗯，咱们今天就把这三个坑一个一个填上。

4.1 轮换触发条件：不是只有“到期”才换

很多人一提到密钥轮换，第一反应就是“有效期到了就换”。其实触发轮换的场景远不止这一个。我个人习惯把触发条件分成三类：

我曾经在一个智能门锁项目里遇到过这样的情况：密钥有效期设了90天，但第85天的时候，运维同事不小心把密钥库的备份文件传到了公开的代码仓库。虽然5分钟内就撤回了，但按照安全策略，所有关联设备的密钥必须立即轮换。这就是典型的事件触发——等不到90天到期了。

4.2 轮换频率设计：别太勤，也别太懒

轮换频率怎么定？你想想看，频率太高，设备天天在换密钥，电池扛不住、网络开销大；频率太低，密钥长期不变，泄露风险直线上升。我见过一个极端案例：某厂商把密钥有效期设成10年，结果第8年被爆出密钥算法有漏洞，所有设备需要远程升级——那叫一个痛苦。

我个人建议从以下几个维度来权衡：

• 设备资源约束：MCU类设备（比如传感器、门锁）建议30～90天轮换一次；网关或边缘计算设备可以缩短到7～30天。
• 网络质量：设备经常断线？那轮换周期要拉长，避免频繁重试耗尽电池。我记得有个NB-IoT水表项目，设备每天只上报一次数据，轮换周期设成7天根本跑不完，后来改成了90天。
• 合规要求：金融、医疗等行业通常要求密钥最长有效期不超过1年。PCI DSS甚至要求每12个月轮换一次。
• 密钥强度：如果用的是2048位RSA，轮换周期可以长一些；如果是128位AES，建议缩短到半年以内。

4.3 轮换安全窗口：换密钥的“黄金时间”

轮换安全窗口，指的是从旧密钥失效到新密钥生效之间，允许的最大时间差。这个窗口如果设计不好，设备就会“断联”——旧密钥不能用了，新密钥还没拿到，设备直接变砖。

我习惯把安全窗口分成两种模式：

4.3.1 平滑轮换模式（推荐）

设备同时持有新旧两把密钥，在窗口期内两把密钥都有效。设备先使用新密钥通信，平台确认新密钥可用后，再吊销旧密钥。这个窗口通常设为5～30分钟。

// 伪代码：平滑轮换流程
1. 平台生成新密钥对 (K_new_pub, K_new_priv)
2. 平台向设备下发 K_new_pub（旧密钥 K_old 仍然有效）
3. 设备存储 K_new_pub，并开始使用 K_new_pub 加密通信
4. 平台确认收到设备使用 K_new_pub 加密的心跳包
5. 平台吊销 K_old，轮换完成

4.3.2 强制轮换模式（紧急情况）

旧密钥立即失效，设备必须在极短时间内（通常1～5分钟）完成新密钥的获取和激活。这种模式风险高，但适合密钥已经确认泄露的场景。

4.4 核心逻辑：一张图看懂密钥轮换策略

下面这张图把触发条件、频率设计、安全窗口的关系串起来了。你可以把它当作设计轮换策略的检查清单。

4.5 避坑指南：我踩过的几个坑

• 坑一：轮换窗口设得太短——有一次我把安全窗口设成2分钟，结果设备批量轮换时，平台处理不过来，大量设备超时。后来改成10分钟，配合分批轮换，问题解决。
• 坑二：没考虑设备时区——全球部署的设备，如果按UTC时间统一轮换，某些地区的设备正好在业务高峰期被触发。我后来加了一个“轮换窗口偏移量”配置，让设备在本地凌晨执行轮换。
• 坑三：轮换失败没有回滚机制——密钥轮换到一半，平台挂了。旧密钥已经被吊销，新密钥还没下发完。嗯，从那以后我强制要求：轮换操作必须是事务性的，要么全部成功，要么全部回滚。