云来了,安全盒子怎么办

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享

云来了,安全盒子怎么办

by 何恐,一个安全人

 

前提和假设:

本文主要讨论“当下的”私有云安全,公有云不在此文范围内

1、云带来的安全挑战

近两年,云计算发展迅猛,新建的IDC如政务云,行业云,绝大部分都是云机房。云计算是大势所趋已经毫无疑问,已开始遍地开花。

关于云环境下如何做网络安全防护,常听见一种观点:云是颠覆性的,传统硬件安全设备完全不适用云环境。

那么,云来了,安全盒子到底该怎么办?

从本质上来说,对于网络安全设备,云带来的最直接挑战有两个:

1、 主机虚拟化

2、 网络虚拟化

云主机虚拟化带来的挑战

传统机房里面,每个租户的服务器是看得见摸得着的。在云环境下,租户的服务器变为了一个个运行在硬件服务器上的虚拟机,一个租户的虚拟机,可以位于不同的硬件服务器上,这是形态的变化,会引起租户的边界,从传统物理边界,变为动态、虚拟的逻辑的边界。

另外,因为一些历史原因会出现软硬件资源混合的情况。某些服务器不方便虚拟化,如历史遗留的数据库服务器,就需要和虚拟资源一起组成租户的计算资产。

最后,不同虚拟化厂家,如vmware,citrix,Hawei,H3C,各家的hipervisor系统不兼容,也会给安全厂商带来适配的工作量。安全厂家如果要以虚拟的形态运行在虚拟环境里面,需要适配不同平台的虚拟机格式。

因此,传统安全硬件要继续发挥作用,首先就要能够识别和保护虚拟的资产域,并且以动态的方式,切入到虚拟计算环境里面去。

另外,现在的运营商也不喜欢硬件盒子了。毕竟专用的盒子,利用率低,又互不兼容,运营商希望用通用的X86服务器来运行虚拟的安全设备,类似NFV,来提升经济性,可扩展性,以及适应业务快速可变的要求。

 

网络虚拟化带来的挑战

如果按照vmware 1999年发布VMware WorkStation算起, OS虚拟化的发展时间已经不短了。但是,仅仅是服务器形态的虚拟化,还不足以支持云的发展。在云环境下,要满足云的虚拟性、动态性,还需要将网络也虚拟化。

第一个问题是传统vlan的4K问题。传统vlan因为tag字段位数限制,只能支持最多4k个vlan。但是在云环境下,租户的数量非常多,4K上限是不能满足租户数量的要求的。基于这个目的,扩展vlan tag字段位数,重新对ip报文做wrap,以便于支持更多的租户容量,采用类似vxlan这种方式来划分网络是主流方式。对传统安全盒子来说,首要问题就是能识别vxlan报文。另外vxlan带来的不仅仅是报文tag改变这一点点内容,vxlan带来的相关的网络控制方式改变,调度,如服务链、SDN等等,也都是安全盒子需要去适应的。

另外,云环境下业务动态变化非常频繁,靠传统硬件去动态开通或者销毁一个业务,显然是不行的。之前大家只知道需要把服务器虚拟化,后来随着云虚拟机数量规模的扩大,大家逐渐意识到光服务器虚拟化还不够,需要把网络部分也虚拟化,软件化,并自动化。举个例子:某租户需要开通一个业务需要一台路由器,过一段时间又不需要了,硬件路由器可以满足这样的频繁变化吗?硬件盒子,必须要也可以动态灵活的部署进去才行啊。

再加上云环境为了满足虚机动态迁移,需要在一个大二层,传统二层设备没办法支持这么巨大的mac表项,这一块也需要新的二层技术,如vxlan的支持。传统网络显然不行的。

还有,租户都有自己的vpc,IP地址范围很可能是重叠的。传统硬件设备大部分是不支持这个的,大部分不具备硬件设备虚拟为多个硬件设备的功能的。租户是逻辑的、虚拟的,是接在“逻辑交换机”上的。逻辑交换机本身就不位于任何一个固定位置,是通过计算机节点overlay的方式,分布式部署的。因此,对多租户的安全检测能力,是传统安全盒子不具备的,这显然无法适应云安全的要求。

最后,SDN控制网络,控制和转发平面分离,也使得云环境的网络和传统网络大大不一样。传统盒子如何接入如何适配新的网络架构,这个也是需要有一个重大改变的。之前安全盒子通过策略路由、桥接、分光镜像等方式接入网络做安全检测的方式,在SDN网络架构下已经不能适用了。传统安全盒子,需要按照新型网络的控制方式,来接入业务流量。否则,就完全不能发挥作用。

总结

上述挑战,传统安全盒子通过交换机、路由器、分光器等物理方式接入租户网络的方式,在云环境下就失效了。要继续发挥作用,传统硬件必须要解决在云环境下的接入问题,要做到看得见、认得出、防的住,才行。

