近日，一位安全研究員在博客上表示發現了本田公司的雲端數據庫未設密碼，這可能導致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’，在做架構體系設計時希望一切從簡，節約開發和運維成本，但麻雀雖小，還是要五臟俱全。暴露公網在有些場景下雖不是關鍵問題，但也不能失去最基本的保護。”