Spring Boot中spring.redis.password仅用于连接认证，不加密数据；Redis默认无服务端TDE，明文存储value，故需在RedisTemplate序列化环节嵌入AES加解密逻辑，实现客户端透明加密。
Spring Boot集成Redis后，RedisTemplate 默认序列化方式（如 Jackson2JsonRedisSerializer）只做 JSON 转换，不加密——数据在 Redis 里仍是明文。要真正加密存储，必须在序列化环节介入，而非靠配置项或密码保护。
为什么不能只靠 spring.redis.password 加密？
Redis 密码仅用于客户端连接认证，不影响数据内容。即使设置了 password，所有写入 redis-cli 或通过 RedisTemplate 存的数据，仍以原始字节形式存在。攻击者若获得 Redis 实例访问权限（比如内网渗透、运维误配），可直接 GET 出完整敏感字段。
-
spring.redis.password是连接层凭证，不是数据加密密钥 - Redis 本身不提供服务端透明加密（TDE），需客户端自行加解密
- 配置文件里用
jasypt加密password值，只防配置泄露，不防 Redis 数据泄露
如何让 RedisTemplate 写入前自动加密？
核心是替换 RedisTemplate 的 defaultSerializer 或指定 value 序列化器，把加密逻辑嵌入序列化流程。推荐使用 AES 对称加密，配合固定 salt 和随机 IV 提升安全性。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 定义一个
AesRedisSerializer类，实现RedisSerializer<Object> - 加密时：生成随机
IvParameterSpec→ 用Cipher加密字节数组 → 将 IV + 密文拼接为 byte[] 返回 - 解密时：拆出前 16 字节为 IV → 用相同密钥和 IV 解密剩余部分
- 注册该序列化器到
RedisTemplate：template.setValueSerializer(new AesRedisSerializer(key)); - 注意：
StringRedisTemplate不适用此方案，它只处理字符串，需改用RedisTemplate<String, Object>
加密 key 还是只加密 value？
通常只加密 value。key 加密会导致无法使用 Redis 命令（如 KEYS、SCAN、EXPIRE）管理缓存，且 key 本身常含业务语义（如 user:1001:profile），加密后运维排查困难。
- key 明文 + value 密文 是平衡安全与可用性的常见做法
- 若必须加密 key，需自定义
RedisCacheManager的cacheKeyPrefix或重写computeKey，但会失去 Spring Cache 注解（@Cacheable）的自动 key 生成能力 - 避免对整个
byte[]key 做 AES 加密——Redis 内部 key 比较依赖字节序，加密可能破坏哈希分布
压缩 + 加密顺序怎么安排？
先压缩再加密。压缩能减少网络传输和内存占用，加密后再压缩几乎无效（加密后数据接近随机分布，不可压缩）。
- 在
AesRedisSerializer的serialize()方法里，先用DeflaterOutputStream压缩原始字节，再 AES 加密 - 解密时逆序：先 AES 解密 → 再用
InflaterInputStream解压 - 注意压缩阈值：小对象（如短字符串）压缩反而增大体积，建议只对 >1KB 的 value 启用压缩
- 不要用
GZIP，它有头部校验开销；Deflater（zlib）更轻量，且 Java 原生支持
真正难点不在代码实现，而在于密钥轮换和 IV 管理：IV 必须每次加密都随机生成并随密文持久化，密钥不能硬编码在代码里，应从 KMS 或环境变量注入。一旦密钥泄漏或失效，存量密文将无法解密——这是最容易被忽略、但后果最严重的环节。
