mysql中权限分离与最小权限原则的应用

应用账号应遵循最小权限原则，仅授予特定库表的select、INSERT、UPDATE、delete权限，禁用DROP、ALTER、GRANT OPTION等高危权限，并限定IP范围；root账号严禁用于应用服务。

mysql 中如何为应用账号分配最小必要权限

直接给 SELECT、INSERT、UPDATE、DELETE 就够了，别碰 DROP、ALTER、CREATE，更不能给 GRANT OPTION 或 FILE 权限。生产环境的应用账号，绝大多数场景下只需对特定数据库的几张表有 CRUD 权限。

常见错误是用 GRANT ALL PRIVILEGES ON *.* TO 'app'@'%' —— 这等于把整套 MySQL 当成裸机交出去，一旦应用被注入或配置泄露，数据库就全盘失守。

• 先创建专用数据库： CREATE database app_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
• 再建账号并限制来源：CREATE USER 'app_user'@'10.20.%.%' IDENTIFIED BY 'strong_password_123';
• 只授指定库表权限：GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.orders TO 'app_user'@'10.20.%.%';
• 执行 FLUSH PRIVILEGES; 生效（仅在修改系统表后需显式调用）

为什么不能用 root 或同级账号跑应用服务

root 账号拥有 SUPER、SHUTDOWN、RELOAD 等高危权限，还能读写 mysql 系统库。应用代码若存在 SQL 注入、日志打印敏感 SQL、或连接串误泄露，攻击者可直接执行 SELECT * FROM mysql.user; 获取所有账号哈希，甚至用 SET PASSWORD for 'root'@'localhost' = ... 提权。

更隐蔽的风险是 ORM 自动生成的语句可能触发隐式权限需求。比如 Django 的 syncdb 或 laravel 的 migrate 默认尝试 SHOW CREATE table 和 SELECT 系统表 —— 这些只需 SELECT 权限即可满足，无需 PROCESS 或 INFORMATION_SCHEMA 全局访问。

• 应用账号不应出现在 mysql.user 表的 Super_priv='Y' 行中
• 避免使用 '%' 作为 host，优先限定内网子网段（如 '10.20.30.%'）
• 禁止授予 GRANT OPTION —— 否则该账号可自行扩大权限范围

如何安全地支持 dba 日常运维与开发查数需求

运维和开发不是“非得用 root 才能干活”。应分角色建三类账号：应用账号（最小权限）、只读分析账号（SELECT + SHOW VIEW）、DBA 账号（有限 ALTER/INDEX 权限，禁用 DROP DATABASE）。

例如导出报表的 BI 工具，只需：GRANT SELECT ON app_db.* TO 'bi_reader'@'192.168.100.%';；而 DBA 账号可授权：GRANT SELECT, INSERT, UPDATE, DELETE, INDEX, ALTER ON app_db.* TO 'dba_team'@'10.10.%.%'; —— 注意没给 DROP，删表必须走工单+二次确认流程。

• SHOW DATABASES 权限默认对所有用户隐藏，如需显示，单独授予（但不推荐）
• 临时查数用的账号，建议配 MAX_QUERIES_PER_HOUR 100 和 MAX_UPDATES_PER_HOUR 0 防误操作
• 避免在应用配置中硬编码账号密码；改用 MySQL 8.0+ 的 CACHING_SHA2_PASSWORD 插件 + 密码轮换策略

MySQL 8.0 权限模型变化带来的实操调整

MySQL 8.0 引入角色（ROLE）和动态权限（如 BACKUP_ADMIN），但角色不能替代最小权限原则——它只是批量授权的语法糖。真正关键的变化是：默认启用 sql_mode=STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION，且 mysql.user 表结构彻底重构，旧版通过直接 UPDATE 系统表改权限的方式已失效。

这意味着你不能再靠脚本去“偷偷”更新 mysql.user，所有权限变更必须走 GRANT/REVOKE 语句，而这些语句本身会被审计日志记录（如果启用了 audit_log 插件）。

• 创建角色示例：CREATE ROLE 'app_rw'; GRANT SELECT, INSERT, UPDATE, DELETE ON app_db.* TO 'app_rw';
• 绑定用户：GRANT 'app_rw' TO 'app_user'@'10.20.%.%';，之后需执行 SET default ROLE 'app_rw' TO 'app_user'@'10.20.%.%';
• 动态权限如 CONNECTION_ADMIN 仅用于管理连接，不应授予应用账号

SELECT user, host, account_locked, password_last_changed  FROM mysql.user  WHERE user IN ('app_user', 'bi_reader');

权限分离不是加几行 GRANT 就完事，真正的难点在于持续识别“哪些权限现在看起来多余，但某天某个新功能又悄悄依赖它”。每次上线新模块前，务必重审该模块实际执行的 SQL 类型，并反向收缩账号权限。