通过MongoDB安全事件来谈谈为什么要用云服务

每到年底，比铁路部门还忙碌就是各路小偷，恰巧最近一篇关于NoSQL暴露公网的文章开拓了他们的思路。就在文章发布后这一周里，陆陆续续接到关于自建MongoDB被“黑客”攻击，数据被删，并且索要Q币的案例。今天我自卖自夸下，为了数据库安全，快点上云MongoDB。但正式自夸之前，我们先来复盘看看。

被黑者特征

本次事件的作案手法实在是称不上高级，所以我暂且称他们为“坏人”，但这事不能完全埋怨“坏人”，被攻击的这些自建MongoDB，全部都满足两个特征：

1. 暴露公网地址，甚至有些实例端口号都是默认的27017；
2. 没有配置鉴权约束，谁来都可以访问；

怎么攻击的

这就是把自己家的大门敞开，任由“坏人”搜割，“坏人”会做几件事：

1. 访问shadon网站，本来这个网站是做互联网数据分析的，原理是扫描全球IP和端口，通过分析协议来收集各种设备或者服务的统计数据。不幸被人利用，这些“坏人”甚至连端口扫描都不用，shadon都为你准备好了；
2. 用mongoshell等管理工具尝试登入，因为很多人的MongoDB都没有配置鉴权，所以连破解密码都的步骤都可以省了；
3. 单独破坏数据库意义不大，一般都是把数据dump到本地留存一份，或者直接修改集合名称或者地址，存在一个相对隐蔽的地方；也有“坏人”纯恶意破坏；
4. 勒索受害人，索要Q币或者比特币，交钱放“人”（归还数据，如果有的话）；

该埋怨谁

看吧，实在不是很高明的手段，也真的不能完全埋怨“坏人”不讲情理。这事情责任三方各打一板，怎么是三方？

1. “坏人”责任50%，勒索良民；
2. 自己责任40%，谁叫你公网地址，谁叫你不配鉴权的？大门敞开，家里被盗，上哪都喊不了冤；
3. MongoDB责任10%，说起来有点冤，但默认配置就应该强制要求鉴权访问，并且这事情也是需要官方不断去教育用户（虽然官方英文文档明确有写明要配置鉴权来保障安全），但不能指望人人都有安全意识；另外，MongoDB 3.0开始修改了鉴权协议，不支持2.x的Driver，很多用户也因此懒得去升级客户端，索性不要鉴权；

亡羊补牢

事实已经发生了，埋怨没有用，怎么解决：

1. 不论你有没有中招，有没有在公网，都要检查鉴权配置，避免更多的损失；
2. 关闭公网的访问入口，把门关上；
3. 如果你是阿里云用户，尝试恢复ECS存储镜像，有多少算多少；但是有一定的风险是镜像恢复了，但数据文件可能是不完整的，用MongoDB的repair命令尝试修复，祈祷吧；
4. 碰碰运气，看看数据表是不是只是被rename了，因为数据dump是有时间成本和存储成本的，有监控数据的可以对比下看看容量有没有变化；
5. [**心有余孽的话就快点用阿里云MongoDB**；](https://www.aliyun.com/product/mongodb)

还是来用阿里云MongoDB吧

阿里云的云版MongoDB从设计之初就重点考虑了安全问题，所以整个服务提供上我们具备：

1. 基于MongoDB 3.2兼容版本的解决方案，并且强制要求鉴权，并且默认不提供公网入口。还在用2.X版本的同学们尽快升级吧，各种原因可以参考另一篇文章，[《告别 MongoDB 2.x 拥抱 3.x 版本的5大理由》](https://yq.aliyun.com/articles/67120?spm=5176.100240.searchblog.22.YA5jTQ)；
2. 阿里云提供云MongoDB的VPC能力，即使在阿里云内网，也可以网络隔离；
3. 阿里云MongoDB提供白名单功能，只接受你自己的ECS访问；
4. 重点的来了哦，这可是自建没有能力，增量数据备份与恢复，哪怕被人删了，或者自己不小心drop了，可以恢复到任意时间的数据状态；
5. 重点的又来了，这可是官方企业版的能力，完整的审计日志，被谁删的，怎么删的，数据哪里去了，一清二楚；
6. 阿里云安全专家众多，“攻击者”也是看风险和收益比的；

另外，值得一提的是，因为PHP这种高级语言，对数据库的操作都是短连接，所以鉴权开启后会带来大量的性能损失（主要影响并发能力），阿里云MongoDB也在这方面做了优化处理，针对短连接场景，阿里云有10倍性能优化。同时，也提供上云在线迁移服务DTS，详情请访问官网了解。

最后再来个硬广，我们不趁火打劫，还大幅度降价，比自建成本更低的三节点集群服务，ApsaraDB产品线6折促销中，请猛烈点击我。