Redis 缓存服务安全加固怎么做？账号、网络与最小权限实践

初始安装：从默认配置开始的风险

很多团队在部署 Redis 时，习惯性地使用默认配置跑起来，后面再考虑安全。但在生产环境里，默认配置意味着无密码、无认证、无网络限制。如果 Redis 实例暴露在公网或者内部非信任网段，攻击者只需要知道 IP 和端口就能直接操作数据，包括读取、修改甚至执行危险命令。

默认情况下，Redis 绑定在 127.0.0.1，这原本是安全的。但很多部署脚本为了容器互通或者外部访问，会把 `bind` 改为 `0.0.0.0`，却忘了加上密码。另一个常见问题是，Redis 默认不启用认证，`requirepass` 参数为空。即使设置了密码，如果密码强度不够或者长期不更换，依然存在被暴力破解的风险。

从企业运维角度，安装 Redis 后的第一步不是调优性能，而是关闭不必要的功能。例如，`CONFIG SET` 和 `CONFIG GET` 命令允许运行时修改配置，如果被攻击者利用，可以直接改写安全策略。还有 `FLUSHALL`、`DEBUG`、`SLAVEOF` 等命令，在正常业务中很少用到，但破坏力很强。

系统部署维护的经验是，所有安全加固都应该在 Redis 实例启动之前规划好，而不是上线后再补。补丁式的安全策略往往会有遗漏，而且变更配置需要重启服务，影响可用性。

账号认证：从 requirepass 到 ACL

早期 Redis 只支持一个全局密码，通过 `requirepass` 设置。这种方式简单，但问题也很明显：所有客户端共用同一个密码，无法区分谁做了什么操作。一旦密码泄露，整个 Redis 实例都不安全。而且 `requirepass` 不支持密码过期、强度校验和登录失败锁定，只能靠外部工具辅助管理。

从 Redis 6.0 开始，官方引入了 ACL（Access Control List）机制。ACL 允许为不同用户设置独立的密码，并控制每个用户能执行的命令和访问的键空间。这意味着可以实现精细的权限隔离，比如给业务应用只分配读写特定键的权限，给运维人员分配管理命令权限，给监控系统只分配只读权限。

配置 ACL 时，建议遵循几个原则：

• 每个用户使用独立的密码，密码长度不低于 32 位，包含大小写字母、数字和特殊字符。
• 默认用户（default）应该被禁用或者只赋予最小必要权限。很多攻击案例中，攻击者利用的就是 default 用户的超级权限。
• 使用 `ACL SETUSER` 命令逐条授予权限，而不是一次性给满。例如，只允许读取键 `user:*` 的权限，就写 `~user:*` 和 `+get`，不要写 `~*` 和 `+@all`。
• 定期审查 ACL 配置，清理不再使用的用户。Redis 没有内置的用户过期机制，需要运维脚本辅助。

需要注意，ACL 配置本身也需要保护。如果攻击者能执行 `ACL SETUSER` 或者 `ACL DELUSER`，权限控制就形同虚设。因此，应该限制能修改 ACL 的用户数量，并且通过日志审计这些操作。

网络隔离：端口、绑定与防火墙策略

Redis 默认使用 6379 端口，这个端口在扫描工具中很容易被识别。如果必须对外提供服务，建议修改为非常用端口，比如 16379 或更高范围。但这只是增加了一点扫描难度，真正的安全依赖网络隔离。

网络隔离的核心原则是：Redis 只监听需要通信的网卡和 IP。如果应用服务器和 Redis 服务器在同一内网，`bind` 应该设置为应用服务器的内网 IP，而不是 `0.0.0.0`。如果使用容器部署，Redis 容器不应该直接暴露端口到宿主机，而是通过内部网络与业务容器通信。

