37、MySQL数据库测评

MySQL 数据库三级等保现场测评：按控制点分节给出账户与权限、validate_password 口令策略、connection_control 登录失败处理、TLS 传输加密、审计日志与备份恢复的核查命令、判定标准与证据留存要求。
Categories:

  5 分钟阅读  

定位：MySQL 数据库作为测评对象的现场核查方法与判定标准，按控制点给出实测判据。 适用版本：MySQL 5.6/5.7/8.0（示例环境 MySQL 5.7.x；8.0 起默认认证插件由 mysql_native_password 改为 caching_sha2_password，且 mysql.user 表结构与字段有调整，现场以实际版本为准）。 配套测评：01、MySQL 测评命令单、12、MySQL 数据库加固；配套加固：12、MySQL数据库加固；高风险口径：22、高风险判定指引与加固对照表。

使用说明：

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

不适用标识说明：

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

一、基础信息

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

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

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

版本与连接核查：

mysql -h 192.168.100.16 -u root -p          # 按实际主机、账号替换

SHOW VARIABLES WHERE Variable_name LIKE 'version';
SHOW VARIABLES LIKE 'version_comment';
  • 备注：同时记录部署形态（单机/主从/集群/云数据库）、端口、运行用户与数据目录。
  • 预期证据：登录成功截图、版本截图、部署拓扑说明。

二、身份鉴别

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

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

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

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

  • 核查要点：

01、登录数据库，确认是否采用「用户名 + 口令」的组合方式鉴别身份。

MySQL 登录认证界面

02、查询用户列表，确认是否存在同名用户（MySQL 的账号由 user + host 二元组唯一确定）。

SELECT user, host FROM mysql.user;

MySQL 用户列表查询结果

03、查询是否存在空口令、口令过期与账户锁定情况。

SELECT user, host, authentication_string, password_lifetime, account_locked FROM mysql.user;

MySQL 口令与账户状态查询结果

04、查询口令复杂度策略（需安装 validate_password 插件，5.7 默认未启用）。

SHOW VARIABLES LIKE 'validate%';

MySQL 口令复杂度策略查询结果

  • 判定标准：
    • 符合：全部账户需口令认证、无空口令与同名账号、启用复杂度策略且配置合理、password_lifetime 设置并定期更换。
    • 部分符合：有复杂度策略但长度/复杂度档位偏低，或有定期更换制度但无更换记录。
    • 不符合：存在空口令账户、validate_password 未启用且存在弱口令，或账号共用无法区分自然人。
  • 证据留存：上述四项查询结果截图、复杂度策略配置、口令更换记录、访谈纪要。

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

  • 核查要点：

01、访谈管理员是否通过其他手段（堡垒机、代理层、OS 层）实现登录失败处理。

02、查看是否安装 connection_control 插件并配置失败处理策略。

SHOW VARIABLES LIKE '%connection_control%';
SHOW VARIABLES LIKE '%max_connect_errors%';

MySQL 连接控制插件查询结果

MySQL max_connect_errors 查询结果

03、查看空闲连接超时与交互超时配置。

SHOW VARIABLES LIKE '%timeout%';

MySQL 超时参数查询结果

  • 判定标准：
    • 符合：安装 connection_control 插件并设置了失败延迟/锁定阈值，且 wait_timeout 非 0（具备空闲超时退出）。
    • 部分符合：仅配置了超时退出，无登录失败处理；或失败处理由堡垒机等旁路实现（须写明补偿措施）。
    • 不符合：插件未安装、超时参数为 0，且无其他补偿措施。
  • 证据留存：上述查询结果截图、插件安装记录、补偿措施配置、访谈纪要。

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

  • 核查要点：

01、确认是否存在远程管理：仅本地管理（bind-address = 127.0.0.1）可判不适用，并注明对象边界。

02、存在远程管理时，查看 SSL 支持情况。

SHOW VARIABLES LIKE '%have_ssl%';
SHOW VARIABLES LIKE '%have_openssl%';

MySQL SSL 支持情况查询结果

  • 判定标准：have_ssl = YES 且实际连接强制使用 SSL（require_secure_transport = ON 或账号级 REQUIRE SSL）判符合； 支持 SSL 但未强制判部分符合；不支持 SSL 且存在远程管理判不符合。
  • 证据留存：SSL 变量截图、账号 REQUIRE 属性截图、远程管理链路说明。

