实用 | 数据库审计产品关键指标与选型建议

正确的产品选型，意味着什么？

对于数据库审计产品而言，正确的选型将直接决定其在未来的应用过程中能否真正发挥出审计的价值！为了帮助广大用户更加合理地选择符合自身需要的数据库审计产品，安华金和根据以往众多项目中的选型经验总结，针对四点关键技术性指标进行分析，并提出参考建议：

技术指标一：准确性

1

会影响数据库审计准确性的因素

· 数据库系统的复杂性大型数据库系统的通讯协议是异常复杂的，为了进行准确的审计，审计产品需要对各种数据库通讯协议进行分析，以还原通讯包中的通讯协议结构，继而准确识别SQL语句、SQL句柄、参数、字符集等信息，技术的复杂性与困难度可想而知；
· 业务系统使用数据库技术的复杂性以银行为例，其业务系统通常由很多参数化语句组成，且每个参数化语句对应一个SQL游标（又称SQL句柄），并使用SQL游标和参数绑定来执行命令；在这种情况下，审计产品必须准确还原数据库通讯协议包中的SQL游标和Bind Variable的值，同时将SQL游标和参数化SQL语句准确关联还原，才能够实现准确的审计；否则，会因为无法识别通讯协议导致数据漏审，而一旦出现审计数据的大量漏审，那么审计工作的价值便无从谈起了，就连合规监测也会受到严重影响。

2

有效验证审计产品准确性的方法

安华金和建议：在选型过程中，尽量采取复制关键业务系统一段时间（最好是业务高峰期）的数据库访问网络流量作为审计基准流量包，并通过重放审计基准流量包，对不同厂商所提供的数据库审计产品进行审计量和审计内容准确性的对比。这是非常有效的一种选型方式——因为最贴近业务，所以也最能体现数据库审计产品的审计准确性和成熟度。

技术指标二：性能

如果说“准确性”是数据库审计的“前提和基础”，那么“性能”就是衡量这一工作“完成效率”的重要指标。不过，判断一款数据库审计产品“性能”的好坏不能光看“表面”，真实情况可能没那么简单。

1

性能瓶颈下的“错觉”

首先要强调的是，任何一款数据库审计产品都存在性能瓶颈；正因如此，用户需要关注一种可能发生的情况，即有些数据库审计产品无论面对多么大的压力测试，其资源消耗始终维持在一个基本不变的水平，也未发出任何“压力告警”提示信息；然而真实情况却是，丢失审计数据的情况已经且正在发生，为什么会出现这种问题？往往是因为这类数据库审计产品通过某些技术配置，将超限的流量“默默丢弃掉”，以维持表面上的“性能错觉”。
对此，安华金和建议通过以下两种方法进行测试：· 测试方法一使用从生产系统通过流量复制获得的基准压力测试流量包，并通过不同的压力进行流量包重放，以观察审计产品在何种的压力下会出现较大规模的审计数据丢失情况。· 测试方式二在相同压力下，对多个审计产品进行对比测试；通过对比审计量，可较为清晰地看出不同审计产品的能力水平。

2

不应缺失的“超限告警”

由于数据库审计产品采用旁路部署的方式，所以会在审计流量超限时，保护性地丢弃无法处理的流量；但是，如果产品本身不具备较为准确的超限告警能力，用户方面就无法及时知晓是否发生了流量超限的情况，也无从判断是否出现了大规模审计数据丢失的问题，更不可能依据流量超限的真实情况进行准确应对。所以说，是否具备准确的“超限告警”能力，对判断数据库审计产品真实性能的具有重要意义。

技术指标三：探针

随着云和虚拟化环境的广泛应用，需要通过部署审计探针来应对上述无法进行流量镜像的场景；正因如此，探针的流量采集性能，以及部署探针对用户主机资源、网络资源的影响等，成为了数据库审计产品选型的重要技术指标之一。

1

探针的流量采集性能

部署探针后，可通过压力测试，检测其在审计流量发生较大规模丢失时的性能表现。

2

探针的资源可调能力

探针的资源可调能力，主要是为解决以下两种情况：· 如果探针对资源占用不合理，会严重影响服务器的业务处理能力；· 探针需要复制数据库流量并通过网络传输至审计设备，而这也意味着增加了一倍的数据库流量；如果对流量传输的控制不合理，就会造成带宽不足，并严重影响服务器的业务处理能力。

根据以上情况，安华金和建议在数据库审计产品选型时，对审计探针是否具备“资源占用监测及可调节能力”进行重点考量：
· 探针支持自我调节能力，可最大限度减少对数据库服务器的影响；可提供CPU、MEM、带宽等多种压力识别检测手段，从而动态调整对数据库流量采集的配置参数；· 可根据动态阈值检测机制调整探针工作状态，通过对不同级别限速（动态限速）或休眠主动挂起以降低对网络带宽的占用，从而保证业务的正常进行；· 具有探针状态监控、远程控制启停等管理功能，从而在大规模、分布式项目部署大量探针的情况下，能够实现集中监测与管理。

技术指标四：灵活性

要知道，不同的用户有着不同的场景、需求和痛点。从实用性的角度来看，是否能够更加灵活地配置审计规则，帮助用户更好地解决问题，是对数据库审计产品的一大考验。安华金和建议从以下三点，对数据库审计产品的“灵活性”进行考量：

（1）默认情况下，产品进行全流量审计；
（2）如果需要根据用户需求及其数据资产的重要性、访问边界或区域等进行有选择性的审计工作，则需要产品具备灵活的审计策略配置能力。例如：可针对登录行为（会话规则）和操作行为（操作规则）配置审计/不审计的规则；可支持包括访问来源、常用操作、指定对象操作在内的丰富的规则项等；
（3）当有人在运维区“批量查询手机号”时，需要数据库审计产品能够识别这一“风险操作”，并实现对个人信息的访问追溯和监测——记录下进行风险操作人员的信息及其查询过的全部手机号，便于事后追溯及追责、定责；但是，如果审计产品仅具备面向全局的“结果集审计”功能，则会“无选择性”地记录所有SQL语句的结果集，从而造成用户存储空间的极大浪费，并严重干扰审计工作的成效。因此，审计产品需要具备“按规则进行结果集审计”的能力，即支持设定“被规则条件命中后“再执行结果集审计动作的功能，而其他未被规则命中的SQL操作则不执行。

【了解更多】