除了接入问题,安全盒子还需要适应云的弹性。硬件固定性能的盒子不容易弹性扩展,在云里面,安全也要像计算资源一样,可以动态的、弹性的扩展。

总的来说,云是利用资源的新的方式,安全本质并没有发生变化。但是,安全发挥作用的方式,需要根据云的变化而调整,才能继续有效。

2、 什么是东西向流量

凡提到云防护,必然会听见“东西向防护”这个词。那么,什么是东西向流量?

下面这幅图,是传统IDC的流量走向:

可以看到,大部分业务流量,都是从外到内为主,安全防护设备,也集中在由外到内的防护路径上,我们称之为“南北向”防护。

IDC云化以后,服务器的规模,包括虚拟机的数量,都扩大了很多。横向的虚机密度大大增加,也因此衍生出租户和各种复杂的网络虚拟设备,如下图:

传统IDC的安全问题,主要集中在①这个位置。云化以后,流量问题复杂化了,衍生出②、③、④、⑤这几个新的情况,防护也因此而有所不同。

在云网络内部,租户之间是隔离的,互相访问要通过vpn或者隧道访问。租户内部可以划分不同的子网,子网之间,子网内部虚拟机之间,虚拟到外部,外部到虚拟机,都会产生访问流量,安全问题也由此而生。

重要的是,这些流量往往产生在云内部,甚至不出服务器(如同一服务器内部虚机之间的流量)。因此这些流量,对传统硬件盒子不可见,从而也无法防护。这些流量,会成为一个真空地带,一旦发生安全问题,如虚机中木马或者病毒,将会迅速在云内部蔓延,并难以进行防护控制。这种情况是非常可怕的。根据《云等保增补方案》同等防护的原则,云内部流量也需要进行同等安全强度的防护,防护缺失是无法接受的。

综上,南北向流量,主要是指外部公网进出云计算内部的流量。东西向流量,主要是指租户内部虚拟机的访问所产生的流量。注意,东西向流量在这里是泛指租户相关的流量,并不仅仅是从外到内的流量。如果外部流量访问虚拟机,需要按照不同租户的策略来防护,此刻也称之为“东西向”。

南北向防护,传统方案都可以继续有效。而东西向防护,是云化后的机房新增加的需求。本文后面的讨论,主要集中在东西向防护方案。

3、 现有东西向防护方案

凡是解决方案,出发点都是根据安全厂商自身情况优先考虑。同样的,对客户而言,“反厂商绑架”也是自然的诉求。

虚拟OS厂商的方案

虚拟OS厂商,指的是虚拟系统厂家。这类厂家因为掌握了虚拟操作系统,所以自然考虑从虚拟系统本身入手来构建安全方案。通用的示意图如下:

 

虚拟操作系统厂家,通过在虚拟系统网卡之上增加驱动过滤层,将虚拟机的流量截获,将流量导向系统内置安全模块,或第三方的安全虚拟机,进行安全防护。

从上图可以看出,对内部流量的防护,利用了计算节点本身的计算能力进行,流量在出计算节点之前,就得到了有效的防护。

这种方式有他的优缺点。优点是,在靠近虚拟机的位置进行防护,能够在最短路径上防护,同时流量不出计算节点,不会对云内部骨干网络,造成额外的流量负担。另外随着虚拟OS的部署,安全能力随之部署,在部署上也会比较便利。

缺点也很明显,首先是第三方安全厂商必须获取虚拟OS的防护API授权,才能引入自己的安全虚机,如vmware的nsx认证。对于虚拟OS厂商来说,自然不愿意第三方碰自己的蛋糕。比如vmware的NSX模块,终端用户须付费购买,第三方安全厂商须通过商业认证。只有同时满足这两个条件,用户才可以用到想要的安全厂商的安全能力。

另外一个缺点是安全模块和安全虚机运行在计算节点,会占用计算资源。对于计算资源紧缺型的用户,或许无法接受。同时安全能力和计算能力混合在一起,出现问题的时候,排查责任也会有较高的复杂度,互相依赖交叉的情况,会对虚拟OS厂商和安全厂商造成同时困扰。

最后一个缺点,是安全虚机厂商多样性也会有问题。不同厂家的安全虚机,要同时出现在同一个计算节点上,技术上会有很大的问题。从客户长远利益考虑,客户需要一个比较好的,兼容各个安全厂商的安全架构,或者说良好的生态圈。

网络厂商的方案

这类厂商,以传统网络数通厂家为主。云化,不仅仅需要服务器虚拟化,也需要网络的虚拟化。流量可以在计算节点的驱动层捕获,也可以在网络层面捕获。我们知道,业务流量在哪里,安全问题就在哪里。因此对于网络安全盒子来说,在网络层面接入才是正道。

