Redis审计日志安全怎么保障，自己日志那些事儿别忽视了

Redis审计日志的安全保障，以及我们自己服务器上日志的那些事儿，确实是不能忽视的重要环节，很多人把Redis搭起来，业务能跑通就以为万事大吉，却忘了“日志”这个默默记录一切的“旁观者”如果保护不当，反而会成为攻击者的帮凶，下面我们就来详细聊聊怎么保障Redis审计日志的安全,以及如何打理好我们自己的日志。

第一部分：Redis审计日志的安全怎么保障

我们要明白Redis社区版本身并不像一些商业数据库那样，内置一个功能完备、开箱即用的审计日志模块，它的日志主要记录的是服务器运行状态、警告和错误信息，而不是详细记录谁在什么时候执行了什么命令，要实现对Redis操作的审计,我们需要采取一些额外的措施。

开启Redis的慢查询日志 虽然慢查询日志的主要目的是为了性能优化，但它在一定程度上也能起到安全审计的作用，我们可以通过设置slowlog-log-slower-than参数（比如设置为0，记录所有命令），让Redis记录下每一个执行的命令，这样，我们就能追溯哪些客户端执行了哪些操作，这个方法有局限性：它不是为审计设计的，日志格式相对简单，而且当命令量巨大时，日志会滚动覆盖，无法长期保存，更重要的是，如果攻击者知道了这个设置，他可能会通过大量发送正常速度的命令来“冲刷”掉他的恶意操作记录。（来源：Redis官方文档关于慢查询日志的说明）

使用Redis的MONITOR命令 MONITOR命令是一个调试命令，它能实时打印出服务器接收到的每一个命令，我们可以通过重定向输出，将MONITOR的结果保存到文件里，实现实时审计，但这是一种性能杀手，因为MONITOR会对Redis性能造成显著影响，在高并发生产环境下绝对不能长时间开启，它只适合在排查特定问题时临时使用。（来源：Redis官方文档关于MONITOR命令的警告）

部署专门的审计方案 这是最推荐的方法，既然Redis原生支持弱,我们就借助外部力量。

1. 使用代理中间件：在应用程序和Redis服务器之间加一层代理（比如Twemproxy），由代理来记录所有经过它的请求和响应，这样既实现了审计,又对Redis本身无侵入。
2. 使用网络流量抓取：通过监听Redis服务器的网络流量，解析Redis协议，将命令记录到独立的审计系统中，这种方式对Redis性能影响最小,但实施起来有一定技术复杂度。
3. 考虑企业版或云服务：Redis企业版和阿里云、腾讯云等云服务商提供的Redis服务，通常都内置了更强大的审计功能，可以直接在控制台配置和查看审计日志，这是最省心的方式。（来源：各大云服务商Redis产品文档）

保障审计日志自身的安全 无论用哪种方法生成了审计日志,日志文件本身的安全必须得到保障：

• 权限控制：确保审计日志文件的读写权限严格控制，只有授权的管理员账户才能访问,防止攻击者篡改或删除日志以掩盖行踪。
• 集中存储：不要将审计日志留在Redis服务器本地，应该使用日志收集工具（如Fluentd, Logstash）实时将日志传输到专门的、安全的日志服务器或日志平台（如ELK Stack）上，这样即使Redis服务器被攻破,审计记录依然完好无损。
• 完整性校验：可以考虑对日志文件进行哈希计算或数字签名,以便检测日志是否被篡改。

第二部分：自己日志那些事儿别忽视了

说完了Redis，我们再来看看服务器上那些我们自己应用程序产生的日志，这些日志同样包含大量敏感信息,处理不好就是下一个安全漏洞。

日志里不能记什么？ 这是最重要的原则，很多开发人员为了图方便，会把所有数据都打印到日志里,这是极其危险的。

• 绝对不要记录明文密码：无论是用户登录密码还是数据库连接密码。
• 谨慎记录敏感个人信息：用户的身份证号、银行卡号、手机号、详细住址等，如果业务确实需要追踪（比如订单日志），可以进行脱敏处理,比如只显示手机号前3后4位。
• 不要记录完整的令牌（Token）或Session ID：这些相当于临时密码,泄露的风险很高。
• 避免记录完整的API密钥。

日志存储和访问的安全

• 权限最小化：和Redis审计日志一样，应用程序的日志文件也必须设置严格的访问权限,避免非授权用户读取。
• 日志轮转和归档：要配置日志轮转策略，防止单个日志文件过大，同时对于过期日志要及时归档或安全地删除,归档的日志同样要加密存储或放在安全的位置。
• 访问日志的监控：谁在什么时候访问了日志文件，这个行为本身也应该被记录下来,形成监控闭环。

日志传输要加密 如果日志需要通过网络传输到中央日志服务器，务必使用加密通道，例如使用TLS加密的Syslog，或者通过SSH、VPN等安全隧道传输,防止在传输过程中被窃听。

建立日志分析和告警机制 光有日志还不够，关键是要能从中发现异常，应该建立日志分析系统,设置一些安全告警规则，

• 频繁的登录失败：可能是在进行暴力破解。
• 异常时间的访问：在非工作时间段出现大量业务操作。
• 执行了敏感命令：比如在业务日志中发现了SQL注入尝试或系统命令执行的痕迹。 一旦触发告警,系统应立即通知管理员。

无论是Redis的审计日志还是应用程序的业务日志，我们都必须从“产生、传输、存储、分析”整个生命周期来考虑其安全性，不能只满足于“有日志”，而是要确保日志是完整的、真实的、受保护的、可用的，忽视日志安全，就等于在给攻击者留后门，等出了问题再回头看，可能就只剩下被清理过的现场了,请务必把日志的这些事儿重视起来。