数据库审计中几个大问题.docVIP

编码问题 描述:由于现在大部分的审计系统都是基于旁路的方式(对网络数据包的采集分析）,另外，不同的数据库系统、不同的操作系统平台都存在不同的编码或字符集问题,要找到一种统一的编码方式进行完全解决是比较困难的，因此对于编码这种问题，包括其他软件的做法，要么只支持几种编码,要么把网络传输的原始信息展示出来然后让用户自己去选择适合的编码。这好比我们的浏览器、邮件接收客户端程序中都有一个编码选择的功能。如下图1、图2所示： 图1　浏览器中的编码选择 图2 Foxmaiｌ中的编码选择功能 现状:因此,该问题应该是每个数据库审计厂商都会碰到的问题，只是处理方式不一样而已。为什么这么说呢？我们先来看下其他一些产商的一些描述或功能 (1）杭州安恒明御: 图3 通过对特定包进行采集，然后进行二次分析，以解决协议解析问题及编码问题 (2）Guａrｄium 图4 Guaｒｄiｕｍ中出现的协议解析或乱码问题 中间件问题 描述：关于中间件，在维基百科中是如下定义的： HＹＰEＲLＩNK 中间件，是提供　HYPERＬINK　＂ \o　＂系统软件＂ 系统软件和 HYPERLＩNK　 \ｏ 应用软件 应用软件之间连接的软件，以便于 HYＰEＲＬＩＮK \ｏ ＂软件 软件各部件之间的沟通，特别是应用软件对于系统软件的集中的逻辑，在现代信息技术应用框架如 HＹＰEＲLINK ＂ ＼o　＂Weｂ服务 Ｗeb服务、　HYＰERLINK \ｏ 面向服务的体系结构＂ 面向服务的体系结构等中应用比较广泛。如 HYＰEＲＬＩNＫ ＂ ＼o　数据库 数据库、Ａｐａｃhe的Tomcaｔ,IBＭ公司的WｅbＳphere,BＥA公司的WebＬogｉc　HYPＥRＬINK ＼ｏ ＂应用服务器（尚未撰写) 应用服务器以及Kiｎgｄeｅ公司的 HＹPＥRLINK ＂ ＼o Ａpuｓｉc(尚未撰写) Ａpｕsic等都属于中间件。严格来讲，中间件技术已经不局限于应用服务器、数据库服务器。围绕中间件,Apachｅ组织、IＢM、Oracｌe(BＥA)、微软各自发展出了较为完整的软件产品体系。 下图是目前典型的ＷEＢ服务器架构，其中中间件部署在WＥB服务器上。 ? 对于有中间件应用的用户，都是希望能够将WEB服务器与数据库服务器之间的数据库操作与前端浏览器的IＰ地址等信息进行关联，以追溯到真正的操作源信息。 现状:目前的旁路监听的数据库审计系统一般只能够审计到WEB服务器与数据库服务器之间的数据库操作，由于在ＷEＢ服务器和数据库服务器之间的通讯没有包含浏览器与WＥB服务器之间通讯的相关信息或唯一标识信息，因此要把WEB服务器与数据库服务器的操作与前端浏览器的信息(IP、URL等）进行准确关联是比较困难的。也许，你会问,既然是这样的话,那么数据库服务器怎么知道要把返回的信息给那个浏览器呢?其实，这个工作是由WＥB服务器来完成的,在WEB服务器中有对应于每个客户端的线程或标记来区别来自于不同浏览器或不用会话的请求。如下图所示： 由于，前后唯一性关联是有WEＢ服务器或中间件来完成，那么在网络传输过程中就很难找到这种关联关系,因为在网络上可能并没有包含这些关联信息。那么，目前的旁路数据库审计产商是如何来处理这个问题呢?由于中间件应用没有一个统一的标准，因此要自动识别各种中间件的应用时比较难的,目前的做法大部分是通过对前端浏览器与WEB服务器之间的ＨTTP通讯协议进行分析,根据对UＲL、时间片及一些关键信息进行分析，然后再与后端的数据库操作进行关联来实现的。这样的做法，只能是缩小操作源的范围,并不能非常准确地定位到前端的实际操作源，这时由于在高峰情况下,每秒可能有上千个浏览器对ＷEB服务器进行访问，这时候如何区分那个浏览器访问与后端的数据库操作一一对应是比较难的,因此可能会存在关联出错的现象。另外，前端多个浏览器并发访问WEB服务器,而后端ＷEB服务器可能只通过一个会话去访问数据库服务器,也就是说，前后通讯并不是一一对应的，这种情况也给前后关联增加了难度。 阻断问题 描述：阻断是对一些已知异常或认为是异常的操作行为进行阻止，以事前避免不必要的损失,这应该是大多数用户希望最终能达到的效果。 现状：然而,目前从技术上来说,主要是如下四种实现方式: （1)将审计设备内联到系统的业务环境中,这有点类似于数据库防火墙,即在用户的生产数据库前面假设个“关卡”,所有要访问数据库的操作都需先经过审计设备,只有审计设备允许了才能够对生产数据库进行访问。对于这种方式的阻断，对审计设备的数据包的转发处理处理能力及审计规则的准确性要求很高,并且也会由于“单点故障”导致整个业务不能正常运行。目前,尚未接触过用户使用过此方式进行审计。(IMＰERVA支持该方式） (2)发送TCP RESEＴ包实现阻断，这种方式的实现方法如