加密基础概念：对称加密与非对称加密

说到加密，很多同学第一反应就是“把数据搞乱”。其实没那么玄乎。加密的本质，就是把明文变成只有特定人能看懂的密文。怎么变的？靠的就是“算法”和“密钥”。

我个人习惯把加密比作“锁和钥匙”的组合。不同的锁配不同的钥匙，这个道理放在加密领域，就是对称加密和非对称加密的根本区别。今天咱们就把这两个核心概念聊透。

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

对称加密，说白了就是加密和解密用同一把密钥。就像你家的门锁，出门锁门、回家开门，用的都是同一把钥匙。

AES（Advanced Encryption Standard）是目前最主流的对称加密算法。我在项目中经常用AES-256，尤其是处理CloudTrail日志中的敏感字段时，比如数据库密码、这些。

举个例子，假设你在CloudTrail日志中发现一条敏感记录，想加密存储。用AES-256-GCM可以这样实现：

from cryptography.fernet import Fernet

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

# 加密
plaintext = b"CloudTrail log entry: user=admin, action=CreateUser"
ciphertext = cipher.encrypt(plaintext)

# 解密
decrypted = cipher.decrypt(ciphertext)
print(decrypted.decode())

非对称加密：公钥和私钥是一对

非对称加密就更有意思了。它有两把钥匙：公钥和私钥。公钥可以公开，私钥必须保密。你用公钥加密，只能用私钥解密；反之亦然。

为什么会这样？因为非对称加密基于数学难题。比如RSA依赖大整数分解，ECC依赖椭圆曲线离散对数问题。这些算法保证了一个方向容易算，反方向几乎不可能。

我在项目中遇到的真实场景：CloudTrail日志中经常包含KMS操作的记录，比如GenerateDataKey。这个操作就是典型的“对称+非对称混合加密”——用非对称加密传输对称密钥，再用对称密钥加密实际数据。

RSA和ECC：主流算法对比

RSA用了很多年，但ECC正在快速上位。原因很简单：ECC用更短的密钥就能达到同样的安全强度。

• RSA-2048：安全强度约112位，密钥长度2048位
• ECC-256：安全强度约128位，密钥长度256位
• ECC-384：安全强度约192位，适用于更高安全需求

你想想看，同样的安全级别，ECC的密钥只有RSA的八分之一。这对性能影响很大，尤其是在移动设备或日志分析中频繁做签名验证的场景。

密钥生命周期：从生到死

加密不仅仅是算法的事。密钥的整个生命周期管理，才是真正的难点。我见过太多因为密钥管理不当导致的安全事故。

密钥生命周期分为以下几个阶段：

1. 生成（Generation）：必须使用可靠的随机数源。不要用random()，要用secrets或硬件安全模块（HSM）。
2. 分发（Distribution）：安全地把密钥送到使用方。对称加密的密钥分发是最大挑战。
3. 存储（Storage）：密钥不能明文存储。通常用密钥管理服务（如AWS KMS）或加密机。
4. 使用（Usage）：在内存中使用，用完立即擦除。
5. 轮换（Rotation）：定期更换密钥。AWS KMS支持自动轮换，每年一次。
6. 撤销（Revocation）：密钥泄露后立即作废。
7. 销毁（Destruction）：确保密钥无法恢复。物理销毁或加密擦除。

我记得有一次排查CloudTrail日志中的异常，发现KMS操作量激增。顺藤摸瓜查下去，原来是一个服务没有做密钥缓存，每次加密都调用KMS API，导致性能开销和费用暴涨。嗯，这就是典型的“密钥使用阶段管理不当”。

下面这张图可以帮你快速理清加密体系的核心概念：

对CloudTrail日志分析的启示

学了这些有什么用？在实际日志分析中，你会频繁遇到加密相关的事件。比如：

• KMS密钥轮换：CloudTrail中会出现RotateKey事件，判断是否合规轮换
• 密钥泄露排查：通过Decrypt操作异常频率，定位可能的密钥泄露
• 加密算法识别：从日志中提取加密上下文，判断使用的是AES还是RSA
• 密钥生命周期审计：检查密钥是否按策略生成、轮换、销毁

我个人习惯在CloudTrail日志分析中，首先关注KMS操作的sourceIPAddress和userIdentity。异常IP调用KMS解密，十有八九有问题。