SQL系统安全加固需坚持账号权限最小化、操作行为可追溯、异常行为能预警三大原则：严格管控账号权限，启用全量SQL审计，实时识别高风险行为，并定期验证策略有效性与应急闭环。
SQL系统安全加固的核心在于账号权限最小化、操作行为可追溯、异常行为能预警。不合理的账号配置和缺失的审计机制，往往是数据泄露或误操作的起点。
严格管控账号权限
避免使用高权限账号（如root、sa）日常运维，所有业务账号必须按需授权：
- 只授予执行业务必需的数据库对象权限（SELECT/INSERT/UPDATE/DELETE），禁用DROP、ALTER、CREATE等高危DDL权限
- 限制登录IP范围，通过GRANT ... FROM 'user'@'192.168.10.%'明确指定可信网段
- 定期清理长期未登录、无业务关联的账号，特别是测试环境遗留账号
- 敏感操作账号（如DBA）应启用双因素认证（如MySQL 8.0+支持FIDO密钥或OTP插件）
开启全量SQL操作审计
审计不是“记录日志”，而是确保关键行为可定位、可还原：
- MySQL建议启用general_log或更轻量的audit_log插件（企业版或Percona Server），记录用户、时间、IP、执行语句、返回行数
- SQL Server启用C2审计或Server Audit规范，将审计日志写入Windows事件日志或专用文件，并设置自动轮转与保留周期（至少90天）
- 禁止审计日志与业务数据共用同一磁盘，防止IO争抢或被恶意清空；日志文件权限设为仅DBA组可读
实时识别高风险行为
单纯记录日志不够，需结合规则主动告警：
- 对单次查询返回超10万行、执行时长超30秒、凌晨2–5点触发的DELETE/UPDATE等行为打标并触发短信/钉钉告警
- 监控账号短时间高频失败登录（如5分钟内10次密码错误），自动锁定该账号15分钟
- 比对账号行为基线（如某应用账号通常只查t_order表），发现突然访问t_user、t_config等敏感表时生成风险事件
定期验证与应急闭环
安全策略必须验证有效性，不能停留在配置层面：
- 每季度执行一次“权限回收演练”：临时收回某业务账号的UPDATE权限，确认其核心功能是否受影响，及时修正过度授权
- 模拟SQL注入攻击（如' OR 1=1 --）验证WAF或数据库层防护是否拦截，同时检查审计日志是否完整记录攻击源IP与语句
- 建立账号变更审批流程，所有新建/提权/删号操作须留痕于ITSM系统，并关联责任人与变更窗口期
