![MongoDB Oplog 安全](https://linux22.com/image/656671/MongoDB%20Oplog%20%E5%AE%89%E5%85%A8.png)
我们正在使用 MongoDB 副本集来在 Web 场中共享会话和其他(潜在敏感的)数据。
我们存储的所有数据都使用 TTL 索引,以便文档在相对较短的时间(比如一小时)后过期,部分原因是出于安全原因。
然而,我发现即使从 MongoDB 集合中删除了数据,用于复制的 oplog 仍然会包含所有创建(然后删除)的文档;然后可以轻松地从 oplog 中读取所有过期的数据。
根据分配给 oplog 的大小,其中的数据可能相当旧。
我的问题是,这里的最佳做法是什么?除了严重减少 oplog 大小之外,我们还能做些什么来防止访问旧数据?
答案1
日志中的敏感数据与任何地方的敏感数据相同。根据关键程度,您需要 -
仅允许有权查看的人访问数据(通常通过角色或组成员身份完成)。
如果数据中有任何监管或外部问题相关信息(PCI、HIPAA 等),则必须进行相应处理并遵守法规
将日志记录和监控(在网络和主机上)设置为 11(或任何适当的值)
尤其是记录和审计数据访问和尝试
仅在需要时保留日志
如果可能的话,在不主动使用时加密
不要让它四处散落,巩固和防御
如果问题上升到一定程度,你可以保护 mongodb 服务器,把它当作一个关键系统(安全黑客:如果你处理 PCI 或其他类型的合规性相关数据,你可以假装它有这些数据,并让操作人员用相同的标准/政策/等等来对待它,而不是想出一种新的方法来处理这一切)
对于 MongoDB 来说,你可以 -
将其(加密!)发送到中央日志服务器,最好标记为敏感或更高严重级别
要么不要在本地存储日志,要么如果需要调试或其他什么,在尽可能短的时间(一天、一周、30 天等)后将它们清除掉(例如扔掉)
如果它们在本地存在,请确保它们由 root/priv'd 用户和模式 0400(或适合您的操作系统的任何模式)拥有
如果您真的很偏执,您可以使用类似于 auditd(8) 的东西来查看何时有人尝试访问日志(并再次将 auditd 日志发送到中央日志服务器!)
如果你是真的出于偏执,您需要在保存日志的任何地方使用加密存储,以便它们在删除后不会被从磁盘上删除
出于合规性原因,某些数据可能需要长期存储,因此请确保不要过早删除任何内容
对中央日志服务器的访问应具有与本地服务器相同的限制,因为...数据
没什么真正令人兴奋的事情,老一套,老一套,只是不要错过任何事情,确定一切,限制访问,并监控所有动作。