MongoDB默认不启用权限控制，只有在admin库创建首个用户后，authorization: enabled才真正生效；否则即使配置开启，仍可无密码直连并执行任意操作。
必须启用 authorization: enabled，否则任何连接到 27017 端口的客户端都能执行任意操作——这不是“默认权限”，而是“零权限控制”状态。
为什么刚装完 MongoDB 还能不输密码就进库
MongoDB 启动时不加任何安全配置，admin.system.users 集合为空时，即使启用了 --auth 参数，认证机制也完全不生效。此时 mongod 仅做连接，不做鉴权，等同于裸奔。
- 典型表现：用
mongo命令直连、Navicat 不填密码就能连上、db.getCollectionNames()正常返回 - 根本原因：MongoDB 的访问控制开关是“按需激活”的——只有在
admin库中成功创建至少一个用户后，整个实例才真正进入鉴权模式 - 错误认知：“改了配置文件就安全了”——如果没重启服务，或重启后没在
admin库里建用户，authorization: true形同虚设
启用鉴权的最小可行步骤（缺一不可）
顺序和位置都关键，错一步就会回到未授权状态。
- 编辑配置文件
/etc/mongod.conf（Ubuntu/Debian）或/usr/local/etc/mongod.conf（macOS Intel），在security段落下添加：security: authorization: enabled
- 保存后执行
sudo systemctl restart mongod（Linux）或brew services restart mongodb-community（macOS） - 用本地
mongo直连（无需认证），切换到admin库：use admin - 运行
db.createUser({user:"adminUser", pwd:"xxx", roles:["userAdminAnyDatabase"]})——注意必须在admin库执行，且角色带AnyDatabase才能后续管理其他用户 - 退出后重连验证：
mongo -u adminUser -p xxx --authenticationDatabase admin，再试use otherdb+db.stats()看是否报not authorized
常见配置陷阱与绕过风险
很多团队以为加了 authorization 就万事大吉，结果仍被扫出未授权漏洞。
-
bind_ip没限制：配置里仍是bind_ip: 0.0.0.0，公网 IP 直连无阻；正确写法是bind_ip: 127.0.0.1,192.168.1.100（显式列出可信内网地址） - 防火墙没开：Linux 上
ufw或iptables未封27017端口，云服务器安全组也开着全通规则 - 误用
root角色：给应用账号分配{role:"root", db:"admin"}，等于把整个实例钥匙交出去；应只授{role:"readWrite", db:"myapp"}这类单库角色 - HTTP/REST 接口残留：老版本 MongoDB 默认开启
httpinterface，可通过http://ip:28017/直接看数据库列表；必须在配置中显式关闭：net: http: enabled: false rest: enabled: false
验证是否真禁用了未授权访问
别信配置，要动手测。最简验证方式就两条命令：
- 从另一台机器执行：
echo '{ "ping": 1 }' | nc your-mongo-ip 27017 | head -c 50—— 如果返回二进制乱码或空，说明端口未暴露；如果返回可读 JSON（含"ok":1），说明还在监听且可能未鉴权 - 用无凭据连接：
mongo --host your-mongo-ip:27017 --eval "db.adminCommand({listDatabases:1})"—— 若返回not authorized或连接拒绝，才算真正生效；若列出所有库名，说明要么没开鉴权，要么用户权限过大
最容易被忽略的是：配置改了、服务也重启了，但忘了在 admin 库里建第一个用户——这一步是鉴权系统的“点火开关”，没有它，所有安全配置都是纸面功夫。
