MongoDB中文社区有话说: 卫报迁移和58简历事件专家剖析

2020-05-28 00:00:00 数据库 中文 迁移 导致 简历

近InfoQ发布了“别了,MongoDB”(翻译自卫报作者Philip McMahon等发表的英文博客 )  一文引起比较大的反响。如果关心技术社区的朋友们都知道,圈子里时不时会冒出一篇 (MySQL | PostgreSQL | MongoDB ) 迁移到 (MySQL | PostgreSQL | MongoDB ) 的文章。有些时候因为选型不当,有些是因为时间的变迁导致场景变化,有些时候是因为有更先进的技术或者更适用产品出现。这些其实都是符合技术正常变革的自然规律的。但是卫报的这篇文章加上前不久的58简历泄露事件,让MongoDB中文社区的核心成员们有必要站出来澄清下事实,以防止标题党语不惊人死不休,以流量为目的的时候无顾于技术的科学性和严肃性。

PART 1:卫报迁移事件解析


其实这是卫报10年来第二次数据库迁移,次是从Oracle。我们来看下这几年的事件回放:

1)2011年4月,卫报成为早的MongoDB用户之一,成功上线其构建在MongoDB之上的内容管理系统。


2)2011年11月,在QCon的一次大会上,Guardian的Mat Wall分享了他们选择MongoDB的原因:

  • 数据库schema 经常需要升级,升级意味着编辑们无法使用系统

  • 基于Oracle的老系统300多张表,10,000多行Hibernate XML配置,异常复杂

  • 关系型数据库难以进行性能扩展


(上述内容摘自于

https://www.infoq.com/presentations/Why-I-Chose-MongoDB-for-Guardian) 


这个分享成了当时一个很大的成功案例,为MongoDB成为Gartner CMS魔力象限中第二的Adobe Experience Manager 及 Sitecore两个CMS系统不约而同选用的数据库奠定了基础。 


3)2015年,卫报因为自己数据中心的备份系统出问题而决定把数据中心迁移到AWS云上。注意,此时为止并没有出现什么运维事故。


4)搬到AWS上以后,发生了两次运维事故,一次是因为NTP时钟服务被中断导致的,一次是因为他们在应用程序启动时候创建索引导致的。


5) 2017年, 以Philip McMahon为首的IT团队开始了为期10个月的迁移工作,从基于AWS的MongoDB迁移到AWS的PostgreSQL。Philip列出了以下理由:

  • 这两年在AWS云里出了两次运维故障

  • MongoDB OpsManager未能兑现“无障碍数据管理“

  • 官方未能及时帮助他解决问题,终是自己解决了


6) Philip团队在花了10个月时间的努力之后,终于把他们系统的数据库迁移到了AWS的PostgreSQL。然后他就发表了bye-bye MongoDB的博客。


好了,至此我们大概了解情况了。


中文社区

有话说

  1. Philip的个要迁移的原因:NTP导致的运维故障。 MongoDB是分布式集群,需要时间统一。 Oracle RAC集群的时钟服务出问题也会导致集群问题。你自己在VPC里面不小心把 NTP时钟服务中断了导致集群不能正常工作,这是谁的锅呢?? 

  2. Philip的第二个要迁移的原因: 应用程序启动时构建索引导致服务不可用。关于这一点,如果是一个读的懂英文文档的开发者都会知道,无论是使用Spring或者Nodejs,都会提到并不建议在程序里来创建索引。 构建索引消耗很多资源并且执行时间不可控,按照MongoDB佳实践是要在复制集内进行滚动构建。实际上使用 OpsManager就可以很容易实现滚动建索引。这一点他自己也意识到了“可能不是一个好主意”。恩,怪我咯

  3. Philip的第三个要迁移的原因:数据库管理很重要而且很难。恩恩,所以我们要换一个数据库,从MongoDB换到PostgreSQL。因为PostgreSQL不是数据库, 就不用管理了? 

  4. 没有比较就没有伤害。和上面提到的Mat Wall的Oracle迁移到Mongo的言之凿凿的原因比较,Philip的3大原因没有一条是真正和MongoDB数据库本身技术相关的。MongoDB丢了数据吗?MongoDB自己崩溃了吗? 作为卫报这个知名媒体,可以有一点逻辑吗?

  5. 在卫报迁移到AWS之前,MongoDB运行都是正常的。所有的问题反而是在AWS里发生的,特别是关于VPC的那个。这个说明了卫报IT团队在云管理能力上有所欠缺。按照他们的理论,亚马逊多半也没有实现“云让你不用再管理你自己的基础架构”的口号吧?是不是也该从AWS迁移走呢?


