29、MongoDB测评

MongoDB 三级等保现场测评：RBAC 角色与用户、SCRAM/x.509/LDAP 认证、企业版 auditLog 审计、TLS 与静态加密、副本集与备份恢复的核查命令、判定标准与证据留存要求。
Categories:

  6 分钟阅读  

定位：MongoDB 数据库作为测评对象的现场核查方法与判定标准，按控制点给出实测判据。 适用版本：MongoDB 4.4~7.x（示例环境 Windows 10 + MongoDB 5.0.8；本文命令以旧壳 mongo 为例，6.0+ 请改用 mongosh，语法一致）。 配套测评：06、MongoDB 测评命令单；配套加固：09、MongoDB数据库加固；高风险口径：22、高风险判定指引与加固对照表。

使用说明：

  • 本文所有命令均为只读取证命令，不修改配置、不重启服务、不执行清除类操作；确需变更由被测单位运维方在授权下实施。
  • 命令回显本身即证据，须连同命令行一起截图；示例中的地址、账户、路径均为演示值，现场须替换为真实取证结果，并对个人信息与内网管理地址脱敏后再入报告。
  • 命令不存在或输出与示例差异较大时，先确认产品版本与部署形态（单机/集群/容器/云托管），再换用等效命令或转入配置文件、管理控制台取证，不得据命令缺失直接判不符合。
  • 文中「默认」「一般」等表述均为初判倾向，须经上机核查 + 访谈 + 配置/制度核对三方印证后定论，并在报告中写明取证来源。

不适用标识说明：

  • 使用 【不适用】 明确标记现场可判定为不适用的控制点，并写明判定依据。
  • 依据 GB/T 28448-2019「按测评对象实际承载功能与数据处理范围判定」原则：控制能力由上层应用、统一认证平台、前置代理、堡垒机、宿主操作系统或云托管平台承载时，应注明测评单元边界后判定不适用或转由上位组件核查，不得机械按缺失判不符合。
  • 产品版本确实不提供该能力（如社区版无审计插件）时，须核查替代措施并按替代措施的实际效果定档，不得直接判不适用。

一、MongoDB 介绍

MongoDB 是一个基于分布式文件存储的文档数据库，由 C++ 语言编写，数据结构为类 JSON 的 BSON 格式，支持松散的数据结构，可存储较为复杂的数据类型。

二、基础信息

对应控制点：非独立控制点（测评对象与资产确认）；部署形态、版本与冗余情况佐证 8.1.2.1 网络架构 e) 关键设备硬件冗余

判定要点：本节为测评对象确认，不单独出结论；版本、监听端口、运行账户、数据目录、部署形态（单机/集群/容器）未取全时，后续控制点的判定口径无法确定，应先补齐再进入控制点核查。

取证要求：版本回显截图、监听端口与进程截图、运行账户截图、配置文件与数据目录路径截图、集群拓扑或部署说明。

先确认版本、edition（社区版/企业版）与认证开关，后续所有控制点判定均以此为前置：

mongod --version            # 含版本与 edition 信息
mongosh --eval "db.version()"
mongosh --eval "db.adminCommand({ getParameter: 1, authenticationMechanisms: 1 })"

grep -nE "authorization|bindIp|tls:|mode:|certificateKeyFile|auditLog|verbosity|quiet" /etc/mongod.conf
  • 备注：Windows 环境对应 mongod.cfg。优先确认版本与 edition、认证是否启用、监听地址、TLS 模式、是否配置审计。
  • 预期证据：版本与 edition 截图、配置文件关键段落截图。

三、测评实施

身份鉴别

对应控制点：GB/T 22239-2019 8.1.4.1 身份鉴别 a)~d)

判定要点：账户唯一且非默认口令、鉴别信息复杂度与有效期均已配置、远程管理走加密通道、失败处理与会话超时已启用 → 符合；仅满足其中一部分（如有口令但无复杂度、无失败锁定、无空闲超时）→ 部分符合；管理入口无鉴别、存在空口令或沿用出厂口令 → 不符合（高风险）。

取证要求：账户清单截图、口令策略参数截图、加密通道配置截图、失败锁定与会话超时参数截图、弱口令实测记录；由统一认证平台承载时补平台侧配置与对接截图。