如上图所示,SDN网络,控制面和转发面分离,通过控制器来集中控制所有流量的转发。在SDN网络内部,可规划安全区。在安全区域,安全虚拟机或安全设备,可注册为服务节点。在SDN协议字段里,通常有服务字段。通过设置服务字段的值,即可控制任意的流通过指定的服务节点。

那么,安全盒子的部署,在这种情况下,也简单了。只要把安全盒子或者安全虚机,部署在服务区域,并注册为标准服务节点,即可利用SDN的服务编排能力,“指挥”任意流量,经过相应的安全节点,从而完成安全防护。

同时,SDN也有强大的网络控制力,可以实现流量镜像到服务节点,以及把服务节点的虚拟机工作口,绑定到用户VPC从而完成扫描类任务。

因为流量调度,通过网络进行了横向迁移,此刻可能大家会担心对网络带宽占用问题。为因对此问题,SDN网络内部增加了横向交换机的密度,所谓spine-leaf架构,通过增加横向带宽,来满足流量横向迁移的能力。

这种方式的优点很明显:通过设置服务节点,将流量通过网络调度的方式,进行服务编排,可以很方便的接入第三方厂商的传统盒子以及安全虚机。同时,因为通过网络控制器来进行流量牵引,可以自然兼容大部分hipervisor OS厂家——因为引流和虚拟OS没有关系。

缺点主要是增加了横向流量,会增加一部分网络建设的开销。另外在网络时延方面,不如内置在计算节点的方式。最后,采用这种方式,网络设备必须是支持服务编排的SDN网络,这对于采用传统网络方式的客户,增加了改造费用。

 

传统终端安全厂商的方案

传统终端安全厂商,优势在于有安全终端,劣势在于没有网络产品,也没有虚拟操作系统产品。那么,自然会从自身优势出发,在虚拟机操作系统内想办法来构建安全能力,如下图:

即:通过在虚拟机操作系统内,安装安全代理(通过虚拟机模板部署),以及在HiperVisor OS内安装安全模块,或称之为“无代理”方式,通过在HiperVisor系统底层以及虚拟机操作系统驱动层,捕获数据流以及文件内容,来实现安全防护。一般可实现杀毒、文件监控、网络防护等功能。

这种方式的优点在于,通过在虚拟机操作系统部署安全代理,避免了必须依赖虚拟OS以及SDN网络,而直接实现了流量捕获以及防护。另外,也可以充分利用计算节点的计算能力,无需额外增加安全硬件资源的投入,也不会引起流量的横向调度。

缺点主要有三个:一个是在客户虚拟机上安装代理,会有信任问题。如果客户数据比较敏感,可能不愿意安装第三方的程序在自己的虚拟机内;另外,如果要按照不同租户不同策略来进行防护,还是需要一个集中的管理中心和虚拟系统用户数据库进行对接,以便于识别租户以及下发相应的策略。第三个缺点是防护能力的多样化会有问题,即:很难在这样高度集成的架构内,开放的引入各家厂商的安全能力。

网络安全厂商的方案

网络安全厂家,既没有SDN产品,也没有虚拟OS产品。在这种情况下,往往会选择一个中立的态度来构建云内的安全解决方案。

网络安全厂商,优势在于安全产品线很全,可以很快的将安全盒子,虚拟化为各种安全虚机,并池化。如下图:

通过在标准x86服务器上,安装各类虚拟机,并形成安全池集群;然后,根据租户的需求,构建虚拟的安全能力,如虚拟WAF,虚拟IPS,以对应虚拟资源的概念。这样做可以将以前安全盒子专属硬件才能提供的能力,灵活的虚拟化到通用硬件,客无须再采购专用硬件,可就地利用虚拟服务器来作为安全池的部署环境,甚至利用现有的虚拟资源池来部署安全虚机。

那么剩下的,就是通过各种方式,将流量往安全池牵引,以实现安全防护。具体的引流方式,需要结合用户网络环境来实现。比如通过SDN API引流,通过传统路由器进行策略路由方式引流,通过虚拟/传统交换机镜像口引流,以及在计算节点内安装引流代理,通过代理方式引流。如下图:

上图的微代理,可以看作一个特殊的虚拟交换机。如果VM2需要被防护,那么只需要拆除VM2和原有虚拟交换机的连接,并将VM2的虚拟网卡,连接到微代理,微代理用TRUNK的方式再连接到虚拟交换机上,这样便不会破坏原有VM2的VLAN拓扑。然后,所有VM2的流量就会经过微代理,即使是同一个计算节点内虚机之间的互访流量,也会被微代理截获。截获后的流量,通过隧道送往安全池过安全策略,然后发回原有微代理进行正常转发。

这种方式的好处在于,通过池化安全能力,可以构建弹性、多样化且开放的安全池,方案本身符合云的特性。同时利用各种引流手段,能够灵活的实现安全防护。

缺点在于,引流方式会带来额外的带宽占用和延时。同时,需要对接不同的客户网络方案,对接成本较大。

