近日，一位安全研究员在博客上表示发现了本田公司的云端数据库未设密码，这可能导致 1.34 亿份文档，约 40GB 数据被泄漏，其中包括机器主机名、MAC 地址、内部 IP 及操作系统版本等。在收到该研究员的提醒后，本田方面已对漏洞进行修复。
本田 1.34 亿份文档，40GB 数据险遭泄漏
根据安全研究员 Justin Paine 的说法，自 2019 年 7 月 1 日起，他就发现了本田对外暴露的 ElasticSearch 数据库未设置任何密码，内部包含大约 1.34 亿份文档，这些文档可以转换为大约 40GB 数据，而这些数据的日期最早可以追溯至 2019 年 3 月左右。
最初，Justin Paine 以为这些数据来自本田的一家经销商，但他很快否定了这一想法，因为这些文档包含了本田全球各地员工机器、网络相关的数据，而这些数据清楚表明了本田内部在使用哪家端点安全供应商，哪些设备在使用最新的安全防护软件，哪些设备依旧在运行旧版操作系统。
此外，这些数据包含了清楚的标记，可以非常容易地识别出 CEO、CFO 以及 CSO 等级别对应的电脑，本田 CEO 的完整电子邮件、全名、MAC 位置、Windows 操作系统版本、IP 及设备类型均可查到，甚至一些字符提供的信息与本田在日本的办事处位置相对应。
在研究人员提交该漏洞后，本田方面迅速封闭了该漏洞，并回复称：“非常感谢您指出漏洞。您发现的安全问题可能允许外部各方访问本田的一些基于云的数据，这些数据包括与员工及其计算机相关的信息。我们调查了系统的访问日志，发现没有任何第三方下载数据的迹象。目前，没有证据表明数据泄露，不包括您拍摄的截图（Justin Paine 在博客中展示了一些处理过的图片）。我们将根据相关法律法规采取适当行动，并将继续采取积极主动的安全措施，以防止今后发生类似事件。”
ElasticSearch 安全事故频发
虽然 ElasticSearch 通常在公司内部运行，但近年因为其未加密而发生的数据泄露事件不在少数：
- 2017 年，白帽汇曾对全球使用 ElasticSearch 引擎发生的勒索事件进行监测，最终发现因被攻击而删除的数据至少 500 亿条，被删除数据规模至少 450TB。系统显示，互联网上公开可访问的 ElasticSearch 服务器超过 68000 余台，受害总数达 9750 台。其中，美国 4380 台，中国第二为 944 台，其余来自法国、爱尔兰和新加坡等地。此次事件后，1% 的 Elasticsearch 启用了验证插件，另外有 2% 则关闭了 Elasticsearch。
- 2018 年 11 月份，美国还曾发生一起 ElasticSearch 服务器在没有密码的开放状态下泄露了将近 5700 万美国民众个人信息的事件。当时共泄漏超过 73GB 数据，并且几个数据库被缓存在服务器内存中，其中一个数据库包含的个人信息就达到了 56,934,021 份。
- 2018 年 12 月份，巴西最大的订阅电视服务之一的 Sky Brasil 在没有密码的情况下将 ElasticSearch 服务器暴露在互联网上，其 3200 万客户数据在网上暴露了很长时间，存储数据包括客户姓名、电子邮件地址、密码、付费电视包数据、客户端 IP 地址、个人地址、付款方式、设备型号等。
根据 InfoQ 此前的粗略统计，仅 2019 年 2 月份，就发生了六起数据泄漏事件，而原因均是：Elasticsearch 服务器没有密码保护。即便是使用云端服务，企业也不可将数据安全的责任全部押到云厂商身上，云厂商只可以在有限的权限范围内提供安全防护，企业还是需要具备安全意识。
Elasticsearch 中文社区深圳分会杨振涛此前在接受 InfoQ 采访时表示：“不少开发人员及其团队在认知上更多地把 Elasticsearch 看成是与 MySQL 同等的存储系统，所以在部署以后并没有太多地关心其访问控制策略和数据安全。而且 Elastisearch 开箱即用的特点也让开发和运维人员放松了对安全的重视。”
对于避免 Elasticsearch 在使用时发生数据泄露，杨振涛给出了几个最基本的低成本措施：
- 服务器必须要有防火墙，不能随意对外开放端口；
- Elasticsearch 集群的端口包括 TCP 和 HTTP，都不能暴露在公网；
- Elasticsearch 集群禁用批量删除索引功能；
- Elasticsearch 中保存的数据要做基本的脱敏处理；
- 加强监控和告警，在安全事件发生的第一时间感知并启动紧急预案，将损失降到最低。
除此之外，很多 Elasticsearch 均可公网访问，杨振涛表示很有可能是团队忽视了数据安全，再加上服务器防火墙对于端口开放策略过于激进，导致 Elasticsearch 集群只要一部署即可公网访问。
“公网访问对于有些业务来说是必要的，例如网站搜索服务。” Elastic 架构师吴斌解释道，“我们经常说‘Simple/less is more, but no simpler’，在做架构体系设计时希望一切从简，节约开发和运维成本，但麻雀虽小，还是要五脏俱全。暴露公网在有些场景下虽不是关键问题，但也不能失去最基本的保护。”