a) 应对登录的用户进行身份标识和鉴别，身份标识具有唯一性，身份鉴别信息具有复杂度要求并定期更换

  • 核查要点：
    1. 裸连执行 mongo / mongosh，确认是否已启用身份鉴别——MongoDB 安装后默认未开启权限验证（security.authorization 默认为 disabled），未启用时任何人无需认证即可做任意操作。
    2. 查账号与认证机制：db.system.users.find({}, { user: 1, db: 1, mechanisms: 1, authenticationRestrictions: 1 })；4.0 起默认机制为 SCRAM-SHA-256。
    3. 查复杂度与定期更换：MongoDB 社区版原生不提供口令复杂度与有效期策略，须确认是否由统一认证/LDAP/堡垒机等外部机制承载并取证。
    4. 实测：尝试创建弱口令账户，验证策略是否生效。
  • 判定标准：
    • 符合：已启用 authorization、全部账号需认证、账号可唯一对应自然人、复杂度与定期更换由外部机制管理且可出示配置与记录。
    • 部分符合：已启用认证与复杂度管理，但定期更换仅靠人工约定、无更换记录。
    • 不符合：未启用认证（裸连可任意操作），或存在空口令/共享账号。该项为高风险线索，须对照 22、高风险判定指引与加固对照表。
  • 常见不符合项：只核对配置文件写了 authorization: enabled 而未实测裸连；把启用认证后的 localhost exception（localhost 免认证创建首个用户的默认行为）误判为配置错误——它是设计行为，但生产环境应通过 enableLocalhostAuthBypass: false 关闭。
  • 证据留存：裸连验证截图、system.users 清单（含 mechanisms）、外部认证机制配置、弱口令实测结果、访谈纪要。

MongoDB 未启用认证时裸连可任意操作界面对照

整改：在 mongod.cfg 中启用身份认证：

security:
  authorization: enabled
setParameter:
  enableLocalhostAuthBypass: false

MongoDB 启用认证后权限不足提示界面对照

MongoDB 口令策略核查界面对照

b) 应具有登录失败处理功能，应配置并启用结束会话、限制非法登录次数和当登录连接超时自动退出等相关措施

  • 核查要点：
    1. 确认是否存在登录失败锁定：MongoDB 社区版无原生的失败次数阈值与自动锁定机制，须核查替代措施（OS 层 fail2ban、堡垒机、代理层限流）并取证。
    2. 确认空闲会话超时：核查是否配置了会话空闲超时（部分版本提供 idleSessionTimeoutSecs 服务器参数，按实际版本核实是否支持），或由连接池/代理层实现。
  • 判定标准：
    • 符合：具备失败次数阈值与自动锁定、且空闲会话超时已配置（原生或外部实现，可演示）。
    • 部分符合：仅由外部设备实现但无法演示，或无策略文档支撑。
    • 不符合：既无失败锁定也无超时退出，且无外部替代措施（社区版默认即此档）。
  • 常见不符合项：把配置文件中不存在的参数当作已配置；只看写在文档里的制度，未上机验证。
  • 证据留存：相关参数输出、替代措施配置（fail2ban jail 或堡垒机策略）、访谈纪要。

c) 当进行远程管理时，应采取必要措施防止鉴别信息在网络传输过程中被窃听

  • 核查要点：
    1. 是否存在远程管理：查 net.bindIp（127.0.0.1 为仅本地）。
    2. TLS 配置：net.tls.mode（disabled / allowTLS / preferTLS / requireTLS）、net.tls.certificateKeyFile、net.tls.CAFile。
    3. 实测：用不带 tls=true 的连接串尝试连接，确认是否被拒绝；必要时抓包验证。
  • 判定标准：
    • 不适用：bindIp 仅本地且账号均从本地管理，需在报告写明依据。
    • 符合：requireTLS 且明文连接被拒绝。
    • 部分符合：preferTLS / allowTLS，允许明文降级。
    • 不符合：远程管理明文传输。
  • 证据留存：TLS 配置截图、明文连接被拒截图、抓包结果。

d) 应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别，且其中一种鉴别技术至少应使用密码技术来实现

  • 核查要点：访谈并验证是否采用双因子。MongoDB 支持 x.509 证书认证（$external 数据库中的用户 + tlsCertificateKeyFile），证书属密码技术类第二因子；企业版还支持 Kerberos/LDAP，也可由堡垒机承载。
  • 判定标准：
    • 符合：口令 + 客户端证书（或经堡垒机/统一认证实现双因子）且可现场演示。
    • 部分符合：双因子由外部平台实现，但未见配置或无法演示。
    • 不符合：仅口令单一因子。
  • 证据留存：x.509 用户清单与证书有效期、双因子登录演示截图。

访问控制

对应控制点：GB/T 22239-2019 8.1.4.2 访问控制 a)~g)

判定要点：账户与权限一一对应、默认账户已处置、无多余与共享账户、管理权限已分离、有书面授权策略、授权粒度达到用户级与表级 → 符合；有权限划分但存在越权高权限账户或粒度仅到角色级 → 部分符合；统一使用超级账户或应用账户持最高权限 → 不符合。

取证要求：账户与角色对照表、权限清单查询输出、默认账户处置记录、访问控制策略文件与授权审批记录、粒度核查（对象级/列级/行级）输出。

