22、应用访问控制测评解读（MySQL 示例）

GB/T 22239-2019 8.1.4.2 访问控制 a)~g) 七项要求的逐条解读：以 MySQL 为例说明每项的核查方法、判定标准、常见误判与报告备注写法，并给出判定标准汇总表。
Categories:

  3 分钟阅读  

定位：理解解读类文章——说明 MySQL 访问控制控制点七项要求的含义、MySQL 权限模型的实现原理，以及现场如何取证与判定。 适用版本：MySQL 5.6/5.7/8.0（示例环境 MySQL 5.7.x；8.0 起 mysql.user 表结构与认证插件有调整，权限层级模型一致）。 配套文章：37、MySQL 数据库测评（全控制点核查命令与判定标准）、01、MySQL 测评命令单、12、MySQL数据库加固。

使用说明：

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

不适用标识说明：

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

一、说明

访问控制是等保测评中分歧最多、也最容易判错的控制点之一。分歧通常不在「有没有配权限」， 而在「配到什么程度算符合」。本文按 a)~g) 七项要求逐一说明其含义、MySQL 的实现方式， 以及现场应取哪些证据。

二、访问控制七项要求

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

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

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

项要求核心问题
a应对登录的用户分配账户和权限是否按人/按岗建账户，且账户权限有差异
b应重命名或删除默认账户，修改默认账户的默认口令默认 root 如何处理，口令是否为强口令
c应及时删除或停用多余的、过期的账户，避免共享账户的存在是否存在多余、过期、共用账户
d应授予管理用户所需的最小权限，实现管理用户的权限分离权限是否按最小必要分配、是否三权分离
e应由授权主体配置访问控制策略，访问策略规定主体对客体的访问规则是否有经授权的策略文件，且实际授权与之一致
f访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级客体粒度是否达到表级或更细
g应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问MySQL 原生不支持，由谁承担

三、测评项 a：应对登录的用户分配账户和权限

3.1 要求理解

该要求容易被读成一句废话——既然用户已经登录，自然存在账户。其实际含义是：

  1. 系统中应存在多个账户；
  2. 按实际需要把不同权限的账户分配给使用者（自然人）；
  3. 通过「账户 → 权限 → 自然人」的链路实现权限分配。

因此该测评项的落脚点是：数据库中至少存在两个账户，且这两个账户的权限不同。

MySQL 访问控制测评实施要求

3.2 MySQL 的默认账户

MySQL 安装完成后默认存在 3 个账户，用户名均为 root：

MySQL 默认 root 账户查询结果

暂不论其中是否存在多余账户：root 通常作为超级管理员使用，默认拥有全部全局权限， 一般不对 root 的权限做限制。全局权限存储在 mysql.user 表中，以权限列的形式存在：

MySQL user 表权限列

3.3 核查方法与判定标准

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

  • 符合：按岗位/人员分别建账户，各账户权限不同，且可对应到具体自然人。

  • 部分符合：存在多个账户但权限划分粗糙（如仅有「管理员」与「应用」两类），或存在少量共用账户。

  • 不符合：所有使用者共用一个账户（通常是一个 root 或应用账户），权限无差异。

  • 证据留存：mysql.user 查询结果截图、账户与人员对照表、各账户 SHOW GRANTS 输出、访谈纪要。

四、测评项 b：应重命名或删除默认账户，修改默认账户的默认口令

4.1 要求理解

root 的用户名可以修改，但数据库通常与业务耦合较深，改名会影响业务连接串。 因此从实操角度：

  • 建议修改 root 用户名，不强制；
  • 若未改名也未禁用，则必须保证 root 使用的是强口令（MySQL 安装时会生成一个随机初始口令， 但现场常见的情况是被改成了弱口令或被清空）。

4.2 核查方法与判定标准

SELECT user, host, authentication_string FROM mysql.user;
SHOW VARIABLES LIKE 'validate%';

  • 符合：已重命名或删除默认账户；或保留 root 但已设置强口令且限制 host 范围。

  • 部分符合：保留 root 且口令强度尚可，但 host 为 %（允许任意地址）。

  • 不符合：默认账户存在且为空口令、弱口令，或沿用安装时的初始随机口令未更换。

  • 证据留存：mysql.user 查询结果截图、口令复杂度核查结论、访谈纪要。

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

5.1 要求理解

默认账户（多个 root）通常就构成多余账户：

MySQL 多余账户查询结果

MySQL 中账户的身份标识为 user + host 二元组，且并不禁止出现实际等价的重复行。 上例中三个账户的 user 都是 root，host 表面不同但实际都指向本机：

  • 127.0.0.1：本地回环地址；
  • localhost：经 hosts 文件映射到 127.0.0.1；
  • ::1：IPv6 格式的本地地址。

从正常业务需求看，这三个账户的身份标识不唯一，应删除 ::1 与其余重复项中的多余部分。 非默认账户是否为多余账户，则通过访谈或权限查询判断。

5.2 核查方法与判定标准

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

  • 符合：无多余、过期、共享账户；离职人员账户已停用或删除。

  • 部分符合：存在长期未使用但未停用的账户。

  • 不符合：存在共享账户，或离职人员仍保留可用账户。

  • 证据留存：mysql.user 查询结果截图、账户清理记录、在职人员名单对照。

六、测评项 d：应授予管理用户所需的最小权限，实现管理用户的权限分离

6.1 MySQL 的权限结构

MySQL 的权限分多个层级，分别存储在不同的系统表中：

层级存储表说明
全局权限mysql.user作用于所有数据库
数据库级mysql.db作用于指定数据库
表级mysql.tables_priv作用于指定表
列级mysql.columns_priv作用于指定列

