单节点 MongoDB 的 oplog 可被读取是因为 local.oplog.rs 是普通 capped collection，只要具备 read 权限且能连接数据库即可 find()；即使未启用副本集，oplog 仍可能存在并暴露敏感数据。
单节点 MongoDB 的 oplog 为什么能被读取
因为 local.oplog.rs 是一个普通 capped collection，只要连接上数据库、有 read 权限（哪怕只是对 local 库的有限权限），就能直接 find() 它。默认安装下，如果没关掉 bindIp 或没设认证，外网连进来就能拖走全部写操作日志——包括插入的明文密码、token、手机号等。
不启用副本集时，oplog 依然存在且可读
这是最容易误判的一点：很多人以为“没配 replica set 就没 oplog”，其实不然。只要启动时用了 --replSet 参数（哪怕只起一个节点），或者初始化过副本集（哪怕后来停了），local.oplog.rs 就会持续写入；而即使完全没碰过副本集，某些旧版本或 Docker 镜像默认会建一个空的 oplog.rs，虽不写入，但结构在，权限控制稍松就可能暴露元信息。
- 检查是否真没 oplog：
db.getSiblingDB("local").oplog.rs.countDocuments({}) - 确认副本集状态：
rs.status()—— 如果报"not running with --replSet"，说明没启用；但不等于 oplog 不存在 - 权限最小化必须覆盖
local库：db.createRole时别漏掉{ resource: { db: "local", collection: "" }, actions: ["find"] }这类隐式授权点
最有效的三道防线：网络 + 认证 + 权限
光靠“我不开副本集”挡不住风险，得层层卡死访问路径：
- 强制绑定内网地址：
bindIp设为127.0.0.1或具体内网段，绝不用0.0.0.0 - 必须开启访问控制：
--auth启动，并创建仅够用的用户，例如应用用户不要readAnyDatabase，更不能给local库任何权限 - 删掉或锁定
local库访问：用db.revokeRolesFromUser清理意外继承的权限；生产环境可考虑在 mongod 启动参数加--setParameter disableLocalHostAuthBypass=1防绕过
监控和自查的关键命令
很多团队上线后从不查权限配置，直到日志泄露才反应过来。这几个命令建议加到部署 checklist 里：
- 看当前用户能读哪些库：
db.runCommand({connectionStatus: 1}).authInfo.authenticatedUsers[0].roles - 验证 oplog 是否可访问：
db.getSiblingDB("local").oplog.rs.findOne()—— 如果返回文档，立刻整改 - 检查监听地址：
db.adminCommand({getCmdLineOpts: 1}).parsed.net.bindIp
oplog 不是副本集专属功能，而是存储机制的一部分；只要它存在、可读、连得上，就是一条现成的数据导出通道。别依赖“我没开 rs”来心安，得靠实打实的网络隔离和权限收敛来堵住。
