防止越权访问需坚持最小权限原则,实施连接层、数据库层、应用层分层校验;MySQL 账号须按角色精确授权、禁用高危权限与通配符;确认 skip-grant-tables 关闭、权限实时生效;应用层须校验资源归属并记录操作日志;定期审计收敛权限。

防止越权访问的核心在于:严格遵循最小权限原则,结合分层校验(连接层 + 数据库层 + 应用层),并确保 MySQL 权限配置精准、及时生效。
明确用户角色与权限边界
每个应用账号应仅拥有完成其功能所必需的最小权限,禁止使用 root 或高权限账号直连生产库。例如:
- 只读服务账号:授予 SELECT 权限,限定在指定数据库和表(如
GRANT SELECT ON app_db.users TO 'app_ro'@'10.20.%.%';) - 写入服务账号:按业务模块拆分,如订单服务仅能操作
orders和order_logs表,禁用DROP、ALTER、FILE等危险权限 - 避免通配符滥用:
GRANT SELECT ON *.*或ON app_db.*容易扩大攻击面,优先精确到表级
启用并验证权限校验流程
MySQL 默认开启权限校验,但需确认未被绕过:
- 检查
skip-grant-tables是否关闭(该参数会完全跳过权限验证,仅用于紧急恢复) - 确认
sql_mode中不含IGNORE_SPACE等可能弱化语法校验的选项 - 执行
FLUSH PRIVILEGES;后,用新连接测试权限是否实时生效(权限变更不自动同步到已有连接) - 通过
SHOW GRANTS FOR 'user'@'host';和SELECT * FROM mysql.user WHERE User='xxx';核对实际生效权限
配合应用层做二次校验
数据库权限是第一道防线,但无法覆盖逻辑越权(如用户 A 尝试访问用户 B 的订单)。必须在应用中补充校验:
- 接口请求中携带当前登录用户 ID,在 SQL 查询中显式添加
WHERE user_id = ?条件,而非依赖前端传来的 user_id 参数 - 对敏感操作(如删除、修改他人数据)增加 owner 校验或 RBAC 角色判断
- 记录关键操作日志,包含操作者账号、目标资源 ID、SQL 摘要,便于事后审计与溯源
定期审计与权限收敛
权限容易随业务迭代膨胀,需建立常态化治理机制:
- 每月扫描
mysql.user和mysql.db表,识别长期未登录、权限过大或 host 为%的账号 - 下线旧系统账号前,先
REVOKE所有权限,再DROP USER - 使用工具(如 pt-show-grants)导出权限快照,纳入版本管理,变更需走审批流程










