28、MariaDB数据库测评

MariaDB 数据库三级等保现场测评：账户与权限、password_validation 口令策略、server_audit 审计插件、TLS 传输加密与备份恢复的核查命令、判定标准、与 MySQL 的关键差异及证据留存要求。
Categories:

  7 分钟阅读  

定位：MariaDB 数据库作为测评对象的现场核查方法与判定标准，按控制点给出实测判据（示例环境 Windows 10 + MariaDB 10.8.3）。 适用版本：MariaDB 10.4~11.x。 配套测评：01、MySQL 测评命令单（MariaDB 与 MySQL 命令同源，差异以本文为准）；配套加固：12、MySQL数据库加固；高风险口径：22、高风险判定指引与加固对照表。

使用说明：

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

不适用标识说明：

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

一、MariaDB 介绍

MariaDB 数据库管理系统是 MySQL 的一个分支，是同一 MySQL 版本的二进制替代品，主要由开源社区维护，采用 GPL 授权许可。

二、基础信息

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

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

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

版本与账号体系核查（后续所有控制点判定的前置）：

SELECT VERSION();
SHOW VARIABLES WHERE Variable_name LIKE '%version%';
SELECT user, host, plugin FROM mysql.user;   -- 10.4 起权限数据实际存于 mysql.global_priv，mysql.user 为兼容视图

