mysql中权限限制与安全审计策略

mysql权限是分层模型，含全局至列级粒度，需避免grant all on .、慎用with grant option和’%’通配host，应用账号应最小化授权并限定库表，审计依赖audit_log插件或受限的general_log，权限回收须显式revoke或drop user。

MySQL 用户权限模型怎么理解才不踩坑

MySQL 的权限不是“开/关”二元开关，而是分层控制：全局、数据库、表、列、存储过程等粒度。直接 GRANT ALL PRIVILEGES ON *.* 是最常见误操作，它绕过后续所有精细化限制，且 WITH GRANT OPTION 会把授予权力下放，一旦子账号泄露，风险指数级放大。

实际权限生效依赖两个关键点：一是 mysql.user 表中 host 和 user 的精确匹配（注意 'user'@'192.168.1.%' 和 'user'@'%' 不等价）；二是权限变更后必须执行 FLUSH PRIVILEGES（仅在直接改表时需要，GRANT 语句自动刷新）。

• 生产环境禁止使用 '%' 通配 host，优先用具体 IP 段或 DNS 名称
• USAGE 权限表示“仅登录”，不赋予任何操作能力，适合审计账号或连接池健康检查账号
• 删除用户要同时用 DROP USER 'u'@'h' 和 FLUSH PRIVILEGES，否则残留记录可能干扰新同名用户创建

如何最小化授予应用账号的权限

应用账号不该有 DROP、CREATE、ALTER、INDEX、GRANT OPTION 等 DDL 权限。典型 Web 应用只需 select、INSERT、UPDATE、delete，且应限定到具体数据库和表。

GRANT SELECT, INSERT, UPDATE, DELETE ON `app_db`.`orders` TO 'app_user'@'10.20.30.40'; GRANT SELECT ON `app_db`.`products` TO 'app_user'@'10.20.30.40';

如果应用用到了存储过程，需单独授权：EXECUTE ON PROCEDURE app_db.calc_discount，而不是给整个库 EXECUTE 权限。

• 避免跨库查询需求，就别给 SELECT 权限到 mysql 或 information_schema
• ORM 框架如 django/SQLAlchemy 默认不建索引，INDEX 权限对应用账号基本无用，反而增加被滥用风险
• 用 SHOW GRANTS FOR 'u'@'h' 验证最终生效权限，注意输出里可能包含多条 GRANT 记录，权限是合并效果

开启 MySQL 审计日志的关键配置项

MySQL 社区版不自带企业级审计插件，但可通过 general_log + log_output 组合实现基础行为记录；更可靠的是启用 audit_log 插件（需 MySQL 5.7.28+ 或 8.0，且仅限企业版或 Percona Server / mariadb 替代方案）。

若用社区版硬上通用日志，务必注意：general_log = ON 会记录所有语句（含密码明文），性能损耗大，只能临时开启，且日志路径需设为非系统盘、有独立配额的目录：

SET GLOBAL general_log = 'ON'; SET GLOBAL log_output = 'TABLE';  -- 写入 mysql.general_log 表，比文件更易过滤 SET GLOBAL general_log_file = '/data/mysql/logs/general.log';

• slow_query_log 不是审计日志，它只捕获超时 SQL，无法替代行为追踪
• Percona Server 提供开源 audit_log 插件，配置项为 audit_log_policy = ALL、audit_log_format = json，日志可直连 SIEM 工具
• 审计日志本身需设置严格文件权限：chown mysql:mysql /var/lib/mysql/audit/ 且禁止其他用户读取

权限回收与账号生命周期管理容易忽略的点

权限回收不是“撤销就完事”。MySQL 不支持按时间自动过期权限，CREATE USER ... PASSWORD EXPIRE 只控制密码有效期，不控制权限存续。账号停用必须显式 DROP USER 或 REVOKE ALL PRIVILEGES 并 FLUSH PRIVILEGES。

更隐蔽的风险在于：MySQL 8.0 引入角色（ROLE），但角色权限不会自动继承到已存在的用户——必须显式 GRANT role_name TO user，且用户登录后需 SET ROLE role_name 才能激活（除非设为默认角色）。

• 定期用 SELECT user, host, account_locked FROM mysql.user WHERE account_locked = 'Y' 检查锁定账号
• 用 SELECT * FROM mysql.role_edges 查看角色继承关系，避免权限“幽灵残留”
• 备份 mysql.user、mysql.db、mysql.tables_priv 表结构及数据，权限恢复不能只靠 SQL dump，得验证 GRANT 语句是否覆盖全部层级

权限越精细，维护成本越高；审计越全，性能和存储压力越大。没有银弹，只有根据业务敏感度做取舍：核心账务库必须列级权限 + 插件审计，内部报表库可适度放宽，但绝不能共用同一套账号凭证。