昨天在朋友圈看到一张图，某某国家的国防安全系统数据库使用了长达几个月的初始账号和密码，账号为“admin”，密码为“123456”。又去了解了下这个新闻并非最近的，2018年就报道出来了，最近又上了朋友圈。
图源自网络，侵删
也不要紧，几年前的“新闻”了，也就再回想下前几年碰到的全球众多企业MySQL、MongoDB数据库遭受“黑客攻击”，原因是数据库实例没有额外设置密码，而初始账号是“root”，无需密码即可登录。这并非MySQL、MongoDB设计的漏洞，在官方文档中早就清清楚楚的写着了，只不过忽略了设置密码、嫌麻烦先不设置，又或者认为不会有人来攻击。这其中的一些企业还把数据库实例暴露在公网中，就算不是黑客，通过一些简单的工具就可以扫描互联网上的IP地址和3306端口，账号是“root”，密码为空，就直接登录成功了。
因为都是翻过去的事
我也翻出了好早之前，也就“刚出道”那会跟同事写的文章
时过5年，思路和方法仍然可借鉴
背景介绍
近期（当时用的是近期，实际上是2017年1月），大批量的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数据库时应该对一些敏感信息进行加密，例如身份证、银行卡等数据。
数据备份
为了保护数据各云服务商对云平台中的数据进行了备份，实际上提供给了我们一个思路，我们也需要对应用中的数据进行备份，在云服务商不同可用区或不同地域进行备份，还可以考虑跨云服务商对数据进行冷备份。
总结
有问题、有危机，并不可怕，可怕的是对危机预兆的漠视、危机出现时没有及时响应、危机之后没有进行总结反思。
关于采用云数据库最佳实践、云端数据库备份，以及安全防护、权限控制等内容也都汇聚在《云端架构》一书中。
发表评论