Security
MongoDB Oplog 安全性
我們正在使用 MongoDB 副本集來共享網路場中的會話和其他（潛在敏感）數據。
我們儲存的所有數據都使用 TTL 索引在相對較短的時間（比如一個小時）後使文件過期，部分原因是出於安全原因。
但是，我突然想到，即使從 MongoDB 集合中刪除數據，用於複製的 oplog 仍然會包含所有創建（然後刪除）的文件；然後可以輕鬆地從 oplog 中讀取所有過期的數據。
根據分配給 oplog 的大小，其中的數據可能很舊。
我的問題是，這裡的最佳做法是什麼？除了大幅減少 oplog 大小之外，我們還能做些什麼來防止舊數據被訪問？
日誌中的敏感數據與任何地方的敏感數據相同。根據您想要的關鍵程度 -
- 只允許有權查看它的人訪問數據（通常通過角色或組成員身份完成）。
- 如果數據中包含任何受監管或外部問題相關的資訊（PCI、HIPAA 等），您必須相應地處理它並進行合規性舞蹈
- 將日誌記錄和監控（在網路和主機上）設置為 11（或任何合適的）
- 尤其是 記錄和審核數據訪問和嘗試
- 僅在需要時保留日誌
- 如果可能，在不主動使用時加密
- 不要讓它四處散落，鞏固和防禦
- 如果它上升到一定程度的擔憂，您可以保護 mongodb 伺服器並將其視為關鍵系統（安全黑客：如果您處理 PCI 或其他類型的合規性相關數據，您可以假裝它擁有該數據並讓運維人員處理它使用您適用於它們的相同標準/政策/等，而不是找出一種新的處理方式）
在 mongo 的情況下，您可能 -
- 將其（加密！）發送到中央日誌伺服器，最好標記為敏感或具有更高的嚴重性級別
- 要麼不將日誌儲存在本地，要麼，如果需要進行調試/其他，在盡可能短的時間（一天、一周、30 天等）之後將它們旋轉到遺忘狀態（例如扔掉它們）
- 如果它們在本地存在，請確保它們歸 root/priv 使用者和模式 0400 擁有（或任何適用於您的作業系統的）
- 如果你真的很偏執，你可以使用類似於 auditd(8) 的東西來查看有人何時嘗試訪問日誌（再次將 auditd 日誌發送到中央日誌伺服器！）
- 如果你真的很偏執，你會想要在任何保存日誌的地方使用加密儲存，這樣它們就不會在磁碟刪除後被扼殺
- 出於合規性原因，某些數據可能需要長期儲存，因此請確保您不會過早銷毀任何內容
- 對中央日誌伺服器的訪問應該具有與本地伺服器相同的限制，因為…數據
沒有什麼真正令人興奮的，同樣的，同樣的，只是不要錯過任何事情，確定一切，限制訪問，並監控所有動作。