grep -nE "bind-address|skip-networking|plugin-load|plugin_load" /etc/mysql/my.cnf /etc/my.cnf.d/*.cnf 2>/dev/null
  • 备注：优先确认版本、运行平台、监听地址、已加载插件、账号体系（mysql.user 视图 vs mysql.global_priv），Windows 环境对应 my.ini。
  • 预期证据：版本截图、配置文件关键段落截图、账号清单截图。

MariaDB 版本与配置核查界面对照

三、测评实施

身份鉴别

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

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

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

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

  • 核查要点：
    1. 不带口令直接执行 mysql，确认是否强制身份鉴别（能直连进入即未启用鉴别）。
    2. 查账号唯一性：MariaDB 账号由 user + host 二元组唯一确定，核查是否存在 host 为 % 的通配账号导致无法区分自然人。
    3. 查空口令与认证插件：SELECT user, host, plugin, authentication_string FROM mysql.user;。注意 plugin 为 unix_socket 时认证不依赖口令，须结合 host 判定，不能只看 authentication_string 为空就认定「无口令」。
    4. 查复杂度策略：SHOW VARIABLES LIKE 'simple_password_check%';、SHOW VARIABLES LIKE 'cracklib%';；未安装时执行 INSTALL SONAME 'simple_password_check'; 后再查。
    5. 查定期更换：SELECT @@global.default_password_lifetime;（默认 0，即不自动过期），并 SHOW CREATE USER '用户'@'主机'; 看是否带 PASSWORD EXPIRE INTERVAL n DAY。
    6. 实测：建弱口令账户，验证复杂度策略是否真正生效。
  • 判定标准：
    • 符合：全部账户需口令认证、无空口令、账号可唯一对应自然人、复杂度插件已启用且参数合理（长度 ≥8 且要求字符种类）、口令有效期已配置且有更换记录。
    • 部分符合：启用复杂度但档位偏低（仅校验长度、不校验字符种类）；或有定期更换制度但无更换记录，仅靠人工约定。
    • 不符合：可免认证直连、存在空口令或共享账号、复杂度插件未启用且实测可建弱口令账号。
  • 常见不符合项：把 unix_socket 插件账号的 authentication_string 为空误判为「空口令」；只装插件不设参数（simple_password_check_* 未配置）就判符合。
  • 证据留存：登录验证截图、mysql.user 清单（含 plugin 列）、复杂度变量输出、default_password_lifetime 与 SHOW CREATE USER 输出、弱口令实测结果、访谈纪要。

MariaDB 免认证直连核查界面对照

MariaDB 强制身份鉴别提示界面对照

MariaDB 口令策略配置文件界面对照

MariaDB 口令复杂度策略查询结果界面对照

口令策略插件未安装时（Windows 后缀 .dll，Linux 后缀 .so）：

INSTALL SONAME 'simple_password_check';
SET GLOBAL simple_password_check_minimal_length = 8;
SET GLOBAL simple_password_check_letters_same_case = 1;
SET GLOBAL simple_password_check_other_characters = 1;

试建弱口令账户验证策略生效（应被拒绝）：

CREATE USER 'test1'@'localhost' IDENTIFIED BY '123456';

MariaDB 弱口令账户创建实测界面对照

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

  • 核查要点：
    1. 会话超时：SHOW VARIABLES LIKE '%timeout%';，关注 wait_timeout / interactive_timeout（空闲会话自动断开，默认 28800 秒）与 connect_timeout。
    2. 账户锁定状态：SELECT CONCAT(user, '@', host) FROM mysql.global_priv WHERE Priv LIKE '%account_locked%true%';。
    3. 确认是否存在「失败次数阈值 → 自动锁定」：MariaDB 官方 Account Locking 提供的是 ALTER USER ... ACCOUNT LOCK/UNLOCK 的手工锁定能力；若未引入 PAM/第三方插件或外部设备，则不存在自动失败锁定。须向管理员确认替代措施（OS 层 fail2ban、堡垒机、数据库代理限流）并取证。
  • 判定标准：
    • 符合：具备失败次数阈值并自动锁定（或由前置设备实现且可演示），且空闲超时、连接超时已配置并生效。
    • 部分符合：仅有超时退出而无失败锁定；或失败锁定由外部设备实现但无法演示、无策略文档。
    • 不符合：既无失败锁定也未配置超时（保持默认 8 小时空闲不退出），且无外部替代措施。
  • 常见不符合项：把 max_connect_errors（主机级连通错误计数，用于防主机被屏蔽）当作「用户登录失败锁定」；只看配置文件写了参数而未验证会话是否真被断开。
  • 证据留存：超时变量输出、账户锁定状态查询、替代措施配置（fail2ban jail 配置或堡垒机策略）、访谈纪要。

MariaDB 会话超时变量查询结果界面对照

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

  • 核查要点：
    1. 是否存在远程管理：核查账号 host 是否全为 localhost / 127.0.0.1，以及 bind-address / skip-networking 配置。
    2. 服务端 TLS：SHOW VARIABLES LIKE 'have_ssl';、SHOW VARIABLES LIKE 'ssl_%';（关注 ssl_cert / ssl_key / ssl_ca）。
    3. 会话是否真正加密：SHOW STATUS LIKE 'Ssl_cipher';（有值表示当前连接走 TLS），必要时用 Wireshark 抓包验证。
    4. 账号级强制：SHOW CREATE USER '用户'@'主机'; 看是否带 REQUIRE SSL / REQUIRE X509。
  • 判定标准：
    • 不适用：账号 host 全为 localhost 且实例仅监听本地（bind-address=127.0.0.1 或 skip-networking），需在报告中写明「不存在远程管理」的依据。
    • 符合：启用 TLS 且会话实测加密、账号带 REQUIRE SSL 无法降级。
    • 部分符合：服务端已配证书但账号未强制 TLS，普通客户端可用明文连接。
    • 不符合：远程管理全程明文。
  • 常见不符合项：仅凭 have_ssl=YES 判符合，未验证客户端会话是否真正加密。
  • 证据留存：Ssl_cipher 输出、SHOW CREATE USER 中的 REQUIRE 子句、抓包结果、bind-address 配置。

MariaDB SSL 支持变量查询结果界面对照

MariaDB 会话 TLS 状态查询结果界面对照

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

  • 核查要点：访谈并验证是否采用双因子。MariaDB 原生支持客户端证书鉴别（REQUIRE X509 / REQUIRE SUBJECT / REQUIRE ISSUER），证书属密码技术类第二因子；也可由堡垒机、统一认证平台承载。
  • 判定标准：
    • 符合：口令 + 客户端证书（或经堡垒机/统一认证实现双因子）且可现场演示。
    • 部分符合：双因子由外部平台实现，但未见配置或无法演示。
    • 不符合：仅口令单一因子。
  • 证据留存：SHOW CREATE USER 的 REQUIRE 子句、证书清单与有效期、双因子登录演示截图。

访问控制

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

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

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

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

  • 核查要点：SELECT user, host, plugin FROM mysql.user; 查账号；SHOW GRANTS FOR '用户'@'主机'; 与 SELECT * FROM mysql.db; 查授权；访谈确认是否设立系统管理员、安全管理员、审计管理员并分别授权。
  • 判定标准：
    • 符合：每名管理员有独立账号、权限按职责分配、可对应到自然人。
    • 部分符合：有独立账号但同时存在一个共用的 DBA 超级账号。
    • 不符合：全部共用 root 或同一账号，无法区分自然人。
  • 证据留存：账号清单、各账号授权输出、三员对照表、访谈纪要。

MariaDB 用户清单查询结果界面对照

MariaDB 用户授权查询结果界面对照

MariaDB 库级权限查询结果界面对照

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

  • 核查要点：核查 root@localhost 是否重命名、锁定或已限制来源；SELECT user, host, JSON_EXTRACT(Priv, '$.account_locked') FROM mysql.global_priv; 查锁定状态。
  • 判定标准：
    • 符合：默认账户已重命名/删除，或已锁定且实测无法登录，无其他可登录默认账户。
    • 部分符合：保留 root 名称但已设强口令并限定来源。
    • 不符合：保留默认名称且弱口令或可从任意来源登录（高风险线索，须对照 22 号高风险判定指引）。
  • 常见不符合项：把 MariaDB 内置的 mariadb.sys / mysql.sys（默认 account_locked: true，为系统内部账户）误记为「未处理的默认账户」。
  • 证据留存：账号清单（含锁定状态）、默认账户处理证明、登录实测截图。

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

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

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

  • 核查要点：SHOW GRANTS FOR '用户'@'主机'; 与 SELECT * FROM mysql.user WHERE user='XXX'; 核查是否存在 ALL PRIVILEGES ON *.* 的超级账号；查角色划分（MariaDB 10.0.5+ 支持 CREATE ROLE / GRANT 角色）。
  • 判定标准：
    • 符合：管理用户仅授予必需权限，系统管理、安全管理、审计管理三类角色齐备且互不兼任。
    • 部分符合：有角色划分，但仍存在越权的超级账号或角色兼任。
    • 不符合：所有运维账号均为 ALL PRIVILEGES ON *.*，无权限分离。
  • 证据留存：各账号授权输出、角色清单与成员对照、权限分离说明。

MariaDB 指定用户权限查询结果界面对照

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

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

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

  • 核查要点：SHOW GRANTS FOR '用户'@'主机'; 确认授权粒度是否到 库.表；查 mysql.tables_priv / mysql.columns_priv 确认是否存在表级/列级授权。
  • 判定标准：
    • 符合：授权按用户分别授予且可精确到表级（重要数据到列级）。
    • 部分符合：授权仅到库级，但库内数据敏感度相当。
    • 不符合：统一使用 ON *.*，无法区分客体。
  • 注意：该项不应「默认判符合」，须以实际授权语句为据。
  • 证据留存：授权语句输出、tables_priv / columns_priv 查询截图。

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

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

安全审计

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

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

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

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

  • 核查要点：
    1. SHOW GLOBAL VARIABLES LIKE 'server_audit%';，关注 server_audit_logging（总开关）、server_audit_events（记录的事件类型）、server_audit_excl_users（排除用户，配置不当会导致审计不覆盖每个用户）、server_audit_output_type、server_audit_file_path。
    2. 未安装审计插件时（Windows 后缀 .dll，Linux 后缀 .so）按需安装并开启。
    3. 访谈并取证是否部署第三方数据库审计系统集中采集。
  • 判定标准：
    • 符合：审计总开关已开启、事件类型覆盖登录与关键操作、server_audit_excl_users 未排除实际使用账号、日志可检索。
    • 部分符合：已开启但事件类型不全，或排除了部分账号，或仅本地文件未集中采集。
    • 不符合：未开启审计且无第三方审计措施。
  • 常见不符合项：为降低性能把应用账号写入 server_audit_excl_users，导致审计覆盖不到业务操作。
  • 证据留存：server_audit_* 变量输出、审计日志文件清单与抽样内容、第三方审计系统截图。

MariaDB 审计插件变量查询结果界面对照

INSTALL SONAME 'server_audit';          -- 或 INSTALL PLUGIN server_audit SONAME 'server_audit.dll';
SET GLOBAL server_audit_logging = ON;
SET GLOBAL server_audit_events = 'CONNECT,QUERY,TABLE';
FLUSH PRIVILEGES;

MariaDB 审计日志记录内容界面对照

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

  • 核查要点：抽样审计记录，核对是否含日期时间、用户（含来源主机）、事件类型、事件结果（成功/失败）。MariaDB 审计插件记录含 timestamp、serverhost、username、host、connectionid、operation、database、object、retcode 等字段。
  • 判定标准：
    • 符合：日期时间、用户、事件类型、事件结果四要素齐全。
    • 部分符合：缺来源主机或事件结果，但可与其他日志（系统日志、堡垒机日志）关联补齐。
    • 不符合：仅有查询内容、无时间或无法区分成功/失败。
  • 证据留存：审计记录抽样（脱敏后）、字段与等保要素对照说明。

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

  • 核查要点：审计文件的属主与权限（OS 层 ls -l）；用普通账号实测能否读取、修改、删除；核查转存/备份策略与留存期是否 ≥6 个月；注意 server_audit_file_rotate_size / server_audit_file_rotations 是循环覆盖参数，不等于留存期。
  • 判定标准：
    • 符合：权限受限（仅审计管理员可读）、有转存或备份、留存 ≥6 个月。
    • 部分符合：仅本地循环覆盖，但轮数与容量可满足 6 个月留存且未被清理。
    • 不符合：普通账号可删除审计文件，或无备份且留存不足 6 个月。
  • 常见不符合项：把 server_audit_file_rotations 的轮数直接当作留存期证据。
  • 证据留存：文件权限截图、转存任务配置、留存清单（含最早文件时间戳）、越权删除实测结果。

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

  • 核查要点：确认哪些账号持有可关闭审计的权限（可执行 SET GLOBAL server_audit_logging=OFF 的 SUPER 权限），核查该权限是否仅授予审计管理员；核查应用账号是否持 SUPER。
  • 判定标准：
    • 符合：仅审计管理员可变更审计配置，普通与账号无法停止审计进程。
    • 部分符合：DBA 兼任审计管理权限，但无应用账号持 SUPER。
    • 不符合：应用或运维账号可直接关闭审计。
  • 证据留存：持 SUPER 权限账号清单、权限分离说明、实测关闭审计的结果。

入侵防范

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

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

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

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

  • 核查要点：SHOW PLUGINS; 与 SHOW ENGINES; 核查是否加载了未使用的插件与存储引擎；查是否存在示例库（如 test）。数据库软件本体的「组件安装」通常由部署方在 OS 侧完成，测评单元若仅含数据库实例，应注明并转由 OS 侧测评。
  • 判定标准：
    • 符合：仅启用必要的插件与存储引擎，无示例库。
    • 部分符合：存在未使用的插件/引擎但未启用，或保留示例库。
    • 不符合：加载了与业务无关的插件且处于启用状态。
  • 注意：不得仅写「数据库此项不适用」而不说明理由。
  • 证据留存：SHOW PLUGINS / SHOW ENGINES 输出、库清单截图。

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

  • 核查要点：SHOW VARIABLES LIKE 'port'; 与 bind-address 配置，OS 层 netstat -ano / ss -lntp 查监听；确认 3306 是否对全网开放，有无防火墙或 ACL 限制。
  • 判定标准：
    • 符合：仅监听必要地址，非必要服务已关闭。
    • 部分符合：监听 0.0.0.0 但有防火墙/ACL 限制（须取得边界策略证据，属补偿控制）。
    • 不符合：数据库端口无任何限制开放且可从办公网/互联网直达。
  • 注意：端口与网络服务属数据库可承载项，不宜直接判不适用。
  • 证据留存：监听端口输出、bind-address 配置、边界访问控制策略截图。

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

  • 核查要点：SELECT user, host FROM mysql.user; 查各账号来源限制（不应为 %）；SHOW GRANTS FOR 'root'@'localhost';；bind-address 与网络层 ACL。
  • 判定标准：
    • 符合：所有账号 host 限定为具体地址或有限网段。
    • 部分符合：部分账号为 %，但有边界防护或堡垒机统一入口。
    • 不符合：root@% 等可从任意地址登录的账号存在。
  • 证据留存：账号 host 清单、边界策略截图。

MariaDB 账号来源限制查询结果界面对照

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

  • 核查要点：数据库侧对应约束机制——字段类型、NOT NULL、CHECK 约束、外键、触发器，以及 sql_mode 是否含 STRICT_TRANS_TABLES（严格模式，非法数据会被拒绝）；若校验由应用层实现，须验证其有效性。
  • 判定标准：
    • 符合：关键字段有数据库约束或严格模式，或应用层校验经验证有效。
    • 部分符合：仅依赖应用层校验但未做验证测试。
    • 不符合：无校验且实测可写入超出设定范围的数据。
  • 注意：只有当应用层完全不在本次测评单元范围内时，才可注明「本组件不承载，由应用侧测评」，不得机械判不适用。
  • 证据留存：SHOW CREATE TABLE 输出、sql_mode 值、非法数据写入实测结果。

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

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

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

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

恶意代码防范

对应控制点：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) 应采用密码技术保证重要数据在传输过程中的完整性，包括但不限于鉴别数据、重要业务数据、重要审计数据、重要配置数据、重要视频数据和重要个人信息等

  • 核查要点：核查是否启用 TLS（SHOW STATUS LIKE 'Ssl_cipher'; 有值表示当前会话加密）；TLS 协议自带完整性保护（AEAD 或 HMAC）。
  • 判定标准：
    • 不适用：管理全在本地（账号 host 全为 localhost 且仅本地监听），需在报告写明依据。
    • 符合：远程管理全程 TLS，且账号强制 REQUIRE SSL。
    • 部分符合：支持 TLS 但允许明文降级。
    • 不符合：远程管理明文传输。
  • 证据留存：Ssl_cipher 输出、SHOW CREATE USER 的 REQUIRE 子句。

MariaDB 传输加密配置核查界面对照

MariaDB 会话加密状态核查界面对照

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

  • 核查要点：核查是否存在第三方完整性保护（配置文件哈希基线、业务表哈希/MAC 校验字段、主机级文件完整性监控）及定期比对记录；MariaDB 自身不提供存储完整性保护。
  • 判定标准：
    • 符合：重要数据与配置文件均有完整性校验机制并定期比对。
    • 部分符合：仅配置文件有哈希基线，业务数据无校验。
    • 不符合：无任何完整性校验措施。
  • 常见不符合项：把 InnoDB 的页校验和（checksum）当作防篡改机制——它仅用于检出磁盘或页损坏，不能防篡改；原稿「一般做不到，判定为不符合」属无核查依据的推断，应以上述核查结论定档。
  • 证据留存：哈希基线清单、比对记录、第三方工具说明。

数据保密性

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

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

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

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

  • 核查要点：在未启用 TLS 时用 Wireshark 抓取认证过程，验证鉴别数据是否明文；核查 Ssl_cipher 与账号 REQUIRE 子句。
  • 判定标准：
    • 不适用：不存在远程管理（依据同数据完整性 a)）。
    • 符合：远程管理全程 TLS 且抓包无法还原明文口令。
    • 部分符合：支持 TLS 但允许明文降级，抓包可获明文。
    • 不符合：远程管理明文传输且抓包可还原鉴别数据。
  • 证据留存：抓包结果（脱敏后）、Ssl_cipher 输出。

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

  • 核查要点：
    1. 鉴别数据：MariaDB 以 mysql_native_password（口令的 SHA-1 双重哈希）或 ed25519 存储，非明文；核查 plugin 列确认未使用弱算法。
    2. 业务与个人信息：抽查表中敏感字段是否明文存储，是否启用库内加密（file_key_management 插件 + innodb_encrypt_tables）或库外加密（第三方加密网关/应用层字段加密）。
  • 判定标准：
    • 符合：鉴别数据非明文存储，且重要业务数据、个人信息字段加密存储。
    • 部分符合：仅鉴别数据非明文，业务与个人信息明文存储。
    • 不符合：鉴别数据明文或可通过弱哈希批量还原。
  • 注意：MariaDB 的 Data-at-Rest Encryption 防的是磁盘丢失与文件被复制，对已控制数据库实例的攻击者不提供防护；密钥若与实例同机存放，防护能力有限，报告中应如实描述。
  • 说明：原稿此处混入 PostgreSQL 的 SCRAM-SHA-256 与 MD5 认证机制说明，与 MariaDB 无关，已按 MariaDB 实际的 mysql_native_password / ed25519 口径更正。
  • 证据留存：mysql.user 的 plugin 分布、敏感字段抽样、加密配置与密钥管理说明。

数据备份恢复

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

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

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

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

  • 核查要点：访谈并查看备份策略与执行记录（crontab、备份脚本、备份目录清单），核对备份产物与策略是否一致，是否有恢复测试记录。备份命令为 mariadb-dump（旧版 mysqldump）：
mariadb-dump -u root -p --all-databases > backup.sql      # 全库备份
mariadb-dump -u root -p --single-transaction --routines --triggers dbname > dbname.sql
mysql -u root -p < backup.sql                              # 恢复（回放 SQL）
  • 备注：也可使用 Navicat 等图形工具按库备份；恢复即回放 SQL。备份文件与数据库同机存放时，主机故障会导致备份同时失效，属常见部分符合点。
  • 判定标准：
    • 符合：有备份任务配置、近期备份产物，且有恢复演练记录。
    • 部分符合：有备份任务与产物，但从未验证可恢复。
    • 不符合：无备份措施。
  • 证据留存：备份任务配置截图、备份产物列表（含时间戳）、恢复演练记录。

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

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

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

  • 核查要点：访谈并核查是否采用 Galera Cluster 多主集群、主从复制 + 故障切换、或宿主层高可用（虚拟化 HA、负载均衡健康检查）。
  • 判定标准：
    • 符合：具备集群/双机/主从容错任一形态且可演示切换。
    • 部分符合：有冗余架构但无切换演练记录。
    • 不符合：单点运行。
  • 证据留存：集群状态输出、冗余架构说明、切换演练记录。

剩余信息保护

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

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

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

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

  • 核查要点：核查 mysql.global_priv 等存放鉴别信息的空间在删除账户后是否被清除；数据库层面的 DELETE/DROP USER 仅做逻辑删除，空间可被复用，实际清除依赖存储层（加密存储后销毁密钥、磁盘安全擦除、第三方擦除工具）。
  • 判定标准：
    • 符合：启用存储加密且密钥销毁可控，或存储层有可验证的安全擦除机制。
    • 部分符合：仅依赖定期整理（OPTIMIZE TABLE）回收空间，未做清除验证。
    • 不符合：仅逻辑删除，无任何清除机制。
  • 证据留存：加密配置与密钥管理说明、擦除验证记录。

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

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

个人信息保护

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

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

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

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

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

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

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

四、测评项对照表

控制点本文章节关键核查命令/配置
身份鉴别§三 身份鉴别mysql.user 的 plugin/authentication_string、simple_password_check、default_password_lifetime、wait_timeout、have_ssl、REQUIRE X509
访问控制§三 访问控制mysql.user/db/tables_priv/columns_priv、SHOW GRANTS、CREATE ROLE
安全审计§三 安全审计server_audit_logging/server_audit_events/server_audit_excl_users、审计文件权限与转存
入侵防范§三 入侵防范SHOW PLUGINS/SHOW ENGINES、bind-address、账号 host、sql_mode、SELECT VERSION()、上位 IDS/IPS 告警
恶意代码防范§三 恶意代码防范宿主 OS 侧取证（数据库自身不承载）
可信验证§三 可信验证宿主服务器可信根取证
数据完整性§三 数据完整性Ssl_cipher、哈希基线比对
数据保密性§三 数据保密性plugin 分布、file_key_management + innodb_encrypt_tables
数据备份恢复§三 数据备份恢复mariadb-dump、备份策略与产物、异地链路、集群状态
剩余信息保护§三 剩余信息保护存储加密与密钥销毁、擦除验证
个人信息保护§三 个人信息保护字段清单、独立授权与访问验证

五、测评总结

在等保测评检查中会发现 MariaDB 数据库大部分配置都可以实现，但是在实际测评过程中很多单位不愿意配置等保中要求的策略，一方面是管理员认为不方便自己运维管理，另一方面可能是数据库在实时生产环境中，管理员担心更改相关安全配置后影响系统的正常运行，所以我们在测评中要做好安全和生产、安全和管理的平衡。

需要强调的是：上述「不愿意配置」不构成判定理由。核定结论时仍须以本文各控制点的核查要点与判定标准为准，未核查到的项应记为「未核查」而非默认符合或默认不符合。

参考依据

关联文章