企业官网建设流程全解析

前阵子帮一家单位做等保三级测评整改，到了机房一看，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 测评时的检查地图。后面的每一个章节，实际上都是在围绕这六类要求做具体展开。

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 whoami

Redis 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 loglevel

Redis 默认的 logfile 是空的，日志直接输出到标准输出。如果是通过 systemd 启动，日志可能进了 journal；如果是在终端里手动起的，一旦关闭终端日志就全丢了。loglevel 默认是 notice，在测评中基本够用，不用刻意调成 debug，debug 会产生海量日志，反而影响运维。

其次看日志内容是否够用。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 这类中间件在不合格项上出镜率最高的五类问题，做成速查表放在下面：

前三个问题如果同时存在，基本可以直接认定为“高危风险”，整个 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结果，和期望基线做比对，有差异就告警。等保测评一年一次，但安全风险是每天都在变的。自动化巡检不能替代正式测评，却能让正式测评到来时，你不至于在手忙脚乱中补作业。