总结:

综上,可看出目前云环境下,缺乏统一的网络安全设备部署环境,目前局势还有点混乱。从另一个侧面,也看出虚拟化发展过程中,基础设施对于安全方面考虑的缺失。

 

4、 关于变化和发展

安全能力池化

传统的安全能力,都是通过固定的硬件盒子的形式提供的。在云时代,这种情况将发生变化。固化的安全能力,不能匹配云防护的要求。安全能力池化,首先是将传统的安全能力(引擎)虚拟化,其次是可弹性伸缩的安全池,最后能适应云环境的部署方式。云环境都是有租户的,那么云平台除了提供基础安全能力以外,也需要提供不同租户需求的不同安全能力套餐,并做到可运营。这样做的原因,本质是为了匹配云的特点:弹性,敏捷,虚拟化,可运营。

未来,传统硬件盒子的份额,可预见会持续下降,虚拟化安全产品的份额则会持续提高,此消彼长。传统盒子为了适应虚拟化,数通部分的模块会退化,引擎部分会持续强化。

在安全池基础上,需要有一个运营平台,对安全池进行统一管理,对安全业务进行灵活的开通、计费,并按照租户查看报表,以及云内部整体态势等功能。传统盒子的安全视角,是基于设备的。云安全池的视角,是基于运营平台的,安全盒子(虚机),只是平台下的一个基础模块。

最后,安全池是软件不是硬件,安全池泛指所有安全能力的集合,包含以安全硬件、安全虚机等组成的混合能力的“池”。

内嵌模式和外置模式互为补充

内嵌模式,指的是安全池内置在计算节点内,充分利用计算节点的计算能力进行安全防御的模式,简单可认为如下图所示:

外置模式,正好相反,安全能力放在单独的通用服务器内,如下图所示:

关于这两种方案的优劣势,争论很多。总的来说,内置式的最大优点,是充分利用计算节点进行就近防御。外置式最大优点,是有单独的安全能力空间,不占用计算资源。

不论安全厂商如何声称哪种方案好,从技术角度看,这两种方式实际上是互补的。外置安全池,更适合通过网络调度能力比较强的场合,以及以网络流量防护为主的场合;但是对于网络调度能力弱,需要结合local防护的场合,就适合内置方式。比如HWAF,本地杀毒,就近阻断,以及想在宿主机OS上搞点事情的场合。

外置和内置模式,都有对方干不了的事儿。从技术角度看,互补能够形成最完整的解决方案,缺一不可。无论目前坚持哪一派的厂商,最终都会走到这条路上来。从看见的客户实际需求,以及大厂的收购路线,都能印证这个趋势。

平台为王

传统盒子都是以卖盒子为主要销售模式。云机房,不但需要虚拟化的安全盒子(池),还需要处理和虚拟系统的对接以获取租户信息、vxlan信息,SDN引流对接;另外从运营模式看,云平台除了提供基础防护,更重要的是提供满足租户多样化需求的可运营的平台,并满足增值收入。

传统机房只需要安全盒子接入,最多加个网管软件,即可完成销售。对云安全来说,这是不够的,需要提供平台能力,通过将虚拟化能力引入平台,并将平台和云平台的对接,从而提供云防护能力。

云安全平台的模式和盒子不一样,平台模式是平台先行,盒子和虚机随后逐步建设。从这个角度看,得平台者得天下。平台模式示意图简单如下所示:

(3个打分, 平均:5.00 / 5)

中国人在硅谷-NetScreen的故事(电子版)

(6个打分, 平均:4.83 / 5)

Lamport与Paxos的血泪史

出处:http://duanple.blog.163.com/blog/static/709717672012112203543166/]

自Paxos提出,迄今已有20多年了,围绕着该算法曾经发生过一些非常有趣的事情,这些也已成为人们津津乐道的一段轶事,故事的主角自然是Paxos的提出者Lamport,当然Lamport的特立独行也是很早就出了名的。首先来讲述下这些有趣的八卦,之后会再理一下Paxos的整个发展过程,以及在这个过程中产生的一系列比较重要的论文,总共会涉及到十几篇论文,如果有时间还是最好都研读一下。由于时间关系,我也只是选择了其中最为重要的三篇,进行了阅读,并将它们翻译了出来,稍后会整理出来。 


关于这段历史, Lamport本人在他的“My Writings”里对于论文<<The Part-Time Parliament>>的整个从创作到发表的过程,也做过非常详细的描述。我们还是先从这里开始吧。

 

