应用层aes加密是保护redis会话数据最可控方案，因redis无字段级加密能力；须用cbc/gcm模式、随机iv、aes-256密钥及pkcs7填充，密文需含iv并校验过期时间。
直接在应用层对敏感会话数据做 AES 加密后再存入 Redis，是最可控、最通用的方案。Redis 本身不提供字段级加密能力，也不支持服务端自动加解密——所有“Redis 加密”说法，本质都是客户端行为。
为什么不能依赖 Redis 自带的 requirepass 或 ACL 来保护会话内容
requirepass 只校验连接密码，ACL 控制命令权限，二者都不碰数据本身。一旦攻击者拿到合法连接凭据（比如通过内存泄露、日志误打、配置错误），GET session:abc123 返回的就是明文会话内容。你存的是用户手机号、JWT payload、临时 token，它们不会因为开了密码就自动变密文。
- ACL 能限制
CONFIG GET，但拦不住GET/HGETALL - requirepass 在传输层无 TLS 时，密码本身还可能被嗅探（尤其用 redis-cli 直连）
- 即使启用了 TLS，也只是保传输，落盘/内存中仍是明文
AES 加密必须带 IV，且不能用 ECB 模式
ECB 模式是致命陷阱：相同明文块 → 相同密文块，攻击者能靠模式识别还原结构（比如一眼看出 “admin” 出现在第 3 个块）。生产环境必须用 CBC 或 GCM，并为每次加密生成随机 iv。
-
AES.MODE_CBC是底线，iv必须随密文一起存储（如拼接在密文前），不能硬编码或复用 -
AES.MODE_GCM更优，自带认证标签（auth_tag），能防篡改，但部分旧版 Crypto 库不支持 - 密钥长度至少 32 字节（AES-256），别用字符串直接当 key，要用
hashlib.pbkdf2_hmac衍生或os.urandom(32)生成
示例关键逻辑（Python）：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
from Crypto.Cipher import AES
from Crypto.Util.Padding import pad, unpad
from Crypto.Random import get_random_bytes
<p>key = b'32-byte-key-for-aes256-just-example' # 实际应安全保管
iv = get_random_bytes(16)
cipher = AES.new(key, AES.MODE_CBC, iv)
data = b'{"uid":1001,"role":"user","exp":1743582000}'
ct = cipher.encrypt(pad(data, AES.block_size))</p><h1>存入 Redis：iv + ciphertext（base64 编码后更稳妥）</h1><p>encrypted = base64.b64encode(iv + ct).decode()
r.set('session:abc123', encrypted)</p>
解密时 IV 提取错、padding 验证失败，会导致静默解密失败
常见报错如 ValueError: Padding is incorrect 或解出来乱码，90% 是因为：iv 长度不对、没正确切分、或加密和解密用的 key 不一致。不要跳过 padding 校验，也不要 try-except 吞掉异常后返回空值——这会让会话失效变得不可排查。
- 从 Redis 读出后，先
base64.b64decode，再切前 16 字节为iv，剩余为密文 - 解密后必须调用
unpad(..., AES.block_size)，否则可能多出填充字节 - 密钥绝不能写死在代码里；建议从环境变量读取加密后的密钥，再用 KMS 或文件系统权限控制解密过程
Redis 的 TTL 和加密会话生命周期要对齐
加密不解决过期问题。如果你设了 EX 3600，但业务逻辑里又手动延长有效期，密文本身不会更新——攻击者截获旧密文，只要 key 没轮换，就能一直解密。反过来，如果只靠 Redis 过期，而应用没检查解密后 exp 字段，可能让已过期会话继续生效。
- 加密 payload 内必须包含可验证的过期时间（如 Unix 时间戳），解密后强制校验
- 避免用
SETEX单独设 TTL，优先用SET ... EX ...原子写入 - 密钥轮换时，需兼容新旧 key 解密（比如加个 version header），否则存量会话全失效
最易被忽略的一点：加密后的会话体积比明文大 20–30%，若原来用 HSET session:abc123 uid 1001 role user 存多字段，改成单字段 JSON 加密后，GET 一次拿全量是高效，但想局部更新（比如只改 role）就必须解密→修改→重加密→重写，没法原子更新某个字段。设计之初就得接受这个 trade-off。
