最小化授权是数据库权限体系核心原则，需按角色分层控制权限、隔离高危操作、结构化审计日志、联动审批留痕，并定期验证清理幽灵权限。
数据库权限体系：最小化授权是核心原则
权限设计不是越细越好，而是要让每个账号只拥有完成其任务所必需的最小权限。生产环境常见错误是给应用账号赋予 DBA 角色 或SUPER 权限 ，一旦应用层被入侵，攻击者可直接导出全库、删除表甚至提权 操作系统。
建议按角色分层控制：
- 应用账号 ：仅授予特定库下指定表的
SELECT/INSERT/UPDATE/DELETE，禁用DROP/CREATE/ALTER和跨库访问 - 运维账号 ：按模块划分（如备份组、监控组），使用
GRANT …… WITH GRANT OPTION谨慎下放权限，禁止共享密码 - 审计账号 ：仅允许查询
performance_schema、information_schema中审计相关视图，不可写、不可执行存储过程 - 高危操作隔离 ：如
TRUNCATE、DROP DATABASE等命令，应通过白名单脚本 + 审批流程执行，不开放给任何 SQL 客户端直连账号
审计日志必须覆盖“谁、在何时、对什么、做了什么”
默认 MySQL 的 general_log 或slow_query_log无法满足安全审计要求——它们不记录执行结果、不区分用户来源、不持久化敏感操作上下文。真正可用的审计需结构化采集四要素：
- 身份标识：登录账号、主机 IP、连接协议（如 SSL 是否启用）、会话 ID
- 时间戳：精确到毫秒，且与 NTP 服务器同步，避免日志时间错乱影响追溯
- 操作对象 ：库名、表名、行级影响（如
WHERE id=123条件）、是否涉及敏感字段（如身份证、手机号） - 行为类型：区分
DML（增删改查）、DDL（建表改结构）、DCL（授权变更）、FUNCTION CALL（调用加密 / 解密函数）
推荐方案：启用 MySQL 企业版 Audit Log 插件，或使用 Percona Server 的audit_log，日志格式设为 JSON 并写入独立远程 syslog 服务器，防止本地篡改。
权限变更与高危操作必须联动审批与留痕
权限不是静态配置，每次调整都应触发可追溯的工作流。例如：
- DBA 执行
GRANT SELECT ON finance.users TO 'report_app'@'10.20.%'前，系统自动弹出审批弹窗，要求填写业务原因、有效期（建议≤90 天）、申请人信息 - 审批通过后，操作由自动化平台代为执行，并将原始 SQL、审批单号、操作人、时间写入审计库的
audit_privilege_change表 - 所有
DROP、ALTER TABLE …… DROP COLUMN、SET GLOBAL类命令，必须经堡垒机二次确认，同时触发短信 /钉钉 告警给 DBA 组长
不依赖人工记日志，所有变更动作本身就要成为审计事件源。
定期验证权限有效性，防止“幽灵权限”堆积
上线新服务、人员离职、系统重构后，常遗留未清理的账号或过度授权。每季度应运行检查脚本：
- 扫描
mysql.user中account_locked='Y'但仍有非空authentication_string的账号 - 找出连续 90 天无登录记录且有
INSERT/UPDATE权限的应用账号 - 比对
INFORMATION_SCHEMA.SCHEMA_PRIVILEGES与当前业务清单，标记未在文档中登记的库级授权 - 用
pt-show-grants导出所有账号权限，做 Git 版本比对，识别意外变更
发现冗余权限后，不是立即回收，而是先设为 REQUIRE SSL 或加 MAX_QUERIES_PER_HOUR 0 冻结，观察一周无异常再彻底删除。
