MongoDB合规高危风险包括：未启用访问控制、默认admin账户未重命名、审计脚本权限不足、TLS配置缺失、密码策略未落实及密钥硬编码。需逐项核查并修复。
检查 mongod 是否启用访问控制
没开 --auth 或 security.authorization: enabled，所有身份验证配置都形同虚设。直接连上就能读写，合规扫描肯定报高危。
实操建议：
- 查启动参数：
ps aux | grep mongod，确认含--auth；或查配置文件（如/etc/mongod.conf）里security.authorization是否为true - 连进 shell 执行
db.runCommand({getCmdLineOpts: 1})，看parsed.security.authorization字段 - 如果返回
"authorization" : "disabled"，立刻停服修正——别等扫描报出来再动
验证默认 admin 用户是否被重命名或禁用
很多扫描工具（如 CIS MongoDB Benchmark、Nessus 插件）会直接检测用户名为 admin 的 root 角色账户。保留默认 admin 用户名是典型合规失分项。
实操建议：
- 切换到
admin库执行：db.getUsers({filter: {roles: {$elemMatch: {role: "root", db: "admin"}}}}) - 若返回用户
user: "admin"，说明仍用默认账号——应改用语义化名称（如"prod-admin-2024"），再删掉旧用户：db.dropUser("admin") - 注意：不能只改密码，必须改用户名；否则扫描仍会标记 “Default administrative account exists”
运行 mongo-audit 或自定义合规检查脚本时的常见失败点
开源工具如 mongo-audit（GitHub 上较活跃的 Python 脚本）依赖特定连接权限和命令支持，不是连得上就能扫。
实操建议：
- 确保用于扫描的账号有
clusterAdmin+readAnyDatabase角色，仅root不够（某些审计命令需集群级权限） - MongoDB 6.0+ 默认禁用
listDatabases对非 admin 库的响应，脚本若没显式指定--eval "db.getSiblingDB('admin').runCommand(...)"会漏检 - TLS 配置不匹配时，脚本常卡在连接阶段而非报错——加
--tls --tlsCAFile /path/to/ca.pem显式声明，别依赖ssl=true配置项自动推断
密码策略与认证机制是否满足等保/ISO 27001 要求
光有账号密码不够，合规要求明确定义最小长度、过期周期、历史密码禁止复用等。MongoDB 原生不提供密码复杂度策略，必须靠外围控制或升级到 Enterprise 版。
实操建议：
- 社区版只能靠 OS 层 PAM 或代理层（如 Mongoproxy）补足——检查
/etc/pam.d/mongod是否加载了pam_pwquality.so并配置minlen=12 difok=5 - Enterprise 版可用
setParameter启用passwordPolicy，但注意：该策略对已存在用户不生效，需逐个调用updateUser强制重置密码才能触发校验 - 扫描脚本通常只查配置是否存在，不验证策略是否实际作用于用户——务必手动测试一个新用户创建流程，确认
db.createUser(...)在弱密码下真会拒绝
真正容易被忽略的是：合规扫描能发现“没开 auth”，但发现不了“开了 auth 却把密钥硬编码在 Dockerfile 的 ENV 里”。配置即代码的上下文安全，得靠 CI/CD 流水线卡点，不是一次脚本扫描能覆盖的。
