mysql如何为审计人员创建只读用户并配置全局审计权限

在企业的数据库运维中，审计人员需要查看全量数据与操作记录，但又不能具备任何写入或修改权限。MySQL通过账户管理与授权机制，可以精确创建只读用户并开放审计视角，而不破坏生产库安全边界。

一、创建来源受限的只读账号

首先应使用create user建立专属账号，并限制其登录主机，避免审计账号被异地滥用。MySQL的账户由用户名与主机组成，主机可用ip或网段，确保审计人员只能从指定办公网络进入。

创建时还可设置密码过期策略与资源限制，防止该账号占用过多连接。以下示例创建一个仅允许从内网审计机登录的账号：

-- 创建审计只读用户，限定来源IP
CREATE USER 'audit_ro'@'192.168.0.1'
  IDENTIFIED BY 'StrongPass#2024'
  WITH MAX_CONNECTIONS_PER_HOUR 50;

-- 查看用户是否创建成功
SELECT user, host FROM mysql.user WHERE user = 'audit_ro';

上述语句中，audit_ro为账号名，192.168.0.1为审计人员机器地址。MAX_CONNECTIONS_PER_HOUR可抑制暴力查询。相比直接给开发账号提权，独立账号让权限边界清晰，也方便后续通过revoke回收。

如果企业使用MySQL 8.0，密码插件默认caching_sha2_password，部分老客户端需显式指定mysql_native_password。但审计工具多已支持新插件，无需降级加密方式。

二、授予全局只读与审计视图权限

只读并不等于只给select，审计人员常需查slow log、general log或审计插件写入的表。MySQL系统库mysql下的部分表存放权限与日志元数据，应单独授权。

使用grant在*.*上赋予select，可实现跨库读；再对审计表单独授权，避免账号能改系统表。示例如下：

-- 授予全局查询权，不含写权限
GRANT SELECT ON *.* TO 'audit_ro'@'192.168.0.1';

-- 若使用MariaDB审计插件，授权审计表
GRANT SELECT ON mysql.general_log TO 'audit_ro'@'192.168.0.1';
GRANT SELECT ON mysql.slow_log TO 'audit_ro'@'192.168.0.1';

-- 刷新权限使生效
FLUSH PRIVILEGES;

注意GRANT SELECT ON *.*不会包含file、super等管理权，因此审计用户无法load_file或终止线程。若使用企业版审计插件（如MySQL Enterprise Audit），审计记录写在audit_log表或文件中，文件类需操作系统级读权，表类则用上述grant即可。

为防审计账号误用事务做写操作，可结合会话级只读：在审计人员连接后执行SET SESSION TRANSACTION READ ONLY;，但这依赖客户端配合。更稳的是在全局开read_only，并给运维账号super权限绕过。

三、通过全局参数强化只读边界

除了账号授权，实例级read_only参数可阻止非super用户写数据。开启后，audit_ro因无super自然只能读，从机制上堵住漏权。

在配置文件或运行时开启该参数，并确认审计账号不在豁免列表。代码如下：

-- 运行时开启全局只读（需super权限执行）
SET GLOBAL read_only = ON;

-- 查看当前只读状态
SHOW VARIABLES LIKE 'read_only';

-- 若使用超级只读，连super也禁写（MySQL 8.0.3+）
SET GLOBAL super_read_only = ON;

super_read_only会连super账号也锁写，适合纯审计从库。主库一般只开read_only，让复制线程可写。审计人员连从库查数据，既不压主库，又满足合规留痕。

当审计需回溯操作历史，可部署旁路审计插件，将记录同步到独立库，再对audit_ro开放那张独立库的select。这样即便生产库表结构变更，审计链路不受影响。

四、权限回收与定期审计

人员离职或审计结束，应及时revoke并drop用户，避免僵尸账号。同时定期用show grants核对账号权，防止累积赋权。

核查与清理的常用语句如下：

-- 查看审计账号权限
SHOW GRANTS FOR 'audit_ro'@'192.168.0.1';

-- 回收某库写权（本例其实未授，仅示范）
REVOKE INSERT, UPDATE, DELETE ON *.* FROM 'audit_ro'@'192.168.0.1';

-- 人员变更后删除账号
DROP USER 'audit_ro'@'192.168.0.1';

通过账户、授权、实例参数三层控制，MySQL能以最小权限支撑审计诉求。实际落地时，建议把创建脚本纳入配置管理，每次变更留单，既满足内控，也降低人为失误。

最后提醒，审计权限不等于安全免检。只读账号若能看到敏感字段，仍应在应用层做脱敏，数据库授权只是第一道闸。

mysqlread_only_useraudit_privilege修改时间：2026-08-04 17:30:19