数据库承载着企业最核心的数据资产，但针对它的威胁有一大半不是来自外部黑客。行业调查数据长期显示，超过七成的安全事件与内部人员有关——违规查询、误操作、越权导出、DBA 账号滥用、第三方代维人员的危险命令。这类行为不带攻击特征，防火墙和入侵检测天然看不见，等保 2.0 与《数据安全法》又明确要求对数据访问行为留痕可溯。
数据库审计系统就是为这个问题而生的。但市面上产品能力差异极大，有的只能记录「谁连了库」，有的能还原「谁在什么时间对哪张表的哪个字段执行了什么语句」。本文把选型时真正拉开差距的六个维度讲清楚。
先分清：数据库审计 ≠ 数据库自带日志
很多 DBA 的第一反应是「数据库本身就有审计模块，为什么还要单独买产品」。原因有三个：
性能代价。数据库自带的审计功能开启后，日志写入直接消耗数据库自身资源，高并发业务场景下性能下降明显；独立审计设备旁路部署，对数据库零影响。
独立性缺失。数据库日志存在数据库里，DBA 自己就能删改——「既当运动员又当裁判员」，审计结果在合规检查中不被采信。独立审计系统实现使用权、管理权、监督权三权分立，这是内控审计的基本要求。
单点视角。真实业务访问大多是「浏览器 → Web 中间件 → 数据库」三层架构，中间件用一个固定账号连库。只看数据库日志，你只能看到中间件账号在操作，无法对应到真实发起业务的自然人。这正是后面要讲的三层关联能力要解决的问题。
六个关键能力维度
1. 数据库类型覆盖：先看你的库能不能被审计
这是硬门槛。评估时先列全自己的数据库清单，逐个核对产品是否支持解析：
- 商业数据库：Oracle、SQL Server、DB2、Sybase、Informix
- 开源与大数据：MySQL、PostgreSQL、MongoDB、Redis、Hive、HBase、Elasticsearch
- 国产数据库：达梦、人大金仓、南大通用、神通、高斯（信创场景的必查项）
不同服务编码（UTF8、UTF16、GB2312）和各种客户端工具也要能正常解析。覆盖不全的审计系统会在你的资产地图上留盲区。
2. 解析深度：SQL 语义级，而不是连接级
这是「真审计」与「伪审计」的分水岭。低能力产品只记录源 IP、目的端口、时间——出了事什么也查不出来。合格的产品要做到 SQL 语义级解析：能还原完整的 SQL 语句，并识别出库名、表名、命令类型、字段名乃至字段值，支持按返回码统计操作结果。
一个直接的测试方法：让供应商现场演示查询一条包含敏感字段的 SQL，看审计日志里能否直接定位到这条语句、这张表、这个返回行数。
3. 三层关联：把 SQL 操作还原到真实用户
如前所述，三层架构下「中间件固定账号」是溯源的最大障碍。成熟产品通过前后台关联技术解决：前台探针解析用户到 Web 服务器的 HTTP 访问，后台探针解析 Web 服务器到数据库的 SQL 会话，两者实时关联后，审计日志能直接显示「业务用户名 → 客户端 IP → HTTP 事件 → 具体执行了哪条 SQL」。
没有这个能力，政务、金融等需要「操作落到自然人」的场景基本无法满足合规要求。
4. 细粒度策略与响应方式
策略定义的粒度决定审计的精确度。看三点：
- 规则集维度：能否按源程序、登录账号、数据库命令、库名、表名、字段名、字段值、返回码组合定义规则，而不是只有全量记录开关
- 特定账号跟踪：对 root、DBA 等特权账号（尤其是「本不该出现的位置突然出现特权账号」）能否重点监控
- 响应方式：除了入库记录，是否支持实时阻断会话（RST）、短信/邮件告警、Syslog/SNMP 对接外部平台；黑白名单能否按用户和操作类型分别设置
5. 审计日志脱敏
容易被忽略但合规检查常查的一项。审计系统自己不能成为二次泄露源：身份证号、手机号、银行卡号等敏感字段在日志存储与界面展示时应支持模糊化，且脱敏规则可自定义。
6. 性能与可靠性：海量日志下的基本盘
审计日志的量级远超一般想象，入库速度和检索速度直接决定系统「用不用得起来」：
- 入库性能：行业标杆水平在每秒数万条以上，否则高峰期日志积压丢失
- 检索体验：入库时同步做分类统计与预处理，事后按时间、IP、账号、关键字等多条件组合检索无明显延迟
- 高可用：在线模式要支持双机热备与 BYPASS（设备故障或断电时自动直通，不影响业务）
- 自身审计：对审计系统管理员自身的操作也要留痕——审计者也要被审计
三种部署模式怎么选
| 部署模式 | 原理 | 适用场景 | 优劣势 |
|---|---|---|---|
| 旁路审计 | 引擎接交换机镜像口，分析复制流量 | 大多数场景的首选，流量大、业务连续性要求高 | 零影响、不改网络；但阻断能力有限，加密协议解析受限 |
| 在线审计（数据库防火墙模式） | 串联在访问路径上 | 需要强阻断、SSH/RDP 等加密协议运维审计 | 控制力强、加密协议可解；对可靠性要求极高，须配双机热备与 BYPASS |
| 云环境审计 | 虚拟机导流软件或虚拟导流器把云内流量引出 | 数据库部署在私有云/虚拟化环境 | 能力与物理环境一致；需评估虚拟化平台兼容性 |
多数企业的组合是：核心数据库旁路审计为主，运维入口（堡垒机后路径）在线审计补加密协议盲区，云上资产用导流方案覆盖。
落地建议：从合规清单出发
- 先盘点数据库资产清单（类型、版本、部署位置、访问路径），没有这个清单一切选型都是空谈
- 按上面六个维度做评分表，权重向「解析深度」和「三层关联」倾斜——这两个能力决定出事后你能不能查清
- 要求 POC 实测：用真实业务流量跑一周，检验入库性能、检索速度与规则命中精度
- 上线前完成特权账号梳理与关键表字段分级，把策略建在业务重点上，避免「全量记录但什么都查不到」
如果你正在做等保测评整改或数据库安全建设，可以把你的数据库类型清单和合规要求发给我们，我们可以给出适配的审计方案与部署建议。