一个854 GB大小的MongoDB数据库无人看管,无需密码登录验证即可查看和访问中国求职者超过2亿份非常详细的简历。202,730,434 条记录中的每条记录不仅包含候选人的技能和工作经验,还包括他们的个人信息,如手机号码,电子邮件,婚姻,子女,政治,身高,体重,驾驶执照,识字水平,薪水期望等。
该安全事件由HackenProof的安全研究员BobDiachenko发现,遭泄露的是MongoDB数据库,其中存有大量中国求职者的详细信息。据一位Twitter用户查证,已被删除的应用主要来源之一是bj.58.com。安全研究员BobDiachenko表示:“经过调查,MongoDB数据库不安全且不受保护,因此无需通过高尖端的手段就可获取用户信息,实际上,大量的求职信息是通过简单的BinaryEdge或Shodan搜索找到的,没有任何密码保护。”
该事件发生不久后,该数据库被加入了保护机制,但这距离数据库成立已过去很久,因此这种后来的保护很有可能起不到多少作用。根据MongoDB日志,至少有十几个IP可能在脱机之前访问了数据库。对于事后“亡羊补牢”,JASK公司的安全研究主管RodSoto认为,或许应该要求软件开发人员引入自动给代码打补丁的机制。他说:“尽管这样做能够有效降低被互联网上已知应用程序攻击的几率,但强行更新或打补丁通常会带来意想不到的后果。”
实际上,此类情况并非个例,如今有越来越多的用户数据被置身于“裸奔”状态,企业应该正确的认识到保护第三方数据库的重要性。显然,此次事件中简历网站并没有行使保护数据安全的责任,让数量如此众多的用户的简历信息被公开查阅。
数据必须受到保护,因为它们存在于流程生命周期中的各个环节。
数据通常是一个组织机构最大最有价值的资产,这一特性使其成为了各种类型敌人(包括犯罪分子和民族国家)的首要目标。几乎每周都会有新的数据泄漏事件发生,持续提醒我们数据安全的重要性。仅在2018年上半年,就有944起数据泄露事件导致了33亿条数据记录遭到泄露。但是真正的数据安全是什么样的呢?
许多解决方案都宣传“端到端保护”的必要性以及他们有能力提供这种保护,但当我们越过这些流行术语,我们是否清楚地知道保护数据意味着什么?
随着攻击途径不断增加,攻击者变得越来越缜密,信息安全的方方面面都变得非常重要——从安全的数据存储、传输和处理到访问控制和有效的密钥管理。如果有一个环节容易受到攻击,则会破坏其他安全措施的有效性。这种来自多方面的风险需要一种全面的、以数据为中心的安全保护方法,这种方法应该在其生命周期的所有环节关注保护数据本身,而不是只关注其周围的网络、应用程序或服务器。组织机构必须遵循如下原则始终确保数据安全:
a. 在文件系统,数据库上或通过存储技术保护静态数据;
b. 当数据在网络中移动时,保护传输中的数据;
c. 在使用或处理数据时,保护正在使用的数据;
经验告诉我们,如果存在有价值的数据正处于危险之中,攻击者会通过某种方法找到并接触它们——我们不能只紧锁大门;每一个入口都需要保护。因此,仅将加密局限在数据安全三要素——存储、传输、使用中的一部分,是一种危险的行为。保护静止、传输和使用中的数据是至关重要的。
1 静态数据
以任何数字形式存储的非活动数据,静态数据可能位于硬盘驱动器或数据库、数据湖、云存储或无数其他位置。在通常被认为是最安全的数据状态下,我们通常会将基于边界的技术和解决方案视为第一道防线,并根据数据本身的用途和敏感性添加额外防线。这些额外防线包括加密敏感数据,无论数据存储在本地还是存储在云中。由于数据存储的聚合性,静态数据对于想要窃取大量有价值数据的攻击者来说是一个很有吸引力的目标。
2 传输中的数据
传输中的数据很容易受到攻击,无论是通过专用网络、本地设备,还是公共不可信空间。人们普遍认为,加密传输中的数据是标准做法——这通常是安全团队保护数据资产时最先关注的环节之一。这是必须的,而且只要企业遵守正确的协议,传输加密就是一种有效的防线。
3 使用中的数据
如果前面描述的两种数据状态可以简单地标记为最容易理解和最容易解决的,那么使用中的数据应该被贴上最容易被忽略的标签。因此,它很快就成为攻击者最容易突破的地方。本质上,数据使用领域的挑战与缺乏对问题本身的认识有关。这部分被忽略的原因是,安全领域的一些人错误地认为,保护静态数据和传输中的数据就可以了。
然而,随着攻击者越来越老练,再加上对计算机芯片处理机制普遍存在的缺陷的惊人披露,所有规模的企业都需要意识到保护正在使用的数据的重要性。当我们使用数据来提取有价值信息时,数据是最有价值的,这可以通过执行搜索或分析来实现。除了访问控制和用户身份验证,这类在任何安全计划中都重要的部分之外,还有各种商业上可用的解决方案和技术方法可于抵御此漏洞,包括同态加密、安全多方计算和安全Secure Enclave技术。
我们都知道攻击者正在成长,而我们的安全工作也必须跟上。保护方案必须识别和保护数据,因为数据存在于流程生命周期中的各个环节,无论是静态的、传输中还是在使用中。
1 部署问题
这就是数据库安全版的博尔特一蹬出起跑器就被鞋带绊倒。数据库经过广泛测试以确保能胜任应该做的所有工作,但有几家公司肯花时间做数据库安全性测试?
解决办法:这个问题的解决办法十分明显:部署前做更多的测试,找出可被攻击者利用的非预期操作。
2 离线服务器数据泄露
公司数据库可能会托管在不接入互联网的服务器上,但这并不意味着对基于互联网的威胁完全免疫。无论有没有互联网连接,数据库都有可供黑客切入的网络接口。
解决办法:首先,将数据库服务器当成联网服务器一样看待,做好相应的安全防护。其次,用SSL或TSL加密通信平台加密其上数据。
3 错误配置的数据库
有太多的数据库都是被老旧未补的漏洞或默认账户配置参数出卖的。个中原因可能是管理员手头工作太多忙不过来,或者因为业务关键系统实在承受不住停机检查数据库的损失。无论原因为何,结果就是这么令人唏嘘。
解决办法:在整个公司中树立起数据库安全是首要任务的氛围,让数据库管理员有底气去花时间恰当配置和修复数据库。
4 SQL注入
SQL注入不仅仅是最常见的数据库漏洞,还是开放网页应用安全计划(OWASP)应用安全威胁列表上的头号威胁。该漏洞可使攻击者将SQL查询注入到数据库中,达成读取敏感数据、修改数据、执行管理操作乃至向操作系统发出指令等目的。
解决办法:开发过程中,对输入变量进行SQL注入测试。开发完成后,用防火墙保护好面向Web的数据库。
5 权限问题
涉及访问权限,数据库面临两大主要问题:
(1)员工被赋予超出工作所需的过多权限;
(2)合法权限被未授权或恶意使用。
解决办法:权限分发时遵循最小权限原则,仅给员工赋予完成工作所需最小权限。数据库访问也要受到严格监视,确保员工权限仅用于经授权的操作。员工离职时需立即撤销分发给他/她的权限。
6 存档数据
与上一条相关,无论出于报复还是利益,员工通过盗取数据库备份获得大量个人资料的事屡见不鲜。
解决办法:加密存档数据,严密监视存档数据访问和使用情况,可以大幅减少内部人威胁。