数据库审计的四种类型

一个企业的最核心资产莫过于数据，在互联网企业则是更甚。

1、旁路型

旁路审计几乎是传统乙方安全厂商最常见的模式，通过网络设备镜像流量，审计设备解码组包 DB 流量，并存储分析，通过模型检测和追溯可疑和高危事件。

这样的架构好处在于部署简单，对于业务方和用户来说几乎是透明的，部署过程无需业务方参与。同时对业务几乎无性能损耗，这也是业务方最关注的一点。

2、主机型

旁路型固然有它的优势，但当面对复杂的业务架构的时候就力不从心了。业务被要求敏捷迭代，新架构层出不穷。大型互联网公司业务环境每日大量的变更，以至于想完全梳理清楚其网络架构特别是 DB 访问模型几乎是不可能的事，至少很难在一个较短的时间内有一个相对静止的架构图。

审计产品尽量靠近 DB 本身部署，最近的莫过于部署到 DB Server 主机上，这就是主机型产品的由来。主机型的 DB 审计产品可以是单个进程也可以是 HIDS 的某个模块。

3、代理型

在业务架构治理做得较好的公司，他的业务数据读写均有统一的接口，无论业务逻辑多么复杂，其 DB 流量都是统一的入口，那么在这些接口位置增加 DB 审计功能是最完美的方案。

这样的架构带来了一个近乎完美的产品形态，有以下诸多优点：

• 部署：不需要像其他产品一样逐一去网络节点或主机部署，其数据采集和 filter 功能原生集成在业务架构里。

• 减少性能开销，基于 DB 协议的数据旁路，不需要基于网络报文数据的处理，组包等开销。

4、攻击检测

DB 审计安全产品主要解决两个问题：1）SQL 注入拖库；2）操作违规审计。

对于违规审计没有太多需要讲的，通过对日常的 DB 请求做好基线学习，超出基线范围之外的则为违规行为。基线学习的维度可以有以下几个：

• 账户对应的常用 DB 访问映射。

• 账户常用的 function。

• 账户+client_ip 与 tables 的映射。

• 应用与数据字段的映射。

• 自然时间+频度与裤表的映射。

虽然基线学习主要用于审计，但对于业务相对固定以及安全检测覆盖范围较小的安全系统来说，用于做攻击检测也是够用的。因为攻击行为也是超出基线范围的。

对于业务较多、变更较多的企业，上述方式用于攻击检测显然不适合了，相对于业务的生命周期、变更周期来说基线的学习期过长。

SQL 注入攻击通常的检测方式是使用相对固化的字符串特征匹配，而这类检测方式会面临各种变形 SQL 语句的绕过攻击。事实上无论黑客如何变换攻击负载，它最终要能被 DB 解析，满足语法要求。那么通过语法解析器的还原，任何的伪装均会褪去。

语法解析之后的语句就需要定义辨别是否恶意的请求了，诸如以下几种场景：

• 有多个子查询、联合查询且查询系统库表。

• 可能导致 SQL 查询失败的语句。

• 多个联合查询，且子查询非业务所需库表。