原标题：虚拟化及云环境下数据库审计技术探讨
随着越来越多的企业用户将传统的业务系统迁移至虚拟化环境或是云服务商提供的云平台，数据的泄露及篡改风险变的越发严峻，针对数据安全的防护以及事后审计追溯也变得越来越困难。究其原因，主要是传统的数据库审计解决方案是通过旁路分析目标被审计数据库镜像的流量，而虚拟化环境或者云平台由于内部的虚拟交换机（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审计设备只需要采集其虚拟网卡上的流量就可以采集到目标数据库服务器的流量，只需要在采集阶段过滤掉其他流量即可完成审计，如下图所示：
　　这种解决方案的缺点也非常明显：
　　1、开启流量广播虽然大部分Vswitch都支持，但是这种方式就好比早期的Hub一样，tcp通信能力将明显降低，严重影响整体网络传输的时延及可靠；
　　2、DB审计可以采集到所有虚拟机的流量，其他虚拟机一样也会采集到所有的流量，这些流量里肯定包含很多未加密的敏感数据如用户名、密码等，假设这些虚拟机中有一台机器被入侵或者非法利用，这样会带来极大的安全问题。
　　场景三　：应用和数据库的虚拟主机随机的分配在一个虚拟化集群的某个主机上
　　这种场景其实是场景一和场景二的结合，目前大部分客户为了避免单一硬件的故障，基本上都采用虚拟化集群的方式实现企业的虚拟化，当碰到单一硬件的故障，虚拟机会在整个硬件虚拟化资源池中自动迁移，具体迁移到哪台物理主机上并不确定，因此传统的镜像方式并不能确定虚拟主机此刻在哪个交换机上，如下图所示：
　　因此在这种场景下同样无法做镜像，只能把虚拟化集群所有主机的流量全部镜像出来，这种缺点也非常明显：
　　1、当出现业务和DB在迁移到同一个物理机器上时，其实并没有流量，实质上审计不到任何数据，这个时候是存在严重的漏审计；
　　2、虚拟化集群涉及的机器比较多，流量非常大，网络可能也比较复杂，传统的镜像方式很难在实际中进行配置，因此很难实施；
　　场景四：应用和数据库分别托管部署在完全独立的第三方云计算平台
　　场景四是场景三的一种延伸与扩大，场景四主要指目前主流的第三方云平台提供商如阿里云、亚马逊、腾讯云、华为云、百度云等等，底层的硬件、存储、网络等等都对用户不透明，上层的虚拟机具体在哪个物理硬件服务器上，连接哪个物理交换机，用户一概不知道，如下图所示：
　　因此要用传统方式配置镜像，基本上没有可能，云平台提供商并不会提供底层资源的控制权给云主机租户，因此对这种场景的数据库要进行审计，传统数据库审计解决方案将彻底无能为力。
　　综上所述，在虚拟化和云环境平台中，只有场景一，传统的数据库审计解决方案勉强可以解决。针对场景二传统数据库审计解决方案基本上是不支持，部分情况即使支持也是有非常明显的缺点及种种环境的限制，针对场景三、场景四传统的解决方案直接是无法支持。
　　针对虚拟化环境和云平台中的数据库审计难题，安恒信息推出了全新架构的虚拟化云环境Agent代理审计解决方案。通过在虚拟主机上部署Agent，以不变应万变，全面支持以上描述的四种典型场景，这种解决方案由Agent对数据库的请求行为直接进行处理，处理完成之后由Agent直接将数据发给采集器统一检测、告警、存储及挖掘分析，彻底解决了各种虚拟化、云环境数据库无法审计的难题。具体部署拓扑图如下图所示：
　　本解决方案有以下优点：
　　1、全面支持所有虚拟化环境和云环境的数据库安全审计，不区分业务部署架构、底层虚拟化软件架构和底层的网络架构，不依赖传统的交换机流量镜像；
　　2、支持部署在虚拟化环境中所有的Linux 2.6以上内核版本、及windows2003、2008、2012等版本；
　　3、支持主流的Oracle、SQL Server、DB2、Sybase、Mysql、Lnformix等数据库，同时支持达梦、人大金仓、Oscar、Gbase等国产数据库，还支持cache、teradata、postgresql等数据库的审计；
　　4、部署简单，支持一键安装；
　　5、对虚拟主机的性能影响可以忽略不计，经实际阿里云环境虚拟主机测试，DB服务器流量在120Mb以内，agent对目标服务器的性能影响在3-8%之内。
　　随着虚拟化、云计算技术的不断成熟，业务迁移到云端也是不可逆的趋势，未来将会有越来越多的企业、政府、个人用户将应用系统及数据库逐渐迁移到自主搭建的私有云中，或者是第三方服务商提供的公有云平台中，企业、政府的核心敏感数据托管在云环境中，面临着各种窃取、篡改的威胁，数据的安全审计将越发重要，传统的数据库审计产品将逐步被下一代数据库审计产品所替代，安恒明御数据库审计产品将继续作为行业的领导者，在虚拟化、云计算时代继续为用户的数据库安全审计保驾护航。更多内容安全内容详见商业新知-内容安全

        
        
                
    

                    
原标题：虚拟化及云环境下数据库审计技术探讨
随着越来越多的企业用户将传统的业务系统迁移至虚拟化环境或是云服务商提供的云平台，数据的泄露及篡改风险变的越发严峻，针对数据安全的防护以及事后审计追溯也变得越来越困难。究其原因，主要是传统的数据库审计解决方案是通过旁路分析目标被审计数据库镜像的流量，而虚拟化环境或者云平台由于内部的虚拟交换机（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审计设备只需要采集其虚拟网卡上的流量就可以采集到目标数据库服务器的流量，只需要在采集阶段过滤掉其他流量即可完成审计，如下图所示：
　　这种解决方案的缺点也非常明显：
　　1、开启流量广播虽然大部分Vswitch都支持，但是这种方式就好比早期的Hub一样，tcp通信能力将明显降低，严重影响整体网络传输的时延及可靠；
　　2、DB审计可以采集到所有虚拟机的流量，其他虚拟机一样也会采集到所有的流量，这些流量里肯定包含很多未加密的敏感数据如用户名、密码等，假设这些虚拟机中有一台机器被入侵或者非法利用，这样会带来极大的安全问题。
　　场景三　：应用和数据库的虚拟主机随机的分配在一个虚拟化集群的某个主机上
　　这种场景其实是场景一和场景二的结合，目前大部分客户为了避免单一硬件的故障，基本上都采用虚拟化集群的方式实现企业的虚拟化，当碰到单一硬件的故障，虚拟机会在整个硬件虚拟化资源池中自动迁移，具体迁移到哪台物理主机上并不确定，因此传统的镜像方式并不能确定虚拟主机此刻在哪个交换机上，如下图所示：
　　因此在这种场景下同样无法做镜像，只能把虚拟化集群所有主机的流量全部镜像出来，这种缺点也非常明显：
　　1、当出现业务和DB在迁移到同一个物理机器上时，其实并没有流量，实质上审计不到任何数据，这个时候是存在严重的漏审计；
　　2、虚拟化集群涉及的机器比较多，流量非常大，网络可能也比较复杂，传统的镜像方式很难在实际中进行配置，因此很难实施；
　　场景四：应用和数据库分别托管部署在完全独立的第三方云计算平台
　　场景四是场景三的一种延伸与扩大，场景四主要指目前主流的第三方云平台提供商如阿里云、亚马逊、腾讯云、华为云、百度云等等，底层的硬件、存储、网络等等都对用户不透明，上层的虚拟机具体在哪个物理硬件服务器上，连接哪个物理交换机，用户一概不知道，如下图所示：
　　因此要用传统方式配置镜像，基本上没有可能，云平台提供商并不会提供底层资源的控制权给云主机租户，因此对这种场景的数据库要进行审计，传统数据库审计解决方案将彻底无能为力。
　　综上所述，在虚拟化和云环境平台中，只有场景一，传统的数据库审计解决方案勉强可以解决。针对场景二传统数据库审计解决方案基本上是不支持，部分情况即使支持也是有非常明显的缺点及种种环境的限制，针对场景三、场景四传统的解决方案直接是无法支持。
　　针对虚拟化环境和云平台中的数据库审计难题，安恒信息推出了全新架构的虚拟化云环境Agent代理审计解决方案。通过在虚拟主机上部署Agent，以不变应万变，全面支持以上描述的四种典型场景，这种解决方案由Agent对数据库的请求行为直接进行处理，处理完成之后由Agent直接将数据发给采集器统一检测、告警、存储及挖掘分析，彻底解决了各种虚拟化、云环境数据库无法审计的难题。具体部署拓扑图如下图所示：
　　本解决方案有以下优点：
　　1、全面支持所有虚拟化环境和云环境的数据库安全审计，不区分业务部署架构、底层虚拟化软件架构和底层的网络架构，不依赖传统的交换机流量镜像；
　　2、支持部署在虚拟化环境中所有的Linux 2.6以上内核版本、及windows2003、2008、2012等版本；
　　3、支持主流的Oracle、SQL Server、DB2、Sybase、Mysql、Lnformix等数据库，同时支持达梦、人大金仓、Oscar、Gbase等国产数据库，还支持cache、teradata、postgresql等数据库的审计；
　　4、部署简单，支持一键安装；
　　5、对虚拟主机的性能影响可以忽略不计，经实际阿里云环境虚拟主机测试，DB服务器流量在120Mb以内，agent对目标服务器的性能影响在3-8%之内。
　　随着虚拟化、云计算技术的不断成熟，业务迁移到云端也是不可逆的趋势，未来将会有越来越多的企业、政府、个人用户将应用系统及数据库逐渐迁移到自主搭建的私有云中，或者是第三方服务商提供的公有云平台中，企业、政府的核心敏感数据托管在云环境中，面临着各种窃取、篡改的威胁，数据的安全审计将越发重要，传统的数据库审计产品将逐步被下一代数据库审计产品所替代，安恒明御数据库审计产品将继续作为行业的领导者，在虚拟化、云计算时代继续为用户的数据库安全审计保驾护航。更多内容安全内容详见商业新知-内容安全

        
        
                
    

                    
本节书摘来自华章社区《Clojure数据分析秘笈》一书中的第3章，第3.7节将安全的副作用引入STM中，作者（美）Eric Rochester，更多章节内容可以访问云栖社区“华章社区”公众号查看
3.7　将安全的副作用引入STM中
STM的副作用并不安全。原因是dosync块很可能会被重试不止一次，无论副作用是正常的还是不当的，都会被一次又一次地执行。值会被多次写到屏幕或日志文件上。更糟的是，值被多次写入数据库。
然而，所有的程序都会产生一些副作用。控制复杂度的同时会引入副作用。最简单的办法是将副作用控制在事务外部。
本方法中，为了演示过程，这里将模拟进程饥饿（thread starvation）。这听起来很严重。但它仅意味着有一个进程无法获得其所需资源，因此它无法完成工作。这里将使用atom（一个不由STM控制的引用）来记录STM重试调用agent的次数。这样一来，可以知道产生问题的原因和解决方法。

        
        
                
    

