虚拟化及云环境下数据库审计技术探讨

随着越来越多的企业用户将传统的业务系统迁移至虚拟化环境或是云服务商提供的云平台，数据的泄露及篡改风险变的越发严峻，针对数据安全的防护以及事后审计追溯也变得越来越困难。究其原因，主要是传统的数据库审计解决方案是通过旁路分析目标被审计数据库镜像的流量，而虚拟化环境或者云平台由于内部的虚拟交换机（Vswitch）流量很难镜像或者无法镜像，因此传统的数据库审计解决方案不足以应对虚拟化和云平台的数据库审计需求。

首先我们对虚拟化及云平台环境中，传统的数据库审计解决方案在典型的几种场景下的优缺点进行解析：

场景一：应用和数据库的虚拟主机不在同一台物理机器上

如下图所示这种情况下的应用和数据库虚拟主机不在同一台物理机器上，对传统数据库审计来说，可以采用传统方式直接镜像数据库服务器所在的物理宿主主机（物理机器4）网卡的流量，完成对目标数据库的审计，缺点是需要将虚拟机流量全部镜像过去，同时可能会导致一些无需审计的主机的数据的泄露，这是这种解决方案最大的一个风险。

场景二：应用和数据库的虚拟主机在同一台物理机器上

针对应用和数据库在同一台物理机器上，应用和数据库的交互过程通过内部的Vswitch进行了流量转发，流量并不通过所在的物理机器的宿主主机网卡，因此采用传统的镜像流量根本无法镜像，如下图所示：

针对这种情况传统数据库解决方案有三种方法解决：

a、 虚拟机虚拟网卡绑定物理网卡

要求宿主主机有多个物理网卡，每个物理网卡和上层交换机直连，虚拟机层面在安装时可以指定将虚拟网卡绑定在对应的宿主主机的物理网卡上，然后使用传统的镜像方式镜像物理网卡的流量完成审计，这种缺点非常明显，要求物理服务器要有多个网卡，实际上大部分PC服务器只有不超过1-4个网卡端口，大部分物理机器上虚拟了几十个虚拟机，因此，在实际部署上并没有那么多网卡可供绑定，存在诸多限制，实际上并无法实施。

b、 在ＶＤＳ上配置流量镜像

Vmware ESX在最新版本中推出的功能，将某虚拟机网卡流量通过GRE封包，直接通过TCP协议发送到某个IP地址上（数据库审计设备），数据库审计设备接收GRE数据包完成审计，但是这种解决方案的缺点如下：

Vmware版本及VDS（分布式虚拟交换机），据官方技术资料只有Vmware 5.5以上版本才支持，目前客户现场主流的4.x、5.0、5.1等版本都不支持，其他非Vmware虚拟化环境就更不支持，因此针对大部分客户现场环境实际并不支持部署。

通过GRE封装做流量镜像对宿主主机的物理网卡性能影响非常严重，所有镜像流量都要通过宿主主机的物理网卡进出，极大影响了物理网卡的性能。

VDS属于虚拟交换机，其对数据包的处理完全依赖于CPU，并不像传统交换机靠硬件进行流量转发，因此对宿主主机的CPU资源占用也非常严重，极大的降低了宿主主机的性能。

c、 开启流量广播

这种方式目前是最主流的方式，将数据库审计以虚拟机的方式部署在对应的宿主主机，当做宿主宿主机的一个虚拟机看待，然后开启Vmware的流量广播功能，每个虚拟机都将收到Vswitch上每个端口通信的IP流量，因此DB审计设备只需要采集其虚拟网卡上的流量就可以采集到目标数据库服务器的流量，只需要在采集阶段过滤掉其他流量即可完成审计，如下图所示：

这种解决方案的缺点也非常明显：

开启流量广播虽然大部分Vswitch都支持，但是这种方式就好比早期的Hub一样，tcp通信能力将明显降低，严重影响整体网络传输的时延及可靠；

