Redis等保测评那些事儿，手册里说的重点和注意点都在这了

说到Redis的等保测评，这事儿说简单也简单，说麻烦也麻烦，简单在于Redis本身很纯粹，就是一个内存数据库；麻烦在于很多人部署的时候图省事，用了默认配置，这在测评眼里全是扣分项甚至是一票否决项,下面我就把手册里反复强调的重点和注意点给你捋一捋。

第一，身份鉴别是第一道坎，也是最容易栽跟头的地方。 手册里明确要求（引用来源：《信息安全技术 网络安全等级保护基本要求》），要对登录的用户进行身份标识和鉴别，但Redis的默认配置是什么？是空密码，没有密码！你直接一个redis-cli就能连上去，这在测评中是绝对不允许的，属于高危风险。首要任务就是给Redis设置一个强密码，在配置文件redis.conf里找到requirepass这个参数，设上一个又长又复杂的密码，光有密码还不够，手册还要求（引用来源：同上）登录失败要有处理机制，比如连续输错几次就锁定一段时间，但Redis原生不支持这个功能，这就得想其他办法了，比如在前面加个代理,或者通过系统日志和脚本来实现类似的监控和阻断效果。

第二，访问控制要做到最小权限。 手册要求（引用来源：同上）应授予管理用户所需的最小权限，Redis的权限控制比较弱，主要就靠那个密码，但有时候，你可能需要给不同的应用分配不同的权限，这时候，如果用的Redis版本比较新（6.0以上），就要用好它的ACL（访问控制列表）功能，你可以创建不同的用户，给每个用户指定它能执行的命令（比如只允许读，不允许写）、能访问的键前缀，千万别用一个密码走天下，应用连数据库用同一个高权限账号,这是大忌。

第三，安全审计是查账的，日志必须开。 手册里对审计的要求很细（引用来源：同上），要求记录重要的用户行为，比如登录、操作这些，Redis的审计功能比较基础，需要在配置文件里通过acllog-max-len设置一个合理的日志长度，并且确保日志文件有正确的权限，别谁都能看，更重要的是，你要有流程定期检查这些日志，看看有没有异常登录、有没有执行危险命令（比如FLUSHALL把整个库清空了），测评的时候,审计日志的记录内容和保护措施是必查项。

第四，数据完整性保密性不能忘。 Redis默认是明文传输的，这意味着你和Redis服务器之间的所有通信，包括密码和敏感数据，在网络上都可能被别人截获看到，手册要求（引用来源：同上）在通信过程中应采用校验技术或密码技术保证数据的完整性和保密性。在生产环境，尤其是跨网络访问时，强烈建议启用SSL/TLS加密，虽然会牺牲一点点性能，但为了安全是值得的，对于存储在内存里的敏感数据，可以考虑在写入前应用层自己先加密一遍,再加一层保险。

第五，入侵防范和恶意代码防范。 这方面Redis自身能做的有限，更多依赖操作系统和环境，手册要求（引用来源：同上）应遵循最小安装原则，仅安装需要的组件。绝对不要用root用户来运行Redis服务！必须创建一个专用的、权限很低的普通用户来跑Redis，要确保这个用户没有登录shell，也不能随便读写系统关键文件，要用系统的防火墙（如iptables、firewalld）严格限制能访问Redis端口的IP地址，最好只允许特定的应用服务器IP连接,对公网暴露Redis端口是极其危险的行为。

第六，剩下的就是一些零碎但重要的点。 比如版本管理，不要用太老的有已知严重漏洞的版本，要及时更新，比如配置文件的权限，redis.conf里面放着密码，它的权限应该设置成只有Redis用户可读可写，其他用户无权访问，再比如危险命令，像FLUSHDB（清空当前库）、FLUSHALL（清空所有库）、CONFIG（动态修改配置）这些命令，在生产环境下可以考虑通过rename-command配置项把它们重命名成一个超级复杂的、别人猜不到的字符串，或者直接重命名为空字符串来禁用,防止被误操作或恶意利用。

Redis过等保，核心思想就是告别默认配置，主动加强安全，从设密码、控权限、开日志、加密传输、限访问、降权运行这几个方面入手，把手册上的要求一个个落实到配置文件和运维流程里，虽然看起来步骤多，但每一项都是为了堵住一个真实存在的安全漏洞,马虎不得。