公司刚上线的新系统跑得挺顺，结果某天财务发现一笔异常转账——钱是从后台直接改的数据库记录。查来查去，问题出在没人知道谁动过那张表。这事儿要是早做了数据库安全审计，日志一翻就清楚了。
什么是数据库安全审计
简单说，就是给数据库装个“行车记录仪”。每次谁登录、查了什么、改了哪条数据，全都记下来。不是等出事才慌，而是平时就把痕迹留着，随时能翻账。
审计从哪儿开始
第一步是明确审什么。不是所有操作都要盯，那样日志爆炸还浪费资源。重点盯几类行为：
- 敏感表的访问（比如用户密码、订单金额）
- 高权限账户的操作（DBA、管理员）
- 非工作时间的数据修改
- 批量删除或导出
开启数据库自带审计功能
主流数据库都支持审计，比如 MySQL 的 general log 和 audit plugin，Oracle 的 AUDIT 功能。以 MySQL 启用通用日志为例：
SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/var/log/mysql/general.log';这条命令一开，所有 SQL 请求都会写进日志文件。虽然有点重，但小系统够用。生产环境建议用企业版审计插件，更细粒度也更轻量。
日志集中管理别堆本地
很多人开了审计，日志却留在数据库服务器上。万一被删库跑路，审计日志也一块没了。正确做法是把日志实时同步到独立的日志系统，比如 ELK 或者阿里云 SLS。
例如，在 syslog 配置中加入转发规则：
local6.* @log-center.example.com:514这样数据库日志会自动发到日志中心，攻击者即使入侵数据库也清不掉记录。
设置异常行为告警
光有日志不够，得有人看。可以配置规则自动报警。比如：
- 单次删除超过 1000 条记录
- 凌晨 2 点有 root 登录
- 某个 IP 短时间内频繁查询用户表
用脚本或 SIEM 工具监控日志流，触发条件就发邮件、钉钉通知负责人。就像银行账户变动提醒，及时反应才能止损。
定期回看审计报告
别等出事才翻日志。每周生成一份审计摘要，看看有没有可疑操作。哪怕没异常，也是一种监督。员工知道行为会被查，自然不敢乱来。
某电商公司就这么干，结果发现一个外包开发用测试账号偷偷导出用户手机号。当场终止合作，避免更大泄露。
权限和审计要一起抓
审计再严，如果人人都是管理员，那日志也看不出谁干的。必须配合最小权限原则：只给必要权限，谁需要查用户信息谁才能查，普通运维不能碰核心表。
审计流程不是一次性的开关，而是持续动作。开了功能、配了转发、设了告警，还得定期检查是否正常运行。就像防火系统，不能装完就忘，得时不时测试喷头通不通水。