防火墙策略应该基于最小访问原则：只允许特定来源 IP 访问 Redis 端口。在云环境中，安全组规则要精确到 IP 段，避免使用 `/0` 这样的全开放规则。内部网络也需要做分段，Redis 所在的网段应该与前端应用、数据库等隔离开，即使被攻破，攻击者也无法直接横向移动到其他系统。

另一个容易被忽视的点是 Redis 的 `protected-mode` 配置。当 `protected-mode` 启用时，如果 Redis 绑定了 `0.0.0.0` 且没有设置密码，Redis 会拒绝来自本机之外的连接。这个机制在 Redis 3.2 之后默认开启，但很多团队在配置 `bind` 时不小心关闭了它。建议始终开启 `protected-mode`，即使已经设置了密码，它能在密码验证失败时提供额外保护。

传输加密：TLS 配置的必要性

很多企业认为 Redis 跑在内网，数据传输不需要加密。这个假设在严格的合规场景下不成立。内网不等于安全，内部人员误操作、内网嗅探、交换机配置错误都可能导致数据泄露。尤其当 Redis 存储了会话令牌、用户信息或者业务敏感数据时，传输加密应该是标配。

Redis 6.0 开始原生支持 TLS/SSL，包括客户端到服务器、主从复制和哨兵通信的加密。配置 TLS 需要准备证书和密钥，建议使用企业内部 CA 签发，避免使用自签名证书带来的信任问题。如果使用自签名证书，需要确保所有客户端都正确配置了信任链。

配置 TLS 时，性能开销是必须考虑的因素。TLS 握手会增加连接建立时间，对于短连接频繁的场景，可以考虑启用 Redis 的连接池复用。数据加密和解密也会消耗 CPU 资源，在 Redis 实例 CPU 使用率接近 80% 时，开启 TLS 可能导致性能下降。这种情况下，需要评估是否可以通过硬件加速或者调整加密套件来缓解。

对于已经运行多年的 Redis 实例，启用 TLS 需要停机配置，或者通过逐步迁移的方式。建议在新部署的实例上直接启用 TLS，避免后期改造的麻烦。如果条件不允许全量加密，至少对主从复制链路和哨兵通信进行加密，因为这些链路传输的是完整的数据集。

命令权限：最小化可执行命令集

Redis 提供了 200 多个命令，但业务应用通常只需要 `GET`、`SET`、`DEL`、`EXISTS` 等十几个命令。很多危险命令在正常业务中根本用不到，比如 `DEBUG`、`OBJECT`、`CLIENT`、`SHUTDOWN`、`BGREWRITEAOF` 等。如果应用账号拥有这些命令的权限，攻击者一旦拿到应用控制权，就能直接破坏 Redis 服务。

命令权限控制可以通过两种方式实现：

• 在 Redis 6.0 及以上版本，使用 ACL 的 `+command` 和 `-command` 语法，明确允许或禁止特定命令。
• 在旧版本中，使用 `rename-command` 配置项，将危险命令重命名为空字符串，从而禁用它们。

`rename-command` 的方式比较粗暴，但适用于无法升级 Redis 版本的场景。需要注意，重命名命令后，所有客户端都不能再使用原名，包括运维工具。所以最好在配置文件中统一处理，并做好文档记录。

对于 ACL 方式，建议按照命令类别来管理。Redis 命令分为多个类别，比如 `@read`、`@write`、`@admin`、`@dangerous` 等。给应用用户只授予 `+@read` 和 `+@write`，禁止 `@admin` 和 `@dangerous`。运维用户则可以授予 `+@all`，但需要配合网络隔离和密码保护。

还有一个实践是限制 `EVAL` 和 `EVALSHA` 命令。Lua 脚本虽然强大，但可能被用来执行复杂操作或绕过权限检查。如果业务中不需要使用 Lua 脚本，建议直接禁用。如果确实需要，应该对脚本内容进行审查，并限制脚本执行时间。

资源配额：防止单一客户端耗尽资源