a) 应对登录的用户分配账户和权限

  • 核查要点：db.adminCommand({ usersInfo: 1 }) 或 db.getUsers()（需 userAdmin 权限）；核对内置角色（read / readWrite / dbAdmin / userAdmin / dbOwner / clusterAdmin / root）与实际职责是否匹配；访谈确认三员分立。
  • 判定标准：
    • 符合：每名管理员有独立账号、按角色授权、可对应到自然人。
    • 部分符合：有独立账号但同时存在共用的超级账号。
    • 不符合：未启用认证（无从分配权限），或全部共用 root 角色账号。
  • 常见不符合项：为图方便给应用账号授予 root 或 clusterAdmin。
  • 证据留存：用户清单与角色对照表、访谈纪要。

MongoDB 用户与权限查询结果界面对照

MongoDB 账户权限列表界面对照

b) 应重命名或删除默认账户，修改默认账户的默认口令

  • 核查要点：MongoDB 安装后不预置可登录的默认账户（账户均由管理员自建），核查重点转为：是否存在测试期遗留的弱口令/空口令账户，以及 localhost auth bypass 是否已关闭。
  • 判定标准：
    • 符合：无遗留账户、enableLocalhostAuthBypass 已关闭、自建账户均为强口令。
    • 部分符合：存在自建弱口令账户但已限制来源地址。
    • 不符合：启用认证后仍可经 localhost 免认证创建账户，或存在空口令账户。
  • 证据留存：用户清单、bypass 参数值、登录实测截图。

c) 应及时删除或停用多余的、过期的账户，避免共享账户的存在

  • 核查要点：核对 db.getUsers() 结果与在岗人员名单；确认是否存在多人共用的应用/运维账号；确认网络管理员、安全管理员、系统管理员是否使用不同账户。
  • 判定标准：
    • 符合：无多余/过期账户、无共享账号，账号与人员一一对应。
    • 部分符合：存在停用账户但未删除。
    • 不符合：存在共享账号，或离职/调岗人员账户未清理仍可登录。
  • 证据留存：账号台账、人员对照表、清理记录、访谈纪要。

d) 应授予管理用户所需的最小权限，实现管理用户的权限分离

  • 核查要点：db.getRoles({ showBuiltinRoles: false }) 查自定义角色；确认是否按系统管理、安全管理、审计管理分别建角色并授予不同账号；核查持 root / clusterAdmin 的账号数量。
  • 判定标准：
    • 符合：三类管理角色齐备且互不兼任，管理用户仅授予必需权限。
    • 部分符合：有角色划分，但仍存在越权的超级账号或角色兼任。
    • 不符合：所有运维账号均为 root 角色，无权限分离。
  • 证据留存：自定义角色清单与成员对照、权限分离说明。

MongoDB 各账户权限核查界面对照

e) 应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则

  • 核查要点：查阅访问控制策略文件（授权主体、主体/客体访问规则），核对线上角色与授权是否与策略一致，抽查授权审批记录。
  • 判定标准：
    • 符合：有书面策略、明确授权主体，实际授权与策略一致且经审批。
    • 部分符合：有策略但授权未走审批，或个别授权与策略不符。
    • 不符合：无访问控制策略，授权由运维人员自行决定。
  • 证据留存：访问控制策略文件、授权审批记录、策略与实际授权比对表。

f) 访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级

  • 核查要点：db.getRole('<角色名>', { showPrivileges: true }) 查看自定义角色的资源粒度，确认是否精确到集合（collection）级；内置角色（read / readWrite 等）粒度为库级。
  • 判定标准：
    • 符合：自定义角色精确到集合级，并按用户分别授予。
    • 部分符合：仅使用库级内置角色，但库内数据敏感度相当。
    • 不符合：统一使用 root / __system，无法区分客体。
  • 注意：原稿称「此测评点多数测评机构默认判定为符合」——不应默认。内置 readWrite 只到库级，不满足「客体为表（集合）级」时的严格口径，须以实际角色定义为据。
  • 证据留存：showPrivileges 输出、角色与用户对照表。

g) 应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问

  • 核查要点：确认 MongoDB 是否具备安全标记机制（原生不具备），是否由操作系统强制访问控制或第三方数据标签/脱敏系统实现并演示。
  • 判定标准：
    • 符合：由 OS 或第三方实现安全标记并能演示基于标记的访问裁决。
    • 部分符合：仅在管理制度层面定义密级，系统层面无强制裁决。
    • 不符合：无任何实现。
  • 注意：不得因数据库自身不具备该功能直接判不适用，须写明「本组件不承载，由上位系统/操作系统测评」及取证结论。
  • 证据留存：第三方方案说明与演示记录、访谈纪要。

安全审计

对应控制点：GB/T 22239-2019 8.1.4.3 安全审计 a)~d)

判定要点：审计功能已启用且实际产生记录、记录含时间/用户/事件类型/结果四要素、覆盖特权账户、审计数据受保护并留存 ≥6 个月、非审计管理员无法变更或清除 → 符合；开关已开但无审计策略、记录要素不全、仅本地留存或留存不足 → 部分符合；审计未启用且无第三方审计措施 → 不符合（高风险）。

取证要求：审计开关与策略配置截图、审计记录抽样（脱敏）、审计存放路径与权限核查结果、清理与转存任务配置、最早记录时间清单、第三方审计系统截图。