“上世纪80年代末,SRC(Systems Research Center,DEC于1984年创立,Lamport也曾在此工作过)构建了一个被称为ECHO的容错文件系统。该系统的构建者们声称,系统可以保证在发生任意数目的非拜占庭式错误情况下的一致性,并且只要有半数以上的进程可以正常工作,它就可以保证系统向前运转。对于大多数像这样的系统来说,在没有错误发生的时候都是很简单的,但是要处理好实现者所有能够想到的各种错误的话,是需要一个非常复杂的算法的。我感觉他们在做的事情基本上是不可能的,并打算去证明它。结果事与愿违,在这个过程中我发现了Paxos算法,也就是本文描述的那个。该算法的核心实际上是一个三阶段的一致性协议。Dale Skeen应该是第一个意识到为避免任意可能的单点失败引起的阻塞需要引入三阶段协议的人。但是,据我所知,Paxos是第一个具有清晰正确性条件说明及完整正确性证明的真正意义上的三阶段提交算法。

无论那时,还是现在,我一直认为Paxos是一个非常重要的算法。在写此文之前,我通过采用拜占庭将军的描述方法使得一致性问题成功地被人们所接受(即论文The Byzantine General Problem),受此启发,我决定通过一个古希腊岛屿上的议会来描述该算法。Leo Guibas提议将这个岛命名为Paxos。我又用工作在该领域的计算机科学家的名字对里面的希腊议员进行命名,并在 Guibas的帮助下翻译成了伪造的希腊方言。(论文题目是由Peter Ladkin提议的)。通过描述一个失落的文明,既增加趣味性又可以让我免于陈述其中乏味的细节,只要直接声明一下关于该议会协议的某些细节已经遗失就可以了。为了让这种形象化的描述更逼真,我还戴上了Stetson毡帽屁股系上了小酒瓶装扮成印第安纳琼斯style的考古学家,进行了几次演讲。

只是我这种尝试不幸地失败了。那些参加我演讲的人们只记住了印第安纳琼斯style,而不是该算法。阅读该论文的人们看起来也饱受里面的希腊故事的干扰以至于根本没有理解该算法。在我发论文给他们阅读的那些人中,其中 Nancy Lynch(分布式理论研究大牛,<<Distributed Algorithms>> 一书作者), Vassos Hadzilacos, 和Phil Bernstein声称已经读完。大概两个月后,我给他们发了封邮件,邮件内容为“是否能够实现一个可以容忍任意数目(可能是所有)的进程出错且能保持一致性的分布式数据库,同时当半数以上进程恢复正常时该系统也能够恢复正常”。但是他们并没有人意识到该问题与Paxos算法间的关联。

我在1990将该论文提交给了TOCS。三个审稿者都认为该论文尽管并不重要但还有些意思,只是应该把其中所有Paxos相关的内容删掉。在该领域工作的人们如此缺乏幽默感,实在令人生气,此后我也没有对该论文做任何修改。很多年后,在SRC工作的两个人需要为他们正在构建的分布式系统寻找一些合适算法,而Paxos恰恰提供了他们想要的。我就将论文发给他们,他们也没觉得该论文有什么问题。下面是Chandu Thekkath所讲述的Paxos在SRC的历史:

“在Ed Lee和我从事Petal相关的工作时,我们需要一种提交协议来确保分布式系统中的全局操作即使是在发生故障的情况下也能保证正确性。我们了解到一些3PC的概念,并阅读了Bernstein, Hadzilacos和 Goodman的经典书籍<<Concurrency Control and Recovery in Database Systems>>,对其进行了研究。我们发现这个协议有些难以理解,于是放弃了对它进行实现的尝试。大概也是在这个时间,Mike Schroeder与我们谈起Leslie Lamport 曾经发明了一个一致性方面的协议并建议我们直接问下Leslie本人。后来Leslie给了Ed一份<<The Part-Time Parliament>>文章的拷贝,我们两都读地很happy。我尤其喜欢其中的幽默,直到今天也无法理解为什么人们都不太喜欢这篇文章。Paxos具备我们的系统所需要的所有属性,同时我们也觉得能够将它实现出来。此外Leslie还为我们提供了很多咨询帮助,这样就产生了我所知的Paxos算法的第一个实现(包含了动态重配置)。一年后,我们又用Paxos实现了Frangipani file system所需的分布式锁服务器”

因此,我觉得重新发表该论文的时机到了。

与此同时,在整个悲催的经历中(指论文一开始被拒,没有人重视),Butler W.Lampson(1992年图灵奖得主)是一个例外,他立刻意识到这个算法的重要性,并在他的演讲和一篇论文(即<<How to Build a Highly Availability System using Consensus>>)中对该算法进行了描述,这引起了Nancy Lynch的关注。此后De Prisco, Lynch和Lampson发表了他们那个版本的描述和证明(即<<Revisiting the PAXOS algorithm>>)。他们那篇论文的发表更使我确信是时候发表我的这篇论文了。于是我提议当时TOCS的编辑Ken Birman发表该论文。他建议我再修改下,比如添加一个关于该算法的TLA描述。但是重读该论文后,我更确信其中的描述和证明已经足够清晰,根本不需要再做改动。诚然,该论文可能需要参考下最近这些年发表的研究成果进行修订。但是一方面作为一种joke式的延续,另一方面为保存原有工作,我建议不是再写一个修订版本,而是以一个被最近发现的手稿的形式公布,再由Keith Marzullozz做注。Keith Marzullo很乐意这样干,Birman也同意了,最终该论文得以重见天日。