d) 应采用口令、密码技术、生物技术等两种或两种以上组合的鉴别技术对用户进行身份鉴别

  • 核查要点：访谈并验证运维访问 MySQL 的入口是否叠加第二因素（堡垒机二次认证、SSL 客户端证书），实际走一遍完整登录链路。
  • 判定标准：MySQL 原生不支持双因子；未经堡垒机等提供第二因子的通道登录判不符合； 经具备双因子的统一运维审计平台接入判部分符合，并写明第二因子的实现方式。
  • 证据留存：双因子措施说明、登录流程截图、访谈纪要。

原文直接写「对于数据库基本不符合」。该结论可作为初判，但必须先确认无堡垒机/代理层补偿措施， 并在报告中写明已核查的范围；若存在补偿措施应判部分符合。

三、访问控制

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

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

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

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

  • 核查要点：

01、查看账户清单与指定账户的授权。

SELECT user, host FROM mysql.user;
SHOW GRANTS FOR 'root'@'localhost';

MySQL 账户清单查询结果

MySQL 指定账户授权查询结果

02、访谈数据库管理员各账户的用途与权限，核对输出结果与实际人员是否相符。

  • 判定标准：按岗位/人员分别建账户并授予不同权限判符合；多人共用一个账户判不符合。
  • 证据留存：账户清单截图、账户与实际人员对照表、访谈纪要。

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

  • 核查要点：查看 root 是否被删除或重命名；保留 root 时须设置强口令（不得为空口令或弱口令）。
  • 判定标准：已重命名或删除默认账户判符合；保留 root 但已设置强口令且限制 host 范围判部分符合； 保留默认账户且为弱口令/空口令判不符合。
  • 证据留存：SELECT user, host FROM mysql.user; 截图、口令复杂度核查结论。

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

  • 核查要点：逐一核对账户用途与启用/锁定状态，结合人员在职情况识别多余、过期与共享账户。
SELECT user, host, authentication_string, password_lifetime, account_locked FROM mysql.user;

MySQL 账户启用与锁定状态查询结果

  • 判定标准：无多余、过期、共享账户，离职人员账户已停用或删除判符合；存在长期未使用账户判部分符合； 存在共享账户或离职人员仍可登录判不符合。
  • 证据留存：账户状态截图、账户清理记录、在职人员名单对照。

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

  • 核查要点：

01、核查是否按角色划分并仅授予必需权限：除 root 外，任何账户不应对 mysql.user 表具备存取权限， FILE、PROCESS、SUPER 等高危权限不得授予管理员以外的账户。

SELECT * FROM mysql.user;

MySQL 用户表全字段查询结果

02、抽查具体账户，验证是否存在超出其角色的权限（以下以 test 账户为例，现场按实际账户替换）。

SELECT * FROM mysql.user WHERE user = 'test';

MySQL 指定账户权限查询结果

  • 判定标准：按最小权限授权且高危权限仅管理员持有判符合；存在越权账户判不符合。
  • 证据留存：mysql.user 查询结果截图、权限分配表、访谈纪要。

原文此处 WHERE user = "test" 使用双引号。MySQL 在默认 SQL 模式下将双引号内容解析为字符串字面量而非标识符， 虽可返回结果，但属不规范写法；已统一改为单引号。

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

  • 核查要点：

01、访谈管理员是否制定了访问控制策略文件。

02、查看用户级权限列表。

SELECT * FROM mysql.user\G

MySQL 用户权限列表查询结果

03、查看数据库级权限列表。

SELECT * FROM mysql.db;

MySQL 数据库权限列表查询结果

04、查看表级权限列表。

SELECT * FROM mysql.tables_priv;

MySQL 表权限列表查询结果

05、查看列级权限列表。

SELECT * FROM mysql.columns_priv;

MySQL 列权限列表查询结果

06、核对实际权限输出是否与管理员制定的访问控制策略一致。

  • 判定标准：有经授权主体审批的访问控制策略文件，且实际授权与策略一致判符合； 有策略但执行不一致判部分符合；无书面策略判不符合。
  • 证据留存：上述四项权限列表截图、访问控制策略文件、审批记录。

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

  • 核查要点：

01、查看用户级与数据库级权限列表。

SELECT * FROM mysql.user;    -- 检查用户权限列表
SELECT * FROM mysql.db;      -- 检查数据库权限列表

