为什么需要关注数据库安全审计
公司刚上线的新订单系统运行两周，突然发现有客户数据被异常导出。排查后发现是某个离职员工的账号仍在使用，而这类操作在日志中根本没有留下痕迹。这种情况在中小型企业中并不少见，核心问题往往不是技术防御不够强，而是缺少一套完整的数据库安全审计流程。
明确审计目标：先想清楚“审什么”
不是所有数据都需要同等强度的监控。财务系统的用户余额变动、医疗系统的病历访问、电商后台的商品价格修改，这些属于高敏感操作，必须纳入审计范围。可以先列出三类重点：谁在什么时候访问了哪些敏感表，做了增删改查中的哪一类操作，是否涉及批量导出或权限变更。
比如某零售企业就规定，单次查询超过5000条用户信息必须触发告警，这就是基于业务场景设定的具体审计阈值。
启用数据库原生审计功能
主流数据库都自带审计模块，以MySQL为例，可以通过开启通用查询日志或使用企业版的审计插件来捕获操作行为。虽然开启审计会带来一定性能损耗，但相比数据泄露的风险，这点代价是值得的。
SET GLOBAL general_log = 'ON';
SET GLOBAL log_output = 'TABLE';这样所有SQL语句都会记录到mysql.general_log表中。如果是Oracle，则可通过AUDIT命令针对特定用户或语句类型开启跟踪。
规范日志存储与保留策略
审计日志本身也是敏感数据，不能和业务库放在同一台服务器上。建议将日志集中传输到独立的日志服务器或SIEM系统，并设置自动归档机制。例如按月分割文件，加密存储至少180天，满足合规要求的同时避免磁盘爆满。
建立自动化分析规则
每天产生上万条日志，靠人工翻查不现实。可以写简单的脚本定期扫描异常模式：
SELECT user_host, sql_text
FROM mysql.general_log
WHERE command_type = 'Query'
AND sql_text LIKE '%SELECT%FROM%user_info%WHERE 1=1%'
AND event_time > NOW() - INTERVAL 1 HOUR;这条查询能快速定位过去一小时内是否有全表扫描用户信息的行为，及时发现潜在风险操作。
定期生成可读性报告
给技术团队看的明细日志和给管理层汇报的摘要报告要区分开。每周自动生成一份统计图表，展示TOP 5高频操作类型、异常登录次数、敏感对象访问趋势，用直观的方式呈现安全状况。某物流公司就靠这份报表说服管理层追加了数据库防火墙预算。
演练响应流程：发现问题之后怎么办
审计不只是记录，更要能驱动行动。提前设定好不同级别事件的应对方案。例如检测到DBA账户从非常用地登录，系统应自动发送短信提醒并临时锁定该账号；发现大量DELETE语句执行，则立即通知运维介入核查。这些流程平时就要测试通，关键时刻才不会手忙脚乱。