这样该论文就有了一些有趣的排版注脚{!即论文<<The Part-Time Parliament>>里Keith Marzullo的那些注,具体内容见原文}。为了让Marzullo的注解更显眼,我认为它们应该印在一个灰色背景上。那时ACM刚获取了一些非常棒的排版软件,同时TOCS也准备不再接收camera-ready copy。不幸的是,他们的新软件做不出阴影效果。于是,我不得不为那段文字提供一个camera-ready copy。但是,他们的那个牛逼软件只能以漂浮图的形式接收我提供的这个拷贝,因此Marzullo的注释的画面效果看起来可能并不理想。还有更不幸的是,他们那个超级昂贵的软件竟然不支持数学公式。(好吧,毕竟他们是一家计算机期刊,so可能不需要对公式排版吧…)。因此我又不得不为A2节里的不变性定义提供一个camera-ready copy,在发表的版本里他们将它作为了图3。这就是那张图里的字体看起来与其他部分的字体并不匹配的原因。

该论文获得了2012年的ACM SIGOPS Hall of Fame Award{!是不是很熟悉,之前介绍过的Lamport的另一篇文章<<Time Clocks and the Ordering of Events in a Distributed System>>就获得了2007年的该奖项。该奖项始创于2005年,主要颁发给那些在操作系统领域产生了深远影响的论文,这些论文都至少经过了十年的检验。获奖结果将会在每年的OSDI或SOSP(操作系统领域顶级会议,通常是偶数年开OSDI,奇数年开SOSP)上宣布。今年的OSDI上除Lamport的这篇获奖外,Liskov(2008年图灵奖得主,她导师是1971年图灵奖得主John McCarthy)1988年写的<<Viewstamped Replication: A New Primary Copy Method to Support Highly-Available Distributed Systems>>也是获奖论文,这两篇都是Paxos相关的。}

从上面可以看到,在Lamport的各种挖坑和吐槽下,已有无数人中枪,连ACM的排版软件也不能幸免(好吧,其实此处Lamport有为他的LaTeX打广告之嫌)。关于该论文的整个曲折的发表过程就是这样的。另外值得关注的是SRC,它的Petal和Frangipani是不是非常类似于Google的某些东西啊,而且在<<The Part-Time Parliament>>发表前,这些系统就已经完成了Paxos的实现。

 

现在我们重新回到Paxos。它的整个发展过程实际上大概可以分为三个阶段。

 

第一个阶段,为算法创立阶段,基本就是88年和89年,代表性事件是88年Liskov发表 <<Viewstamped Replication: A New Primary Copy Method to Support Highly-Available Distributed Systems>>,89年Lamport写出了<<The Part-Time Parliament>>,并在90年将它提交给TOCS。这两篇都是独立完成的,而且Liskov那篇还要早些,但是因为上述种种轶事,大家最终还是称之为Paxos,而且在Paxos的盛名下,Liskov那篇估计更少有人知道了。最早指出二者本质上是一样的人是Butler Lampson。在这个阶段,这两篇论文基本上都还没有人关注。当然这两篇论文的殊途同归,也从一个侧面说明解决异步一致性问题基本上也没有其他的路子可走。


第二个阶段,可以从开始引起理论研究界的重视算起。代表性事件是96年Butler Lampson发表<<How to Build a Highly Availability System using Consensus>>。正是经过Lampson的大力宣传,该算法才逐渐为理论研究界的人们所重视,也直接导致了The Part-Time Parliament的重新发表。为啥当年Lamport一方面费尽心机地扮考古学家,另一方面千辛万苦把论文写的那么幽默,都没能让理论界的人们看上眼,而Lampson振臂一挥,就有无数响应呢?这可能是因为天时、地利、人和吧,从时间上来看,此时人们对于一个分布式一致性算法的需求日益紧迫,而且与Lamport相比,Lampson明显说话还是要更有分量些,Lampson 92年就拿到了图灵奖,江湖地位自然高些,而且他更善于把复杂的问题讲清楚,另外还有就是功力的确深厚,就算Lamport这样的人物对其也是佩服得不行。这篇论文发表之后,后续便引出了一系列关于Paxos的研究。1999年,De Prisco, Lynch和Lampson联合在TCS(Theoretical Computer Science)发表了<<Revisiting the PAXOS algorithm>>对Paxos算法进行了全新的描述及证明,分析了其时间开销及容错性。2001年,Lampson又写了一篇<<The ABCD’s of Paxos>>对Paxos的各种不同形式进行了描述,包括AP:Abstract Paxos;BP:Byzantine Paxos;CP:Classic Paxos;DP:Disk Paxos,发表在PODC’01上。也是在这一年,在参加PODC会议时,Lamport发现人们还是觉得Paxos很难理解,于是回家后对Paxos进行了重新描述和表达后,形成了<<Paxos Made Simple>>这篇文章,而这篇文章基本上就是The Part-Time Parliament的一个简化版本。可以看出,到了2001年,Paxos已经成为理论界关注的热点。此后的2004年,Lamport写了篇<<Cheap Paxos>>,2005年又写了篇<<Fast Paxos>>,对经典Paxos算法进行了改进。


