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

虚拟化及云环境下数据库审计技术探讨 　　随着越来越多的企业用户将传统的业务系统迁移至虚拟化环境或是云服务商提供的云平台，数据的泄露及篡改风险变的越发严峻，针对数据安全的防护以及事后审计追溯也变得越来越困难。究其原因，主要是传统的数据库审计解决方案是通过旁路分析目标被审计数据库镜像的流量，而虚拟化环境或者云平台由于内部的虚拟交换机(Vswitch)流量很难镜像或者无法镜像，因此传统的数据库审计解决方案不足以应对虚拟化和云平台的数据库审计需求。　　首先我们对虚拟化及云平台环境中，传统的数据库审计解决方案在典型的几种场景下的优缺点进行解析：　　场景一：应用和数据库的虚拟主机不在同一台物理机器上　　如下图所示这种情况下的应用和数据库虚拟主机不在同一台物理机器上，对传统数据库审计来说，可以采用传统方式直接镜像数据库服务器所在的物理宿主主机(物理机器4)网卡的流量，完成对目标数据库的审计，缺点是需要将虚拟机流量全部镜像过去，同时可能会导致一些无需审计的主机的数据的泄露，这是这种解决方案最大的一个风险。　　场景二：应用和数据库的虚拟主机在同一台物理机器上　　针对应用和数据库在同一台物理机器上，应用和数据库的交互过程通过内部的Vswitch进行了流量转发，流量并不通过所在的物理机器的宿主主机网卡，因此采用传统的镜像流量根本无法镜像，如下图所示：　　针对这种情况传统数据库解决方案有三种方法解决：　　a、 虚拟机虚拟网卡绑定物理网卡　　要求宿主主机有多个物理网卡，每个物理网卡和上层交换机直连，虚拟机层面在安装时可以指定将虚拟网卡绑定在对应的宿主主机的物理网卡上，然后使用传统的镜像方式镜像物理网卡的流量完成审计，这种缺点非常明显，要求物理服务器要有多个网卡，实际上大部分PC服务器只有不超过1-4个网卡端口，大部分物理机器上虚拟了几十个虚拟机，因此，在实际部署上并没有那么多网卡可供绑定，存在诸多限制，实际上并无法实施。　　b、在VDS上配置流量镜像　　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在迁移到同一个物理机器上时，其实并没有流量，实质上审计不到任何数据，这个时候是存在严重的漏审计;　　◆虚拟化集群涉及的机器比较多，流量非常大，网络可能也比较复杂，传统的镜像方式很难在实际中进行配置，因此很难实施;　　场景四：应用和数据库分别托管部署在完全独立的第三方云计算平台　　场景四是场景三