如何通过安全基线扫描检查MongoDB的配置合规性

在进行 MongoDB 安全基线扫描时，真正让人头疼的往往不是工具不会用，而是扫描报告虽然显示一片绿色，但实际检测结果却毫无参考价值。今天就来详细拆解几个最常见也最容易踩坑的环节，把每一步的实操要点讲清楚、说明白。

扫描前必须确认 mongod 已启用访问控制

如果security.authorization: enabled没有开启，或者在启动时漏掉了--auth参数，那么后续所有扫描结果都不可信——连最基础的身份验证机制都没有生效，合规性检查本身就失去了意义，报告做得再漂亮也毫无价值。

实操建议：

• 检查配置文件（例如/etc/mongod.conf）中security.authorization参数是否设置为true
• 进入 MongoDB shell 执行db.runCommand({getCmdLineOpts: 1})，查看parsed.security.authorization字段值是否为"enabled"
• 如果返回"authorization" : "disabled"，请立即停止扫描，先修正配置并重启服务

使用 mongo-audit 扫描时，权限和连接参数经常出错

工具能连上并不代表能够扫描全面。常见的失败不是直接报错，而是静默地漏检或卡住，尤其在 MongoDB 6.0 及以上版本中，这种“无声失效”往往最致命。

实操建议：

• 扫描账号必须同时具备clusterAdmin和readAnyDatabase角色，仅分配root角色不够——某些审计命令需要集群级别的权限才能执行
• 如果脚本没有显式切换到 admin 库，listDatabases操作在非 admin 库上默认被禁用。建议改用--eval "db.getSiblingDB('admin').runCommand({listDatabases: 1})"来绕过限制
• TLS 连接不要依赖配置自动推断，要强制加上参数：--tls --tlsCAFile /path/to/ca.pem，否则可能卡在 handshake 阶段且无任何提示，而你还在一旁傻等

默认 admin 用户未重命名，会被合规工具直接标为高风险

CIS MongoDB Benchmark、Nessus 等合规检测工具会直接匹配用户名为admin且拥有root角色的账户，命中即报告“Default administrative account exists”。用户名本身就是检测锚点，只修改密码完全没有用。

实操建议：

• 执行use admin后运行：db.getUsers({filter: {roles: {$elemMatch: {role: "root", db: "admin"}}}})
• 如果返回结果中包含user: "admin"，必须新建语义化账户（例如"ops-admin-2026"），再执行db.dropUser("admin")
• 只改密码是无效的——用户名本身才是检测依据

密码策略和 TLS 版本不达标，社区版需要绕过原生限制

MongoDB 社区版不支持口令复杂度、过期周期等原生策略，等保/ISO 27001 等标准要求的“最小长度 12、历史密码禁止复用”无法通过db.createUser()直接实现。此时需要想办法从其他层面补齐。

实操建议：

• 社区版只能依靠操作系统层 PAM 来补充：确认/etc/pam.d/mongod已加载pam_pwquality.so，并配置好minlen=12 difok=5
• TLS 必须使用 1.2 及以上版本：检查net.tls.mode: requireTLS是否存在，并通过openssl s_client -connect host:27017 -tls1_2实测握手能否成功
• 密钥硬编码是高频高危项——encryptionKeyFile路径不能直接写在配置文件的明文里，应该由密钥管理服务（KMS）动态注入

实际跑通一次 MongoDB 安全基线扫描，关键不在于工具选哪个，而在于每一步是否堵住了最基础的缺口：授权没开启、默认账户还在、TLS 握手不通、密码策略全靠人肉记忆——这些点只要漏掉一个，整份扫描报告就失去了可信度。别让工具白忙活，先把这些地基打牢。