数据库审计如果审不准，要它何用？-凯发k8游戏

目前，数据库审计是数据库安全市场中接受度最高的产品，但即使该产品几乎是数据库安全的首选，但真正用起来的概率并不乐观，不少已经沦为僵尸机，更多时候只是为了应付检查，满足合规。其最根本的风险监控预警能力根本没有得到释放。

怪用户安全意识不强？当然不完全是。我们经手的不少审计项目并不是没有数据库审计系统，而是原品牌替换，询问原因常听到这样的回答：

产品不好用。该风险告警的时候不报，正常操作却没完没了的报，真要是天天开着，光是处理误报就要耗费很大精力。

为什么会有这么多误报？sql语句解析是关键。

目前市面上的数据库审计产品按照解析方式的不同主要有两类，一类是基于语法语义进行协议解析的审计技术；一类是基于正则表达式匹配的审计技术，大多数采用后者。而在实际测试中，后者的准确率明显低于前者。原理是什么？我们简单分析：

基于语法语义的解析技术

这种解析技术采用的是“智能”理解的方式，不受限于sql语句长度、复杂度等影响，能够精确定义每一条sql语句，准确理解其真正的含义，从而实现精准告警。

基于正则表达式的解析技术

正则表达式是一种“傻瓜式”的通用字符串匹配的方法，通常用于简单的场景匹配指定字符。对于超长的、多层嵌套、多表关联等复杂的sql语句，使用正则表达式很容易造成误识别或漏识别。

有点听不懂？举个栗子：

你希望的安全策略是：仅对b表插入数据的sql操作定义为风险。

语法语义解析的思路：语句操作关键字为insert into并且作用表对象为b。

正则表达式配置规则思路：语句中包含insert into、b等关键字。

这时候，数据库接收到这样一条访问请求：

insert into a select * from b;

识别结果将会是这样：

语法语义解析后：识别该语句将test b中的所有数据插入到a中，准确判定为非风险操作——不予告警

正则表达式匹配sql后：发现该语句中包括insert into和b关键字，识别为风险操作——进行告警

除了sql语句解析能力，通过在应用系统中部署agent，可以准确将应用会话与数据库会话做唯一的组合匹配，有了唯一的组合匹配即可实现百分百的信息关联。而传统数据库审计通常是通过同时镜像应用前端的流量做通过时间戳的匹配关联，此种做法往往会在高压、高并发的场景中造成“张冠李戴”的错审现象。

审计产品如果连基本的准确性都没办法保障，要它何用呢？仅从技术视角做两种审计产品的对比科普，如何让产品价值完美匹配用户需求，请诸君巧思量。