第三个阶段,由Google发表的两篇论文开启,也是从那时起Paxos开始从理论界进入工业实践,并被越来越多的工程技术人员所熟知。2006年,Google有两篇论文发表在OSDI上,一篇是<<Bigtable:A Distributed Storage System for Structured Data>>,另一篇就是<<The Chubby lock service for loosely-coupled distributed systems>>,而在Chubby这篇中有这样一段话“Indeed, all working protocols for asynchronous consensus we have so far encountered have Paxos at their core”。另外还有一句流传甚广的话,“世上只有一种一致性算法,那就是Paxos—Mike Burrows”,这句话可能是出于这篇文章<<Consensus Protocols: Two-Phase Commit>>,是否为Mike Burrows的原话就不得而知了,但是Chubby中的那句的确与这话十分接近。Chubby发表之后,开源社区也推出了与之对应的Zookeeper。此后,Paxos逐步为大众所了解,至少听说过的人越来越多了。Google除了Chubby那篇,当然实际上Chubby并未讲述Paxos相关的内容,还有另一篇非常好的文章<<Paxos Made Live>>,这篇文章详细解释了Google实现Paxos中越到的各种问题及解决方案,讲述了如何将理论应用到实践,而二者之间通常都是具有很大的鸿沟的,尤其是在分布式系统领域,往往都是理想丰满现实悲惨。其实这篇已经完全超越了Paxos算法本身,重要的不是如何实现Paxos(实际上大多数人都不需要实现Paxos),而是应理解如何将理论应用到实践,如何弥补理论与实践的差异,如何进行分布式系统的工程实现,如何进行分布式系统的测试,而实践中的很多问题理论界并没有给出答案。


另外,如果要自己实现Paxos,还有如下几篇文章可供参考:<<Paxos Made Code>>作者Macro Primi,他实现了一个Paxos开源库libpaxos,更多信息可以参考此处。<<Paxos for System Builders>>以一个系统实现者的角度讨论了实现Paxos的诸多具体问题,比如leader选举,数据及消息类型,流控等。<<Paxos Made Moderately Complex>>,这篇比较新,2011年才发表的,该文章介绍了很多实现细节,并提供了很多伪代码,一方面可以帮助理解Paxos,另一方面也可以据此实现一个Paxos。<<Paxos Made Practical>>是少有的一篇对Liskov的那篇论文进行重新解读的文章,主要介绍如何采用Paxos实现replication,如果要读Liskov的那篇,也可以同时参考这篇。除了Macro Primi的那个开源实现外,目前还可以找到如下一些Paxos实现的代码:Java版Python版

 

关于Paxos的介绍,这两篇文章也非常不错:<<Consensus Protocols: Paxos>>,<<Consensus>>。
(5个打分, 平均:3.80 / 5)

《关于新一代操作系统的思考》

(7个打分, 平均:3.43 / 5)

新三板最大并购案:南洋股份57亿人民币收购天融信切入信息安全行业

8月3日,新三板迎来了史上最大的上市公司收购挂牌企业的并购案,南洋股份57亿人民币收购天融信切入信息安全行业。公司拟通过发行股份及支付现金的方式购买北京天融信科技股份有限公司100%股权,交易作价57亿元,其中股份支付约36.2亿元,现金支付20.8亿元。

天融信的一些财务状况如下:

2014年、2015年天融信股份分别实现营业收入73,719.64万元、85,512.67万元,净利润18,392.69万元、22,955.31万元。

从收购的情况来看,这里面有不少对赌协议。例如,“天融信全体股东承诺,天融信2016年度净利润不低于3.05亿元,2016年度和2017年度净利润累积不低于7.15亿元,2016年度、2017年度和2018年度三年净利润累积不低于12.55亿元。”

(3个打分, 平均:5.00 / 5)

Network Functions Virtualization: Challenges and Opportunities for Innovations

(3个打分, 平均:5.00 / 5)

Bloomberg . The Risk I Will Not Take

(5个打分, 平均:4.20 / 5)

山石网科下一代防火墙荣获NSSLabs推荐级


(3个打分, 平均:5.00 / 5)

On The Time Complexity of Moving Turing Machines

(6个打分, 平均:4.67 / 5)

为什么云计算中心内部安全那么重要

