从MongoDB安全事件说起，找到了原因和解决方案，危机之后又该怎样反思呢？
更多深度文章，请关注：https://yq.aliyun.com/cloud
背景介绍
近期，大批量的MongoDB实例因为配置漏洞遭遇了攻击，黑客无需身份认证即可登录MongoDB实例，从而删除了大量数据，并勒索受害者支付赎金才能要回自己的数据。截止目前为止，被劫持的MongoDB实例已经达到了一个惊人的数量。更加可恶的是，黑客在删除完业务数据库后，在里面的数据库留下了这段嘲讽+敲诈的“战书”。简单翻译下：“你的数据库可以通过公网IP免密码登陆，你是怎么想的？”
面对赤裸裸的挑战，我们如何应对？我们如何保证数据的安全？
事件当天多家云计算服务商及时响应事件，在各云服务商控制台推送声明和处理办法，也通过官方微信等渠道对事件及出现数据库被入侵的原因，同时提供了应对办法。
被入侵原因
黑客攻击的MongoDB实例需要同时具备以下两个条件：
- MongoDB实例免密码登录
- MongoDB实例开放了公网访问
其实熟悉MongoDB的同学会不难发现，被攻击原因非常简单，而且由来已久。从根本上说，这其实是MongoDB在设计之初的一个小疏忽。MongoDB为了让开发者能够更快地上手使用，支持免去复杂的连接配置和鉴权方式的做法，默认情况下是无鉴权的，即免密码即可登陆。同样的原理，其他类型的数据库比如MySQL，只要配置了允许免密码公网IP访问，同样会存在遭遇攻击的风险。
通过上述的原因分析，也反应了MongoDB使用者安全意识不高，把重点精力放在产品开发和工具使用上，而忽略了数据安全的重要性。并且在2015年包括之前已经有技术人员公布了使用MongoDB存在的这个问题，但每次都没有引起足够重视，造成了这次更严重的入侵数据库事件。
自建MongoDB数据库的解决办法
参考解决办法
1.开启密码认证方式访问MongoDB（如果是副本集或mongos集群建议使用keyfile认证，UDB默认使用keyfile）;
2.在“admin”数据库添加一个“userAdminAnyDatabase”角色的用户，如下所示将会添加一个用户名为“myUserAdmin”密码为“abc123”的用户（千万不要使用弱强度密码）：
use admin
db.createUser(
{
user: "myUserAdmin",
pwd: "abc123",
roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
}
)
详细配置参考MongoDB官网文档：https://docs.mongodb.com/manual/reference/configuration-options/
3.已经使用鉴权的，建议将密码修改为足够的复杂度，排除被暴力破解的可能
4.禁止通过公网IP访问MongoDB
在配置文件mongo.conf中设置bindIp为该云主机的内网IP或127.0.0.1。
net:
bindIp: 127.0.0.1
port: 3001
http:
enabled: false
5.使用云MongoDB
相比自建MongoDB，云MongoDB具有一定的优势。优势和特性将在下节具体介绍。
安全性检查列表
MongoDB官网提供了一些安全检查点：
- 开启访问控制并强制鉴权
- 配置基于角色的访问控制
- 通信加密
- 加密并保护数据
- 限制对公网开放
- 进行审计
- 使用单独的账户来运行MongoDB
- 运行MongoDB时使用安全配置参数
- 参照适用的安全技术实施指南
- 符合安全合规标准
详细内容请参考MongoDB官网文档：https://docs.mongodb.com/manual/administration/security-checklist/
使用云MongoDB
使用内网访问
部分云服务商的MongoDB实例必须通过内网连接对内提供服务或通过堡垒机对外提供服务，避免了MongoDB实例直接暴露在公网上。MongoDB实例完全实现VPC内网隔离，并且在配置文件中强制设置了bind_ip值为该MongoDB实例的内网IP。
强制使用密码鉴权
云MongoDB在设计开发时并非直接把开源MongoDB简单安装，而是对一些配置参数进行调整、对性能进行优化、对安全措施进行加强。各主流云服务商的云MongoDB都是强制使用密码进行鉴权，并且要求使用强复杂度的密码，也减小了被暴力破解的可能性。
数据加密
云服务商在MongoDB数据存储时进行了相应的加密措施，以应对黑客入侵后获取数据进行利用的灾难。
数据备份
数据加密只能保证数据即便被获取也不能被使用，但无法保证数据被删除。云MongoDB数据库在各主流云服务商的存储机制不尽相同，但都对数据进行了备份，进一步保证数据的可靠性。
如何从云主机迁移到云MongoDB
一般MongoDB的迁移上云的策略都是通过副本集的高可用性来实现，不过需要首先保证网络的连通性（云计算服务商基本都会协助打通）。通过将云数据库作为自建数据库的Secondary节点，当两个节点的数据达到完成一致，确认数据正常后，手工做一次高可用的切换，使得服务整理从自建数据库切换到云数据库。当切换完成后，云数据库可成功选举成为新的Primary节点，此时即可在新的Primary节点上移除自建数据库节点，从而实现了MongoDB上云的平滑迁移。
我们以三个节点组成的副本集的自建MongoDB为例，将数据迁移上云MongoDB步骤如下:
1.打通源库和目标库之间的网络
如果源库部署在云服务商的云主机上，那么一般来说同一账户下的网络已经打通。对于从其他IDC机房迁移到云MongoDB上，可以通过做代理的方式实现网络互通。
2.建立源数据库和目标数据库的副本集
以源库作为主节点，目标库作为从节点，建立主从进行复制。还需要注意的是保证账户鉴权方式一致，即Auth关闭或开启状态一致、副本集名称（replSet）一致、各节点使用的keyfile一致。任何一个节点在这三方面务必保持一致，否则无法正常同步。
副本集结构图如下：
3.在副本集连接字符串URI中加入目标数据库IP
待数据同步完成后，需要检查从节点的数据完整性。将目标数据库的IP地址添加到副本集连接字符串URI中，重启应用层连接客户端。
4.选取新的主节点
选择云上的某个从节点作为主节点候选节点，提高它的选举优先级，人为触发副本集的选举过程（具体操作参见rs.reconfig()），从而将MongoDB云数据库中的一个从节点提升为新的主节点。新的主节点提升完成后的结构图如下：
5.从副本集连接字符串URI中删除源数据库IP
确认业务正常、数据正常，将源数据库的IP地址从副本集连接字符串URI中删除，重启应用层连接客户端。
6.移除自建数据库
登录到云MongoDB的主节点中逐个删除自建数据库的节点，只保留了云数据库的节点。
7.迁移完毕
您可以放心的使用云MongoDB了。
以上过程可以平滑迁移到云数据库，其实在步骤3和步骤5还有一定的优化空间，可以预先配置好URI，包括变更前URI、中间态URI和变更后URI，不同阶段使用相应的URI配置文件，启用或者关闭对应的应用层连接客户端，这种策略可以缩短对业务的影响时间。
引申思考
加强安全意识
这次大量MongoDB数据库被入侵事件被各大技术媒体争相报道，看热闹的人还以为出了多大的BUG，究其原因只是技术人员使用不当。实则是MongoDB使用者安全意识的问题，只考虑到为了方便先拿来用而忽略了数据安全隐患，甚至没考虑到MongoDB默认允许无密码访问的特性。包括之前已经有人指出了MongoDB的这个特性，但不重视、不去行动，还是无法消除最基本的安全隐患。
监控并及时响应
对MongoDB应该进行监控，实际上对应用以及应用中用到的各个组件都需要进行监控，包括性能监控、可用性监控、是否有未知IP进行大量操作等。在出现异常时通过告警信息感知问题，重要的还是需要去响应这些问题。
审计
审计功能方便在事后对攻击进行分析，掌握是从哪些IP进行入侵、黑客进行了哪些操作等。
数据加密
用户业务数据加密并不同于云服务商对数据的加密，在用户侧需要保证自己数据不被破解使用。MongoDB使用者在把业务数据存储到MongoDB数据库时应该对一些敏感信息进行加密，例如身份证、银行卡等数据。
数据备份
为了保护数据各云服务商对云平台中的数据进行了备份，实际上提供给了我们一个思路，我们也需要对应用中的数据进行备份，在云服务商不同可用区或不同地域进行备份，还可以考虑跨云服务商对数据进行冷备份。
总结
有问题、有危机，并不可怕，可怕的是对危机预兆的漠视、危机出现时没有及时响应、危机之后没有进行总结反思。
未来已来，云计算不再遥远，就在您的指点之间。
作者：吕昭波、姜健 来源：细说云计算 微信公众号
