前阵子帮一家单位做等保三级测评整改到了机房一看Redis 实例裸跑了三年多。6379 端口监听在所有网卡上没有口令root 用户启动日志没开。评估人员顺手敲了一句keys *几千万条用户会话数据就那么摊在眼前。这不是个例类似的场景我每年都能遇到好几次。所以想用这篇文章把 Redis 在等保三级测评里的那些事从头到尾捋一遍测评时到底查什么、为什么查、怎么查、查完不合格怎么改。目标读者不只是等保测评机构的工程师也包括企业侧的安全运维、DevOps、研发负责人——很多人第一次被要求在 Redis 上做安全整改时其实是懵的不知道从哪下手。1. 测评视角里Redis 到底算等保三级的哪一类对象1.1 先搞清楚为什么一个“缓存组件”会被揪着不放很多研发同学的第一反应是Redis 不就是个缓存吗数据丢了还能从数据库回源有什么可测的这个想法放在早期确实成立但现在早就站不住脚了。Redis 的实际部署位置早就超出了“缓存”两个字。大量业务把登录会话、验证码、用户 Token、活动配置、限流计数、甚至订单状态都放进了 Redis。有些系统为了扛住高并发把热点数据全量塞进 Redis。换句话说Redis 里躺着的大概率是“重要数据”一旦被拖库、被篡改、被加密勒索带来的损失和数据库泄密没有本质区别。等保三级关注的是“重要信息系统受到破坏后的侵害程度”。Redis 如果承载了身份认证信息或核心业务数据那它在测评范围里就不是一个可有可无的中间件而是与数据库同等重要的测评对象。测评报告中Redis 的不合格项往往直接对应到“安全计算环境”这一章的若干控制点严重的情况下会拉低整个系统的测评结论。另一个容易误解的点是很多人觉得 Redis 只在内网跑外部访问不到就不用管了。但等保测评考察的是系统自身的安全防护能力而不是赌“内网很干净”。内网里一台机器被攻破横向渗透第一个盯上的就是这种裸奔的高价值组件。测评机构在做风险分析时不会因为“内网部署”就直接放行反而会结合网络架构判断间接暴露面。1.2 等保三级里关于 Redis 的核心控制点浓缩下来就六类以实际测评中常对照的安全计算环境要求来看Redis 主要涉及下面这些方向控制点核心要求对应到 Redis 的落地项身份鉴别用户身份唯一标识、鉴别信息复杂度、登录失败处理requirepass 口令、ACL 用户体系、认证失败日志访问控制默认口令修改、最小权限、多余账户清理禁用默认配置、rename-command、非 root 运行安全审计审计开启、记录完整、留存至少 6 个月logfile、loglevel、日志集中收集、ACL LOG入侵防范最小安装、关闭无关端口、补丁更新绑定内网、禁用危险命令、升级到安全版本数据完整性与保密性重要数据传输应采用校验技术或密码技术启用 TLS 加密传输数据备份恢复本地备份、异地备份、恢复测试RDB/AOF、备份文件异机存放、恢复演练这张表基本就是我每次做 Redis 测评时的检查地图。后面的每一个章节实际上都是在围绕这六类要求做具体展开。1.3 一个容易被忽略的前提Redis 版本决定了你的“底子”很多人做整改方案时不看版本就直接抄网上的配置结果抄完发现命令不生效。Redis 的版本差异非常关键。ACL 用户体系是 Redis 6.0 才引入的TLS 加密传输也是 Redis 6.0 开始才正式支持。如果你手里是一个 Redis 3.x、4.x 的老实例那很多等保三级要求的安全能力它本身就不具备再怎么调配置也变不出来。所以拿到测评任务后的第一件事永远是确认版本、确认构建参数。测下来 Redis 5.x 及以下的存量系统依然很多这类老系统如果业务无法升级整改思路只能是通过网络隔离、防火墙白名单、端口限制、危险命令重命名等方式做补偿性控制并在测评报告里如实说明风险。这一点在后面的整改章节还会详细展开。2. 测评现场第一步按顺序收集信息别上手就敲命令2.1 先摸清 Redis 实例的真实运行状态测评不是上来就config get一顿敲而是要先建立一个全局认知这个 Redis 是怎么装起来的、谁在跑、监听在哪、有没有集群关系。否则很容易出现“查了 A 实例却漏了 B 实例”的情况。我习惯按下面的顺序来# 1. 看进程与运行用户 ps -ef | grep redis # 2. 看版本和构建信息 redis-server --version redis-cli info server # 3. 看监听端口 netstat -tlnp | grep redis ss -tlnp | grep 6379 # 4. 看启动配置与配置文件位置 cat /proc/redis_pid/cmdline这一步的目的很直接确认当前 Redis 以什么用户权限运行、是否监听在非预期网卡、加载的是哪个配置文件。我见过不止一次管理员明明改了/etc/redis.conf但服务是用命令行参数启动的配置文件根本没被加载。不看进程光看配置文件结论就是错的。另外要留意实例数量。一台机器上跑多个 Redis 实例的情况非常常见每个实例用不同端口错开。测评表上如果只覆盖了 6379漏掉 6380、6381那这份测评结论是不完整的。2.2 判断部署形态单机、主从、哨兵还是集群Redis 的部署形态直接影响测评范围和检查项需要单独确认。单机模式最简单检查当前实例即可。主从复制模式则要额外关注主从之间是否需要认证。很多主从架构里从库连接主库没有配置密码或者主库requirepass改了但从库的masterauth没同步更新结果主从断连。这种配置瑕疵本身不算等保高危项但在高可用层面上是风险点。哨兵模式有一层 Sentinel 进程需要单独测评Sentinel 本身也是一个 Redis 服务默认端口 26379。它同样存在身份鉴别、访问控制、日志审计的问题而且 Sentinel 如果有写权限理论上可以触发故障转移影响的是整个集群的可用性。集群模式更复杂一些节点之间的 gossip 通信、主从复制、迁移槽位时的数据交互都需要考虑认证和加密。测评时要确认requirepass和masterauth是否配置了一致的口令以及集群总线端口默认 16379是否做了访问控制。在主从、哨兵、集群模式下如果只测单个节点就下结论往往会把所有高风险项都“测没了”。正确的做法是把每个角色的节点都纳入测评范围记录拓扑后再逐台检查。2.3 该问管理员的三个问题比敲命令更重要测评工作里有一个经常被新入行的同事忽略的环节访谈。技术检测只能反映“现在跑起来的配置”但很多测评项比如备份策略是否有效、日志是否异地留存、补丁更新机制是否健全必须结合管理员的回答来判断。我会准备三个必问题Redis 的口令由谁保管管理员账号是否与开发账号分离Redis 运行日志保留多长时间是否有集中收集备份文件放在哪里最近一次备份恢复到测试环境是什么时候这三个问题背后各有深意。口令管理回答不清说明身份鉴别控制点在制度层面已经松动日志保留时间答不上来审计留存这项很可能不达标备份恢复没有做过的数据备份恢复这一项大概率可以下“不符合”结论。访谈的价值在于有时系统实际配置做得很好但管理流程缺失有时配置看起来乱七八糟但运维团队已经有成体系的补偿措施。两者结合才能给出客观的测评结论。3. 逐项核查实操每个控制点对应哪些命令、怎样判定3.1 身份鉴别只看 requirepass 远远不够身份鉴别是等保三级测评里权重很高的一个控制点。对 Redis 来说多数测评人员的习惯是敲一句config get requirepass如果结果不是空就认为达标。但实际测评中我会分四步来看。第一步是确认是否启用了密码认证。redis-cli -h ip -p 6379 config get requirepass如果返回空值说明当前没有口令。这里要留个心眼如果查询命令本身没有报错不一定代表不需要认证可能是配置了乱码口令也可能是通过 ACL 用户体系做的认证。所以第二步要看当前连接的身份和权限。redis-cli --user datacheck --pass your_password info auth username password acl whoamiRedis 6.0 以后ACL 可以创建多个不同权限的用户。检查点是业务连接是否使用了专用账号、是否仍存在默认的default用户带口令直接访问。如果所有客户端都用 default 账号没有按角色拆分那么“用户唯一标识”这项工作在 Redis 层面是不达标的。第三步是检查口令复杂度。如果能拿到配置我通常会看口令长度是否小于 8 位、是否包含纯数字或纯字母。虽然 Redis 本身不强制作复杂度限制但等保三级要求“鉴别信息复杂度”在实际判定时弱口令会被记为一处不符合。第四步是检查认证失败处理。Redis 没有内置的锁定策略但它会通过 ACL LOG 记录大量的认证失败事件。acl log这条命令可以查看最近发生的未授权访问尝试。如果在日志里看到同一个来源 IP 在短时间内尝试了上百次密码说明当前系统已经遭受过暴力破解但没有任何机制阻断。测评结论中我会把“登录失败处理功能缺失”单独列出来督促整改方在网络层加防暴力破解策略。3.2 访问控制三处高频扣分点全在这里访问控制这一块Redis 的三处高频扣分点分别是监听地址裸奔、危险命令未禁用、高权限用户运行。监听地址是第一道关卡。config get bind config get protected-mode最危险的配置组合是bind 0.0.0.0加上protected-mode no这等于告诉整个网络里的任何一台机器可以随意连接。即使后面配置了 requirepass弱口令一旦被爆破攻击者就能直接进入内网核心数据层。检查时还要配合netstat -tlnp看实际监听地址因为有些云环境会通过端口转发绕过绑定限制。危险命令是第二道关卡。测评中我会查看配置文件确认是否对高危险命令做了重命名或禁用。rename-command FLUSHALL rename-command FLUSHDB rename-command CONFIG rename-command KEYS rename-command SHUTDOWN rename-command EVAL 为什么这几条命令要优先处理FLUSHALL、FLUSHDB可以直接清空所有数据对业务是毁灭性的CONFIG能让攻击者动态修改运行配置把保护模式关掉KEYS在数据量大时能阻塞整个 Redis 服务也可用于批量拖取键名SHUTDOWN直接拒绝服务EVAL在旧版本上则可能与 Lua 沙箱逃逸相关的漏洞组合利用。检查时要注意config get rename-command并不会从运行配置里返回重命名结果因为 rename-command 只在配置文件加载时生效。所以唯一可靠的检查方式是查看配置文件本身或者用redis-cli尝试执行被重命名的命令如果返回unknown command说明已经被干掉了。运行用户是容易被忽视的一处扣分点。Redis 官方文档明确建议用专用账号运行不要用 root。检查方法很简单ps -ef | grep redis-server如果第一列是 root那就是一项高危风险。原因是 Redis 历史上出现过多次未授权访问导致的远程命令执行漏洞攻击者一旦利用成功拿到的是 root 权限。测评现场我一般会把这一条写进“入侵防范”段落并强烈要求整改。3.3 安全审计日志没开等于白测这一项等保三级对审计的要求很朴素要有日志、记录要全、要能留存、不能被随便改。但 Redis 默认配置恰恰在审计上做得非常弱。首先看日志是否开启。config get logfile config get loglevelRedis 默认的 logfile 是空的日志直接输出到标准输出。如果是通过 systemd 启动日志可能进了 journal如果是在终端里手动起的一旦关闭终端日志就全丢了。loglevel 默认是 notice在测评中基本够用不用刻意调成 debugdebug 会产生海量日志反而影响运维。其次看日志内容是否够用。Redis 运行日志默认主要记录启动、关闭、主从连接、错误事件并不会记录每一次读写命令。所以如果测评标准要求“审计覆盖到每个用户”单靠 Redis 原生日志很难完全满足通常需要配合集中式日志平台抓取、或者开启 Redis 的慢查询日志和有选择的命令审计。再看留存周期。等保三级要求日志留存不少于 6 个月。Redis 运行日志如果只存在本机/var/log/redis/做一下 logrotate 轮转留存 6 个月问题不大。但如果日志量很大、轮转周期太短或者直接把日志打到了/tmp那就需要整改。建议是把 Redis 日志统一转发到集中日志系统由日志平台统一做冗灾和留存。最后是审计保护。检查日志文件权限是否配置为 640 或更严格属主是否为 redis 专用用户。如果任意用户都能删改日志这份日志的法律效力和审计价值就打了折扣。3.4 数据完整性与保密性TLS 是最大的一道分水岭等保三级里“重要数据传输完整性”和“重要数据传输保密性”这两个控制点到 Redis 身上对应的主要就是 TLS 加密。Redis 6.0 之前的版本默认没有 TLS 能力。Redis 6.0 之后需要在编译时启用 TLS 构建才支持tls-port、tls-cert-file、tls-key-file、tls-ca-cert-file等配置项。测评时我会检查config get tls-port config get tls-cert-file config get tls-key-file config get tls-ca-cert-file如果tls-port返回 0 或空说明没有启用 TLS。客户端到 Redis 之间的数据交互就是明文。在高风险网络环境下Token、会话信息、订单数据在网络传输过程中相当于裸奔抓包工具能直接还原出认证信息。有人会反驳说我们 Redis 只在内网内网抓包不太现实。这个说法在测评实践中不成立。等保三级的测评标准强调的是“应采用密码技术保证重要数据在传输过程中的保密性”它不区分内网还是外网。换句话说能不能被抓到是一回事有没有加密措施是另一回事。要实现合规最直接的办法就是启用 TLS。但启用 TLS 的代价往往比想象中高所有客户端连接方式都要改很多老业务用的客户端库版本不支持 TLS需要升版本或换驱动Redis 本身的性能会因为 TLS 握手和加解密有所削降。所以我在测评时一般会先把结论讲清楚如果内网隔离条件很好而且短期内无法启用 TLS那这项会被列为主要风险点但可以通过网络防护措施做补偿在报告中说明。如果业务数据敏感度高那就必须排期整改。数据完整性除了传输还可以关注存储文件本身。比如 RDB 持久化文件、AOF 重写文件如果存放目录权限过大任意用户都能读取或篡改数据完整性也会出问题。检查文件权限和属主是顺手要做的事。ls -l /var/lib/redis/3.5 数据备份恢复比“有没有备份”更重要的是“能不能恢复”备份恢复这一项测评时最容易踩的坑就是“有备份但恢复不了”。很多系统的 Redis 备份策略是每天用BGSAVE生成 RDB 文件然后存放在同一台机器的同一个磁盘上。表面上看备份有了但磁盘一旦故障备份和源数据一起消失等于没有备份。我在测评检查时至少会确认四点RDB 或 AOF 持久化是否开启。config get save或config get appendonly。备份文件是否存放在独立存储或异机目录。是否有备份恢复演练的记录或报告。备份数据是否加密保存防止备份文件泄露。另外要补充的是AOF 文件的 fsync 策略对数据恢复的影响很大。appendfsync everysec是性能和安全的平衡点默认值。如果被改成了no操作系统可能要缓冲好几秒甚至更久才落盘极端情况下丢数据。测评时这一项看起来不起眼但对“数据备份恢复能力”的最终评价有直接影响。4. 整改落地的具体操作与复测要点4.1 一套能过等保三级的最小安全基线模板每次测评后被测评方最关心的问题往往是你直接告诉我怎么改。这里我给出一个在多数场景下可以落地的 Redis 安全基线模板配套说明每条配置在等保三级里对应什么要求。# 网络访问控制 bind 10.10.10.10 127.0.0.1 protected-mode yes port 6379 # 身份鉴别 requirepass YOUR_STRONG_PASSWORD # 运行账号与权限建议通过系统 useradd 创建专用账户 # 文件属主设置为 redis:redis配置文件权限 600 # 危险命令禁用 rename-command FLUSHALL rename-command FLUSHDB rename-command CONFIG rename-command KEYS rename-command SHUTDOWN rename-command EVAL # 日志审计 logfile /var/log/redis/redis-server.log loglevel notice # 持久化与备份 save 900 1 save 300 10 save 60 10000 appendonly yes appendfsync everysec dir /var/lib/redis # 连接限制 maxclients 1024 timeout 300 tcp-keepalive 60这套模板不是万能的但它覆盖了身份鉴别、访问控制、安全审计、入侵防范、数据备份恢复等核心控制点。放到测评师面前至少能让一大半基础项不被判为高风险。唯一需要特别提醒的是把危险命令直接改成空字符串会让这些命令彻底无法使用可能会影响某些依赖 Lua 脚本或在线清空数据的业务。稳妥的做法是先和研发确认业务是否用到这些命令再决定是禁用还是重命名为随机字符串。4.2 动态改配置和改配置文件两种方式的坑很多管理员在整改时会直接用CONFIG SET改运行配置改完发现进程重启后又恢复原状。这就是典型的没有区分“动态配置”和“持久化配置”。CONFIG SET只能修改当前运行状态的参数如果想把改动固化到配置文件需要执行CONFIG REWRITE。但要注意CONFIG REWRITE有一个副作用它会把当前 Redis 中的所有运行配置都写入配置文件包括那些你原本不想落盘的临时参数。如果之前为了调试改了某些特殊配置CONFIG REWRITE会一并固化可能引入隐患。更安全的做法是直接修改配置文件然后重启 Redis 服务。但这种方式的代价是重启期间业务中断。对于不能中断的线上系统可以分两步走先用CONFIG SET把关键安全参数动态改掉比如requirepass、maxclients、appendonly然后在业务低峰期修改配置文件并执行CONFIG REWRITE或重启实例让配置持久化。在执行CONFIG SET requirepass时还要注意一旦设置成功当前未认证的连接并不会马上被踢掉。也就是说已经建立的长连接依然可以继续操作直到连接断开或者服务重启。测评时如果发现整改方只设置了密码但不断开已有连接我会提示他们重新评估因为风险并未完全消除。4.3 老版本不具备 TLS 或 ACL 能力时整改往哪个方向走如果你的 Redis 是 5.x 或更早版本等保三级里关于传输加密、用户权限隔离的硬性要求单靠参数调优做不到。这种情况下整改路径只有两条。第一条是升级版本。建议升级到 Redis 6.2 或 7.x 的 LTS 版本启用 ACL 和 TLS。升级前要关注兼容性问题特别是旧版本 AOF/RDB 文件能否被新版本加载、已有的客户端驱动是否兼容、业务代码是否有使用已废弃命令。升级后要在测试环境完整做一遍数据迁移和功能回归。这一条路径的成本最高但收益也最大。第二条是在无法升级的前提下通过补偿性控制来降低风险。具体做法包括通过安全组、iptables、云防火墙只允许业务网段访问 6379 端口启用系统级审计比如auditd监控 Redis 相关文件的访问使用跳板机统一管理 Redis 的运维入口不允许业务网络直连把 Redis 放入独立的 VPC 子网与核心数据库网络隔离。补偿控制不能消除不符合项但能够在风险分析中证明“实际可利用的攻击面已被大幅收敛”。测评报告里如果把这类措施写清楚整体结论的严重程度会有所缓解。5. 测评现场的常见问题与避坑速查5.1 高频不合格项 Top 5根据我接触过的测评项目Redis 这类中间件在不合格项上出镜率最高的五类问题做成速查表放在下面排序问题表现对应控制点整改优先级1requirepass 为空或弱口令身份鉴别立即整改2监听所有网卡且 protected-mode 关闭访问控制立即整改3redis-server 以 root 运行入侵防范立即整改4日志未开启或未集中留存安全审计限期整改5备份文件与源数据同机同盘数据备份恢复限期整改前三个问题如果同时存在基本可以直接认定为“高危风险”整个 Redis 实例几乎等于向内网所有恶意行为敞开了门。后两个问题通常不会单独导致整体测评不通过但会拉低这部分的分值而且在“持续安全运营”这块留下明显的短板。5.2 整改过程中容易引发的“次生灾害”整改本身也可能带来新的问题这是很多人没预料到的。我列几个自己实际见过的次生事故。第一是rename-command导致业务崩溃。有一个项目把KEYS命令重命名了结果研发侧有一个定时脚本用KEYS做缓存清理上线第二天就炸了。所以重命名命令之前必须让研发把用到的 Redis 命令清单拉出来逐一比对。第二是开启appendonly后磁盘被撑满。AOF 文件会持续增长如果配置了 everysec极端情况下每秒都会写一次。如果事前没有评估磁盘容量也没有配置自动 rewrite 策略几周内就可能把磁盘打满。整改时最好同步配置auto-aof-rewrite-percentage和auto-aof-rewrite-min-size。第三是开通 TLS 后客户端全部连不上。一个老项目用的 Redis 客户端库版本太旧不支持 TLS结果一开tls-port所有连接全部失败。整改 TLS 一定要先在测试环境验证客户端兼容性再灰度切换。第四是设置 bind 后从库连不上主库。主从复制环境下从库连接主库依赖的是主库的监听地址。如果 bind 只写了业务网段而漏掉了主从同步流量来源网段从库就会出现同步中断。排查半天才发现是 bind 列表没写全。5.3 这几年测 Redis 下来我自己记住的三件事最后分享三个个人层面的体会不算教程但对我后续做测评非常有帮助。第一永远不要低估“默认配置”的危害。Redis 的设计理念是“开箱即用”这意味着它默认的安全性很低。很多系统上线时管理员图省事所有配置都用默认值这本身就等于把大量风险暴露在了攻击者面前。第二测评不是找茬而是帮被测评方建立安全边界。每次整改辅导时我都会用最直白的话告诉对方你不想让任何一个陌生人在你家的保险柜前随意翻东西Redis 也一样。防护做在前面省下来的都是事后救火的成本。第三Redis 的安全测评不是一个静态动作而是需要持续维护的过程。版本会更新、业务会扩展、配置会漂移。每次发版、扩容、主从切换之后重新对照基线检查一遍才能保证安全状态不滑坡。如果还有余力的话建议把这份基线检查做成自动化用脚本定时拉取config get结果和期望基线做比对有差异就告警。等保测评一年一次但安全风险是每天都在变的。自动化巡检不能替代正式测评却能让正式测评到来时你不至于在手忙脚乱中补作业。