作者为北京山石网科信息技术有限公司虚拟化产品线总监,本文仅代表个人观点。本文是云计算安全系列文章第二篇。

      云计算中心要特别重视内部的安全!为什么?因为云计算中心不仅会成为安全攻击的目标,由于云计算本身的技术特质,它还会成为网络犯罪分子的法外非地,甚至会成为网络犯罪分子的老巢、他们手中的“核武器”!

     原子弹发明的时候,都说它既会给世界带来和平与正义,也有可能带来灾难!由于原子弹/核武器制造难度大、成本高,通常只会掌握在少数的政府手中,虽然也有人担心、各种影视剧中也有原子武器被恐怖分子夺去的桥段,但是现实社会中,获取原子武器对恐怖分子来说还太难。但是,在信息社会里,云计算给正派人士带来的所有优点,都可能成为犯罪分子、恐怖分子手中犯罪利器,让犯罪手段、恐怖手段升级跨入到“云计算”时代!成本还很低!

     1、巨大的计算容量=巨大的安全攻击力量!即使是企业的私有云,至少都有几十个物理计算节点、几百个虚拟机。大型的公有云,动辄上千台服务器,几万个虚拟机!如此巨大的计算资源,简单的搞个DDoS攻击,面对复杂的密码,搞个穷举……试问谁能抵抗?

       记得比特币火的时候,有个朋友跟我讲,他有天加班发现服务器过了12点就极慢,后来一查是被员工偷着用来挖矿了,深夜上班,早上再释放掉……要在云计算环境里干点类似的事情,一是计算资源丰富、二是成本低,三是不易被发觉。

     2、按需付费=犯罪成本低,更灵活!云计算的优势就是按需付费,计费灵活,现在有的服务商推出了按照分钟/秒计费的模式……多年前,当亚马逊刚对公众提供云计算服务的时候,有朋友就说,这下子搞DDoS容易了,在亚马逊上申请一批主机,装上软件,攻击完了就释放,花钱少,比到处种肉机简单!

     3、迁移容易,业务持续性好=攻击持续性高!说上面那个例子的人当时对云计算还没那么了解。现在云计算技术多完善啊,又是虚机迁移,又是快照、镜像的。黑客持续性攻击的成本低啊!申请个虚机,攻击一会儿,然后整个快照,把虚机释放了,待会儿再申请,复制一下,再攻击一会儿……既攻击了,还省钱,还不容易被追溯,利器啊!

     4、虚拟化=无边界、不可视、不好定位。云计算的基础是计算、存储、网络虚拟化,就是要打破盒子、线缆这些物理的条条框框,给计算资源、应用以自由!最早接触云计算的时候,提到云计算中心的新思路时候,总是在提大广播域、网络扁平化,而不是早先哪种VLAN,广播域尽早终结的概念。每每想到这里我就赞叹当年电影《黑客帝国(Matrix)》编剧的前瞻性,对于网络犯罪分子来说,云计算中无边界、不可视、不好定位,真是最佳的游猎场所。(在命名为云计算之前,记得还提过网格等等名词,比起好莱坞的编剧,我们汗颜啊!)

     5、虚机聚集=APT攻击更隐蔽!现在的攻击手段多种多样,我学到的一个新名词是APT(高级持续性攻击),黑客会很小心把攻击伪装到正常应用中,还会在多个主机之间多次跳转,伪装攻击源。过去,主机没有这么密集,可能要经过多个防火墙最后达成目的,还是会留下不少蛛丝马迹。今天,成千上万台虚拟机聚集在一个大的防火墙后面,分属不同的业主,各有各的管理思路、安全能力又不同,犯罪分子在多个虚机之间来回跳,把狐狸的尾巴藏起来……云计算中心可能成为犯罪分子的温床并不过分!

     6、入门门槛低,普及性高!最后还要再说成本。云计算不论是IaaS、PaaS、SaaS,核心目标就是降低用户使用成本啊,提高易用性。现在都说互联网+,就是让很多不具备太强IT能力的公司也上互联网。但是很多企业不具备IT能力,更没有什么安全意识,也就是说网站多了、计算资源多了,安全防护的整体水平却可能低了,这在犯罪圈子里难道不是喜大普奔的好消息吗?

       过去我们谈安全,总是考虑内外有别,外部是盗匪横行,内部是净土一块。但在云计算、虚拟化计算环境下,内部安全不早着手,极易成为滋生安全问题的温床。全世界都在加强信息安全的立法和管控的条件下,个人认为别光惦记着如何防别人攻你,很有可能有天警察找上门来,说你攻击了别人,追究你的法律责任!

     不论是私有云还是公有云,都要把云计算中心内部的安全问题仔仔细细想想清楚!云计算给你了幸福,也可能给你带来灾难!我们后续会展开讨论云计算内部的安全问题。

       我们云计算安全系列文章的第三篇是谈谈云计算中心的异构问题。

(2个打分, 平均:3.00 / 5)