17370845950

MySQL应用级权限设计核心是为每个应用创建独立账号并授予最小必要权限。需按应用命名账号、限制IP来源、精确授权到库表列、禁用高危权限、定期审查与自动化管理。

MySQL 应用级权限设计的核心，是为每个应用创建独立账号，并仅授予其实际需要的最小权限，避免共用 root 或高权限账号，从源头降低误操作和越权访问风险。

按应用创建专用账号

不同应用（如订单系统、用户中心、报表服务）应使用不同的数据库账号，账号名建议体现应用用途，例如 app_order_rw、app_user_ro、app_report_select。避免多个应用共享同一账号，否则无法精准审计或快速隔离问题。

• 创建账号示例：CREATE USER 'app_order_rw'@'192.168.10.%' IDENTIFIED BY 'strong_pass_2025';
• 限制登录来源 IP 段，不开放 '%'% 通配（除非确有跨网段需求）
• 生产环境禁用空密码、简单密码；建议配合 MySQL 8.0+ 的密码强度策略（validate_password 插件）

按业务场景精确授权

权限粒度要落到具体库、表甚至列，而非直接 GRANT ALL ON *.*。读写分离、只读报表、后台管理等角色应严格区分。

• 订单应用需读写：GRANT SELECT, INSERT, UPDATE, DELETE ON shop_db.orders TO 'app_order_rw'@'192.168.10.%';
• 报表应用仅查数据：GRANT SELECT ON shop_db.sales_summary TO 'app_report_select'@'192.168.10.%';
• 敏感字段（如 user.phone）可进一步用视图封装 + 列权限控制，或在应用层脱敏

禁用高危权限与操作

绝大多数业务应用完全不需要 DROP、ALTER、CREATE、FILE、SUPER 等权限。这些权限应保留在 DBA 或部署账号中。

• 明确禁止授予：GRANT DROP, ALTER, CREATE, FILE, PROCESS, SUPER, REPLICATION CLIENT 等
• 不给 mysql 系统库任何访问权限（除非极特殊运维需求）
• 避免使用 GRANT ... WITH GRANT OPTION，防止权限扩散

定期审查与自动化管理

权限不是“设一次就不管”。上线新模块、人员变动、应用下线时，都需同步更新权限配置。

• 每月执行：SELECT user, host, authentication_string FROM mysql.user; 结合 SHOW GRANTS FOR 'xxx' 核查账号权限
• 将账号创建与授权语句纳入 IaC 流程（如 Ansible/Terraform），确保环境一致性
• 对长期未登录账号（如 last_login IS NULL 或超 90 天无活动）标记并评估是否回收