DB审计可以采集到所有虚拟机的流量，其他虚拟机一样也会采集到所有的流量，这些流量里肯定包含很多未加密的敏感数据如用户名、密码等，假设这些虚拟机中有一台机器被入侵或者非法利用，这样会带来极大的安全问题。

场景三：应用和数据库的虚拟主机随机的分配在一个虚拟化集群的某个主机上

这种场景其实是场景一和场景二的结合，目前大部分客户为了避免单一硬件的故障，基本上都采用虚拟化集群的方式实现企业的虚拟化，当碰到单一硬件的故障，虚拟机会在整个硬件虚拟化资源池中自动迁移，具体迁移到哪台物理主机上并不确定，因此传统的镜像方式并不能确定虚拟主机此刻在哪个交换机上，如下图所示：

因此在这种场景下同样无法做镜像，只能把虚拟化集群所有主机的流量全部镜像出来，这种缺点也非常明显：

当出现业务和DB在迁移到同一个物理机器上时，其实并没有流量，实质上审计不到任何数据，这个时候是存在严重的漏审计；

虚拟化集群涉及的机器比较多，流量非常大，网络可能也比较复杂，传统的镜像方式很难在实际中进行配置，因此很难实施；

场景四：应用和数据库分别托管部署在完全独立的第三方云计算平台

场景四是场景三的一种延伸与扩大，场景四主要指目前主流的第三方云平台提供商如阿里云、亚马逊、腾讯云、华为云、百度云等等，底层的硬件、存储、网络等等都对用户不透明，上层的虚拟机具体在哪个物理硬件服务器上，连接哪个物理交换机，用户一概不知道，如下图所示：

因此要用传统方式配置镜像，基本上没有可能，云平台提供商并不会提供底层资源的控制权给云主机租户，因此对这种场景的数据库要进行审计，传统数据库审计解决方案将彻底无能为力。

综上所述，在虚拟化和云环境平台中，只有场景一，传统的数据库审计解决方案勉强可以解决。针对场景二传统数据库审计解决方案基本上是不支持，部分情况即使支持也是有非常明显的缺点及种种环境的限制，针对场景三、场景四传统的解决方案直接是无法支持。

针对虚拟化环境和云平台中的数据库审计难题，安恒信息推出了全新架构的虚拟化云环境Agent代理审计解决方案。通过在虚拟主机上部署Agent，以不变应万变，全面支持以上描述的四种典型场景，这种解决方案由Agent对数据库的请求行为直接进行处理，处理完成之后由Agent直接将数据发给采集器统一检测、告警、存储及挖掘分析，彻底解决了各种虚拟化、云环境数据库无法审计的难题。具体部署拓扑图如下图所示：

本解决方案有以下优点：

全面支持所有虚拟化环境和云环境的数据库安全审计，不区分业务部署架构、底层虚拟化软件架构和底层的网络架构，不依赖传统的交换机流量镜像；

支持部署在虚拟化环境中所有的Linux 2.6以上内核版本、及windows2003、2008、2012等版本；

支持主流的Oracle、SQL Server、DB2、Sybase、Mysql、Lnformix等数据库，同时支持达梦、人大金仓、Oscar、Gbase等国产数据库，还支持cache、teradata、postgresql等数据库的审计；

部署简单，支持一键安装；

对虚拟主机的性能影响可以忽略不计，经实际阿里云环境虚拟主机测试，DB服务器流量在120Mb以内，agent对目标服务器的性能影响在3-8%之内。

随着虚拟化、云计算技术的不断成熟，业务迁移到云端也是不可逆的趋势，未来将会有越来越多的企业、政府、个人用户将应用系统及数据库逐渐迁移到自主搭建的私有云中，或者是第三方服务商提供的公有云平台中，企业、政府的核心敏感数据托管在云环境中，面临着各种窃取、篡改的威胁，数据的安全审计将越发重要，传统的数据库审计产品将逐步被下一代数据库审计产品所替代，安恒明御数据库审计产品将继续作为行业的领导者，在虚拟化、云计算时代继续为用户的数据库安全审计保驾护航。