a) 应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计

  • 核查要点：
    1. 先确认 edition：审计为 MongoDB Enterprise 专有能力。执行 mongod --version 确认是否为企业版；社区版无 auditLog。
    2. 企业版：查 auditLog.destination / path / format / filter 与 auditAuthorizationSuccess（默认 false，即只记录授权失败，需显式开启才能记录成功操作）。
    3. 社区版：查是否部署第三方数据库审计系统（旁路/代理）集中采集，或仅依赖 mongod.log 与 profiler。
    4. 核查日志详细程度：systemLog.verbosity（旧版本为 quiet，quiet: true 会大幅减少日志量）。
  • 判定标准：
    • 符合：企业版 auditLog 已启用、覆盖各用户的重要操作（auditAuthorizationSuccess: true 或过滤器覆盖到位），或第三方审计系统集中采集且证据充分。
    • 部分符合：仅依赖 mongod.log 与 profiler——记录内容有限，不含完整的事件结果与用户来源；或企业版审计已开但未开成功操作审计。
    • 不符合：无任何审计措施（社区版未部署第三方审计即属此档）。
  • 常见不符合项：把 mongod.log 或 profiler 当作等保要求的安全审计；在社区版报告里写入 auditLog 配置项。
  • 证据留存：版本与 edition 输出、systemLog 段落截图、企业版 auditLog 配置与日志抽样，或第三方审计系统截图。

MongoDB 日志详细程度配置核查界面对照

MongoDB mongod.log 记录内容界面对照

b) 审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息

  • 核查要点：抽样审计记录，核对是否含日期时间（ts）、用户（users）与来源（local / remote 的 IP:port）、事件类型（atype）、事件结果（result）。
  • 判定标准：
    • 符合：四要素齐全（时间、用户、事件类型、事件结果）。
    • 部分符合：缺来源地址或事件结果，但可与其他日志（系统日志、堡垒机日志）关联补齐。
    • 不符合：仅有操作内容，无时间或无法区分成功/失败。
  • 证据留存：审计记录抽样（脱敏后）、字段与等保要素对照说明。

c) 应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等

  • 核查要点：审计/日志文件的属主与权限（OS 层）；用普通账号实测能否读取、修改、删除；核查转存策略（logRotate 为 rename 或 reopen 时须由 logrotate 定期归档）与留存期是否 ≥6 个月。
  • 判定标准：
    • 符合：权限受限、有归档或转存、留存 ≥6 个月。
    • 部分符合：仅本地保留但容量与轮转可满足 6 个月，且未被清理。
    • 不符合：普通账号可删除日志，或无归档且留存不足 6 个月。
  • 常见不符合项：把 logRotate 的轮转机制直接当作留存期证据。
  • 证据留存：文件权限截图、logrotate 配置、留存清单（含最早文件时间戳）。

d) 应对审计进程进行保护，防止未经授权的中断

  • 核查要点：确认哪些账号持有可变更审计配置/参数的权限（如执行 setParameter 所需的 clusterAdmin、持 root 角色的账号），核查应用账号是否在其中。
  • 判定标准：
    • 符合：仅审计管理员可变更审计配置，普通与应用账号无法停止审计。
    • 部分符合：DBA 兼任审计管理权限，但无应用账号持特权角色。
    • 不符合：应用或运维账号可关闭审计或删除审计文件。
  • 证据留存：持特权角色账号清单、权限分离说明、实测结果。

MongoDB 特权角色持有情况核查界面对照

入侵防范

对应控制点：GB/T 22239-2019 8.1.4.4 入侵防范 a)~f)

判定要点：最小安装、非必要服务与高危端口已关闭、管理终端来源受限、有数据有效性检验、版本无已知高危漏洞且定期漏扫修补、上位部署入侵检测并能出示本对象告警 → 符合；部分措施到位（如有防火墙限制但库层未配来源校验、有漏扫无修补记录）→ 部分符合；管理端口无限制开放或存在已知高危漏洞未修补 → 不符合（高风险）。

取证要求：已安装组件/选件清单、监听与端口核查输出、来源限制配置截图与拒绝实测、约束或校验配置输出、版本与补丁记录、漏扫报告、上位 IDS/IPS 告警与处置工单。

a) 应遵循最小安装的原则，仅安装需要的组件和应用程序

  • 核查要点：db.adminCommand({ listDatabases: 1 }) 查是否存在示例库/测试库；确认是否部署了与业务无关的组件（如仅单实例却运行 mongos、旧版本的 HTTP status 与 REST 接口）；核查对外遥测上报是否关闭。
  • 判定标准：
    • 符合：无多余组件与示例数据，对外遥测/免费监控已关闭。
    • 部分符合：存在测试库但已停用，或非必要组件存在但未启用。
    • 不符合：启用非必要的对外上报接口或遗留 HTTP/REST 接口（旧版本）。
  • 注意：不得仅写「数据库此项不适用」而不说明理由；数据库软件本体的组件安装若由宿主 OS 承载，应注明并转由 OS 侧测评。
  • 证据留存：库清单截图、组件与接口启用情况核查记录。

