一个月 6 次泄露，为啥大家用 Elasticsearch 总不设密码？

2019 年 1 月 30 日，外媒又报道了一起 Elasticsearch 数据泄露事件！这已经是笔者统计到的 2019 年 1 月份的第六起 Elasticsearch 数据泄露事件了。

据外媒报道称，IT 安全和云数据管理公司 Rubrik 遭受了大规模数据泄露，遭到泄露的数据库托管在 Amazon Elasticsearch 服务器上，拥有数十亿字节的数据，泄露信息包括每个企业客户的客户名称、联系信息和工作信息。除此之外，数据库中还包含有来自企业客户的电子邮件，其中包含带有姓名、职位和电话号码的电子邮件签名，以及一些包含有关客户配置的敏感信息。

本次数据泄露事件是由安全研究员 Oliver Hough 发现的。2019 年 1 月 29 日，Rubrik 下线了该服务器，泄露事件发生的原因是暴露的服务器未受密码保护。

Rubik 发言人表示：在为客户构建新的解决方案时，包含客户信息和支持交互数据的部分沙箱环境可在短时间内被访问。目前，除了发现此问题的安全研究员，没有其他人访问过该环境，所以也没有任何数据被暴露。

Rubrik 没有透露是否会通知其客户或国家监管机构，但是因为此次数据泄露事件包含了欧洲企业，所以可能会面临 GDPR 相关的罚款，一旦确定其违反了欧盟的数据保护法，那么该公司将被处以其全球年收入 4%的罚款。

一个月被曝 6 次数据泄露，为啥大家使用 Elasticsearch 总不设密码？

事实上，这已经是 Elasticsearch 在本月发生的第六起数据泄露事件了，前五次数据泄露事件分别为：

• VOIPO 超百万的电话和短信数据泄露；

• 青年学生组织 AIESEC 的 400 万条志愿者信息泄露；

• 在线赌场泄漏 1.08 亿投注信息；

• 美国多家大银行贷款文件遭泄露，文件数量达 2400 万；

• 百安居发生数据泄露，70000 起店内盗窃案的信息流出。

泄露事件具体情况可参考：（https://www.infoq.cn/article/ApF6houjkuEBz*X8zpph）

综合这六起数据泄露事件，我们发现原因都是一样的：Elasticsearch 服务器没有密码保护。在数据重要性如此高的今天，为什么大家都不设密码呢？

Elasticsearch 中文社区深圳分会杨振涛表示：“不少开发人员及其团队在认知上更多地把 Elasticsearch 看成是与 MySQL 同等的存储系统，所以在部署以后并没有太多地关心其访问控制策略和数据安全。而且 Elastisearch 开箱即用的特点也让开发和运维人员放松了对安全的重视。”

除此之外，笔者还发现很多 Elasticsearch 都是可以公网访问的，为什么出现这种情况呢？杨振涛表示很有可能是团队忽视了数据安全，再加上服务器防火墙对于端口开放策略过于激进，导致 Elasticsearch 集群只要一部署即可公网访问。

“公网访问对于有些业务来说是必要的，例如网站搜索服务。” Elastic 架构师吴斌解释道，“我们经常说‘Simple/less is more, but no simpler’，在做架构体系设计时希望一切从简，节约开发和运维成本，但麻雀虽小，还是要五脏俱全。暴露公网在有些场景下虽不是关键问题，但也不能失去最基本的保护。”

在数据保护方面，Elasticsearch 提供了哪些服务和功能？

首先，我们先来明确一点：“Elasticsearch 的开源版本是不具备任何数据保护功能。”吴斌表示，“这是因为在搜索引擎设计之初就是为了让用户检索到所有包罗万象的信息，在此场景下是没有数据保护的需求，只有基本的攻击保护，例如防火墙。”

但是 Elasticsearch 产品的提供商 Elastic 为订阅用户提供了多方位的数据保护：

首先是认证和授权，只有通过认证的请求才能访问 Elasticsearch。Elastic 支持最基本的用户 名、密码认证，也可以对接一些常见的认证体系从而实现 SSO；授权主要是控制谁（用户或其它应用）可以能看到哪些数据，目前 Elastic 的控制粒度到了字段级别。

其次是数据加密。首先是通讯加密，当外部应用在和 Elasticsearch 交互时，连接需要是安全的。其次，Elasticsearch 自身是分布式应用，那么各个节点之间的通讯也需要是安全的。最后就是落到磁盘上的数据，Elastic 可以通过操作系统对路径进行选择性的加密访问控制。

最后是审计合规，企业内部何人何时在何地做了哪些操作以及操作成功与否等信息都会被记录下来，当发生问题时帮助我们回溯。

警钟敲响，Elasticsearch 使用者如何避免发生数据泄露？

每一次的 Elasticsearch 安全事件其实都是在给 Elasticsearch 使用者敲响警钟，直接使用开源软件，而不采取必要的安全措施，实际上就是让业务系统在互联网上"裸奔"。

如何才能避免 Elasticsearch 在使用时发生数据泄露呢？杨振涛给出了几个最基本的低成本措施：

1）服务器必须要有防火墙，不能随意对外开放端口；

2）Elasticsearch 集群的端口包括 TCP 和 HTTP，都不能暴露在公网；

3）Elasticsearch 集群禁用批量删除索引功能；

4）Elasticsearch 中保存的数据要做基本的脱敏处理；

5）加强监控和告警，能够在安全事件发生的第一时间感知并启动紧急预案，将损失降到最低 。

亡羊补牢，一旦 Elasticsearch 发生数据泄露是否有补救措施？

如果是在没有任何保护措施下造成的数据泄露，那么第一时间肯定是尽快恢复服务。因为 Elasticsearch 是一个分布式搜索引擎系统，所以在实际场景中，进入 Elasticsearch 数据一定也存在了其它存储中，我们可以通过快速重建索引在第一时间内恢复服务。

另外，就像本月发生的数据泄露事件，安全事件的原因并不是 Elasticsearch 本身的安全漏洞，而是 Elasticsearch 宿主服务器安全性太低。杨振涛建议针对这种情况应该第一时间为服务器做安全加固，比如开启防火墙，拒绝非授权端口的访问，修改 root 密码，禁用密码直接登录服务器，而是通过 SSH KEY 来登录等。

如果发生了极端情况，泄露的数据包含用户账号信息，杨振涛表示要在第一时间通知用户修改密码，甚至在登录模块强制用户重置密码后才可登录。