最小化授权是数据库权限体系核心原则，需按角色分层控制权限、隔离高危操作、结构化审计日志、联动审批留痕，并定期验证清理幽灵权限。

数据库权限体系：最小化授权是核心原则

权限设计不是越细越好，而是要让每个账号只拥有完成其任务所必需的最小权限。生产环境常见错误是给应用账号赋予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冻结，观察一周无异常再彻底删除。