非关系型数据库的安全现状
现在越来越多的项目开始用MongoDB、Redis这类非关系型数据库，速度快、扩展方便，特别适合做用户行为记录、缓存或者实时数据处理。但很多人只关注效率，忽略了安全问题。比如公司内部一个后台系统用了MongoDB存用户操作日志，端口直接暴露在内网，没开认证，结果被同事误连上去删了数据，恢复起来费了好几天功夫。
这其实不是个例。不少开发为了图省事，在测试环境甚至生产环境都默认关闭身份验证，以为“反正没人知道地址”。可一旦服务器IP泄露或者被扫描到，数据就等于裸奔。
常见的安全隐患
第一是认证机制缺失。像Redis，默认配置下不需要密码就能访问。有人做过统计，公网还能搜到上万个未授权的Redis实例。攻击者连上去可以直接写入恶意脚本，甚至利用主从复制机制拿到服务器权限。
第二是缺乏细粒度权限控制。MySQL可以给用户分配具体库、表的操作权限，而很多NoSQL数据库早期版本只支持“能连”或“不能连”两种状态。虽然新版本已经改进，但很多老系统还在用旧模式。
第三是数据传输不加密。默认情况下，MongoDB内部通信是明文的。如果集群节点分布在不同机房，中间经过公网链路，数据包很容易被截获。曾经有团队把用户手机号哈希值存在MongoDB里做匹配，结果因为没开TLS，被中间人还原出了原始信息。
实际应对措施
开启身份验证是最基本的操作。以MongoDB为例，必须启用keyFile或x.509认证，并创建最小权限账号。不要用admin这种通配角色，而是按需分配read、readWrite等权限。
网络层面要做好隔离。数据库不要直接绑定0.0.0.0，应该限定只监听内网IP。配合防火墙规则，只允许应用服务器IP访问对应端口。比如Redis配置中加上：
bind 192.168.1.100敏感数据要主动加密。即使数据库本身支持字段级加密（如MongoDB Client-Side Field Level Encryption），也不妨在应用层先处理。比如用户身份证号入库前用AES加密，密钥由独立服务管理，就算数据库被人拖走，也很难解密。
定期审计和监控也不能少。设置告警规则，当出现大量delete操作或异常IP登录时及时通知。有家公司就是因为监控到位，发现某个Redis实例突然有境外IP连接，立刻切断并排查，避免了数据泄露。
选型时也要考虑安全
不是所有NoSQL都一样。Cassandra支持节点间SSL加密和基于角色的访问控制；而某些轻量级KV存储可能连日志审计都没有。做技术选型时，除了性能和成本，得把安全能力列进去对比。
另外，别忘了更新和补丁。去年MongoDB修复了一个CVE漏洞，允许未认证用户通过特定查询获取内存信息。打了补丁的版本没问题，但很多老系统一直没升级，风险持续存在。