如何检查MongoDB是否配置了合理的认证强度？

MongoDB 必须启用 security.authorization: enabled，否则所有密码策略和角色配置无效；管理员账户不能为默认用户名“admin”，需创建新用户并删除旧用户；社区版无原生密码策略，需通过PAM或脚本实现强度校验；审计需专用高权限账号连接 admin 库并显式启用 TLS。

怎么确认 MongoDB 是否启用了访问控制

没开 security.authorization: enabled，所有密码策略和角色配置都无效。这是最常被忽略的第一道关卡。

检查方式有三种，优先级从高到低：

• 查运行时配置：db.runCommand({getCmdLineOpts: 1})，看 parsed.security.authorization 字段是否为 true
• 查配置文件（如 /etc/mongod.conf）里是否有 security: authorization: enabled
• 执行 ps aux | grep mongod，确认启动命令含 --auth 或等效参数

如果返回 "authorization" : "disabled"，别继续往下测密码强度——先停服务、改配置、重启。

如何验证管理员账户不是默认用户名

合规扫描工具（如 CIS Benchmark、Nessus）会直接报 Default administrative account exists，只要用户名是 admin 就算高危，改密码没用，必须改名。

操作步骤：

• 连进 shell，切到 admin 库：use admin
• 查 root 级用户：db.getUsers({filter: {roles: {$elemMatch: {role: "root", db: "admin"}}}})
• 若返回中含 {"user": "admin", ...}，立刻执行：db.createUser({user: "prod-root-2026", pwd: "...", roles: ["root"]})，再删旧用户：db.dropUser("admin")

注意：不能只用 db.changeUserPassword，旧用户名仍存在，扫描照样失败。

密码策略靠外围补足，社区版没有原生校验

MongoDB 社区版（截至 2026 年 7 月）不提供密码最小长度、字符类别、历史复用等策略。所谓“强度”其实是 OS 层或代理层的事。

常见落地方式：

• Linux 上启用 PAM：/etc/pam.d/mongod 需加载 pam_pwquality.so，并配置 minlen=12 difok=5 等参数
• Windows 上依赖本地组策略或第三方认证代理（如 Mongoproxy）拦截弱密码创建请求
• 若用自定义脚本预检密码（如 Node.js 调 createUser），必须手动实现两套判断：minLength（纯长度比对）和 characterClassCount（大小写字母、数字、符号四类至少占三类），且注意老驱动对含 & 或 = 的密码可能截断

Enterprise 版才原生支持 passwordPolicy 字段，但社区版用户别指望靠 db.createUser 自动拒绝弱密码。

审计连接权限是否足够跑合规检查

很多“验证密码强度”的脚本（如 mongo-audit）其实根本没在检查密码，而是在查用户是否存在、角色是否最小化——但连不上 admin 库就什么都干不了。

关键权限要求：

• 账号必须同时有 clusterAdmin 和 readAnyDatabase，光有 root 角色不够（某些审计命令需集群级权限）
• 连接字符串必须显式指定 admin 库：mongodb://user:pass@host:27017/admin?authSource=admin，否则 listDatabases 在 MongoDB 6.0+ 默认返回空
• TLS 必须显式声明：--tls --tlsCAFile /path/to/ca.pem，不能只靠配置文件里的 ssl=true，否则脚本常静默卡住

最容易被忽略的是：扫描账号的权限 ≠ 生产应用账号的权限。别拿应用账号去跑审计，得单独建一个审计专用账号并授全权。