📚 课程目录第3章对称密钥与非对称密钥

对称密钥与非对称密钥：应用场景与越权风险对比

做 RBAC 审计，绕不开密钥管理这块硬骨头。

我这几年帮企业做安全改造，最怕的就是密钥混用。很多人觉得「都是加密，用哪个不是用」，结果出了事才发现——对称密钥和非对称密钥，根本不是一回事。

咱们先搞清楚这两个家伙到底长什么样，再说它们的越权风险。

对称密钥：一把钥匙开一把锁

简单说，加密和解密用同一个密钥。就像你家大门钥匙，锁门用它，开门也是它。

我早期做过一个金融项目，内部流水传输用的就是 AES-256。速度快，吞吐量大，很适合海量数据加密。但问题也出在这——这把钥匙一旦泄露，全完蛋。

    核心特点：加密和解密使用相同密钥；算法效率高；密钥分发是最大痛点。

常见算法有：AES、DES、3DES、SM4。企业里基本都在用 AES，DES 太老了，已经很少有人碰。

你看下面这个流程图，数据在传输前用密钥加密，到对端再用同一个密钥解密。如果密钥在信道里被劫持，那就等于裸奔。

# 对称加密简单示例
import cryptography
from cryptography.fernet import Fernet

key = Fernet.generate_key()  # 生成密钥
cipher = Fernet(key)

# 加密
data = b"RBAC_Audit_Log_2025"
encrypted = cipher.encrypt(data)

# 解密
decrypted = cipher.decrypt(encrypted)

说白了这个例子就是告诉你——密钥必须安全存储。我在生产环境中见过太多人把密钥写死在代码里，直接硬编码。嗯，这是我最想让你避开的坑。

避坑指南：我曾经审计过一个电商平台，他们把 AES 密钥直接写在 config.py 里，还提交到了 Git。结果被爬虫扫到，几万条订单数据全被拖走。密钥存储，永远别相信「没人能看到」。

非对称密钥：两把锁的世界

非对称就聪明多了。它有一对密钥：公钥和私钥。公钥随便发，私钥自己藏。

你可以把公钥想象成快递柜的投递口——谁都能往里塞东西。私钥是你手机里的取件码——只有你能打开柜子取走包裹。

RSA 和 ECC 是主流。RSA 2048 位以上能用，1024 位已经被破解了。ECC 现在越来越火，同等安全强度下密钥更短，性能更好。

    核心特点：公钥加密，私钥解密；私钥签名，公钥验签；密钥分发相对安全。

我记得在做一个政务系统审计时，发现他们用 RSA 做签名。按理说这个用法是没问题的，但他们犯了个低级错误——把私钥传到了构建镜像里。

# 非对称加密简单示例（示意，非完整代码）
from cryptography.hazmat.primitives.asymmetric import rsa, padding
from cryptography.hazmat.primitives import serialization, hashes

# 生成密钥对
private_key = rsa.generate_private_key(
    public_exponent=65537,
    key_size=2048
)
public_key = private_key.public_key()

# 公钥加密
message = b"audit_log_entry"
ciphertext = public_key.encrypt(
    message,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None)
)

# 私钥解密
plaintext = private_key.decrypt(
    ciphertext,
    padding.OAEP(mgf=padding.MGF1(algorithm=hashes.SHA256()), algorithm=hashes.SHA256(), label=None)
)

你看这个代码流程——公钥能加密，但解不了。只有私钥能解。这就是非对称的优势，分发公钥不用太担心。

应用场景对比

我习惯把这两兄弟的应用场景分得清清楚楚，绝不混用。下面这个表你认真看看。

场景	推荐方案	原因
大量数据加密	对称加密（AES）	速度快，适合批量处理
密钥交换/分发	非对称加密（RSA/ECC）	不需要提前共享密钥
数字签名/身份认证	非对称加密（私钥签名）	防抵赖，公钥可公开验证
会话加密（HTTPS）	混合加密（非对称握手的对称会话）	平衡安全与性能
配置/文件加密	对称加密	简单高效，配置文件体积小

记住这个原则：数据传输量大，优先对称；需要身份验证，想也别想，直接上非对称。

越权风险：密钥搞错了，权限就崩了

这个才是咱们审计的重点——密钥用错地方，导致越权。

我举两个真实案例，你感受一下：

对称密钥当签名用：AES 是对称的，加密者和验证者拥有相同的密钥。这意味着任何能加密的人都可以伪造签名。我在一个 IoT 平台看到过，他们用 AES 给设备下发指令做「签名」——结果攻击者拿到固件里的密钥，直接伪造指令控制了所有设备。
非对称密钥的私钥泄露：私钥是身份的象征。一旦泄露，别人就能用你的私钥签名，或者解密你的通信。我审计过一个 SaaS 系统，私钥存在共享目录下，权限为 777。嗯，结果可想而知。

越权风险总结：

对称密钥：泄露即失全。密钥分发过程是主要攻击面。
非对称密钥：私钥必须隔离。公钥不需要保密，但必须保证真实性。
混合使用时：不要用同一个密钥做加密又做签名。这是行业大忌。

一张图看懂对称 vs 非对称

下面这张图把这两个模型的核心逻辑和越权风险点串起来了。你盯着看几分钟，思路会清晰很多。

一个实用建议：在 RBAC 系统中，推荐用非对称密钥做 JWT 签名（RS256 或 ES256），用对称密钥加密会话流量。这样分工明确，审计时一眼就能看出问题。

说到底，密钥越权这件事，就是「把对的东西放到了错的地方」。你只要记住：每一种密钥都有它该待的位置，不要心疼代码工作量，强制把二者分清楚。

我见过太多项目因为「图省事」直接把对称密钥当万能钥匙用，结果审计时被查出大量越权记录。嗯，这个教训是用真金白银换来的。

下次你再设计一个功能模块，先问自己三个问题：

这个数据需要保密还是需要防抵赖？
密钥需要分发给谁？
如果密钥被拿走了，损失范围有多大？

想清楚这三件事，你基本不会踩坑。