等保测评现场常有这样一种尴尬：安全设备都装了，但是一问“上个月谁改过这张表”，没人回答得上来。

这个问题背后是审计的缺位。防护能力再强，如果没有留下可核查的记录，事后既说不清发生了什么，也拿不出证据证明自己管住了。等保把安全审计列为基本要求，道理就在这儿。

换个角度看，审计是数据安全里少有的「事后仍然有用」的能力。防火墙、加密、脱敏都在事前和事中起作用;事情已经发生之后，能还原过程的只有记录。

图1　一条数据库审计记录包含的六个维度

一、审计要记录的，不只是「有人访问了数据库」

很多单位理解的审计，是记一条「某账号在某个时间登录了数据库」。这个粒度在测评和溯源时都不够用。

可用的审计记录至少要回答六个问题：谁(数据库用户名、操作系统用户名)、何时(毫秒级时间戳)、从哪来(客户端 IP 与端口、访问工具名)、做了什么(SQL 全文、操作类型)、结果如何(执行结果与错误代码)、代价多少(影响行数与执行耗时)。

六个维度凑齐，一条记录才具备追溯价值。举个实际的例子：如果只记录账号，就无法区分是应用连接池的批量操作还是人工用客户端工具的临时查询;而「访问工具名」这一项，恰好能把二者分开。

再比如「影响行数」。一条 SELECT 语句返回 3 行和返回 30 万行，在记录里看不出差别，但在安全含义上完全不同——前者可能只是一次正常查询，后者很可能是批量导出。

采集方式上，系统支持协议解析与旁路抓包两种方式，不需要改变数据库原有的运行方式;兼容 Oracle、MySQL、SQL Server、PostgreSQL、达梦、人大金仓、GaussDB 等接近百种主流数据库。

二、光有记录还不够：风险要能被识别出来

记录是原料，识别才是产出。海量审计日志里，真正需要关注的只是少数异常行为。

系统内置敏感数据发现、异常访问检测、SQL 注入检测、黑白名单、防统方等风险策略，并提供行为轨迹分析，把同一账号的分散访问串成一条完整线索。

防统方是一个行业性很强的策略。在医疗行业，统计医生处方量的行为本身在业务上就属于敏感操作，需要对特定账号、特定表的访问模式做专门识别。这类策略的价值在于它贴着业务场景，而不是通用规则。

策略命中后的告警要送得出去才算数。系统支持 Syslog、电子邮件(SMTP)、SNMP Trap 等多种外发方式，可按告警级别分渠道发送：高等级告警直接推送，低等级告警进入日志待查，避免告警风暴淹没真正重要的信息。

三、测评真正要的，是能导出、能对上、能持续

图2　从采集到报表：审计记录变成测评证据的四段链路

数据库审计能提供什么证据?判断标准可以归成三条。

能不能导出，指记录和报表能否从系统直接生成可提交的材料。系统内置等保、SOX 等合规报表模板，支持 PDF、Word、Excel、HTML 四种格式导出，并可按日、周、月自动生成——自动生成的意义在于时间戳的连续性。

能不能对上，指审计记录与资产清单、策略配置之间是否前后一致。一条访问记录如果对应不上任何已登记的数据资产，测评时反而会成为问题。

能不能持续，指这些记录是按周期自动产生的，还是测评前集中补做的。后者的时间戳分布特征很明显，做不了假。

还有一件容易被忽略的准备：留存周期。日志留存时间不够、或者没有配置归档到外部存储，测评时同样会被追问。这件事要在建设阶段定好，临测再调整已经来不及。

此外，系统还提供 CVE 漏洞、弱口令、配置缺陷扫描，以及对 Telnet、SSH、FTP 等运维行为的统一审计，把数据库审计与运维审计放在同一套记录体系里，避免两套证据互相矛盾。

四、常见误区

在项目里，下面几个误区比较常见。

第一个误区是把审计当成「开了就行」。审计的价值取决于记录维度与策略配置，全按默认值跑起来，往往既看不到重点行为，也生成不了可提交的报表。

第二个误区是只审计数据库、不管运维。数据泄露的路径经常是「先拿到运维权限，再访问数据库」，两条记录不放在一起看，就很难还原完整过程。

第三个误区是把审计记录当成只进不出的档案。记录检索不便、报表导出困难，等于有证据却拿不出来，实际效果大打折扣。

五、落到实现层

审计能力能不能用起来，很大程度上取决于它和其余安全能力是否共享数据。如果审计是一台独立设备，异常行为往往只能自己告警，很难与其他线索交叉验证。

以数达安全的数安版等保一体机(DS-CMP)为例，数据库审计与日志审计、运维堡垒机同处一台设备，数据库侧的可疑操作可以与运维侧的操作记录相互印证——同一时间点的敏感数据导出，如果对应着一条异常来源的运维登录，性质就完全不同了。

还有一点需要提前规划：数据库的访问来源本身就是多样的。业务应用、报表工具、运维客户端、数据同步任务，都会建立数据库连接。审计策略要能把这些来源区分开，而不是统一记成一句「某账号访问了数据库」。

这也解释了为什么「访问工具名」这个字段值得单独列出来——它是区分正常业务流量与人工操作的重要依据。

六、审计与其他能力的配合

审计很少单独发挥作用，它和另外几项能力的配合比较紧密。

一是和数据分类分级配合。分级结果告诉审计「重点看哪些表、哪些字段」，审计才可能在海量记录里抓住关键行为，而不是把整库的访问都当成同等重要。

二是和数据库防火墙配合。防火墙负责把不该发生的访问拦下来，审计负责把已经放行的访问记下来。两者的记录放在一起，才能判断一次攻击尝试到底是被挡回去了，还是成功得手了。

三是和运维堡垒机配合。数据库侧的敏感操作与运维侧的操作记录相互印证，直接回答了「是谁、在什么场景下动了这些数据」这个问题——这往往是事后复盘里最关键的一环。

四是和日志审计配合。数据库的异常访问如果同时伴随服务器登录异常或边界攻击告警，事件的性质会完全不同。单独看任何一条记录，都可能被当成正常业务放过。

最后提一个容易被忽略的准备动作：在建设阶段就把审计记录的检索方式想清楚。测评现场最常见的场景，是检查人员当场提出一个具体问题——「某张表在某天的访问记录能不能调出来」。能不能在几分钟内给出答案，直接反映这套审计是否真的可用。

另一个动作是把告警处置流程写下来。告警产生之后由谁确认、多长时间内响应、确认后如何记录，这些如果没有事先约定，告警就只是屏幕上的一行提示。

七、小结

审计在数据安全里的角色，是让「管住了」这件事变得可证明。对需要通过测评的单位来说，这份证明能力与防护能力同等重要。

推进这项工作，建议从三件事入手：先把记录维度配齐，再把风险策略调到贴合自身业务的水平，最后把报表与留存周期按周期化方式设好。三件事做完，审计才算真正跑起来。