b) 应关闭不需要的系统服务、默认共享和高危端口

  • 核查要点：net.port（默认 27017）与 net.bindIp；OS 层 netstat -ano / ss -lntp 查监听；旧版本还需关注 HTTP status 接口默认端口（HTTP 接口自 3.6 起已移除）。
  • 判定标准：
    • 符合：仅监听必要地址，非必要服务与接口已关闭。
    • 部分符合：监听 0.0.0.0 但有防火墙/ACL 限制（须取得边界策略证据）。
    • 不符合：数据库端口无限制开放，可从办公网/互联网直达。
  • 注意：端口与网络服务属数据库可承载项，不宜直接判不适用。
  • 证据留存：监听端口输出、配置文件、边界策略截图。

c) 应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制

  • 核查要点：net.bindIp（127.0.0.1 仅本地；0.0.0.0 为任意地址；多地址用半角逗号分隔，如 127.0.0.1,192.168.10.10）；用户级限制 authenticationRestrictions: [{ clientSource: ["192.168.10.0/24"] }]；OS 防火墙规则。
  • 判定标准：
    • 符合：bindIp 限定管理网段，且用户级 clientSource 已限制。
    • 部分符合：仅有 bindIp 限制，无用户级来源限制。
    • 不符合：bindIp: 0.0.0.0 且无边界防护。
  • 证据留存：bindIp 配置截图、用户 authenticationRestrictions 输出、防火墙规则截图。

MongoDB bindIp 监听地址配置核查界面对照

d) 应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求

  • 核查要点：MongoDB 自 3.2 起提供原生文档校验（$jsonSchema + validationLevel / validationAction）。执行 db.getCollectionInfos() 核查 options.validator 与 validationAction（error 为拒绝写入，warn 仅告警）；无校验时核查应用层校验并验证其有效性。
  • 判定标准：
    • 符合：关键集合配置了 $jsonSchema 校验且 validationAction: error，或应用层校验经验证有效。
    • 部分符合：校验级别为 warn，或仅依赖应用层校验但未做验证测试。
    • 不符合：无校验且实测可写入超出设定范围的数据。
  • 注意：不能一律判「数据库此项不适用」——MongoDB 具备原生校验能力，须先查 validator 再定档。
  • 证据留存：getCollectionInfos 输出、非法数据写入实测结果。

e) 应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞

  • 核查要点：mongod --version / db.version() 对照 CVE/NVD 与 MongoDB 官方安全公告；查阅漏扫或渗透测试报告（建议周期不超过半年）与升级台账。
  • 判定标准：
    • 符合：有定期漏扫（≤半年）且发现的高危漏洞已修补并有复测验证记录。
    • 部分符合：有漏扫但无修补记录，或已升级未复测。
    • 不符合：无漏扫记录且当前版本存在已知高危漏洞。
  • 证据留存：版本输出、漏扫报告、升级记录与复测结论。

f) 应能够检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警

  • 核查要点：确认上位系统是否部署 IDS/IPS、数据库审计或数据库防火墙，并能提供针对本数据库的告警记录；MongoDB 自身不具备入侵检测能力。
  • 判定标准：
    • 符合：上位系统已部署并能出示针对本对象的告警与处置记录。
    • 部分符合：已部署但告警未覆盖本对象或从未处置。
    • 不符合：无任何入侵检测措施。
  • 注意：按「本组件不承载、由上位系统测评」记录，不得判不适用，须取得上位系统的证据。
  • 证据留存：上位系统部署说明、告警记录、处置工单。

恶意代码防范

对应控制点：GB/T 22239-2019 8.1.4.5 恶意代码防范 a)b)

判定要点：宿主 OS 已部署恶意代码防范且规则库更新正常（含数据目录未排除），库内可执行载体（JVM/外部过程/脚本扩展）已按需关闭或受限 → 符合；OS 侧已部署但排除数据目录，或可执行载体已启用未加限制 → 部分符合；宿主无任何防范措施 → 不符合。仅当测评单元不含宿主 OS 时方可判不适用，并写明测评单元边界。

取证要求：宿主 OS 防范措施截图、规则库版本与更新时间、库内可执行载体启用状态查询输出、访谈纪要。

应采用免受恶意代码攻击的技术措施或主动免疫可信验证机制及时识别入侵和病毒行为，并将其有效阻断

  • 核查要点：确认恶意代码防范能力由宿主操作系统承载，核查 OS 侧杀毒/EDR 的部署与更新状态；数据库组件自身不承载该能力。
  • 判定标准：
    • 符合：宿主 OS 已部署恶意代码防范且规则库更新正常（须提供宿主机构取证）。
    • 部分符合：已部署但规则库过期或未覆盖数据目录。
    • 不符合：宿主机构无任何防范措施。
  • 注意：仅当测评单元为独立数据库实例、不含宿主 OS 时，方可判不适用并写明理由与测评单元边界。
  • 证据留存：宿主 OS 侧防范措施截图、规则库版本与更新时间。