权限判定过程：客户端通过身份认证后发送操作命令，服务器按下述顺序逐级检查—— 先查 user 表（全局权限），未授权则查 db 表（数据库级），再查 tables_priv（表级）， 最后查 columns_priv（列级）；全部检查完毕仍未找到允许的权限，则返回错误、操作失败。

MySQL 权限判定过程示意

查询某用户的权限有两种方式：直接查上述权限表，或使用 SHOW GRANTS（会把各表中的权限汇总列出）：

SHOW GRANTS FOR 'dba'@'localhost';
SELECT * FROM mysql.user WHERE user = 'dba';

+---------------------------------------------------------------------------------------------+
| Grants for dba@localhost                                                                    |
+---------------------------------------------------------------------------------------------+
| GRANT RELOAD, SUPER, REPLICATION CLIENT ON *.* TO 'dba'@'localhost'                         |
| GRANT CREATE TEMPORARY TABLES ON `mysql`.* TO 'dba'@'localhost'                             |
| GRANT SELECT, INSERT, UPDATE, CREATE, DROP ON `mysql`.`backup_history` TO 'dba'@'localhost' |
| GRANT INSERT, UPDATE, CREATE, DROP ON `mysql`.`ibbackup_binlog_maker` TO 'dba'@'localhost'  |
| GRANT INSERT, UPDATE, CREATE, DROP ON `mysql`.`backup_progress` TO 'dba'@'localhost'        |
+---------------------------------------------------------------------------------------------+

其中第一行为全局权限，第二行为 mysql 库级权限，第三至五行为表级权限。

两种查询方式的对照：

MySQL 两种权限查询方式对照

6.2 判定要求

是否判符合，需结合应用程序的业务复杂程度判断：业务越复杂、越庞大，数据库账户的权限就应划分得越细致。

可以确定的下限是：所有场景都使用同一个 root 账户，必然判不符合。

MySQL 权限划分参考

6.3 核查方法与判定标准

SELECT * FROM mysql.user;
SELECT user, host FROM mysql.user WHERE Super_priv = 'Y' OR File_priv = 'Y' OR Process_priv = 'Y';

  • 符合：按最小权限授权，且 FILE、PROCESS、SUPER 等高危权限仅管理员持有，实现三权分离。

  • 部分符合：做了权限划分但粒度较粗，或高危权限授予了非管理员账户但无实际危害。

  • 不符合：全部使用同一高权限账户，或存在明显越权账户。

  • 证据留存：mysql.user 查询结果截图、高危权限持有者清单、权限分配表、访谈纪要。

七、测评项 e：应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则

7.1 要求理解

「授权主体」在数据库中即拥有授予他人权限能力的账户，对应 mysql.user、mysql.db 表中的 Grant_priv 字段。授予权限时附加 WITH GRANT OPTION，即表示该账户可将自己获得的权限再授予他人 （本质上是同时修改了 Grant_priv 字段）：

GRANT ALL ON *.* TO 'test'@'192.168.1.20' IDENTIFIED BY '<password>' WITH GRANT OPTION;
FLUSH PRIVILEGES;

执行后该账户的 Grant_priv 为 Y。

⚠️ 原文示例中使用的是中文弯引号 ’（从网页/文档复制粘贴带入），直接执行会报语法错误。 现场所有 SQL 均须使用英文半角单引号 '，这是 MySQL 测评中最常见的低级失误之一。

7.2 核查方法与判定标准

SELECT user, host, Grant_priv FROM mysql.user WHERE Grant_priv = 'Y';

  • 符合：存在明确的授权主体（通常为安全管理员），且有经其审批的访问控制策略文件，实际授权与策略一致。

  • 部分符合：有授权主体但无书面策略，或策略与实际情况存在偏差。

  • 不符合：无明确授权主体，权限由多人随意分配且无记录。

  • 证据留存：Grant_priv = 'Y' 的账户清单、访问控制策略文件、审批记录、访谈纪要。

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

8.1 要求理解

本项关注粒度：

  • 客体：是否达到数据库表级（视图、存储过程同样可视为客体）。仅做到数据库级或服务器级，不符合要求。
  • 主体：MySQL 中不存在用户组的概念，主体天然为账户（用户）级。

8.2 核查方法与判定标准

SELECT * FROM mysql.tables_priv;
SELECT * FROM mysql.columns_priv;

  • 符合：存在表级或列级授权（客体粒度达到表级或更细）。

  • 部分符合：仅做到库级授权。

  • 不符合：仅为全局（*.*）授权。

  • 证据留存：mysql.tables_priv、mysql.columns_priv 查询结果截图、授权粒度说明。

九、测评项 g：应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问

MySQL 自身不具备安全标记能力，需依靠操作系统或第三方软件实现。

  • 判定标准：由应用层或第三方实现了安全标记与访问控制判部分符合并说明边界； 无实现判不符合（三级系统该项通常不符合）。
  • 证据留存：安全标记实现说明或不适用的对象边界说明、访谈纪要。

十、判定标准汇总

项符合部分符合不符合
a按岗建户、权限有差异、可对应自然人多账户但划分粗糙共用单一账户
b已改名/删除，或保留但强口令且限 host保留且口令尚可但 host 为 %空口令/弱口令，或沿用初始口令
c无多余、过期、共享账户有长期未使用账户有共享账户或离职人员仍可登录
d最小权限且高危权限仅管理员持有划分较粗或高危权限外授全用同一高权限账户
e有授权主体 + 审批过的策略且执行一致有主体无书面策略无授权主体，权限随意分配
f客体粒度达表级或列级仅库级仅全局级
g由应用层/第三方实现标记—无实现

参考依据

关联文章