Redis 是单线程模型，虽然 IO 多路复用能处理大量并发，但 CPU 计算和内存分配仍然是瓶颈。如果某个客户端执行了慢查询或者一次性写入大量数据，可能导致整个 Redis 实例响应变慢，影响其他客户端。

资源配额控制主要从几个方面入手：

• `maxclients`：限制最大连接数。默认值是 10000，但根据服务器内存和业务并发量，可能需要调低。当连接数达到上限时，新连接会被拒绝，避免服务过载。
• `maxmemory`：限制最大内存使用。当内存达到上限时，Redis 会根据淘汰策略删除键。这个配置不仅是为了防止内存溢出，也是安全措施——防止攻击者通过写入大量数据耗尽内存。
• `client-output-buffer-limit`：限制客户端输出缓冲区大小。如果某个客户端消费速度慢，Redis 会在输出缓冲区积累数据，占用内存。设置合理的软限制和硬限制，可以强制断开异常客户端。
• `timeout`：设置空闲连接超时时间。如果客户端连接后长时间不发送命令，Redis 会自动断开，释放资源。

对于 ACL 用户，还可以通过 `SETUSER` 的 `channels` 和 `keys` 限制来约束用户能访问的键空间。虽然这不直接控制资源，但能减少用户误操作或恶意操作对全局的影响。

资源配额的设置需要结合业务实际。比如，如果一个业务需要批量写入大量数据，`maxmemory` 太严格会导致写入失败，太宽松又可能被滥用。建议先监控一段时间的数据量变化，再设定合理的阈值，并设置告警。

持久化与备份安全

Redis 的持久化文件（RDB 快照和 AOF 日志）存储了所有数据，如果这些文件被未授权访问，数据安全就无法保障。持久化文件的安全保护包括：

• 文件权限：RDB 和 AOF 文件应该只允许 Redis 进程用户读写，其他用户无权限。默认情况下，Redis 以 root 运行的情况并不少见，这会带来更大的风险。建议创建专用系统用户 `redis`，并确保数据目录的属主和权限正确。
• 存储位置：持久化文件应该存储在专用目录，不要和应用程序日志、临时文件混在一起。如果使用云存储备份，应该加密传输和存储。
• 备份加密：如果备份文件需要长期保存，建议在备份时加密。Redis 本身不提供备份加密功能，可以通过外部工具（如 GnuPG）或者存储服务的内置加密实现。
• 备份访问控制：只有运维和备份系统有权限读取备份文件。备份系统本身也需要加固，避免成为数据泄露的入口。

在 SystemDo 的部署维护项目中，我们曾遇到客户因为备份文件权限设置不当，导致内部员工下载了生产环境的 RDB 文件。虽然最终没有造成数据泄露，但这件事说明持久化安全容易被忽略。

日志与审计：记录谁做了什么

Redis 的日志系统相对简单，默认只记录启动信息、错误和警告。对于安全审计来说，这远远不够。需要知道谁在什么时候执行了什么命令，尤其是配置变更、权限修改和数据删除操作。

Redis 6.0 的 ACL 日志（`ACL LOG`）可以记录认证失败、权限拒绝等事件，但默认只保留最近 10 条记录。可以通过 `acllog-max-len` 配置增加日志容量，比如设置为 1000 条。ACL 日志保存在内存中，重启后会丢失，所以需要定期导出到外部日志系统。

对于更全面的审计，可以考虑使用 Redis 的 `MONITOR` 命令，但生产环境中慎用。`MONITOR` 会输出所有命令，在高并发场景下会显著降低 Redis 性能，并且产生大量日志。更好的做法是，在业务应用层记录 Redis 操作日志，或者使用代理层（如 Twemproxy、Redis Sentinel）来拦截和记录命令。

操作系统的审计功能也可以辅助 Redis 安全。通过 `auditd` 监控 Redis 配置文件的修改、进程启动和停止、网络连接变化等事件。这些系统级日志和 Redis ACL 日志配合，可以构建更完整的安全事件记录。

