一个企业的最核心资产莫过于数据，在互联网企业则是更甚。
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查询失败的语句。
- 多个联合查询，且子查询非业务所需库表。
