📚 课程目录第2章密钥管理基础

2. 密钥管理基础：对称密钥与非对称密钥

聊密钥异常检测之前，得先把密钥本身搞明白。你想想看，一个连密钥怎么生成、怎么用、什么时候该换都不清楚的检测引擎，怎么可能靠谱？

这一节我把对称密钥、非对称密钥，还有密钥从生到死的完整生命周期给你捋一遍。都是我这些年做安全项目实打实积累下来的经验。

对称密钥，说白了就是加密和解密用同一把钥匙。我刚开始接触密码学的时候觉得这很直观——就像你用一把钥匙锁门，也用同一把钥匙开门。

但实际项目里你会发现，这把"钥匙"怎么安全地交到对方手里，才是真正的难题。

核心特点：加密解密速度快，适合大数据量加密，但密钥分发需要安全通道。

常见的对称算法有 AES（我主力推荐）、SM4（国标场景）、ChaCha20（移动端友好）。以 AES-256 为例：

// 伪代码：对称加密示例
key = "这是一个256位的密钥材料"
ciphertext = AES_Encrypt(plaintext, key)
plaintext = AES_Decrypt(ciphertext, key)
// 加密解密用的是同一个 key

我在项目中遇到过一件事：有团队把对称密钥硬编码在配置文件里，结果代码泄露后整个数据库被脱了个干净。记住——密钥永远不该出现在源码、配置文件或日志里。

非对称密钥，加密用公钥，解密用私钥。公钥可以公开，私钥必须保密。这样密钥分发的难题就解决了——别人拿公钥加密数据发给你，只有你用私钥能解开。

但代价是什么？慢。RSA-2048 做一次私钥解密，比 AES-256 慢上千倍。所以我个人习惯：非对称只用来加密对称密钥或做数字签名，实际数据加密还是交给对称算法。

我的建议：不要非此即彼。实际系统中两者配合使用——非对称交换对称密钥，对称密钥加密业务数据。这叫"混合加密"，TLS 就是这么干的。

选哪个，看场景。

我曾经踩过一个坑：给一个 IoT 项目选型时，为了"省事"全用了 RSA 加密每条设备上报的数据，结果网关 CPU 直接拉满，延迟飙到不可接受。后来改成 ECDH 交换 AES 密钥，问题就解决了。选型这事，真不能拍脑袋。

密钥不是生成出来就能扔在那不管的。它有自己的生命周期：生成、分发、使用、轮转、归档、销毁。每个阶段都可能出问题，每个阶段都需要监控和审计——这就是我们做密钥异常检测的根基。

下面这张图是我梳理的密钥生命周期全流程，你看一遍就能建立起整体认知：

你看，密钥从生成到销毁正好六个节点，分成"活跃阶段"和"退役阶段"。我画这个图的时候特意把轮转和生成用虚线连起来——轮转不是终点，而是新一轮生命周期的起点。

每个阶段都有坑，我一个个说。

密钥得有足够的随机性。我在项目中见过用时间戳 + 用户ID拼出来的"密钥"，那玩意儿用字典树几分钟就能爆破。个人习惯：一定要用密码学安全的随机数生成器（CSPRNG），比如 Linux 的 /dev/urandom，或者直接调用 KMS 生成。

对称密钥分发必须加密传输，非对称公钥分发的关键是验证身份。我建议走双向 TLS 或预置证书，千万别明文传密钥文件——这是我见过最多的安全漏洞之一。

密钥在使用中需要被保护。内存中用完要清零，磁盘上建议用内存盘或加密存储。核心原则：密钥只在需要时短暂出现，用完立刻擦除。

老密钥用久了，被破解的风险就越大。轮转就是定期换新密钥。我曾经遇到一个金融系统，RSA 密钥用了三年没换过，审计时直接被开了高危漏洞。我建议：对称密钥每 90 天轮转一次，非对称密钥每 1~2 年轮转一次，具体看合规要求。

已经退役但可能还有历史数据需要解密的密钥，不能直接删，得归档保存。归档的密钥要加密存储，并设置严格的访问审计。说白了就是"冷冻起来，但随时能查"。

确认密钥不再需要了，必须彻底销毁。软件删除要覆写多遍，硬件密钥要物理破坏。我曾经踩过一个坑：以为删了文件就完事了，结果 forensic 工具从磁盘残留里把密钥恢复了出来。嗯，那之后我再也不敢小瞧销毁这一步了。

特别注意：密钥销毁必须有"双重确认"机制——一人操作、一人复核，并且全程记录日志。密钥销毁不可逆，手抖一下可能就造成数据永久丢失。

一点经验：密钥生命周期管理最好全自动化。人肉操作密钥，十个有八个会出事。引入 KMS 或密钥管理平台，把轮转、归档、销毁的流程写进代码里，比你写十页安全规范都管用。

对称密钥和非对称密钥各有各的用场，密钥生命周期每个环节都牵扯到安全风险。搞懂了这些基础，你才能理解为什么需要一套密钥异常访问检测引擎——因为密钥在生命周期的每个阶段都可能被"滥用"或"误用"，而我们就是要盯着这些异常行为。