MongoDB二次勒索過後，如何加強資料庫安全防範？
作者介紹
上海小胖[Miracle Young]，中國第十五位MONGODB PROFESSIONAL獲得者，資深Python開發、DBA。DevOps的踐行者，曾獨立開發Web服務平臺，電商爬蟲系統、運維管理系統，涵蓋資料熱力圖、核心資料監控、伺服器監控系統等。個人部落格：https://segmentfault.com/u/shanghaixiaopang。
原本這周想寫一個系列關於 GDPR(General Data Protection Regulation) MongoDB 的，但是9月5日爆出了超2.6W 個MongoDB 節點被劫持。所以臨陣變卦，決定寫一篇關於MongoDB安全的文章。
是什麼心理讓各位Developer & DBAer 在發生瞭如此大的比特幣勒索事件後，還是敢於裸奔？縱使覺得資料不重要、有備份，出於對安全的意識，是不是也應該使用一些安全保護措施呢？
（注：裸奔在此處的解釋為，使用預設埠27017，並對公網開放，未做任何防火牆措施，同時未開啟認證和鑑權的MongoDB 資料庫）
一、現狀
- 通過類似SHODAN 這樣的網站（諸如：ZoomEye等）提供的API，進行全網掃描，MongoDB 那就是掃描27017埠
- 獲取到IP後，進行嗅探
- 如果可以獲取到登入資訊，那麼執行指令碼（備份全庫、清理journal、留下打款賬號資訊）
- 具體的實現，這裡不做過多描述，目的不是為了教學攻破MongoDB，而是為了給大家敲響警鐘。
二、防範
use admin
db.createUser(
{
user: “myUserAdmin”,
pwd: “abc123”,
roles: [ { role: “userAdminAnyDatabase”, db: “admin” } ]
}
)
2.在啟動項中加入–auth，或者在配置檔案中加入 security.authorization: enabled.
mongod –auth –port 27017 –dbpath /data/db1
3.使用之前建立的myUserAdmin 使用者登入mongo
mongo –port 27017 -u “myUserAdmin” -p “abc123” –authenticationDatabase “admin”
4.在應用庫中建立一個具有讀寫許可權的應用賬號。（注意：在MongoDB中，賬號跟著資料庫走，也就是說在哪個資料庫下建立的，該賬號就屬於哪個庫）
use test
db.createUser(
{
user: “myTester”,
pwd: “xyz123”,
roles: [ { role: “readWrite”, db: “test” },
{ role: “read”, db: “reporting” } ]
}
)
Configure Role-Based Access Control
這裡需要明確的是，MongoDB的基本安全分為兩種：一種是認證，一種是鑑權。其實英語會說的比較明白點: authorization, authentication。
認證是作為使用者登入的一種賬號密碼校驗，類似MySQL 的 root/password ，在大部分應用中，一旦建立一個連線（用於連線池的），那麼該連線只會做一次，所以大可不必擔心因為認證而帶來的開銷。
鑑權是在資料庫中的賬號擁有的許可權做鑑定，類似MySQL中的privilege。
Encrypt Communication
開啟MongoDB 的TLS/SSl 的配置，社群版需要下載一個SSL版本，或者可以從社群版通過升級步驟升級到SSl版本，企業版自帶SSL。
SSL 可以保證MongoDB的 所有連線（輸入和輸出的連線）都是加密的。
Encrypt and Protect Data
MongoDB 3.2 WT 引擎推出了一個新的加密功能，僅限企業版，可以對物理資料檔案進行加密，若不開啟，則預設通過系統對檔案進行加密。
Limit Network Exposure
通過指定bindIp ，並在生產線上關閉MongoDB 的Http介面來達到規避網路進口的安全問題。
Audit System Activity
MongoDB 企業版同時提供了審計功能，幫助使用者更好的巡檢自己的資料庫。
Run MongoDB with a Dedicated User
使用MongoDB使用者 啟動MongoDB，而不是使用root 使用者。
三、後續
希望大家在經過2次 MongoDB 的打劫後，都提高警惕了。把自己的生產節點都check 一遍。避免同樣的悲劇在發生。
原文來自微信公眾號：DBAplus社群