Redis 为什么不能直接暴露公网：protected-mode、ACL 和审计检查

把 Redis 的 6379 端口直接放在公网，很多人会有个误判：已经设了密码，应该不会出问题。但实际上密码、protected-mode 和网络隔离解决的完全不是同一个层面的问题，端口一旦对不可信网络开放，配置被意外改乱、弱口令被暴力破解、凭据日志泄露、误操作删库这类风险都会被直接放大。Redis 官方的安全指引也明确建议把部署的 Redis 放在可信内网环境里，绝对不要直接暴露在公网下。

排查优化的时候顺着这个顺序走就行：先限制清楚哪些地址能访问到端口，再给每个依赖服务分配刚好够用的ACL权限，最后把所有配置变更和复核动作留下可追溯的记录。这样哪怕某一层的配置被人误改，其他防护边界也能把影响范围拦住。

先把 Redis 当作受保护的数据资产

很多人觉得Redis只是个缓存，数据丢了也无所谓，其实完全不是这样。会话信息、限流计数、队列状态、热点数据、短期令牌都有可能存在里面，所有上层业务都在依赖它正常运行，根本不是随便哪里都能连上的公开服务。

从资产依赖关系来看，真的有必要连Redis的，通常就只有同个内网里的少数业务服务。运维操作入口、监控采集入口、在线业务服务都应该有明确的身份和使用范围。先把这些连接关系梳理清楚，后面配安全组、子网路由、ACL账号、审计记录的时候，才不会变成零散的、互不相干的无效配置。

外网暴露先看网络路径，不要只看密码

第一步根本不是去改配置里的密码字段，而是先核对清楚Redis的端口到底哪些地址能访问到。Redis官方指引就推荐把端口访问限制在可信内网，外部请求在防火墙或者网络边界层就直接拦截掉。如果是本机部署的应用，直接把Redis绑定到本地回环地址就是最稳妥的最小暴露方式；如果是多服务跨主机部署，那就只绑定并放通提前规划好的私有网段。

# 仅适用于 Redis 与业务程序运行在同一主机的示例
bind 127.0.0.1
protected-mode yes

上面这段示例不是所有部署场景的通用方案。容器集群、跨机房部署的情况，要结合实际的私网地址、路由规则和访问边界单独设计。核心判断标准永远是：是不是只有提前授权过的业务网络才能访问到Redis，而不是“我有没有给端口设过一个密码”。

protected-mode 能拦什么，不能替代什么

protected-mode的作用更像一层兜底的容错机制。按照Redis官方的说明，默认配置下如果满足“监听所有网卡接口、没有设置认证密码”这类条件，它就只会接受来自本地回环地址的连接，直接拒绝所有外部地址的请求。这个特性可以大幅降低你不小心把实例误暴露出去之后的安全风险。

但它绝对不是“可以把Redis跑在公网上”的许可证明。这个保护模式本身就能被配置项关掉，也完全没有能力识别一个已经连进内网的调用方，到底有没有权限读写某一类key。实际部署里永远要把网络隔离作为第一道防护，protected-mode只作为防止配置错误扩大影响的补充机制存在。

ACL 不是把 default 用户换个密码

网络边界收紧之后，下一步要做的就是把不同业务的访问身份拆分开。Redis 6之后自带的ACL能力，支持按不同的账号名分别限制可执行的命令和能访问的key范围。比起来所有服务共用同一个全局密码，单独给每个服务分配专属账号，后续排查“谁在访问什么数据”的时候会清晰很多，后续某个服务下线或者调整的时候，也可以单独回收对应权限，不用动其他服务的配置。

# 概念示例：缓存服务仅处理 cache: 前缀，规则需按实际业务验证
user app_cache on >REDACTED ~cache:* +@read +@write -@dangerous

这里有三个要注意的要点。第一，ACL账号要对应服务的用途创建，不能直接对应到某个开发人员的个人账号。第二，key的匹配规则要贴合真实业务用到的数据前缀，不能为了省事直接给全库的访问权限。第三，可执行的命令范围要从实际业务调用清单反推出来：普通读写缓存的服务，根本不需要拥有执行管理命令、主从复制这类高风险操作的权限。上线之前要先在预发环境验证所有实际调用逻辑，后续看到异常日志里出现被拒绝的命令，要先核对是不是漏掉了正常业务的调用需求。

