📚 本文属于专题：数据安全与国密加密
为什么密钥管理比算法更关键
SM4、AES 在正确使用下没人能暴力破解。攻击者从不去硬碰算法，而是去找密钥：翻代码仓库、翻配置文件、翻备份、翻日志。密钥一旦泄露，加密就等于没做。所以密评、等保都把密钥管理列为核心检查项。下面五个反模式，是踩坑最多的地方。
反模式一：硬编码密钥
把密钥写死在代码、配置文件或脚本里。后果：密钥随代码进了 Git 历史，谁有仓库权限谁就有密钥；改密钥要重新发版。正确做法：密钥从不进代码，运行时从密钥管理系统（KMS）或密码机动态获取。
反模式二：一把钥匙走天下
全系统、所有数据、所有环境共用一把密钥，且从不更换。后果：一把泄露，全盘沦陷；无法按业务/数据分级隔离；不满足密钥定期更新要求。正确做法：按用途、按数据分级、按环境拆分密钥，并设定明确的轮换周期。
反模式三：密钥和密文存在一起
把加密密钥和它加密的数据放在同一个数据库、同一台服务器、同一个备份里。后果：攻击者拿到数据的同时也拿到了密钥，加密毫无意义。正确做法：密钥与密文物理/逻辑分离，密钥进密码机或独立的 KMS，业务侧只拿到密文和调用句柄。
反模式四：用 Excel/人工台账管密钥
用电子表格、文档甚至纸质台账记录密钥及其状态。后果：密钥明文散落、无访问审计、轮换靠人记、人走了密钥就成了无主黑盒。正确做法：用 KMS/密码机统一托管密钥全生命周期，所有操作可审计。
反模式五：没有撤销与销毁流程
密钥只管生成和使用，从不考虑"怎么作废、怎么销毁、怎么证明已销毁"。后果：泄露后无法快速撤销，过期密钥长期游荡，密评时拿不出销毁记录。正确做法：建立密钥撤销、归档、销毁的规范流程，且每一步可审计、可举证。
正确做法：分层密钥 + 集中托管
成熟的密钥体系通常是三层密钥架构：
| 层级 | 作用 | 存放 |
|---|---|---|
| 根密钥 / 主密钥 | 保护下层密钥 | 硬件密码机内，永不出硬件 |
| 密钥加密密钥（KEK） | 加密数据密钥 | 由根密钥保护 |
| 数据密钥（DEK） | 实际加解密数据 | 密文形式存储，用时解封 |
配合 KMS 统一管理产生、分发、轮换、撤销、销毁全生命周期，上面五个反模式基本一次性解决。
快速自查
- 代码/配置里能搜到明文密钥吗？（中 → 反模式一）
- 所有数据共用一把密钥、且从没换过吗？（中 → 反模式二）
- 密钥和密文在同一个库/备份里吗？（中 → 反模式三）
- 密钥是靠人记、靠表格管的吗？（中 → 反模式四）
- 能拿出某把密钥的销毁记录吗？拿不出 → 反模式五。
结论
密钥管理的水平，直接决定加密是不是"纸上加密"。五个反模式里中了任意一个，都值得优先整改。最省力的根治方式是引入 KMS + 硬件密码机做集中托管和分层密钥。想评估你们当前的密钥管理成熟度，可了解密钥管理系统 KMS或联系我们。