可信验证

对应控制点：GB/T 22239-2019 8.1.4.6 可信验证

判定要点：宿主服务器配备可信根（TCM/TPM）并启用引导与关键执行环节动态验证、验证结果送安全管理中心 → 符合；具备可信根但未启用动态验证或未送安全管理中心 → 部分符合；无可信验证措施 → 不符合（多数现场属此档，须由宿主机构侧取证）。

取证要求：可信计算配置截图、动态验证与报警记录、送安全管理中心的对接证据、访谈纪要。

可基于可信根对计算设备的系统引导程序、系统程序、重要配置参数和应用程序等进行可信验证，并在应用程序的关键执行环节进行动态可信验证，在检测到其可信性受到破坏后进行报警，并将验证结果形成审计记录送至安全管理中心

  • 核查要点：访谈并核查宿主服务器是否配备可信芯片（TCM/TPM）并启用可信验证；数据库自身无该能力。
  • 判定标准：
    • 符合：宿主服务器启用基于可信根的验证并接入安全管理中心（须提供宿主机构取证）。
    • 部分符合：具备可信根但未启用动态验证或未送安全管理中心。
    • 不符合：无可信验证措施（多数现场属此档）。
  • 证据留存：可信计算相关配置截图、访谈纪要、宿主机构测评结论引用。

数据完整性

对应控制点：GB/T 22239-2019 8.1.4.7 数据完整性 a)b)

判定要点：传输侧启用密码技术保护并强制校验（不可降级），存储侧有哈希基线或校验字段并定期比对 → 符合；仅传输侧保护或仅配置文件有基线、校验参数可降级 → 部分符合；传输与存储均无完整性保护 → 不符合。管理全在本机时传输项可判不适用，须写明依据。

取证要求：传输加密与校验参数截图、抓包结果（脱敏）、哈希基线清单与比对记录、第三方完整性监控说明。

a) 应采用密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等

  • 核查要点：核查 net.tls.mode 与证书配置，用不带 tls=true 的连接串实测是否被拒绝；TLS 协议自带完整性保护。
  • 判定标准：
    • 不适用：管理全在本地（bindIp 仅本地且账号均本地管理），需在报告写明依据。
    • 符合：远程管理全程 TLS，明文连接被拒。
    • 部分符合：允许明文降级。
    • 不符合：远程管理明文传输。
  • 证据留存：TLS 配置截图、明文连接实测结果。

b) 应采用密码技术保证重要数据在存储过程中的完整性，包括但不限于鉴别数据、重要业务数据和重要个人信息等

  • 核查要点：核查是否存在第三方完整性保护措施——配置文件哈希基线、文档/集合级哈希或 MAC 校验字段、主机级文件完整性监控，并查定期比对记录；MongoDB 自身不提供存储完整性保护。
  • 判定标准：
    • 符合：重要数据与配置文件均有完整性校验机制并定期比对。
    • 部分符合：仅配置文件有哈希基线，业务数据无校验。
    • 不符合：无任何完整性校验措施。
  • 常见不符合项：把 WiredTiger 的 journal（预写日志） 当作完整性保护——它用于崩溃恢复时的数据一致性，不能防止人为篡改；原稿「通过 journaling 保证完整性、由 MongoEvent 实现校验」为未核实的网络说法，已去除。
  • 证据留存：哈希基线清单、比对记录、第三方工具说明。

数据保密性

对应控制点：GB/T 22239-2019 8.1.4.8 数据保密性 a)b)

判定要点：鉴别数据以强算法加盐存储（不含已废弃的弱哈希），重要业务数据与个人信息字段采用透明加密或应用侧加密，密钥管理可控 → 符合；仅鉴别数据非明文而业务数据明文，或加密算法强度不足 → 部分符合；鉴别数据使用弱哈希或重要数据明文且无加密措施 → 不符合。

取证要求：口令存储格式查询输出、加密配置与密钥（钱包/证书）管理截图、敏感字段抽样结果、算法清单与选型说明、抓包结果（脱敏）。

a) 应采用密码技术保证重要数据在传输过程中的保密性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等

  • 核查要点：在未启用 TLS 时用 Wireshark 抓取认证过程，验证鉴别数据是否可被还原；核查 net.tls.mode 是否为 requireTLS。
  • 判定标准：
    • 不适用：不存在远程管理（依据同数据完整性 a)）。
    • 符合：远程管理全程 TLS 且抓包无法还原明文凭据。
    • 部分符合：支持 TLS 但允许明文降级，抓包可获明文。
    • 不符合：远程管理明文传输且抓包可还原鉴别数据。
  • 证据留存：抓包结果（脱敏后）、TLS 配置截图。

