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