MongoDB Oplog 安全性

Question

我们正在使用 MongoDB 副本集来共享 Web 场中的会话和其他（可能敏感的）数据。

我们存储的所有数据都使用 TTL 索引在相对较短的时间段（例如一小时）后使文档过期，部分原因是出于安全原因。

但是，我突然想到，即使从 MongoDB 集合中删除数据，用于复制的 oplog 仍将包含所有创建（然后删除）的文档；然后可以轻松地从 oplog 中读取所有过期的数据。

根据分配给 oplog 的大小，其中的数据可能很旧。

我的问题是，这里的最佳实践是什么？除了大幅减少 oplog 的大小，我们还能做些什么来防止旧数据被访问？

Answer 1

日志中的敏感数据与任何地方的敏感数据相同。根据您想要的重要性 -

• 只允许那些有权查看数据的人访问数据（通常通过角色或组成员身份完成。）

• 如果数据中包含任何受监管或外部问题相关的信息（PCI、HIPAA 等），您必须相应地对待它并遵守合规性要求

• 将日志记录和监控（在网络和主机上）设置为 11（或任何适当的值）

• 尤其是 记录和审核数据访问和尝试

• 仅在需要时保留日志

• 如果可能的话，在不主动使用时进行加密

• 不要让它分散，要巩固和防御

• 如果它上升到一定程度的担忧，您可以保护 mongodb 服务器并将其视为关键系统（安全黑客：如果您处理 PCI 或其他类型的合规性相关数据，您可以假装它拥有该数据并让操作员处理它使用相同的标准/政策/等，而不是找出一种新的处理方式）

对于 mongo，你可能 -

• 将其（加密！）发送到中央日志服务器，最好标记为敏感或具有更高的严重性级别

• 要么不要在本地存储日志，要么，如果需要进行调试/任何其他操作，请在尽可能短的时间（一天、一周、30 天等）后将它们轮流遗忘（例如扔掉它们）

• 如果它们存在于本地，请确保它们由 root/priv'd 用户和模式 0400（或适用于您的操作系统的任何内容）拥有

• 如果你真的很偏执，你可以使用类似于auditd(8)的东西来查看何时有人尝试访问日志（并且再次将auditd日志发送到中央日志服务器！）

• 如果你真的很偏执，你会想要在保存日志的地方使用加密存储，这样它们就不会在删除后从磁盘上消失

• 出于合规性原因，某些数据可能需要长期存储，因此请确保不要过早地破坏任何内容

• 对中央日志服务器的访问应该具有与本地服务器相同的限制，因为......数据

没有什么真正令人兴奋的，同样的，同样的，只是不要错过任何事情，把一切都敲定，限制访问，并监控所有的动作。