如何避免数据库行为监控系统部署问题？

【按】本文是SIEM及DAM咨询公司Securosis的一个关于数据库审计产品的文章，载于TT安全。

在部署数据库行为监控（DAM）系统时有两个最常见的问题：数据采集的准确性问题和DAM系统的性能问题。这篇文章，我们将讨论如何避免掉入DAM的上述陷进中。

　　不当的监控方式会影响审计的准确性

　　DAM产品一个经常被忽视的缺点就是网络监视。对于非关键的数据库基础设施，通过网络监视采集SQL行为是可行的。但如果出于合规需要，则最好选择代理型的DAM产品。这类产品通过在数据库平台上安装代理来检测所有的数据库连接，包括管理员的行为。

　　上述两种采集方式都能够收集各种原始SQL语句，包括嵌入在查询中的变量，而这是系统自带的审计以及大部分其他采集方式所无法做到的。然而，对于网络流量检测和基于代理的检测两种部署方式而言，在数据收集的准确性和完整性方面有着很大的差别。在高负载的情况下，某些方法就会丢失数据包。由于丢失查询语句很少被注意到，通常不会引起什么抱怨。但是如果正在对一组事务（译注：事务即Transaction，属于数据库管理系统的术语，相当于一组数据库操作的集合）进行SOX合规审计，那么丢失的事务记录将导致审计报告失效。

　　第二个不易察觉的严重问题是DAM系统收集SQL语句返回信息的能力很弱。所有的查询都会产生响应，一般是一组数据，有时候则仅仅是一个标志成功或者失败的返回码。如果一个查询失败，查询没有被真正执行，这就意味着数据库没有发生变化。最近我做的一项非正式的调查显示某个产品仅仅能够收集45%的微软SQL Server数据库的返回信息，以及15%的Oracle返回信息。仅仅因为一条查询请求被收集到了，并不意味着它就能够成为审计线索的合法部分，还要看这个查询请求的响应信息。

　　正是由于这些原因，在合规审计的背景下，最好的部署方式是将网络代理方式或者内存扫描器方式与系统自身的审计数据收集方式结合起来。将系统自身的审计信息与（通过网络检测或者代理检测等方式获得的）包含在原始查询中的数据结合起来，提供了一种两全其美的确保数据准确性的方法。

　　策略过载和性能过载

　　性能依然是数据库行为监控系统需要关注的一个问题。对于任何一款安全产品，随着在产品中生效的策略数量的增长，行为分析所需的整体计算开销会出现超负荷。每条收集到的查询语句或者事务执行语句都要匹配所有的策略，策略数量从20条增长到40条与每天分析的事务数从200万条到400万一样，都会对性能产生影响。因此，DAM产品的性能极限既取决于分析的事务数，也取决于生效的策略数。

　　要使得DAM产品性能维持在可接受的水平，可以遵循以下几条指南*：

　　1）行为分析策略会使得行为资料数据随行为分析的进行而增长。应该尽量保持行为资料数据最小化，因为对这些资料的分析更加复杂。
　　2）要决定 DAM系统何时匹配这些策略。在收集到记录（即行为资料数据）后进行策略匹配，还是在将记录存储到DAM产品后再进行策略匹配？存储延迟和对收集到的记录的再查询都会造成额外的计算开销，显然对产品提供商而言不是一个好的选择。
　　3）要对策略进行优化，尽量使得策略匹配过程中最快和最简单的部分被首先执行。这就跟查询语句的优化是一个道理，策略的规则表达方式对于性能会产生戏剧性的影响。重新评估和优化那些策略规则，同时，必要的话，让DAM供应商重写那些低效的规则。

 

【*注释】文中Policy和profile（records）之间的关系最关键。根据我们设计DAM产品的经验，DAM系统在policy的作用下，在进行数据检测的时候会有选择的进行抓包和协议还原，将符合策略的SQL语句（Transaction）记录下来，称作profile，进行进一步的策略匹配。这个匹配可以在内存中进行，也可以在记录存储到DAM的后台数据库后进行。显然，1）被匹配的记录量越小越好，越小效率越高。2）内存即时匹配比存储后再匹配更高效。另外，策略一般包括规则和动作两个部分，其中规则部分的表达方式跟SQL语句很类似，说白了就是一组if then else，以及各种逻辑表达式。就像SQL语句要优化，以提升查询效率一样，策略的规则也要进行优化，以提升匹配效率。