最小化授权是数据库权限体系核心原则，需按角色分层控制权限、隔离高危操作、结构化审计日志、联动审批留痕，并定期验证清理幽灵权限。
数据库权限体系：最小化授权是核心原则
权限设计不是越细越好，而是要让每个账号只拥有完成其任务所必需的最小权限。生产环境常见错误是给应用账号赋予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冻结，观察一周无异常再彻底删除。
