面试题：在分布式环境下使用Redis EVALSHA命令，有哪些额外的安全考量及应对策略

Question

在分布式系统架构中，使用Redis EVALSHA命令会带来一些与单机环境不同的安全问题。请详细分析这些额外的安全考量，并提出相应的应对策略。

Answer 1

额外安全考量

1. 脚本注入风险：在分布式环境中，多个客户端可能同时调用 EVALSHA 命令。如果脚本的哈希值（SHA1）由客户端生成并传递，恶意客户端可能通过构造恶意脚本并计算其哈希值，然后在其他客户端不知情的情况下执行恶意操作。因为 EVALSHA 命令只验证脚本的哈希值，不检查脚本内容。
2. 哈希碰撞风险：理论上，不同的脚本可能会产生相同的 SHA1 哈希值（尽管概率极低）。在分布式系统中，大量脚本执行可能增加这种风险，一旦发生哈希碰撞，可能导致非预期的脚本被执行。
3. 版本控制问题：在单机环境中，脚本的修改和更新相对容易管理。但在分布式系统中，不同节点可能缓存了不同版本的脚本，当脚本更新时，可能存在部分节点使用旧版本脚本，部分节点使用新版本脚本的情况，这可能导致系统行为不一致。

应对策略

1. 脚本签名验证：
   • 服务端可以维护一个可信脚本的列表，记录脚本内容及其对应的哈希值。当客户端发送 EVALSHA 命令时，服务端除了验证哈希值，还可以通过与可信列表对比，确保脚本的来源可靠。
   • 可以使用数字签名技术，对脚本进行签名。客户端在发送 EVALSHA 命令时，同时发送脚本的签名。服务端使用公钥验证签名的有效性，以确保脚本未被篡改。
2. 降低哈希碰撞影响：
   • 除了使用 SHA1 哈希值，还可以结合其他校验方式，如计算脚本的CRC32 或 MD5 值（虽然 MD5 也有碰撞风险，但结合多种校验可降低整体风险），对脚本进行多重验证。
   • 定期审计脚本执行记录，一旦发现异常行为，及时排查是否存在哈希碰撞导致的问题。
3. 统一版本管理：
   • 引入版本控制系统来管理脚本，每次脚本更新时，更新版本号。客户端在发送 EVALSHA 命令时，附带脚本版本号。
   • 服务端维护一个脚本版本映射表，当收到 EVALSHA 命令时，检查版本号是否匹配。如果不匹配，拒绝执行并提示客户端更新脚本。
   • 可以通过发布 - 订阅机制，当脚本更新时，通知所有节点更新缓存的脚本，确保所有节点使用的是最新版本的脚本。