02、访谈管理员并核查：主体是否达到用户级，客体是否达到数据库表级（MySQL 还支持列级，粒度优于要求）。

  • 判定标准：主体为数据库账户级、客体达到表级或更细判符合；仅做到库级判部分符合；整库共用账户判不符合。
  • 证据留存：mysql.user/mysql.db 截图、权限粒度说明。

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

  • 核查要点：核查 MySQL 是否提供主体/客体标记能力（不提供）；确认是否存在应用层或第三方强制访问控制措施并抽查越权访问。
  • 判定标准：MySQL 不提供安全标记能力；由应用层实现标记与访问控制判部分符合并说明边界； 无实现判不符合（三级系统该项通常不符合）。
  • 证据留存：安全标记实现说明或不适用的对象边界说明、访谈纪要。

四、安全审计

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

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

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

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

  • 核查要点：

01、查看通用日志开关（默认 OFF）。

SHOW GLOBAL VARIABLES LIKE '%general%';

MySQL 通用日志开关查询结果

02、访谈管理员是否通过第三方插件（如审计插件、数据库审计系统）采集并分析审计数据。

  • 判定标准：审计覆盖所有用户且包含重要用户行为与安全事件判符合； 仅开启 general_log 或仅采集部分操作判部分符合；无任何审计措施判不符合。
  • 证据留存：日志开关截图、审计系统采集配置截图、审计记录样例、访谈纪要。

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

  • 核查要点：抽取审计记录样例，逐项核对是否包含日期时间、用户、事件类型、成功/失败标识等要素。
  • 判定标准：五类要素齐全判符合；缺少成功/失败标识或用户标识判部分符合；仅有 SQL 语句无用户与时间判不符合。
  • 证据留存：审计记录样例截图、字段说明。

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

  • 核查要点：访谈备份策略并核对留存期限（不少于 6 个月）；若采用第三方审计产品，核对存储期限配置； 检查审计日志的访问权限，确认非授权用户无法删除或修改。
  • 判定标准：权限受限、定期备份且留存 ≥6 个月判符合；留存不足或无备份判部分符合/不符合。
  • 证据留存：备份策略与备份记录、留存期限配置截图、日志文件权限截图。

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

  • 核查要点：MySQL 自带日志随实例运行，一般用户无法单独停止；采用第三方审计产品时， 须核查其采集进程/代理的运行权限与非授权中断的可能性。
  • 判定标准：非授权用户无法停止审计进程判符合；可随意停止且无告警判不符合。
  • 证据留存：审计进程属主与权限截图、停止审计的操作验证记录。

原文「MySQL 数据库系统大多数默认符合」属未经核查的推断。改为上述核查要点后， 结论必须由上机验证结果支撑。

五、入侵防范

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

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

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

原文将 a/b/d/f 四项打包判为不适用。按现行口径逐条给出判定依据，数据库不承载的能力 须写明「由宿主 OS 或上位系统测评」并指向取证来源，现场结论以实际部署为准。

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

  • 核查要点：核查 MySQL 安装方式与已启用的插件（SHOW PLUGINS;），确认未启用与业务无关的组件； 承载 MySQL 的操作系统最小安装由主机侧测评并取回安装清单证据。
  • 判定标准：仅启用业务所需的插件且主机侧已按最小安装 → 符合；存在额外插件但均可说明用途 → 部分符合； 存在无法说明用途的组件/插件 → 不符合。
  • 证据留存：SHOW PLUGINS; 输出、主机侧安装组件清单。

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

  • 核查要点：SHOW VARIABLES LIKE 'port'; 与 SHOW VARIABLES LIKE 'bind_address'; 核查监听端口与地址， 结合主机侧 ss -ntlp 确认 3306 端口来源受限；MySQL 无默认共享概念；主机侧不需要的服务由操作系统测评并取回证据。
  • 判定标准：bind_address 限定管理网段、端口来源受限 → 符合；端口全网开放但已由网络层限制来源 → 部分符合； 端口全网开放且无任何限制 → 不符合。
  • 证据留存：port/bind_address 截图、主机侧端口监听输出、防火墙策略截图。

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

  • 核查要点：对数据库登录地址进行限制，不能允许任意地址登录；应在配置文件或账号的 host 字段限定为本地或指定地址。

MySQL 登录地址限制配置

