防止越权访问需坚持最小权限原则，实施连接层、数据库层、应用层分层校验；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）导出权限快照，纳入版本管理，变更需走审批流程