日志和审计的目的是事后追溯，而不是实时防御。所以日志的存储、轮转和检索也需要规划。日志应该集中存储到独立的日志服务器，保留时间根据企业合规要求确定，一般不少于 6 个月。

版本升级与补丁管理

Redis 作为一个活跃的开源项目，会定期发布安全更新。CVE 记录中，Redis 出现过远程代码执行、权限提升、拒绝服务等漏洞。例如，CVE-2021-32687 允许通过 Lua 脚本执行任意命令，CVE-2022-0543 涉及 Lua 沙箱逃逸。这些漏洞的修复版本发布后，企业应该尽快评估并升级。

版本升级的策略建议：

• 关注 Redis 官方安全公告和 GitHub 发布页面，订阅邮件通知。
• 建立测试环境，在升级前验证新版本对现有业务的影响。Redis 小版本升级通常兼容，但大版本升级（如 5.x 到 6.x）可能涉及配置变更和命令行为变化。
• 对于无法立即升级的实例，可以采取临时缓解措施。例如，如果漏洞涉及 Lua 脚本，可以先禁用 `EVAL` 命令，直到升级完成。
• 容器化部署的 Redis，可以使用镜像扫描工具检查基础镜像中的 Redis 版本是否有已知漏洞，并定期更新镜像。

版本升级本身也有风险。Redis 在升级过程中需要重启，如果配置了主从复制，需要规划好切换顺序，尽量减少对业务的影响。对于集群模式，可以逐个节点升级，保持集群可用。

补丁管理的核心是速度和覆盖范围。从漏洞公开到被利用的时间窗口越来越短，企业应该有能力在 72 小时内完成紧急补丁的评估和部署。做不到这一点，至少要有明确的应急预案，包括回退方案和业务降级措施。

监控与告警：安全事件的实时感知

安全加固不是一次性的工作，而是持续的过程。监控和告警能帮助团队及时发现异常行为，比如暴力破解、未授权访问、资源异常增长等。

监控内容可以包括：

• 认证失败次数：通过 `INFO` 命令的 `total_connections_received` 和 `rejected_connections` 指标，结合日志分析，判断是否存在暴力破解。
• 命令执行频率：监控 `FLUSHALL`、`CONFIG SET`、`DEBUG` 等敏感命令的执行次数，触发告警。
• 内存和 CPU 异常：如果 Redis 内存突然飙升，或者 CPU 使用率持续高位，可能是攻击者在进行资源耗尽攻击。
• 连接数变化：短时间内大量新连接建立，可能是扫描或者 DDoS 攻击。

监控工具可以使用 Prometheus 结合 redis_exporter，或者使用 Redis 自带的 `INFO` 命令定期采样。告警阈值需要根据业务基线设置，避免误报。例如，业务高峰期认证失败次数可能比平时高，需要动态调整。

告警的目的是让人介入处理，所以告警信息要清晰明了，包含时间、实例、指标值和可能的根因。同时，告警应该分级，严重告警（如检测到 `FLUSHALL` 执行）需要立即响应，而一般告警（如连接数接近上限）可以纳入日常处理。

结语

Redis 缓存服务的安全加固没有银弹。账号认证、网络隔离、命令权限、资源配额、传输加密、日志审计、版本升级和监控告警，每个环节都需要根据企业自身情况做权衡。核心原则是最小权限：只给必要的权限，只开放必要的接口，只允许必要的访问。

安全策略需要定期复查。业务在变，攻击手法也在变，半年前的配置可能已经不再安全。建议每季度做一次 Redis 安全审计，检查 ACL 配置、网络策略、版本状态和日志记录情况。如果团队内部缺乏安全审计经验，可以邀请外部团队做渗透测试或安全评估。

在 SystemDo 的部署维护项目中，我们通常会在 Redis 实例上线前完成上述加固措施，并在运维手册中记录所有配置项和变更历史。这样做的好处是，无论是人员变动还是环境迁移，安全基线都能保持一致。