SequoiaDB 关于 MongoDB 安全事件的一些思考

事件回顾

此前，众多无需身份验证的开放式 MongoDB 数据库实例正在遭受多个黑客组织的攻击，被攻破的数据库内容会被加密，受害者必须支付赎金才能找回自己的数据。攻击者利用配置存在疏漏的开源 MongoDB 数据库展开了一系列勒索行为。此番针对 MongoDB 的勒索行为早是由 GDI Foundation 的安全研究人员 Victor Gevers 在2016年12月27日发现的，在这之后影响陆续扩大，目前至少有五个不同黑客组织控制了上万个数据库实例。

目前在Google Docs上有一个列表，其中列出了参与此次攻击的黑客组织名单，具体数量还在增加中。攻击者所要求支付的金额各异，低仅0.15个比特币，但也有高达1个比特币的赎金。2017年至今，比特币的价值上下波动，截止1月6日，具体金额约等于892美元。

此次针对MongoDB的攻击非常简单，利用了配置有误且可公开访问的数据库，无须具备相应的管理员凭据即可展开攻击。一旦攻击者登录到开放的数据库，随后会全面夺取控制权并窃取或加密数据库，被勒索的受害者必须支付赎金才能找回自己的数据。

事件几点分析

针对此次的MongoDB安全时间，业界的评判不一，而从一个数据库厂商的角度，我们认为主要的原因有一下几点：

1） 数据库用户的安全意识：本次攻击的原理并不复杂，基本属于把自己数据库的大门敞开，难免终会被贼“光顾”。一方面，用户对于数据库特别是MongoDB这样的数据库新面孔并没有特别熟悉，因此在使用的过程中由于经验不足而没有注意数据库安全的设置。另一方面，一些用户会认为防火墙和数据中心的安全机制已经足够，不需要再管数据库的安全设置，终“大意失荆州”。归集起来，原因主要还是用户对于数据库使用的经验不足。

2） 黑客攻击后未有有效的警告：除了本身用户使用的大意，对于数据库安全的监控无论是厂商自己还是相关的机构都远未达到大家的预期。首先，早在15年有关MongoDB“裸奔”的消息放出后，无论是厂商还是业界都没有引起足够的重视，更没有有效的警告和提醒。其次，在本次大规模的攻击事件发生后，各方的反应也较慢，直到有媒体开始爆出消息才引起了厂商和用户群体的警惕。然而可以说是“为时已晚”。

3） MongoDB的安全机制不完善：虽然本次安全时间并不是因为MongoDB程序自身的漏洞而遭到大规模攻击，但是作为厂商，产品用户遭到大规模的攻击和勒索，自己也是难逃其咎。总结起来主要有两个问题，一个是安全机制的不完善，也就是在使用中没有自动化的安全保护机制，如MongoDB在3.x之后更改了鉴权协议，而不兼容2.x版本协议，许多用户因为不愿升级而终选择“裸奔”。另一个，MongoDB也没有能有效的提醒用户注意设置数据库权限，对于可能出现的“裸奔”情况，其并没有做好十足的提醒，保证用户必须设置好权限才可以使用，这也是造成本次事件的主要原因之一。

数据库安全的思考

说了这么多，大家应该也比较关心怎么去预防类似问题的出现，我们也在这里给大家几点思考吧：

1） 数据库安全十分重要：这次的事件提醒大家，数据库安全真的很重要。无论是的还是新人“小白”用户，都应该把数据库的安全提到一个重要的位置。用户们要注意数据库的安全保护，充分利用好数据库的安全机制，保护好自己的数据。避免这次MongoDB“裸奔”的情况出现。

2） 企业用户需要专业的技术支持：对于数据量达到一定规模或者是保存的数据十分敏感、重要的企业用户，无论是数据库安全还是数据库的高效管理、高性能配置，我们认为好都要寻求专业的厂商技术团队的支持。厂商专业的团队可以帮助企业更全面的使用和管理好自己的数据库平台，同时，厂商专业的团队也能给到用户好及时的数据库安全保护和漏洞修复服务，避免大规模数据库安全事故的发生。

3） 国产化与开源产品：虽然目前业界也有许多的海外开源产品，但是作为用户，如果在并不能完全了解这些技术的前提下使用开源架构，很可能也会面临使用上和管理上的一些盲点，造成出现数据库“裸奔”这样的失误。因此，国内的用户我们也认为可以考虑更多国产大数据架构，这样不仅产品更适合国内应用场景需求，在技术支持上相对海外的开源架构，更能给到原厂代码级别的服务支持。

4） 厂商的产品服务：反过来，对于厂商，我们希望厂商也都能引以为戒，产品开发要更全面的考虑到用户的需求以及可能遇到的问题，同时对客户的服务响应上也要更加的及时，不要等到大规模的爆发了问题才引起重视。

来源：https://www.oschina.net/news/80823/some-thoughts-on-mongodb-security-incident