多线程安全问题&线程通信
一、内容安排

实现两个线程累加一个变量到10_000
累加超过10_000的原因分析
synchronized解决安全问题
synchronized可以加在那些地方
synchronized面试考点
后续更新

二、文章内容
1. 实现两个线程累加一个变量到10_000


实现步骤

定义静态变量NUM等于0， MAX等于10_000
定义任务Runable，任务中实现只要NUM<MAX就不断累加NUM
开启两个线程同时执行任务
观察最终结果



具体代码
package com.huangguoyu.article3;

public class ThreadSecurity {
    //静态变量
    static int NUM = 0;
    static int MAX = 10_000;
    public static void main(String[] args) {
        //定义任务
        Runnable task = () -> {
            while (NUM < MAX) {
                NUM++;
            }
        };
        //线程1
        Thread t1 = new Thread(task);
        //线程2
        Thread t2 = new Thread(task);
        t1.start();
        t2.start();
        //让主线程等待两个线程执行完成打印最后的结果
        try {
            t1.join();
            t2.join();
            System.out.println("最终的NUM等于" + NUM);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}




最终效果
注意: 大家机器上可能跑出来的结果是正确的， 可以多跑几次或则多开几个线程; 确实不行就看下面的分析通过idea的多线程调试实现
9993
9994
9995
9996
9997
9998
9999
10000
10001
最终的NUM等于10001
Disconnected from the target VM, address: '127.0.0.1:51903', transport: 'socket'

Process finished with exit code 0



2.累加超过10_000的原因分析


首先通过上面的实验我们可以分析发现最终的结果并不是我你们想要的， 那这个产生的原因是什么呢；


出错根本原因在于CPU对多线程执行之间的切换




接下来我们通过idea的调试来看看


首先在while条件判断哪一行打断点并且右键断点处设置当NUM==9999时拦截断点， 操作如下




用debug模式启动程序，断点拦截下来之后先让线程1进入循环




切换线程到线程二，让线程2也进入循环




最后放开两个线程的断点可以看到结果就是，当NUM=9999时，两个线程同时进入了while中这样NUM就会被++两次，也就导致NUM不是我们预期的结果




3.synchronized解决安全问题


synchronized： 此关键字能够使得方法或则代码块中的代码在执行时只能有一个线程进入， 这样咱们就可以在while最外层添加一个synchronized代码块保证只能有一个线程进入，这也就使得同时只能有一个线程执行。


具体代码：

此处代码中可以发现synchronized需要指定一个对象作为锁，只有持有当前锁的线程才能够进入；注意锁对象必须唯一，所以此处选择了ThreadSecurity字节码对象作为锁

        //定义任务
        Runnable task = () -> {
            synchronized (ThreadSecurity.class) {
                while (NUM < MAX) {
                    NUM++;
                    System.out.println(Thread.currentThread().getName() + "==>" + NUM);
                }
            }
        };



效果：虽然此处问题是解决了，大家同样可以使用多线程的调试方式去查看能否让线程二也进入，你会发现线程二处于阻塞状态；并且也可以从打印中看的出来所有的累加都是一个线程做了，那也就是说加了线程相当于把我们的任务串行化了，那我们多线程的意义在哪里呢；咱们这里只要有一个线程抢到锁了就会把while执行完所以另外一个线程根本没办法参与累加工作， 其实这里咱们锁的范围太大了我们把整个while都锁住了，我们完全可以吧代码修改一下，把锁的粒度（范围）降低这样两个线程就都有可能抢到锁了，代码修改如下


修改后：
        //定义任务
        Runnable task = () -> {
            while (true) {
                synchronized (ThreadSecurity.class) {
                    if (NUM < MAX) {
                        NUM++;
                        System.out.println(Thread.currentThread().getName() + "==>" + NUM);
                    } else {
                        break;
                    }
                }

            }
        };



4.synchronized可以加在那些地方


成员方法上,可以修改任务代码查看执行效果
    //成员方法
    public synchronized void add() {
        NUM++;
    }



静态方法上
    //静态方法
    public synchronized static void add() {
        NUM++;
    }



代码块，如案列中的写法


5.synchronized面试考点


synchronized加在不同的地方他们的锁对象分别是什么

成员方法上锁对象为：this
静态方法上锁对象为：当前类的字节码对象
代码块上：指定的对象



synchronized和显示锁性能谁更好

实际上jdk每个版本都在对该关键字进行优化，目前来说次关键字性能不比显示锁差（后续我们聊了显示锁后一起做测试）



6.后续更新

下次内容：

线程之间如何通信
实现简单的生产者消费者模型
自定义显示锁实现同步操作