日志加密基础：对称加密与非对称加密原理，常用算法（AES、RSA、SM4），密钥生命周期管理
对称加密：一把钥匙开一把锁
对称加密，说白了就是加密和解密用同一个密钥。就像你家入户门锁，一把钥匙既能锁门也能开门。审计日志里大量数据需要实时写入、快速读取，对称加密的性能优势就成了首选。
我在项目中曾遇到一个案例：某支付系统每天产生 200GB 的流水日志，起初用了非对称加密，结果写入队列直接堵死，CPU 飙到 99%。后来换成 AES-256-GCM，吞吐量提升了将近 20 倍。说白了，日志加密的场景里，性能是第一道坎。
| 特性 | 对称加密 | 非对称加密 |
|---|---|---|
| 密钥数量 | 1 个 | 2 个（公钥+私钥） |
| 加密速度 | 极快（硬件加速） | 慢（数学运算重） |
| 典型用途 | 大数据量加密 | 密钥交换、数字签名 |
| 算法举例 | AES、SM4、ChaCha20 | RSA、ECC、SM2 |
非对称加密：快递柜与取件码
非对称加密，你可以想象成快递柜。公钥是投递口（谁都能往里塞东西），私钥是你的取件码（只有你能打开）。审计日志场景下，非对称加密一般用在两个地方：一是安全分发对称密钥，二是对日志做数字签名防止篡改。
不过我得提醒一点：千万别拿 RSA 直接加密日志正文。RSA 对数据长度有限制，而且慢得让人抓狂。我见过有人把整条 JSON 日志用 RSA 加密，结果解密队列天天堆积告警——后来改成“混合加密”方案才解决。
避坑指南：我曾经在日志采集端直接拿 RSA 加密整条记录，上线后生产日志延迟暴涨。后来换方案：用随机生成的 AES 会话密钥加密日志，再用接收方公钥加密这个会话密钥。既安全又高效。
常用算法实战要点
说说三个主流算法。在我负责过的金融项目里，AES 是主力，SM4 是合规必备，RSA 是最后一张牌。
- AES-256-GCM：推荐模式。自带认证标签，能同时保证机密性和完整性。我习惯用 256 位密钥，加 96 位随机 IV，性能和安全平衡。
- SM4：国密标准，必须支持。结构类似 AES，密钥长度 128 位。别听网上说“SM4 不如 AES 安全”，实际在金融场景下两者安全级别等价，只是生态兼容性差异。
- RSA-4096：密钥交换的首选。千万别用 1024 位，已经 deprecated 了。我建议直接用 4096 位，虽然加解密慢，但密钥交换只做一次，影响不大。
# 我常用的 Python 代码片段 —— AES-GCM 加密一条日志
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os
key = AESGCM.generate_key(bit_length=256) # 生成 256 位密钥
aesgcm = AESGCM(key)
nonce = os.urandom(12) # 96 位随机 nonce
ciphertext = aesgcm.encrypt(nonce, b"log entry: amount=1200, time=2025-03-12", None)
# 存储时：nonce + ciphertext 一起写入日志文件
# 解密时拿到 nonce 再调用 decrypt嗯，这里要特别注意：nonce 不能重用。我见过一个同事把 nonce 固定写死，结果两个不同日志块用了相同 nonce，被安全审计发现问题。代价很大。
密钥生命周期管理
密钥从生到死，每个环节都可能翻车。我把它拆成五个阶段，你想想看哪个阶段最容易出问题？
- 生成：必须用真随机数发生器（比如 /dev/urandom 或硬件 TRNG）。别用伪随机库，容易被预测。
- 分发：对称密钥的分发是最危险的时刻。我习惯用“信封加密”：A 端生成对称密钥，然后用 B 端的 RSA 公钥加密后传输。
- 使用：密钥明文只在内存里存在，用完立即清零。我曾经在 C 代码里用 memset 清零，结果编译器优化掉了——后来改成 volatile 指针或调用 SecureZeroMemory。
- 轮换：金融合规要求至少每 90 天轮换一次加密密钥。我通常设 30 天自动轮换，给运维留缓冲。
- 销毁：密钥不再使用时，必须物理销毁（比如删除文件并覆写，或销毁 HSM 中的密钥句柄）。
小技巧：审计日志加密场景里，我常用 KMS（密钥管理服务）替代本地存密钥。比如 AWS KMS 或阿里云 KMS，轮换、审计、权限控制都现成。即便在机房自建，也会用 KMIP 协议统一管理。
我在实际项目中的选择习惯
日志加密没有银弹。我一般会画个简单的决策树：
- 如果日志只在内部网络流转，且对性能极度敏感 → AES-256-GCM + 密钥约定（pre-shared key）
- 如果日志需要跨组织传输，或者要满足国密合规 → SM4 + SM2 做密钥交换
- 如果需要长期保存且事后可审计（比如监管要求保留 5 年） → AES-256-GCM + RSA-4096 密钥信封
核心原则：对称加密保性能，非对称加密保安全，密钥生命周期保合规。三者缺一不可。
记得有一次做渗透测试，测试人员发现我们的密钥轮换日志明文记录了旧密钥的散列值——虽然散列不可逆，但合规要求“完全不可逆推”。后来我把轮换机制改成了直接销毁旧密钥，只保留加密后的密文，才通过审计。这些小细节，实战中一个都逃不掉。