b) 应采用密码技术保证重要数据在存储过程中的保密性，包括但不限于鉴别数据、重要业务数据和重要个人信息等

  • 核查要点：
    1. 鉴别数据：MongoDB 以 SCRAM 的加盐哈希形式存储（mechanisms 为 SCRAM-SHA-256 / SCRAM-SHA-1），非明文。
    2. 业务与个人信息：抽查集合中敏感字段是否明文存储。
    3. 静态加密：存储层加密为企业版专有能力（自 3.4 起，通过 --enableEncryption 配合 KMIP 或密钥文件实现）；社区版不具备，须核查是否采用磁盘/文件级加密或应用层字段加密替代。
  • 判定标准：
    • 符合：鉴别数据非明文，且重要业务数据与个人信息字段加密存储（企业版原生或第三方/应用层实现）。
    • 部分符合：仅鉴别数据非明文，业务与个人信息明文存储。
    • 不符合：鉴别数据明文或可通过弱哈希批量还原。
  • 注意：原稿称「MongoDB 自身提供加密机制」未区分社区版与企业版，社区版实际不具备原生静态加密，已更正。企业版静态加密防的是磁盘丢失与文件被复制，对已控制数据库实例的攻击者不提供防护，报告中应如实描述。
  • 证据留存：system.users 的 mechanisms 分布、敏感字段抽样、加密方案与密钥管理说明。

数据备份恢复

对应控制点：GB/T 22239-2019 8.1.4.9 数据备份恢复 a)~c)

判定要点：有本地备份任务与近期备份产物且有恢复演练记录、有异地实时或定时备份链路、具备热冗余（集群/主备）并可演示切换 → 符合；有备份产物但仅做过校验从未真实恢复、异地周期过长、有冗余架构无切换演练 → 部分符合；无备份措施或单实例且无异地副本 → 不符合。

取证要求：备份脚本或作业配置截图、备份产物清单（含时间戳）、恢复演练记录、异地备份拓扑与同步状态输出、集群或主备状态输出、切换演练记录。

a) 应提供重要数据的本地数据备份与恢复功能

  • 核查要点：访谈并查看备份策略与执行记录（crontab、备份脚本、备份目录清单），核对备份产物与策略是否一致，是否有恢复测试记录。
mongodump    -h 127.0.0.1:27017 -d test -o /backup/mongodump        # 备份
mongorestore -h 127.0.0.1:27017 -d test --dir /backup/mongodump     # 恢复
mongorestore -h 127.0.0.1:27017 -d test --dir /backup/mongodump --drop   # 恢复前先清空
  • 参数：-h 服务地址（可含端口）、-d 库名（恢复时可与备份时不同）、-o / --dir 备份目录（需预先建立）、--drop 恢复前先删除当前数据。
  • 备注：副本集环境必须加 --oplog 才能保证时间点一致；单机 mongodump 备份期间的业务写入会导致备份集时间点不一致，恢复后可能丢失或错乱。也可使用文件系统快照（需配合 journal 或 db.fsyncLock()），或 Navicat 等图形工具按库备份。
  • 判定标准：
    • 符合：有备份任务配置、近期备份产物，且有恢复演练记录。
    • 部分符合：有备份任务与产物，但从未验证可恢复；或单机备份未用 --oplog 导致时间点不一致。
    • 不符合：无备份措施。
  • 证据留存：备份任务配置截图、备份产物列表（含时间戳）、恢复演练记录。

b) 应提供异地实时备份功能，利用通信网络将重要数据实时备份至备份场地

  • 核查要点：确认备份目的地与主机是否分处不同物理地点（异地机房/同城灾备/对象存储），确认同步方式（rsync 定时推送、副本集跨机房节点、存储层复制、备份一体机）与周期。
  • 判定标准：
    • 符合：存在异地备份链路且周期满足业务 RPO 要求。
    • 部分符合：有异地备份但周期过长，或链路未验证过可用性。
    • 不符合：无异地备份。
  • 常见不符合项：把「本机多块磁盘互拷」或「同机房另一台主机的副本」当作异地备份。
  • 证据留存：异地备份拓扑说明、同步状态输出、异地侧文件清单。

c) 应提供重要数据处理系统的热冗余，保证系统的高可用性

  • 核查要点：rs.status() 查副本集成员与健康状态，或 sh.status() 查分片集群；确认是否具备自动故障转移并有过切换演练。
  • 判定标准：
    • 符合：副本集或分片集群部署，且可演示故障切换。
    • 部分符合：有冗余架构但无切换演练记录，或副本集仅单节点可用于承载业务。
    • 不符合：单机 mongod 运行。
  • 证据留存：rs.status() 输出、冗余架构说明、切换演练记录。

剩余信息保护

对应控制点：GB/T 22239-2019 8.1.4.10 剩余信息保护 a)b)

