MongoDB 安全门事件
此前，MongoDB 也多次出现安全问题。无需身份验证的开放式 MongoDB 数据库曾遭到多个黑客组织的攻击，被攻破的数据库内容会被加密，受害者必须支付赎金才能找回自己的数据。
- 2016 年 12 月底,MongoDB 遭黑客攻击，事情在 2017 年 1 月达到顶峰。攻击者利用配置存在纰漏的 MongoDB 展开勒索行为，自称 Harak1r1 的黑客组织将网络上公开的 MongoDB 资料库中的资料汇出，并将 MongoDB 服务器上的资料移除。起初两百个 MongoDB 数据库实例的数据被非法清除，几天之内，受感染的 MongoDB 数据库实例已经增长至一万多台。开始攻击者要求受害人支付 0.2 个比特币 (当时的价值约为 184 美金) 作为数据赎金，随着被感染的数据库越来越多，攻击者将勒索赎金提升至 1 个比特币 (价值约为 906 美金)。此次事件被称为“MongoDB 启示录”。
- 2017 年 9 月，MongoDB 数据库再次遭到黑客勒索攻击，三个黑客团伙劫持了 2.6 万余台服务器。与“MongoDB 启示录”相比，此次攻击者的数量有所下降，但每次攻击的破坏性（受害者）数量上升。
MongoDB 为何如此易受攻击
MongoDB 出现时，凭借简单的部署方式，高效的扩展能力、多样化的语言接口，并借着云蓬勃发展的势头，一度在全球数据库市场占据第四名。但是，MongoDB 也存在安全风险。在一篇文章中，作者分析了 MongoDB 的最大的安全问题来源于 MongoDB 的默认配置。在默认部署情况下，MongoDB 无需身份验证，即可登录，不法分子只要在互联网上发现 MongoDB 的地址和端口就可以通过工具直接访问 MongoDB，并拥有 MongoDB 的全部权限，从而进行任意操作。之所以会如此设计，原因在于：
- MongoDB 默认通过最简单部署方式，最大限度提高运行速度，以在虚拟机（低配机）上运行而定制的，并未充分考虑 MongoDB 的安全性。
- MongoDB 官方文档，如针对身份验证，传输加密，网络配置的文档、指南并不规范，容易误导 MongoDB 管理员。
- 一些 MongoDB 环境是为了单一项目或者是测试环境搭建，搭建者并不关心 MongoDB 的安全问题。
徐飞博士在极客时间的专栏《技术与商业案例解读》中也总结过，MongoDB 作为一个文档数据库，在开发策略上把绝大部分注意力都放在提高产品易用性上，也花了不少功夫来打开市场，但是在安全方面投入的精力相对很少。
如何防范隐私数据被泄漏
随着隐私数据泄漏的情况变得越来越普遍，组织应该认识到正确保护第三方数据库服务器的重要性，并采取必要的步骤来加密数据，以确保在恶意目的下无法使用。去年 8 月底华住集团泄露 2 亿多开房记录的事件闹得沸沸扬扬，InfoQ 在对事件的报道中也向大家提供了防范数据泄漏的建议：
- 更换端口：不使用默认端口虽然无法杜绝黑客的入侵，但可以相对增加入侵难度；
- 公网屏蔽：只监听内网端口屏蔽公网端口的请求，通过该策略继续增加黑客的入侵难度；
- 使用普通用户启动：建议大家维护的所有 db 都使用禁止登录的非 root 用户启动；
- 开启验证：这虽然是复杂、痛苦的一步，但却是明智的选择；
- 权限控制：建议大家针对自己维护的数据库设置一套适合对应业务的权限控制、分配方案；
- 备份策略：一套可靠的本地备份逻辑 + 远程备份存储方案可以解决被黑、误删、机房漏水、服务器报销，甚至机房被核弹炸毁的场景；
- 恢复策略：建立一套能够覆盖多数灾难场景的恢复策略来避免手忙脚乱是非常必要的；
- 敏感数据加密存储：我们建议大家一定对任何敏感信息加密后再入库，例如：密码、邮箱、地址等等。
此类事件频发也表明，安全是个不容忽视的问题，希望各厂商、开发者能够重视安全问题，避免造成不必要的损失。