从MongoDB安全事件说起,找到了原因和解决方案,危机之后又该怎样反思呢?

本文涉及的产品
云数据库 MongoDB,独享型 2核8GB
推荐场景:
构建全方位客户视图
简介: 近期,大批量的MongoDB实例因为配置漏洞遭遇了攻击,黑客无需身份认证即可登录MongoDB实例,从而删除了大量数据,并勒索受害者支付赎金才能要回自己的数据。截止目前为止,被劫持的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" } ]
    }
    )
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数据库时应该对一些敏感信息进行加密,例如身份证、银行卡等数据。
数据备份
为了保护数据各云服务商对云平台中的数据进行了备份,实际上提供给了我们一个思路,我们也需要对应用中的数据进行备份,在云服务商不同可用区或不同地域进行备份,还可以考虑跨云服务商对数据进行冷备份。

总结

有问题、有危机,并不可怕,可怕的是对危机预兆的漠视、危机出现时没有及时响应、危机之后没有进行总结反思。
未来已来,云计算不再遥远,就在您的指点之间。

作者:吕昭波、姜健   来源:细说云计算 微信公众号
相关实践学习
MongoDB数据库入门
MongoDB数据库入门实验。
快速掌握 MongoDB 数据库
本课程主要讲解MongoDB数据库的基本知识,包括MongoDB数据库的安装、配置、服务的启动、数据的CRUD操作函数使用、MongoDB索引的使用(唯一索引、地理索引、过期索引、全文索引等)、MapReduce操作实现、用户管理、Java对MongoDB的操作支持(基于2.x驱动与3.x驱动的完全讲解)。 通过学习此课程,读者将具备MongoDB数据库的开发能力,并且能够使用MongoDB进行项目开发。   相关的阿里云产品:云数据库 MongoDB版 云数据库MongoDB版支持ReplicaSet和Sharding两种部署架构,具备安全审计,时间点备份等多项企业能力。在互联网、物联网、游戏、金融等领域被广泛采用。 云数据库MongoDB版(ApsaraDB for MongoDB)完全兼容MongoDB协议,基于飞天分布式系统和高可靠存储引擎,提供多节点高可用架构、弹性扩容、容灾、备份回滚、性能优化等解决方案。 产品详情: https://www.aliyun.com/product/mongodb
相关文章
|
安全 NoSQL MongoDB
20 MongoDB高级 - 用户管理安全
20 MongoDB高级 - 用户管理安全
104 1
|
NoSQL 安全 Java
MongoDB:9-MongoDB的安全和认证
MongoDB:9-MongoDB的安全和认证
|
10月前
|
NoSQL 安全 MongoDB
【MongoDB深度揭秘】你的更新操作真的安全了吗?MongoDB fsync机制大起底,数据持久化不再是谜!
【8月更文挑战第24天】MongoDB是一款备受欢迎的NoSQL数据库,以其灵活的文档模型和强大的查询能力著称。处理关键业务数据时,数据持久化至关重要。本文深入探讨MongoDB的写入机制,特别是更新操作时的fsync行为。MongoDB先将数据更新至内存以提升性能,而非直接写入磁盘。fsync的作用是确保数据从内存同步到磁盘,但MongoDB并非每次更新后都立即执行fsync。通过设置不同的写入关注级别(如w:0、w:1和w:majority),可以平衡数据持久性和性能。
127 1
|
10月前
|
持续交付 C# 敏捷开发
“敏捷之道:揭秘WPF项目中的快速迭代与持续交付——从需求管理到自动化测试,打造高效开发流程的全方位指南”
【8月更文挑战第31天】敏捷开发是一种注重快速迭代和持续交付的软件开发方法,通过短周期开发提高产品质量并快速响应变化。本文通过问题解答形式,探讨在Windows Presentation Foundation(WPF)项目中应用敏捷开发的最佳实践,涵盖需求管理、版本控制、自动化测试及持续集成等方面,并通过具体示例代码展示其实施过程,帮助团队提升代码质量和开发效率。
146 0
|
NoSQL 分布式数据库 MongoDB
【MongoDB 专栏】MongoDB 的分布式事务解决方案
【5月更文挑战第11天】本文探讨了MongoDB的分布式事务处理,涉及两阶段提交(2PC)、TCC补偿事务、分布式锁和幂等处理。2PC通过协调者与参与者确保数据一致性,而TCC提供更高性能和容错性。分布式锁解决并发冲突,幂等处理保证事务正确性。根据业务需求选择合适方案,并关注性能、可靠性和容错。
569 2
【MongoDB 专栏】MongoDB 的分布式事务解决方案
|
存储 NoSQL 数据处理
探索MongoDB:灵活、高性能的NoSQL数据库解决方案与应用实践
探索MongoDB:灵活、高性能的NoSQL数据库解决方案与应用实践
469 1
|
12月前
|
NoSQL Java 关系型数据库
非关系型数据库NoSQL数据层解决方案 之 Mongodb 简介 下载安装 springboot整合与读写操作
非关系型数据库NoSQL数据层解决方案 之 Mongodb 简介 下载安装 springboot整合与读写操作
139 0
|
存储 监控 NoSQL
MongoDB分片:打造高性能大数据与高并发处理的完美解决方案
MongoDB分片:打造高性能大数据与高并发处理的完美解决方案
490 0
|
NoSQL 安全 MongoDB
MongoDB安全机制:认证、授权与加密
【4月更文挑战第30天】MongoDB提供全面的安全机制,包括认证(用户名/密码、LDAP、Kerberos、x.509证书)、授权(基于角色的访问控制,RBAC)和加密(TLS/SSL、透明数据加密TDE、字段级加密FLE),确保数据保密性、完整性和可用性。通过合理配置这些机制,企业可保障数据安全,应对不断变化的安全威胁。
|
NoSQL 安全 MongoDB

推荐镜像

更多
下一篇
oss创建bucket