判定要点：鉴别信息与敏感数据所在存储空间在释放或重分配前有可验证的清除机制（客体重用参数、存储层安全擦除、加密后销毁密钥），且备份介质纳入清除范围 → 符合；仅有逻辑删除（DROP/DELETE）未做清除验证，或备份介质未纳入 → 部分符合；无任何清除机制 → 不符合。

取证要求：客体重用或擦除相关参数截图、擦除验证记录、密钥销毁流程说明、备份介质销毁与清除记录、敏感数据分布清单。

a) 应保证鉴别信息所在的存储空间被释放或重新分配前得到完全清除

  • 核查要点：db.dropUser() / db.dropDatabase() 均为逻辑删除，MongoDB 不会擦除底层数据文件；核查是否依赖存储层安全擦除、加密存储后销毁密钥，或第三方擦除工具。
  • 判定标准：
    • 符合：启用存储加密且密钥销毁可控，或存储层有可验证的安全擦除机制。
    • 部分符合：仅依赖 compact/空间回收，未做清除验证。
    • 不符合：仅逻辑删除，无任何清除机制。
  • 证据留存：加密配置与密钥管理说明、擦除验证记录。

b) 应保证存有敏感数据的存储空间被释放或重新分配前得到完全清除

  • 核查要点：同 a) 项，针对存放敏感业务数据与个人信息的数据文件与备份产物（含 mongodump 输出目录）。
  • 判定标准：与 a) 项同口径；备份介质未纳入清除范围时，应判部分符合。
  • 证据留存：敏感数据分布清单、备份介质销毁/清除记录。

个人信息保护

对应控制点：GB/T 22239-2019 8.1.4.11 个人信息保护 a)b)

判定要点：仅采集与保存业务必需字段且有清单与制度支撑、个人信息所在对象有独立授权且实测非授权账户无法访问 → 符合；存在非必要字段但有清理计划，或有授权控制但备份文件未纳入管控 → 部分符合；超范围采集无制度，或非授权账户可直接读取 → 不符合。对象确实不承载个人信息时可判不适用，须先访谈确认并留存反向证据。

取证要求：个人信息字段清单、采集必要性说明与管理制度、权限清单、非授权访问实测记录、访谈纪要。

a) 应仅采集和保存业务必需的用户个人信息

  • 核查要点：核查集合中是否存储个人信息；若存在，索取字段清单与采集必要性说明、个人信息保护管理制度。
  • 判定标准：
    • 符合：仅存储业务必需字段，有清单与制度支撑。
    • 部分符合：存在非必要字段但有清理计划。
    • 不符合：超范围采集且无清单与制度。
  • 证据留存：个人信息字段清单、采集必要性说明、管理制度文件。

b) 应禁止未授权访问和非法使用用户个人信息

  • 核查要点：验证非授权人员（或低权限账号）能否访问存储个人信息的库、集合与备份文件；核查个人信息保护机制的访问控制配置。
  • 判定标准：
    • 符合：个人信息所在库集合有独立授权，实测非授权账户无法访问。
    • 部分符合：有授权控制但备份文件未纳入管控。
    • 不符合：非授权账户可直接读取个人信息。
  • 证据留存：角色与权限清单、非授权访问验证记录、个人信息保护制度。

四、测评项对照表

控制点本文章节关键核查命令/配置
身份鉴别§三 身份鉴别security.authorization、system.users 的 mechanisms、enableLocalhostAuthBypass、net.tls.mode、x.509 用户
访问控制§三 访问控制usersInfo、getRole(showPrivileges)、authenticationRestrictions、自定义角色
安全审计§三 安全审计edition 判定、auditLog（企业版）、auditAuthorizationSuccess、systemLog.verbosity、第三方审计
入侵防范§三 入侵防范listDatabases、net.bindIp / net.port、validator / validationAction、db.version()、上位 IDS/IPS 告警
恶意代码防范§三 恶意代码防范宿主 OS 侧取证（数据库自身不承载）
可信验证§三 可信验证宿主服务器可信根取证
数据完整性§三 数据完整性TLS 模式与明文降级实测、哈希基线比对
数据保密性§三 数据保密性mechanisms 分布、企业版静态加密或应用层/磁盘加密
数据备份恢复§三 数据备份恢复mongodump / mongorestore（副本集加 --oplog）、rs.status()、异地链路
剩余信息保护§三 剩余信息保护存储加密与密钥销毁、擦除验证
个人信息保护§三 个人信息保护字段清单、独立授权与访问验证

五、测评总结

在等保测评检查中会发现 MongoDB 很多都不满足等保的一些控制点的要求，它的功能和 MySQL、Oracle 相比单一不少，等保测评机构提出整改问题后，数据库使用单位加固也是一件比较困难的事，可能需要第三方工具协助才能完整加固整改工作。

需要强调的是：能力缺失不等于可以直接判不适用。社区版缺少的审计与存储加密能力，应通过第三方工具、应用层改造或上位系统补偿来核查；确无补偿措施的，按本文各控制点的判定标准如实定档，并在报告中写明取证来源与理由。

参考依据

关联文章