MySQL用户账户分类的使用

MySQL 8.0.16 及以后版本 中引入的一项重要安全机制：用户账户分类（Account Categories），通过 SYSTEM_USER 权限来区分 系统用户（System User） 和 普通用户（Regular User）。

下面我将用中文为你逐层解析、通俗易懂地解释这段内容的核心思想和实际意义，帮助你真正“理解”它。

一、核心概念：什么是“系统用户”和“普通用户”？

从 MySQL 8.0.16 开始，MySQL 把用户分为两类：

✅ 注意：SYSTEM_USER 是一个独立的权限，它不赋予任何其他操作能力（比如建表、查数据），它的作用是控制谁能管理“系统级账户”。

二、为什么要分“系统用户”和“普通用户”？—— 安全隔离

问题背景：

在早期版本中，只要一个用户有 CREATE USER 或 SUPER 权限，他就可以：

• 创建/删除/修改任何用户（包括 root）
• 终止任何会话（包括 DBA 的连接）
• 设置存储过程的 DEFINER 为 root

这就导致了一个严重问题：
👉 一个“普通管理员”可能误删 root 账户，或者被攻击者利用提权，造成整个数据库失控。

解决方案：

引入 SYSTEM_USER 权限作为“守门员”，实现权限的层级控制。

三、关键规则总结（重点！）

✅ 规则 1：谁可以改谁？

📌 举例：

• 用户 A 是普通用户，拥有 CREATE USER 权限 → 他只能创建/修改/删除其他“普通用户”，不能动 root。
• 用户 B 是系统用户，拥有 CREATE USER → 他可以操作所有用户，包括 root。

这就像公司里的“超级管理员”和“部门管理员”：

• 部门管理员可以管理本部门员工账号；
• 但不能动 CEO 或总管理员的账号；
• 只有超级管理员才能动 CEO 的账号。

✅ 规则 2：哪些操作受SYSTEM_USER限制？

以下操作如果涉及“系统用户”，执行者必须自己也是“系统用户”：

四、“会话”也有系统/普通之分

不仅用户分类型，当前连接的“会话”也分类型：

• 会话是否为“系统会话”，取决于：
  • 当前用户的账号是否有 SYSTEM_USER
  • 或者当前激活的角色中是否有包含 SYSTEM_USER 的角色

会话可以动态变化！

-- 当前是普通会话
SET ROLE admin_role; -- 如果 admin_role 包含 SYSTEM_USER
-- 现在变成了系统会话！

-- 再取消角色
SET ROLE NONE;
-- 又变回普通会话了

📌 注意：

• 权限变更（如 GRANT SYSTEM_USER TO user）只对新连接生效，不影响已存在的会话。
• 存储过程执行时，继承的是调用它的会话类型，而不是 DEFINER 是否是系统用户。

五、如何保护系统账户不被普通用户篡改？（实战建议）

仅仅不让普通用户有 SYSTEM_USER 权限还不够！因为还有另一种方式可以改用户信息：

⚠️ 直接修改 mysql 系统数据库中的表（如 mysql.user）！

所以，为了彻底保护系统账户，你需要双重防护：

✅ 防护策略 1：禁止普通用户操作mysql表

即使用户有 ALL PRIVILEGES ON *.*，也可以通过 Partial Revoke（部分撤销） 剥夺其对 mysql 库的操作权。

示例：创建一个“全能但安全”的普通管理员 u1

-- 1. 创建用户
CREATE USER u1 IDENTIFIED BY 'password';

-- 2. 授予全局所有权限（包含 SYSTEM_USER）
GRANT ALL ON *.* TO u1 WITH GRANT OPTION;

-- 3. 撤销 SYSTEM_USER —— 让 u1 成为普通用户
REVOKE SYSTEM_USER ON *.* FROM u1;

-- 4. 撤销对 mysql 系统库的所有修改权限
--    防止他直接 INSERT/UPDATE mysql.user 来绕过限制
REVOKE ALL ON mysql.* FROM u1;

✅ 结果：

• u1 可以管理所有数据库、所有普通用户；
• 但不能修改系统用户（如 root）；
• 也不能直接改 mysql.user 表来“偷渡”；
• 完全安全！

更精细的权限控制示例：

示例 1：只允许读mysql表（用于监控）

CREATE USER monitor IDENTIFIED BY 'pass';
GRANT SELECT, INSERT, UPDATE, DELETE ON *.* TO monitor;
REVOKE INSERT, UPDATE, DELETE ON mysql.* FROM monitor;
-- monitor 可以读 mysql.user、mysql.db 查用户信息，但不能改

示例 2：只允许看特定字段

CREATE USER auditor IDENTIFIED BY 'pass';
GRANT ALL ON *.* TO auditor;
REVOKE ALL ON mysql.* FROM auditor;
GRANT SELECT ON mysql.db TO auditor;
GRANT SELECT (Host, User) ON mysql.user TO auditor;
-- 只能查看 user 表的 Host 和 User 字段

六、常见问题解答（FAQ）

❓ Q1:SYSTEM_USER和SUPER有什么区别？

💡 SUPER 正在被拆解成多个专用权限（如 CONNECTION_ADMIN, SYSTEM_USER, SET_USER_ID 等），这是 MySQL 权限体系现代化的一部分。

❓ Q2: root 用户是系统用户吗？

✅ 是的！默认的 root@localhost 在 MySQL 8.0+ 中会被自动赋予 SYSTEM_USER 权限，属于系统用户。

❓ Q3: 我怎么查看某个用户有没有SYSTEM_USER权限？

-- 查看用户权限
SHOW GRANTS FOR 'username'@'host';

-- 或查询 mysql.user 表
SELECT User, Host, System_user FROM mysql.user WHERE User = 'root';

注意：字段名是 System_user（在 mysql.user 表中），值为 'Y' 或 'N'。

七、总结：一句话理解

🔐 SYSTEM_USER 权限是一个“守门员”，它决定了一个用户是否有资格去管理和影响那些“更高权限的系统账户”（如 root），从而实现了权限的层级隔离，提升了数据库的安全性。

🛡️ 实际建议（给 DBA 的最佳实践）

1. 只给真正需要的 DBA 分配 SYSTEM_USER 权限
2. 普通运维人员、应用管理员应设为“普通用户”
3. 使用 Partial Revoke 禁止普通用户访问 mysql 系统库
4. 避免使用 SUPER，改用细粒度权限（如 CONNECTION_ADMIN, SYSTEM_USER）
5. 定期审计谁有 SYSTEM_USER 权限

如果你是数据库管理员，这个机制就像是给你的“保险箱”加了一把锁：
🔑 普通员工可以处理日常事务，但动不了保险箱（root 账号）；
🔐 只有拿着特定钥匙（SYSTEM_USER）的人才能打开。

这样，即使有人拿到管理员账号，也无法轻易破坏核心系统。

如有具体场景（比如你想创建一个“受限管理员”），我可以帮你写具体的 SQL 示例。

到此这篇关于MySQL用户账户分类的使用的文章就介绍到这了,更多相关MySQL用户账户分类内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论