Redis权限没管好，数据随便被读，信息泄露风险挺大

（来源：根据近期多起企业安全事件通报及安全研究人员案例分析综合整理）

这事儿说起来其实挺让人后怕的，很多公司，尤其是那些业务跑得飞快、技术团队年轻人多的公司，在用Redis这个内存数据库的时候，压根就没把它当个需要严加看管的“保险柜”，反而觉得它就是个临时放东西的“公共抽屉”，谁都能拉开抓一把，结果呢？就因为这个疏忽,出了不少大乱子。

最要命的一点是，很多管理员在安装好Redis之后，直接就用了默认配置，这个默认配置有个天大的漏洞：它为了图省事，默认是不设置密码的，这就好比您家买了个高级保险箱，结果出厂密码是空的，或者就是个简单的“123456”，您也没改，直接就用了，那这不就等于敞开着大门迎客吗？攻击者根本不需要什么高深的技术，只要通过网络扫描工具，批量找一下那些暴露在公网上的、用了默认端口6379的Redis服务，一连接就能进去，进去之后，发现没密码，得，整个数据库对他而言就是透明的，想怎么看就怎么看,想怎么拿就怎么拿。

（来源：基于网络安全公司对暴露在公网的不安全服务扫描统计报告）

光没密码还只是第一道坎儿，就算有些团队意识到了要设密码，这个密码的管理也往往很随意，要么是设了个特别简单的弱密码，容易被暴力破解；要么是把这个密码硬编码在应用程序的配置文件里，而这个配置文件又可能因为各种操作失误，比如部署脚本写错了、代码仓库权限没管好，就被泄露到了公开的网络上，攻击者一旦拿到了这个配置文件，就等于拿到了钥匙,照样登堂入室。

更让人头疼的是权限划分的问题，Redis本身在权限控制上就比较简单粗暴，不像有些数据库能精细到“张三只能读A表，李四只能写B表”，在Redis里，通常就是一个密码，谁有这个密码，谁就拥有了对这个Redis实例的最高权限，这意味着，如果一个公司内部多个业务、多个应用都共用同一个Redis实例，而又没有做网络隔离或者代理层控制，那么理论上，一个只应该有权限读取某些缓存数据的后勤应用，其背后的代码或人员，也有可能因为拿到了这个通用密码，而看到甚至修改电商模块的用户订单信息、支付数据，这种内部权限的混乱,造成的风险一点也不比外部攻击小。

（来源：来自某电商平台内部安全审计案例分享）

数据泄露的后果可不是闹着玩的，Redis里经常会存放些什么呢？那可都是核心数据，用户登录的会话信息（Session），里面可能包含着用户ID、登录状态，攻击者拿到了就能冒充用户登录；用户的个人资料，比如手机号、邮箱地址、昵称；在一些业务场景下，甚至可能临时存放一些敏感信息，比如短信验证码、用户的浏览历史、购物车内容，如果是一些金融或交易类应用，还可能缓存有部分脱敏不彻底的交易记录，这些数据一旦被拖库（整个数据库被下载走），后果不堪设想，轻则用户接到骚扰电话、诈骗短信，重则导致用户在其他平台的账号被撞库攻击（用泄露的账号密码尝试登录其他网站），直接造成财产损失，对于公司来说，除了面临监管的重罚、用户的诉讼，最致命的是品牌信誉的崩塌,用户再也不相信你能保护好他的数据了。

（来源：综合自多起数据泄露事件后的用户投诉及监管部门公告内容）

为什么这么明显的风险却普遍存在呢？一方面是因为Redis的设计初衷更偏向高性能和简单易用，它在安全方面的“不贴心”让很多开发人员误以为它不需要像关系型数据库（比如MySQL）那样去严格管理，在快速迭代的开发压力下，安全步骤往往是被第一个牺牲掉的。“先让功能跑起来，安全以后再说”这种思想非常普遍，总觉得黑客不会盯上自己这个小公司，但现实是，自动化的攻击脚本可不管你是大公司还是小公司，它们24小时不停地在网上扫描，只要你有漏洞，就会被发现、被利用。

说到底，Redis权限没管好，根本原因还是安全意识薄弱和侥幸心理作祟，它不是一个高精尖的技术难题，而是一个需要被重视、被规范执行的管理问题，如果继续把它当成一个无足轻重的“缓存工具”而放任不管，那么数据泄露的风险就像一颗定时炸弹,随时都可能被引爆。