SELECT user, host FROM mysql.user;    -- host 为 % 表示允许任意地址
  • 判定标准：账号 host 限定为指定管理地址（配合主机防火墙/堡垒机）判符合；存在 host = '%' 的账户判不符合。
  • 证据留存：配置文件相关段落截图、mysql.user 的 host 列截图、防火墙策略截图。

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

  • 核查要点：用 mysql 客户端构造超长/非法 SQL 与特殊字符输入，观察是否正确返回错误而非崩溃； 核查该版本是否存在与 SQL/协议解析相关的已披露 CVE。
  • 判定标准：对非法/越界输入能正确拒绝且无相关未修补漏洞 → 符合；存在相关 CVE 但已修补并记录 → 部分符合； 可构造非法输入导致服务异常 → 不符合。
  • 证据留存：非法输入实测记录、版本与 CVE 检索结论、补丁记录。

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

  • 核查要点：

01、查看当前版本（原文语句使用双引号，已规范为单引号）。

SHOW VARIABLES WHERE Variable_name LIKE 'version';

MySQL 版本查询结果

02、访谈补丁升级机制，并核对是否定期开展漏洞扫描、对高风险漏洞是否在测试评估后修复。

  • 判定标准：有版本台账与补丁机制、漏扫报告显示无未修复高危项判符合； 有漏扫报告但存在未修复高危项判不符合（该类问题通常按高风险项处理）； 无漏扫、无补丁机制判不符合。
  • 证据留存：版本截图、漏扫报告、补丁/升级记录、漏洞修复验证记录。

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

  • 核查要点：MySQL 不承载入侵检测能力，核查上位措施：主机侧 EDR/IDS、网络层 IDS、数据库审计系统的告警规则 是否覆盖 MySQL 进程与 3306 端口，告警是否可达责任人并有处置记录。
  • 判定标准：经主机侧 EDR/IDS 或审计系统实现检测与告警且可达责任人 → 符合；有检测但告警未绑定责任人 → 部分符合；无任何检测与告警 → 不符合。
  • 证据留存：EDR/IDS 或审计系统告警规则与样例、责任人与通知链路说明。

六、数据完整性

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

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

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

a) 应采用校验技术或密码技术保证重要数据在传输过程中的完整性

  • 核查要点：确认是否启用 SSL 进行通信；本地管理可判不适用并写明边界，远程管理须核查是否开启 SSL 并强制使用。

MySQL SSL 配置查询结果

SHOW VARIABLES LIKE '%have_ssl%';
SHOW VARIABLES LIKE 'require_secure_transport';
  • 判定标准：启用 SSL 并强制使用判符合；支持但未强制判部分符合；未启用判不符合。
  • 证据留存：SSL 变量截图、连接加密方式验证记录、远程/本地管理边界说明。

b) 应采用校验技术或密码技术保证重要数据在存储过程中的完整性

  • 核查要点：对数据库配置文件做完整性检测：取初始可信状态的哈希值，与当前文件哈希值比对，确认是否被篡改。 MySQL 自身不带该机制，需访谈是否使用第三方工具（如文件完整性监测、数据库堡垒机）对重要数据做完整性校验。
sha256sum /etc/my.cnf                    # 与初始可信基线哈希值比对
sha256sum /var/lib/mysql/ibdata1
  • 判定标准：有校验机制且定期比对、有比对记录判符合；仅有机制无记录判部分符合；无措施判不符合。
  • 证据留存：哈希基线值、比对记录、第三方工具配置截图、访谈纪要。

七、数据保密性

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

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

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

a) 应采用密码技术保证重要数据在传输过程中的保密性

  • 核查要点：核查 SSL 是否启用并强制（require_secure_transport 或账号级 REQUIRE SSL），必要时抓包确认鉴别数据与查询结果是否明文传输。MySQL 的认证与传输加密特性如下：

  • 5.7 及以前默认使用 mysql_native_password：采用基于 SHA-1 的挑战-响应机制，口令本身不在网络上明文传输， 但查询结果与 SQL 语句仍为明文，且哈希可被重放与离线破解。

  • 8.0 起默认使用 caching_sha2_password：基于 SHA-256，非加密连接下通过 RSA 公钥交换口令，安全性优于前者。

  • 未启用 SSL 时，可通过 Wireshark 抓取认证过程与查询报文，可能还原传输的字段信息。

SHOW VARIABLES LIKE '%have_ssl%';
SHOW VARIABLES LIKE 'require_secure_transport';
SELECT user, host, ssl_type FROM mysql.user;
  • 判定标准：启用 SSL 并强制（require_secure_transport = ON 或账号级 REQUIRE SSL/X509）判符合； 支持未强制判部分符合；未启用且存在远程连接判不符合。
  • 证据留存：SSL 变量与账号 ssl_type 截图、抓包验证结论（如开展）、远程管理链路说明。