到这里相信读者能够有所甄别。Philip团队真正的痛点是他们无足够的能力,也无意在这方面去增强自己的能力来运维自己的MongoDB集群。这个出发点本身并无诟病,这是SaaS/PaaS 平台存在的意义。MongoDB自己就提供基于AWS的云托管服务 。 Philip确实提到了有一个超出他决策范围的非技术原因(来自编辑部)让他无法选择MongoDB 云托管服务。换句话说,如果没有那个编辑部的外在影响,Philip的完美解决方案就是:


卫报自管理的 AWS MongoDB   ->  无缝迁移工具  -> MongoDB AWS 云托管服务


这个方案可以完美解决:

  1. NTP 或类似的问题

  2. 数据库管理(托管服务的基本价值)

  3. 应用程序构建索引。。。(oops 不行, 这种自己挖坑自己踩的哪个云平台恐怕都解决不了)


这种迁移由于不涉及到代码改动,所需工作会大大减少。我们不知道Philip开始迁移方案的时候有没有预料到会花他们团队10个月,而且可能是Sleepless的10个月。但是线下Mongo到Atlas的迁移在工具的协助下,可以在数天内就完成并可以轻松的实现无缝切换。


如果我们可以打倒标题党,这篇文章的题目更应该叫做:


别了,自运维数据库,拥抱云托管数据库。


PART 2:58简历泄露事件


原文是:“854GB!MongoDB数据库泄露2.02亿中国求职者履历


关于这个因为发生在国内,大家还是比较容易辨清是非的。MongoDB中文社区和58工程师非正式的确认了一下,此次泄露和58毫无关系。


结合前年已经发布的58简历事件的文章,我们大概可以猜到事情可能是这样发生的:


  • 若干年前,某黑客使用58网站的公开API,使用爬虫把数以亿级的简历信息爬下来

  • 爬下来的数据存在MongoDB(恩恩,爬虫很喜欢水果)

  • 然后在淘宝上几百元一套出售

  • 某位兄弟买了这样一套数据,可能也存放在MongoDB里面

  • 这位兄弟当然无须为这些数据的安全性负责,于是连基本的安全措施都没有使用,导致数据泄露


所以其实数据泄露源头根本不在于MongoDB。源头在此(感谢徐雷的整理):

其实关于58的简历,国内的安全网站很早2017年就给出了预警,58同城API存在漏洞,导致的网络爬虫程序等攻击,导致的数据泄漏。 


原文摘选:

由于58同城网站存在弱加密等设计缺陷,导致攻击者可通过访问该网站的某些数据查询接口,经过简单的解密还原,获取并关联用户关键信息,进而获取用户简历的全部信息。


简而言之,攻击者获取简历全部信息可通过以下三个步骤:


1、攻击者通过某移动端接口获取部分简历信息(求职方向、年龄、期望月薪、工作经验、居住地、学历、用户ID、更新简历时间等内容)和简历ID;

2、攻击者使用简历ID通过另一个接口获取用户的真实姓名;

3、攻击者使用用户ID通过另一个网站页面获取用户的电话号码。

通过用户ID和对应简历ID将三部分信息关联,攻击者就可以获得完整的用户简历信息,终实现简历遍历的目的。

原文链接: 

https://www.freebuf.com/news/130299.html


防止此类数据泄露其实非常简单, 只要有一些基本的安全意识就好了。 MongoD数据库本身的安全机制已经非常强大,简单来说,你只要执行下述一条或者多条佳实践,就可以很大程度上保护好你的数据库了:


  1. 启用鉴权!不管是本地鉴权,还是LDAP 、 Kerberos第三方验证

  2. MongoDB尽可能不要部署在公网上

  3. 如果一定要部署在公网,那就要设定防火墙 – 端口只开放给授权的应用或者客户端

  4. 使用bind_ip限定监听的网卡,一般只监听内网甚至本地网卡端口

  5. 尽可能使用SSL/TLS协议来访问MongoDB

  6. 使用角色和权限来微调管理用户权限

  7. 启用审计功能(需要MongoDB企业版)


结论

大家该怎样使用MongoDB就怎样使用。互联网上信息质量参差不齐,一定要小心标题党,擦亮眼睛不要被哗众取宠的人所误导 。




MongoDB中文社区参与撰稿成员:


徐雷  

中文社区联席主席 、MongoDB实战指南译者

刘诚杰

中文社区上海分会长、平安集团DBA

李丹

 中文社区北京分会长、逻辑思维首席DBA

周李洋

中文社区联席主席、MongoDB Master、Teambition 运维总监

唐建法

中文社区主席



关注一下,精彩不停

相关文章