老版本的全局密码只适合做兼容场景，完全没办法表达不同服务之间的权限差异。如果是多个业务服务共用同一个Redis的长期运行环境，优先用命名式的ACL账号和最小权限规则来管控，后续维护起来会顺畅很多。认证信息本身也没办法替代传输层的保护，Redis官方也提醒过，没有加密的链路上传输的认证凭据，还是有可能被网络嗅探窃取，所以要搭配可信内网或者合适的TLS传输加密方案一起使用。

把配置变更做成可审计的路径

线上出问题很多时候都是踩了这个坑：临时改的运行时配置当时生效了，服务一重启就回到之前的旧配置，等于之前的加固动作全部白做。Redis官方配置说明里也提到过，直接在运行时修改的参数，不会自动同步写到持久化配置文件里。所以任何涉及监听地址、保护模式开关、ACL规则的调整，都要在变更记录里写清楚预期要达到的状态、配置文件的存储路径、复核人、回退方案，同时把持久化配置的修改放到同一次变更窗口里操作。

一套合格的审计记录，至少要能回答四个问题：哪个业务服务申请了对应权限，它能访问哪些前缀的key、能执行哪些命令，这条规则是由谁确认生效的，后续服务重启或者实例迁移之后，要怎么确认规则还保持正确。后续真的出现权限异常的时候，排查方向可以直接从身份和变更记录入手，不用在多份散落的配置文件里到处找问题。

验证不靠扫描公网，而是在受控环境逐步核对

安全验证的目标是确认实际防护效果符合之前的设计，不是从公网上反复扫描端口做爆破测试。可以由网络或者平台负责人核对安全组、路由、防火墙规则；由业务开发负责人在授权的私网环境里确认服务连接正常；由Redis管理员核对所有ACL账号对应的key和命令权限范围。验证的时候要用只有最小权限的测试账号操作，同时把验证结果留存下来。

1. 确认公网没有任何能直接连到Redis的放行路径，只有提前规划好的内网服务可以访问。
2. 确认protected-mode保持开启状态，监听地址和当前部署架构的预期完全一致。
3. 给每个业务服务单独核对对应的ACL账号、可访问key前缀、实际需要的命令集合。
4. 变更窗口操作完成之后，先做一次全链路服务健康检查，后续在重启或者实例迁移的演练里，再次确认所有配置都已经持久化生效。
5. 定期查看权限拒绝、连接异常的日志记录，及时清理掉已经不再使用的老旧服务账号。

常见问题

打开 protected-mode 后，还需要 ACL 吗？

需要。protected-mode是对连接来源做兜底限制，ACL是对已经连上的调用方能做什么操作做限制，两个能力叠加起来，才能把“能不能连上”和“连上之后能做什么”两层防护都收紧。

使用 requirepass 就够了吗？

单一的全局密码没办法区分不同服务的职责，也完全限制不了可访问的key范围和可执行的命令范围。如果有老旧版本的兼容需求，可以保留这个配置，新搭建的多服务共用场景，更推荐按服务分配独立的ACL账号，所有凭据都放到受控的密钥管理系统里统一维护。

跨服务访问 Redis 应该怎样安排？

所有业务服务都通过私有网络、受控路由或者内部统一的连接层来访问Redis，不要把Redis直接当成对外接口暴露出去。跨环境访问的需求，要先由网络和安全负责人明确好访问边界、访问身份、审计责任之后，再决定要不要引入TLS这类传输加密能力。

为什么改完设置，重启后又恢复了？

基本都是运行时修改的状态和持久化配置文件没有同步导致的。把预期的配置统一纳入版本管理和变更流程，每次操作完成之后都验证一遍重启之后的效果，就能避免这类看似已经修复、实际没落地的问题。

结语

Redis的安全起点从来不是选一个复杂度更高的密码，而是先明确它只应该给可信的调用方提供服务。先隔离好网络边界，再用ACL把每个服务的访问身份和权限限制清楚，最后让所有的配置调整都能复核、能追溯。整套方案不需要加很多复杂的特殊配置，就能大幅减少单次配置疏忽直接演变成大规模数据安全事故的概率。

参考：Redis 官方安全文档、Redis 官方 ACL 文档、Redis 官方配置文档。