1. 等保三级测评中Redis为什么总被标成高风险项先讲个我在测评现场遇到的真实场景。某客户的业务系统用的是默认配置的Redis部署在内网服务器上端口6379直接监听在0.0.0.0没有设置任何口令root权限启动运行。当时测评师拿着扫描报告指过去客户运维负责人第一反应是“Redis只是给后端做个缓存数据又不在里面要不要这么严格”这个问题我几乎每次做等保测评项目都会碰到。很多人对Redis的认知停留在“它就是给MySQL挡一层读压力的工具”但等保三级要求考察的是“承载业务信息系统的整体安全防护能力”Redis作为业务架构中真实存在、有网络通信、有数据读写、可能涉及敏感信息缓存的技术组件它天然就在测评范围内。而且Redis本身的一些设计特性让它特别容易被“抓典型”默认配置完全裸奔安装完就能直接连协议简单、命令强大一旦被攻破拿到的可能不只是缓存数据运行权限过高很多部署直接就是root数据落盘文件RDB、AOF常以明文存放高版本虽然有ACL、TLS等安全能力但多数生产环境没启用所以等保三级测评中Redis被标成高风险项通常不是因为测评师故意找茬而是它的暴露面确实大得离谱。这篇文章就把我处理过的十几个Redis测评整改项目经验捋一遍从等保三级的具体控制项要求出发逐条对照Redis的配置做法覆盖测评准备、自查整改、现场迎检和常见问题排查给要做测评或者正在整改的团队一份能直接抄作业的清单。2. 先搞懂等保三级对Redis到底提了哪些要求等保三级的技术要求集中在安全物理环境、安全通信网络、安全区域边界、安全计算环境、安全管理中心这五个层面。其中Redis这种中间件组件主要受“安全计算环境”和“安全区域边界”两个层面的约束部分单位还会在“安全通信网络”层面提加密传输的要求。我把实际测评中会和Redis直接挂钩的控制项整理了一下。2.1 身份鉴别谁在用Redis能不能确认身份对应测评指标是“安全计算环境-身份鉴别”。这项要求核心是对登录和操作Redis的用户进行身份标识和鉴别用户身份标识要唯一鉴别信息要复杂且定期更换。很多团队在这项的认知误区是“Redis就是个缓存谁没事会连它”。但测评师拿到你的网络拓扑和端口开放列表后第一个关注点就是这个6379端口有没有身份鉴别机制如果Redis没设密码那在测评报告里写的是“系统未对登录用户进行身份标识和鉴别任何人可直接连接并执行Redis命令”这一条直接就是高风险。这一项对应的Redis配置动作# redis.conf 中开启认证 requirepass 配置一个满足复杂度要求的强口令口令复杂度要能过得了测评师的检查至少要满足长度12位以上、大小写字母数字特殊字符混合、不能是键盘顺序或连续重复字符。有些测评机构还会查是否存在弱口令字典命中我在项目里遇到过配置了redis2023这种密码然后被标弱口令的情况所以密码这关一定要狠一点。另外等保三级还要求“具有登录失败处理功能如结束会话、限制非法登录次数”。Redis在身份鉴别这块能做的很有限高版本虽然支持ACL但也没有锁账户机制所以说应对措施通常是在网络边界侧限制可访问Redis的源IP把失败处理这层控制放到防火墙或安全组策略上。2.2 访问控制数据能不能只看该看的、只做该做的对应“安全计算环境-访问控制”。等保三级明确要求授予用户最小权限、重命名或删除默认账户、及时删除多余或过期的账户、避免共享账户。Redis默认有两个内置账户——高版本默认使用default用户老版本就是一条requirepass全局口令。这里的问题在于所有人都是同一个身份没有权限区分。如果业务A和业务B共用一套Redis谁能执行FLUSHALL谁能执行KEYS *完全分不清。应对方案是上ACLRedis 6.0以上的版本支持# 在redis.conf 或运行时配置 ACL 用户 ACL SETUSER biz_read on 密码 ~* read ACL SETUSER biz_write on 密码 ~* read write keyspace ACL SETUSER admin on 密码 ~* all我给客户做整改时通常建议按业务角色拆分ACL用户主应用一个读写账号、报表服务只给只读权限、运维管理走单独的高权账号default用户直接禁用掉ACL SETUSER default off。这样测评师检查时可以看到“不同角色分配了不同权限”而不是一个口令走天下。Redis的ACL配置细节比较多我会在后面单开一节讲。2.3 安全审计干了什么事情能不能追溯对应“安全计算环境-安全审计”和“安全管理中心-集中管控”。要求是启用安全审计功能、审计记录覆盖每个用户的每个重要操作、审计记录不能删除或意外覆盖、审计记录要能留存至少6个月。Redis的审计能力天生薄弱这是很多测评整改项目里最棘手的一项。Redis本身有SLOWLOG和MONITOR但前者只记录慢查询命令后者是实时调试工具都不算真正的操作审计。高版本6.2有ACL LOG也只记认证失败和权限拒绝事件。我在实际操作中主要靠三层组合来满足这项要求第一层Redis自身日志loglevel设为notice以上把启动、认证、主从同步、错误信息记录到日志文件第二层开启Redis的ACL LOG记录认证失败等安全事件第三层也是我强烈建议的——在Redis前面加一层代理或者从业务侧把Redis操作日志化。比如让开发在业务代码的Redis客户端工具层做统一日志切面记录涉及写操作、删操作、配置变更的命令来源IP、账号、时间、命令内容有个更省事的做法是直接用云Redis服务云厂商自带审计日志拉出来对接日志平台就行。如果是自建Redis就得靠上述组合拳这也是测评整改中工作量相对大的一项。2.4 数据保密性数据落盘了能不能防窃取对应“安全计算环境-数据保密性”。核心要求采用加密技术对鉴别数据和重要业务数据进行加密存储。Redis这把有两类数据要盯第一类是口令和鉴权信息。requirepass或ACL用户的密码在redis.conf和运行时配置中要用强加密算法存储或加密传输。Redis 6.0开始配置文件支持用#!sh的方式调用外部脚本解密配置但多数项目用不到这么复杂我一般建议至少保证配置文件权限是600只有Redis运行用户可读。第二类是落盘数据。RDB快照和AOF文件里就是明文数据如果Redis缓存了个人信息、会话信息、接口报文等敏感数据测评师会要求“对存储数据进行加密”。但要注意Redis自身没有透明数据加密能力在做整改时我通常给出的方案是方式一应用层加密后再写入Redis读取时解密。适合对性能要求不极端的场景方式二把RDB/AOF文件所在磁盘做成加密卷比如Linux下的LUKS、云盘的加密选项方式三在Redis前面用代理做加解密转换业务侧无感这三种方案各有适用场景后面讲整改路径时我会展开对比。2.5 入侵防范和资源控制Redis被利器利用了怎么办对应“安全计算环境-入侵防范”和“资源控制”。这一项在等保测评里经常以“系统存在远程代码执行或未授权访问风险”的形式出现可说的点比较多。Redis历史上出现过多次严重漏洞最有名的就是“未授权访问结合主从复制写入crontab/公钥文件导致命令执行”的攻击链。测评机构在漏洞扫描时如果发现你开着外网端口即使有密码也可能提示“Redis可能存在未授权访问风险”更不用说完全裸奔的情况。对应的整改要点禁止Redis监听在0.0.0.0改为绑定内网业务网段的具体IP网络边界限制6379端口只对业务服务器的IP开放去掉高危命令或重命名比如CONFIG、FLUSHALL、EVAL、KEYS等具体命令列表后面给不用root权限启动Redis单独建一个redis用户运行及时升级Redis版本至少是6.2以上的稳定版如有可能把Redis放进独立的VPC子网最小化网络暴露资源控制方面主要看maxmemory限制、连接数限制maxclients、timeout空闲超时等防止耗尽主机资源。这些参数在测评整改里虽然权重不如安全功能项高但测评师偶尔会抽查。3. 测评现场必查项和自查脚本这是最常被检查的一组配置做了几年等保测评配合工作我发现测评师检查Redis时基本有一套固定的套路跟客户业务关系不大主要就是看配置、看端口、看权限、看版本。搞清楚他们怎么看我们做自查就能有的放矢。3.1 测评师的标准检查动线测评师到现场之后一般不会直接去扣Redis细节而是先看几个大面网络拓扑图里有没有Redis、资产清单里Redis的版本型号、端口开放列表里有没有6379。确认这个组件存在后他们通常会让运维配合执行一组命令来采集现状。我根据实际项目经验整理了一份测评师常见的Redis检查命令清单检查项执行命令测评关注点服务运行身份ps -ef | grep redis是否root运行监听地址ss -tnlp | grep 6379是否绑定内网IP或公网当前认证配置redis-cli -a 密码 CONFIG GET requirepass是否设置了强口令访问控制redis-cli ACL LIST有无ACL用户default是否禁用版本信息redis-cli INFO server版本是否过旧是否存在已知漏洞身份权限ls -la /etc/redis* /var/lib/redis*配置文件和数据目录权限数据传输加密redis-cli INFO replication主从复制链路上有无TLS日志情况redis-cli CONFIG GET logfile loglevel是否记录日志、日志级别资源限制redis-cli CONFIG GET maxmemory maxclients有无内存和连接数上限如果你的Redis挂在容器里跑测评师还会用docker inspect查容器是否以特权模式运行、有没有做端口映射暴露到宿主机之外。这些细节在检查时都会被纳入扣分项。3.2 我做的自查脚本一小时内把所有风险点摸清楚现场临时手动敲命令容易漏项我给客户做整改前通常直接写一个自查脚本。不用搞太复杂几条命令组合加简单输出就行。大致逻辑如下#!/bin/bash # Redis 等保三级自查脚本适用 Redis 6.x REDIS_HOST127.0.0.1 REDIS_PORT6379 REDIS_PASS自查时临时填入 echo 1. 进程运行身份 ps -eo user,pid,cmd | grep redis-server | grep -v grep echo echo 2. 监听地址和端口 ss -tnlp | grep $REDIS_PORT echo echo 3. 认证配置 redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS --no-auth-warning CONFIG GET requirepass echo echo 4. ACL用户列表 redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS --no-auth-warning ACL LIST echo echo 5. 高危命令配置 redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS --no-auth-warning CONFIG GET rename-command echo echo 6. 数据目录文件权限 redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS --no-auth-warning CONFIG GET dir DATADIR$(redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS --no-auth-warning CONFIG GET dir | tail -1) ls -la $DATADIR echo echo 7. 日志配置 redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS --no-auth-warning CONFIG GET logfile redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS --no-auth-warning CONFIG GET loglevel echo echo 8. 资源限制 redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS --no-auth-warning CONFIG GET maxmemory redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS --no-auth-warning CONFIG GET maxclients echo echo 9. 版本信息 redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS --no-auth-warning INFO server | grep -E redis_version|os|process_id|tcp_port这套脚本基本覆盖了测评师会看的关键项跑完一遍当前Redis的安全水位大致就有数了。实际做整改项目时我先跑一遍脚本再根据输出结果逐项处理。有个细节要注意脚本里的密码是临时明文传的跑完自查记得清shell历史别给自己留一个安全隐患。3.3 版本和组件供应链信息也是测评关注点很多团队容易忽略的是等保三级测评在“安全计算环境-定制开发”和“软件供应链”等控制项上会核查组件的来源和漏洞情况。测评师会问Redis是从哪下载的、用的什么版本、有没有官方渠道的安全补丁记录。这里我给到的建议是整理一份资产清单写清楚Redis版本号、部署服务器IP、用途、数据敏感级别、补丁更新时间。虽然没有正式的“等保表单”要求这么填但现场配合检查时这份表能让测评师更快完成核对减少来回拉扯。如果自查发现版本偏低比如还在用4.x、5.x甚至更老的版本我的建议是直接升级到最新的6.2.x或7.x。升级前要做的事用redis-cli --cluster check或INFO replication确认现有集群/主从架构先在一台从节点上升级观察同步和业务访问是否正常稳定后再逐台升级主从切换做好计划低版本升级到高版本时注意配置文件兼容性有些参数名有变化目前我用下来Redis 7.2版本在安全特性上最完整ACL功能更完善也支持更细粒度的权限控制测评现场给测评师的回答余地也更大。4. Redis安全整改的核心路径从裸奔到过检的全过程这一节是全文最实用的部分。我以最近一个做过的测评整改项目为例把Redis从完全裸奔状态整改到过检状态的完整路径写出来。项目背景概括一下某公司的一套业务系统Redis部署在一台4核8G的云服务器上端口全开无密码root启动缓存了用户登录会话和一些交易中间态数据。等保三级预测评时Redis相关的风险项被标了三个“高风险”。整改周期只有两周我一个人配合客户的运维团队做了全套整改。4.1 身份鉴别整改强口令ACL用户切分第一步先把最刺眼的未授权访问问题解决。在redis.conf里设置requirepass Xx#9fQ$pL2vR8mN同时还改了绑定地址bind 10.10.x.x 127.0.0.1 protected-mode yes port 6379protected-mode yes这个参数在Redis 3.2之后默认开启它的作用是在没有设置密码且监听地址是非本机地址时拒绝外部连接。但如果设置了requirepass理论上protected-mode的兜底意义就不大了。不过这个参数开着没坏处测评师看到也顺眼。第二步是配ACL用户切分。我在整改中的配置方式是# 先禁用默认用户 ACL SETUSER default off # 给业务主进程用的读写账号 ACL SETUSER bizapp on Biz#9fQ$pL2vR8mN ~* read write keyspace transaction # 给数据分析团队用的只读账号 ACL SETUSER readonly on Read#9fQ$pL2vR8mN ~* read scan # 给运维DBA用的管理账号 ACL SETUSER redisadmin on Admin#9fQ$pL2vR8mN ~* all这里有几个关键的权限细节值得展开说~*表示允许访问所有key如果业务上能按key前缀限定范围就更安全read write是命令分类授权比逐条命令写get set简洁得多运维账号给all是方便管理但必须配合强口令和网络限制否则一个高权账号反而扩大了风险面keyspace主要覆盖KEYS、SCAN这类命令如果不想业务账号全库扫描可以不给keyspace这会强制业务方通过精确key访问实际中很多业务的Redis key命名没有统一规范全指望按前缀隔离不现实所以我通常给~*权限但限制命令类别这样既保证业务能正常跑又能卡住危险操作。ACL配置好以后记得CONFIG REWRITE否则重启就丢了。4.2 高危命令的禁用与重命名在等保测评的漏洞扫描报告中Redis的“危险命令未禁用”是最常出现的提示之一。Redis默认允许所有命令而CONFIG可以动态改配置、FLUSHALL可以直接清空数据、EVAL可以执行Lua脚本、KEYS在数据量大时会阻塞主线程。这些命令一旦被未授权攻击者利用后果很直接拿到配置、清空数据、挂后门。整改时我在redis.conf中统一处理rename-command CONFIG rename-command FLUSHALL rename-command FLUSHDB rename-command EVAL rename-command EVALSHA rename-command KEYS 把高危命令直接重命名为空字符串也就是彻底禁用。有些团队担心EVAL禁用会影响业务因为有些Redis客户端库内部事务或复杂操作用了Lua脚本。我的处理办法是先查业务代码里有没有直接用EVAL/EVALSHA如果有在整改窗口期内跟开发确认能否改成普通命令组合如果确实停不掉先不禁EVAL但必须同时用ACL把EVAL权限从业务账号上拿掉仅给管理账号保留。这个“先业务梳理后禁命令”的顺序很重要。我见过一个项目直接在配置文件里禁了所有高危命令第二天业务大面积超时报警最后回滚找原因的案例。Redis的命令禁用不是越狠越好而是要确保业务路径先走通。4.3 降权和最小化网络暴露原环境Redis以root启动这个风险在测评整改里同样被点了名。虽然Redis官方文档不建议以root运行但很多安装脚本默认就是root运维也习惯了。整改步骤# 创建专用用户不允许登录shell useradd -M -s /sbin/nologin redis # 迁移数据目录属主 chown -R redis:redis /var/lib/redis chown redis:redis /etc/redis.conf # 修改systemd服务启动用户或调整启动脚本 # 例如 /etc/systemd/system/redis.service 中设置 # Userredis # Groupredis注意如果Redis从root切换成普通用户有几个坑RDB和AOF目录如果仍然root属主Redis没权限写盘启动后持久化会报错日志文件的属主也要是redis用户或至少可写如果用到rename-command以外的外部模块或脚本要确认普通用户有执行权限云厂商如果通过自定义镜像拉起Redis改用户后配置文件的路径和软链可能出问题建议改完后用redis-cli DEBUG sleep 1这种简单命令做一次写路径验证网络暴露面上我把原来0.0.0.0改成了业务网段的具体IP。同时在云安全组和主机防火墙层面做了双重限制iptables -A INPUT -p tcp --dport 6379 -s 10.10.0.0/16 -j ACCEPT iptables -A INPUT -p tcp --dport 6379 -j DROP这里有个看似矛盾但实际常见的场景有时候本机备份脚本也要连Redis而备份脚本所在机器和Redis不在同一个安全组里。我处理过多例“安全组只放行业务网段结果凌晨备份全失败”的案子所以做网络策略前要把所有需要连接Redis的源IP列全包括但不限于应用服务器、定时任务服务器、监控采集器、堡垒机、管理运维跳板机。4.4 审计和加密整改的具体操作审计这块等保测评最看重“可追溯”。我前面提到的三层组合在整改项目里具体落地是这样的第一层调高Redis日志级别并固定日志文件。loglevel notice logfile /var/log/redis/redis-server.log并在logrotate里配置日志轮转保留至少6个月/var/log/redis/*.log { weekly rotate 26 compress missingok notifempty }第二层开启ACL LOG。Redis 6.0以上的ACL LOG默认记录最近10条认证和权限失败事件用于追踪暴力破解尝试# 查看最近的安全事件 redis-cli ACL LOG # 查看日志条数配置 redis-cli CONFIG GET acllog-max-len第三层业务操作日志。如果业务系统本身对Redis的调用量不大可以在中间件封装里做日志切面如果量很大就抽样记录高风险操作比如删除key、清库、配置变更。我给那家客户配的方案是在Java客户端的Redis工具类里加了一个拦截器把涉及写操作的命令异步发到日志集群配合应用的TraceID把请求链路串起来这样测评师要查“某个时间点谁删了哪个key”时我们能拿出完整的调用链日志。数据加密这块因为整改窗口短我采用了“敏感字段应用层AES加密RDB所在磁盘加密卷”的组合。具体来说用户手机号、身份证这类强敏感字段由应用在写入Redis前用AES-GCM加密读取时解密。对业务代码的侵入是可控的服务器的数据盘启用云盘加密云厂商都有这个选项这样即使RDB文件被拖走破解成本也很高至于Redis主从复制链路的TLS加密因为客户的Redis是单节点暂时没有涉及。如果是主从或多节点集群建议直接用Redis 6.x的TLS支持配置tls-port 6379、tls-cert-file、tls-key-file。这块配置起来有一定门槛证书签发和轮换都要配合我在第6节会单独讲。4.5 资源限制和独立运行最后低优先级但也是测评控制项的是资源限制。maxmemory 4gb maxmemory-policy allkeys-lru maxclients 512 timeout 300 tcp-keepalive 60这些参数不只是等保测评里“资源控制”的考察点更是Redis自身稳定的边界。很多生产事故都是maxmemory没设或者设了maxmemory-policy noeviction导致写失败。从测评角度看设置合理的资源上限代表“系统具备一定的资源控制能力”防止单个组件耗尽宿主机资源影响其他业务。还有一个容易被测评师顺带问到的点Redis所在服务器的安全基线。比如系统账号口令策略、登录超时限制、重要目录权限等这些不在Redis本身配置范围内但因为他们要写服务器的测评结论Redis所在主机如果整体基线很差也会拖累Redis相关项的测评结果。5. ACL配置的实战细节这一块最容易在测评现场被追问ACL是Redis 6.0之后最重要的安全特性也是测评整改时最有说服力的“硬件”。但实际配置中我见过不少翻车场景所以单独开一节把细节讲透。5.1 ACL规则语法的完整解释Redis ACL规则语法看起来简单但组合起来坑不少。先拆解一下ACL SETUSER username on password ~pattern category -command各段含义on/off启用或停用该用户password设置密码password是删除密码#hash则是直接设置哈希后的密码~pattern可访问的key模式~*代表全部keycommand/-command允许或禁止某个命令category/-category按命令分类授权。Redis把命令分成keyspace、read、write、admin、dangerous、pubsub等类别可以一次授权一整个类别allkeys等价于~*allcommands等价于allnopass表示无需密码一个常见的坑如果只写了read业务用MULTI开事务再加EXEC提交你会发现被拒绝。原因是事务相关命令属于transaction分类。我在整改时遇到过业务反馈“单条SET没问题SET完放流水线里批量写就报NOPERM”排查了半天发现是ACL少加了transaction。另一个坑是Lua脚本。EVAL属于scripting分类还是admin分类取决于版本6.0里EVAL在slow和scripting分类中如果按网上老版本教程只给了all或者读了旧文档会导致EVAL无法执行。建议在配置完ACL之后用业务真实调用链做一轮回归测试不要只测几个常用命令就上线。5.2 密码存储和权限管理ACL用户密码不是明文存在配置文件里的可以使用ACL GENPASS生成随机强密码也可以用命令获取哈希值# 生成随机密码 redis-cli ACL GENPASS # 查看指定用户的密码哈希需要管理员权限 redis-cli ACL GETUSER bizapp配置文件中存的是密码哈希值但ACL LIST会把哈希打印出来。要注意CONFIG REWRITE写回配置文件时密码哈希也会写入配置文件请按600权限保护Redis 6.0及以上版本还支持配置文件用aclfile参数单独指定ACL用户文件为了好管理一般建议单独一个acl.conf文件存放ACL配置和主配置隔离。主从环境下配ACL有个容易踩的坑主从节点的ACL配置必须一致。Redis的主从同步不自动同步ACL用户信息你只在主节点上加了用户从节点不知道这个用户客户端连到从节点做只读请求就会鉴权失败。我把这个写进过整改方案里不要问是怎么知道的。5.3 和requirepass的关系别混着用有些团队在加了ACL之后原来的requirepass还保留着。这里要理清requirepass在ACL体系中等价于设置default用户的密码。如果default用户是off状态那全局的requirepass根本不会生效如果default用户是on状态又配了密码那requirepass和ACL中的default密码其实是一个东西。我在整改中发现一个很典型的问题配置里既有requirepass又有ACL多用户客户端连接时到底用哪个密码实际上无论你用哪种方式连接最终都是通过default用户或你指定的ACL用户名密码完成鉴权。requirepass存在时如果客户端连接不指定用户名就是用default用户requirepass的密码做认证。规范的建议是一旦启用ACL就把requirepass去掉把default用户显式禁用所有业务通过独立ACL用户认证。这样权限边界清晰测评师现场问起来也好讲。5.4 实测中的ACL命令授权参考分享一份我在多个项目里打磨出来的ACL授权模板覆盖常见的生产场景可以直接改密码和key范围后使用# 通用业务读写账号 ACL SETUSER app_rw on 密码 ~* read write transaction keyspace -admin -dangerous -slow # 报表只读账号 ACL SETUSER bi_ro on 密码 ~* read scan -write -admin -dangerous # 缓存管理账号清缓存等 ACL SETUSER cacheops on 密码 ~* read write keyspace dangerous -admin # 运维管理账号 ACL SETUSER dba on 密码 ~* all # 应用初始化和巡检账号只跑信息类命令 ACL SETUSER monitor on 密码 ~* connection pubsub server transaction read -write -admin -dangerous这里-dangerous把FLUSHALL、SHUTDOWN这些命令从业务账号上摘掉即使业务代码被SQL注入或者应用被脱壳攻击者拿到的也是“受限Redis权限”而不是整库的控制权。这一层纵深防御在等保测评的访谈环节讲出去评审专家是认可的。6. Redis Cluster、主从和哨兵架构的安全整改要点单节点Redis整改相对简单生产环境一旦上了Cluster、主从或哨兵架构安全整改的复杂度会高不少但测评师的重点关注方向反而更集中节点间通信是否安全、故障转移时会不会因为安全问题出岔子、数据复制过程中是不是明文传输。6.1 节点间通信的认证与加密Redis主从复制时从节点要拉取主节点的数据这个连接默认是不加密的。如果只是内网环境部分单位可以接受这个风险但等保三级在新版测评要求下数据完整性、保密性都要有措施建议启用TLS加密。Redis 6.2支持全链路TLS主要配置项port 0 tls-port 6379 tls-cert-file /etc/redis/tls/redis.crt tls-key-file /etc/redis/tls/redis.key tls-ca-cert-file /etc/redis/tls/ca.crt tls-auth-clients yes tls-replication yes tls-cluster yes启用后所有客户端、从节点的复制连接、集群节点通信都走TLS。这套配置的难度是证书生命周期管理证书过期会导致副本无法同步这是最常见的生产事故。给我的建议是证书有效期尽量长建议两年以上证书到期前一个月就要排期轮换轮换时先更新从节点再灰度更新主节点或者设置好tls-cluster让节点在滚动重启时逐步完成证书替换可以在监控系统里配置证书到期提醒提前告警如果暂时不启用TLS那至少保证Redis节点处在独立的安全内网通过防火墙和网络ACL严格限制Redis节点之间的通信端口只对指定节点开放。6.2 主从复制场景下的认证配置主从复制除了TLS加密还有一个“复制认证”问题。高版本Redis用masteruser和masterauth# 从节点上配置 masterauth 主节点上的账号密码 # 如果有ACL则指定 masteruser repluser主从架构启用ACL后建议单独建一个复制专用账号ACL SETUSER repluser on 强密码 ~* psync replconf ping这个账号只给复制相关的最小权限业务账号和管理账号完全分离。这样即使某个从节点的配置被泄露攻击者拿到的也只是复制权限做不了太多破坏。有一个我在集群整改中踩过的坑主从节点版本不一致比如主节点是6.0从节点升级到了7.0ACL语法规则有差异masteruser特性和旧版兼容性不佳导致从节点认证失败。日志刷屏但业务无感知。等发现问题时主从已经断了好几个小时。所以集群升级时要特别注意版本组合尽量保持主从一致性。6.3 Cluster模式下安全参数的特殊性Redis Cluster模式下节点间通过CLUSTER BUS端口默认16379进行心跳和数据迁移通信这个端口在测评和渗透测试中经常被忽视。网络策略上要特别注意客户端访问端口6379只对业务服务器开放Cluster bus端口16379只对集群内的其他Redis节点开放哨兵模式中哨兵节点之间、哨兵到Redis主从节点都有专属端口要按角色最小化开放Cluster模式下还有一个和测评相关的心智问题有些团队以为“Redis Cluster自带安全能力”其实Cluster只解决横向扩展和高可用和认证、授权、加密毫无关系。Cluster模式下照样裸奔照样未授权访问被利用而且攻击面从单节点变成多节点。所以我见过测评报告里写“Redis集群多个节点存在未授权访问风险”处理起来比单节点麻烦得多因为每个节点的安全配置都要对齐。Cluster的CONFIG REWRITE也要小心在集群节点上执行CONFIG SET后再CONFIG REWRITE会写入各节点自己的配置文件如果各节点配置不规范很容易出现配置漂移。整改时我建议把配置文件纳入统一的配置管理工具节点配置变更走自动化发布而不是手工在每台机器上改。6.4 哨兵和高可用架构的测评顾虑使用哨兵模式的Redis架构在测评时有一个场景容易被问到主节点挂了从节点自动提升为主节点新主节点的安全配置还是原来从节点的那套吗如果只是主节点手工加固过而从节点没跟上故障切换后可能整个Redis集群的安全水位“一夜回到解放前”。推进整改时我会确认所有节点的配置文件内容完全一致、版本一致、安全参数一致并且有自动化脚本巡检节点间的配置差异。测评师对高可用架构的安全一致性没有百分百固定的要求但“各节点安全配置一致性核查”在测评报告里是很常见的观察项提前做到位可以少费很多口舌。7. 现场访谈与测评报告的配合技巧测评不只是技术检查还包含管理层面的访谈和证据收集。Redis相关的测评结论往往取决于三方面证据配置现状、管理制度、整改痕迹。这一节讲讲现场配合的注意点。7.1 测评师让拿证据时要能快速给出带日期的材料测评师不太可能只凭你在现场口头说“我们配了密码”就下结论他们会要截图、要命令输出、要配置文件的脱敏版本。这些证据最好提前准备好Redis配置文件的关键安全段截图requirepass、ACL、bind、rename-command等服务器上执行ps -ef确认运行用户的截图网络策略截图安全组规则或iptables规则日志轮转配置和日志留存时长的说明ACL用户列表及权限说明Redis版本跟已知漏洞的对应关系说明如果版本较旧要有解释或已修复说明这些材料我还建议加上生成日期做成PDF或者截图存档。测评报告里引用证据时有时间戳的材料更有说服力。7.2 访谈环节怎么回答“Redis数据不敏感所以不用管”这是运维团队最常挂在嘴边的一句话但也是应付测评最危险的一句话。测评师听到“数据不敏感”会追问你怎么定义“不敏感”如果Redis里缓存了用户登录态登录态算不算敏感如果缓存里有业务中间态数据如何保证不会通过Redis被拖库实际上哪怕Redis里只存了数字ID、商品列表这种“看起来不敏感”的数据攻击者利用未授权访问执行INFO、CONFIG GET dir等命令也能拿到服务器路径、运行信息为进一步攻击提供跳板。这还是单点问题更严重的是“横向移动”——Redis所在服务器一旦被拿下一层权限内网其他系统的暴露面都会受影响。所以访谈时我的建议是不要强调“数据不敏感”而是强调“我们按照统一的等保标准给Redis做了全套加固”把整改的每一项对应到测评指标上比如“我们对Redis配置了身份鉴别和ACL覆盖了身份鉴别和访问控制要求”展示配置和文档不要只给口头解释曾在测评现场碰到评测机构要求看Redis的变更审批记录最好能当场调出运维变更单或者配置管理平台的记录。测评不只看技术做得怎么样还看管理和流程有没有跟上来。7.3 预测评和复测的整改周期安排等保测评一般分预测评、整改、复测三个环节。预测评时Redis的高风险项通常都会被点名整改的安排建议是第一周完成身份鉴别requirepass/ACL这步工作量最小效果最明显第二周完成网络暴露收敛、高危命令禁用、运行用户降权第三周补齐审计日志和数据加密措施整理证明材料第四周全量自查脚本回归确认所有问题项都有对应处置如果整改周期极短优先级的顺序也很清晰改密码 → 绑IP → 禁外网 → 降权 → 禁命令 → 审计 → 加密。越靠前的事情投入产出比越高。反之如果时间充裕加密和审计务必做扎实因为这两项是复测时测评师重点复查的对象。8. 复测和后续持续运营测评通过不是终点Redis安全要保持常态等保测评拿到通过结论不代表Redis的安全工作就到此为止了。测评报告里给出的整改建议如果只是“本次整改已覆盖”但运维中配置漂移、高权账号复用、补丁长期不更新下一次测评还是会被打回高风险。下面是我在复测以及后续持续运营中遇到最多的几类问题。8.1 配置漂移手工修改Redis配置导致的安全回退最常见的回退场景有三种研发排查问题时临时CONFIG SET requirepass 忘了改回来新扩容的Redis节点直接拉镜像部署镜像里的配置还是三个月前的裸奔版业务上线时为了联调方便安全组临时放开了6379调完没人回收规则我建议在Redis服务器上部署两条防线第一定期跑配置巡检脚本跟第3节那个自查脚本类似但输出不是给人看的而是对接监控告警。比如发现CONFIG GET requirepass返回空字符串、发现bind配置包含0.0.0.0、发现maxmemory没有设置就触发告警通知DBA。第二把Redis配置纳入配置管理流程任何变更走审批和记录禁止在服务器上直接改redis.conf或执行CONFIG SET后不做CONFIG REWRITE持久化。这个在测评整改后能不能维持住很大程度上取决于团队的执行力。8.2 口令和证书的轮换周期不能只在测评前做一次等保三级要求“鉴别信息定期更换”如果测评报告里写了“每90天更换一次Redis口令”那实际执行中就要按这个周期去轮换。ACL用户多了之后口令轮换的工作量不算小我把操作整理成了一套可执行步骤# 1. 生成新密码 NEW_PASS$(redis-cli ACL GENPASS) # 2. 为各ACL用户批量更新密码 redis-cli -a 旧管理密码 ACL SETUSER bizapp $NEW_PASS # 3. 修改业务系统的配置中心的Redis密码 # 这里注意先改备用节点或低流量时段避免全量断连 # 4. 验证新密码可连接 redis-cli -h 127.0.0.1 -p 6379 -a $NEW_PASS PING # 5. 写回配置文件 redis-cli -a 旧管理密码 CONFIG REWRITE我踩过最大的坑是改了ACL用户的密码但业务系统的配置中心里写死的是原来的requirepass而且代码里连接Redis时没有指定用户名。改完密码后所有连接瞬间认证失败报警消息刷屏。所以要特别提醒改密码前确认业务侧连接Redis的配置项里写的是用户名密码形式的连接串还是只写了密码。老式的只写密码的方式在ACL开启后很容易出这种问题。TLS证书轮换也是类似的。证书文件不是改了配置就能生效需要确认Redis加载的是新证书建议在低峰期重启Redis实例或执行CONFIG SET触发重新加载。Cert轮换时不止要更新Redis进程的证书如果客户端也开启了TLS校验客户端的信任链也要同步更新两头都换才不会有“悄悄断连”的情况。8.3 监控和告警把Redis安全事件纳入统一监测等保三级“安全管理中心”要求对安全事件进行集中监测。Redis在安全层面的监控怎么落地我总结为三个维度认证失败监控ACL LOG和Redis日志中认证失败出现大量记录说明有人在尝试爆破要告警高危命令监控如果ACL日志里出现CONFIG SET被拒绝、FLUSHALL被拒绝的记录说明有人在尝试侵入异常连接监控连接数突然激增、每秒新建连接数异常很多时候是扫描器在扫端口这些日志如果只躺在服务器本地等保测评时给测评师的解释就没那么有说服力。我的建议是接入现有日志平台配置对应的告警规则。现在的开源日志采集方案已经很成熟Redis日志是怎么接入不需要我再多讲关键是要定好告警阈值和响应流程别让告警变成没人看的数字。9. Redis安全测评的最终自查清单对完这一张表就能约复测做测评整改到最后落点永远是一份清单。我给客户做复测前总是拉一张自查表把每一项过完一遍才敢约复测时间。这张表按上面的内容整理出来可以直接照着用。类别检查项自查命令/方法合规状态身份鉴别已配置强口令且无弱口令CONFIG GET requirepass检查密码复杂度身份鉴别已启用ACL且default用户为offACL LIST确认default状态访问控制业务账号按最小权限授权ACL GETUSER 业务账号检查命令分类访问控制高危命令已禁用或重命名CONFIG GET rename-command访问控制服务以非root用户运行ps -ef | grep redis-server安全审计日志开启且留存不少于6个月CONFIG GET logfile检查logrotate配置安全审计ACL日志已启用CONFIG GET acllog-max-len数据保密RDB/AOF文件权限正确ls -la /var/lib/redis*数据保密敏感数据加密存储或磁盘加密检查磁盘加密状态及应用层加密代码通信安全bind未绑定0.0.0.0CONFIG GET bind通信安全网络策略仅允许业务地址访问安全组/iptables规则复核通信安全如使用主从复制复制链路易受保护检查TLS配置或网络隔离资源控制maxmemory已设置CONFIG GET maxmemory资源控制maxclients已设置CONFIG GET maxclients漏洞管理版本为受支持且已修复已知漏洞INFO server对照官方安全公告日常运营有配置巡检和告警机制检查监控系统Redis安全相关告警规则如果自查表里还有空项就不要急着约复测先补上再走流程。我做过一个项目第一次复测前以为只差一个“数据加密说明材料”结果测评师现场随机抽查了Redis服务运行用户是否真的是redis用户、ACL日志能不能现场查出来这两个细节没准备到位推迟了验收。所以自查这事宁可多过几遍也别赌现场发挥。整个过程走下来我的体会是Redis等保测评整改并不难难的是把“看起来做了”变成“清清楚楚、证据齐全地做了”。测评师也是按标准和流程做事的人让他们能快速从配置和证据里确认你的控制措施有效整个测评过程就会顺畅很多。如果这篇内容对你有帮助照着清单一项一项过你的Redis也能从“裸奔大隐患”变成“等保过检样板间”。