原文本节描述的是 PostgreSQL 的 SCRAM-SHA-256 与 MD5 认证机制，与 MySQL 无关，属内容错位，已按 MySQL 实际机制重写。

b) 应采用密码技术保证重要数据在存储过程中的保密性

  • 核查要点：核查重要数据（鉴别数据、重要业务数据、个人信息）在存储时是否加密，密钥与数据是否分离管理。MySQL 提供内置加解密函数：AES 方案 AES_ENCRYPT / AES_DECRYPT，DES 方案 DES_ENCRYPT / DES_DECRYPT。
SELECT AES_ENCRYPT('plaintext', 'key');
SELECT AES_DECRYPT(AES_ENCRYPT('plaintext', 'key'), 'key');
  • 判定标准：重要数据（鉴别数据、重要业务数据、个人信息）在存储时经加密，且密钥与数据分离管理判符合； 仅部分字段加密判部分符合；明文存储判不符合。
  • 证据留存：加密字段清单、加密方案说明、密钥管理制度、加密效果验证截图。

八、数据备份恢复

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

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

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

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

  • 核查要点：访谈备份策略（日备/周备、全备/增备），并索取恢复测试记录。
  • 判定标准：有定期备份且有恢复测试记录判符合；有备份但从未验证恢复判部分符合；无备份判不符合。
  • 证据留存：备份策略文件、备份任务配置截图、备份文件清单、恢复演练记录。

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

  • 核查要点：是否开展异地备份，记录异地备份机房；异地备份是实时（如主从复制）还是定时传输。
  • 判定标准：数据实时或准实时同步至异地判符合；仅本地备份判不符合； 经建设单位确认无异地灾备要求判不适用（须有书面依据）。
  • 证据留存：主从复制状态截图、异地机房说明、备份传输记录。

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

  • 核查要点：云数据库核查是否为高可用版本；自建数据库核查是否部署两台及以上服务器（集群、双机热备均可）。
  • 判定标准：具备自动故障切换的高可用架构判符合；有备机但需人工切换判部分符合；单点部署判不符合。
  • 证据留存：架构拓扑图、高可用配置截图、故障切换演练记录。

九、剩余信息保护

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

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

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

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

  • 核查要点：MySQL 删除用户（DROP USER）后，其在 mysql.user 表中的记录与权限缓存被清除； 需进一步确认磁盘上残留数据（如 binlog、慢日志、备份文件中的历史口令）是否一并清理。
  • 判定标准：账户删除流程完整、历史鉴别信息无残留判符合；仅删账户但日志/备份中仍有残留判部分符合。
  • 证据留存：账户删除操作记录、日志与备份清理说明。

原文「默认符合」属未核查的推断。删除操作是否真正清除需上机验证，不能直接默认。

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

  • 核查要点：DROP TABLE / DELETE 后，数据在 InnoDB 表空间与 binlog 中仍可能存在； 需确认是否有表空间重建、binlog 清理等处理。
  • 判定标准：同 §九 a）。
  • 证据留存：数据销毁流程说明、binlog 与备份清理记录。

十、个人信息保护

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

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

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

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

  • 核查要点：检查库中是否存储个人信息；若存在，核查个人信息保护机制与管理制度。
  • 判定标准：仅存储业务必需字段且有清单与制度判符合；存在非必要字段判不符合。
  • 证据留存：个人信息字段清单、采集必要性说明、管理制度文件。

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

  • 核查要点：验证非授权人员是否能访问存储个人信息的相关组件（库、表、备份文件）。
  • 判定标准：对个人信息所在库表有独立授权且验证无法通过非授权账户访问判符合；可访问判不符合。
  • 证据留存：权限清单、非授权访问验证记录、个人信息保护制度。

测评项对照表

控制点本文章节关键核查命令/配置
身份鉴别§二mysql.user 的 authentication_string/account_locked、validate_password、connection_control
访问控制§三mysql.user/db/tables_priv/columns_priv 四级权限表
安全审计§四general_log、审计插件或旁路审计系统，留存 ≥6 个月
入侵防范§五账号 host 范围、版本与补丁台账、漏扫报告
数据完整性§六SSL 启用情况、配置文件哈希基线比对
数据保密性§七require_secure_transport、账号 ssl_type、AES_ENCRYPT
数据备份恢复§八备份策略、恢复测试记录、主从复制、高可用架构
剩余信息保护§九账户与敏感数据删除后的残留清理（含 binlog、备份）
个人信息保护§十个人信息字段清单、独立授权与访问验证

参考依据

关联文章