标签：文件 数据 os 类 问题 代码
云计算因为能够提供虚拟化的资源池、弹性的服务能力、自助服务等，深得CIO们的青睐，为了提高企业IT设备的利用率，提高服务容灾的能力，提高对业务支撑的快速响应能力，大多数的企业都开始尝试企业私有云的建设。
私有云安全的尴尬现状
一般来说，从现有的IT管理体系过渡到私有云平台，大致需要几个步骤：数据大集中、业务系统整合、IT资源的虚拟化、管理平台云化、云服务提供。(很多人认为私有云就是信息中心的建设，其实信息中心的虚拟化改造一般是最后两个阶段合并为信息中心的统一运维管理平台，而不一定会提供云服务，因此，不能称为严格意义上的私有云。)这个过程中，资源虚拟化是关键，因为只有资源都虚拟化管理，才可以谈得上动态的调配，才能够提供弹性服务支撑能力。哪些资源可以且需要虚拟化管理？计算资源，包括CPU 与内容，以及存储资源、网络资源。我们注意到，一般都没有涉及到安全资源。这不奇怪，因为虚拟化平台厂家都是先以业务服务实现为主，安全问题大多是放在后边考虑的。
这就给CIO们出了一个难题：私有云为企业各个业务部门提供统一服务，不仅仅包括计算资源、存储资源、网络资源，还应该包括安全资源，如身份认证、病毒查杀、入侵检测、行为审计等，只分配了计算资源与存储资源的系统，对用户来讲，无异于“裸奔”。私有云与公用云不同，公用云的业务单一，可以建立统一的安全策略;而私有云不同业务系统的安全需求差异很大，在一个“云”内，为不同业务系统提供不同的安全策略，安全策略如何部署？部署在哪里？
云计算的安全问题一直是业界争论的热点，还有个专门的组织CSA(云安全联盟)制定了一些指导性意见，但落地都比较困难。总结起来，云计算的安全落地有两方面的难题：
第一，是云计算系统架构本身的问题。由于采用了虚拟化的资源管理，用户业务系统的服务器不再明确地运行在哪台服务器上，而是动态漂移的VM(虚拟机)，不同业务系统的用户都在一个“大杂院”内进进出出，各个业务系统之间没有了“边界”，如何保证那些不安分的用户偷窥其他系统的数据，只靠虚拟化操作系统的管理，能够满足用户业务流之间的隔离吗？且不说虚拟机逃逸方面的研究，如“蓝色药丸”，传统的操作系统都是漏洞一堆，虚拟化操作系统的漏洞就会很少吗？危害程度可是更大。
第二，是虚拟化操作系统厂商的问题。目前，能够提供虚拟化操作系统的厂商不是很多，如VMware、Microsoft、Citrix、Xen、RedHat、方物等。先说市场份额最大的VMware，是一家与微软一样的私有代码厂商，只提供第三方的开发接口API。VMware提供系统底层的安全接口，如VMSafe，但这个接口目前还没有对国内的安全厂商开放，也就是说，实现安全部署，只能采购国外的第三方安全厂商产品。其他的厂商，如Xen 是开源的，是没有接口问题，但需要用户自己的技术力量非常强才可以部署与维护。
一句话：云内的安全问题是严重的，最好的方法，就是安全设备可以如同存储设备一样，形成池化的资源池，在用户申请云服务器时，与计算资源、存储资源一起按需分配给用户。
但是，就目前安全厂商的现状，完全达到这个阶段还需要一段时间;为了应对过渡时期的私有云服务运行的安全，我们提出了过渡时期的安全解决方案——“云朵”方案。
“云朵”方案的设计思路
在没有办法确定多个不同业务系统在一个云中运行可以做到安全的隔离的情况下，根据不同业务系统的安全需求，把安全需求近似的、服务对象相似的业务系统部署在一个云内，否则就部署在不同的云中，这样在企业中就形成了一个一个的云朵，如办公业务云、生产业务云、互联网服务云等，或者按照等级保护的级别，分为一级系统云、二级系统云、三级系统云等。
“云朵”方案设计模型
企业核心网络是“物理”的，不同的业务服务云朵连接在核心网络上，每个云朵内部有自己的云朵管理中心，负责云朵内的计算、存储、安全资源管理;企业用户分为虚拟终端(如运行虚拟桌面的“傻终端”)与真实终端(如PC 等“富终端”)，通过企业网络，可以登录不同的云朵;整个网络的用户采用统一的身份认证，并建立云朵安全管理的中心平台，该平台通过各个云朵的管理中心接口，可以直接监控云朵内虚拟机的运行状态。
云朵方案的优点是明显的：一朵云内的业务系统安全需求是相近的、用户是相同的，安全隔离的需求大大降低了，这样就解决了不同业务系统在一个云内安全隔离的安全难题，在云朵之间的网络是“物理”可见的，传统的安全边界思路完全适用;当然，不同云朵可以采用不同的虚拟化操作系统，减少对一个厂家的过度依赖(桌面操作系统对微软的依赖是很多CIO 头痛的难题);最后，若一朵云出现问题，也不会影响其他云朵内的业务系统。
云朵方案的缺点也是明显的：IT 资源利用率提高有限，这与采用虚拟化技术的目标显然是违背的;人为地建设多个云朵，多个管理运营平台，管理复杂度明显是加大的。
但是，云朵方案可以解决目前虚拟化平台自身安全还不到位，业务需求推动云计算模式纷纷上马的矛盾。边走边学，“摸着石头过河”，总比因噎废食要好。
云朵方案把企业私有云的安全问题进行了分解：1、云朵间的安全;2、云朵内的安全。
云朵间的安全设计思路
不同的云朵，逻辑上如同传统安全方案设计中的“安全域”，具有明确的安全区域边界，因此，云朵间的安全完全可以按照传统的安全方案设计思路，部署思路可以参考“花瓶模型”的三条基线一个平台，网络边界与安全域边界的安全防护基线;重要资源区域与核心汇聚的动态监控基线;用户与运维人员的信用管理基线;日常运维与应急处理的安全管理平台，具体的技术与管理要求，可以参照等级保护的要求，这里就不赘述了。
云朵内实际上是一个云朵平台管理的系统范围内，也可以说是一个虚拟化操作系统的管理平台下的安全设计。从系统角度看，可以分为两个层面的安全设计：1、虚拟机内的安全;2、虚拟化平台上的安全。
虚拟机内的安全
就是用户申请到的虚拟机，从用户角度看起来与物理服务器是一样的，用户选定的操作系统与业务服务软件，因此，虚拟机内的安全就如同对一个主机系统进行安全防护设计。由于虚拟机的管理比起物理机要简单的多，容易进行配置修改与补丁升级管理，开关机就是一个目录下的文件运行而已。
同时，虚拟机的计算资源是可动态申请的，不再存在传统主机内安全与业务争资源的矛盾， 因为驻留主机内部的安全监控会降低业务运行的效率，很多业务管理者拒绝安装其他驻留软件。当然，软件间的兼容问题依然是存在的，因此，在系统升级或安装安全软件前，一定要在其他的虚拟机上测试，保证不影响业务软件的正常运转。
虚拟机内的安全须考虑如下几个方面：
l 身份鉴别与权限管理：身份鉴别可以与整个网络的身份认证系统统一起来，但权限管理在云朵内部有自己的明细管理，保证云朵内部用户可访问业务的差异;
l 服务加固与反控制防御：这主要是针对服务器的，如同普通的业务服务器一样，需要基本的安全加固，安装适合的补丁、关闭不需要的服务、删除不需要的账户等，但这还是不够的。服务器是面向网络服务的，中断了服务，仅仅是影响自己的业务;若被黑客入侵，成为“肉鸡”，就可能成为攻击其他目标的工具。由于云朵内一般是多个业务系统在运行，一个系统的漏洞被利用，就建立了黑客入侵的桥头堡，成为内部攻击的跳板，很多黑客入侵正是这样一步一步渗透到核心机密服务器中的。因此，服务器不被入侵者控制，不成为“肉鸡”是服务器安全的最低底线要求，安装反控制防御系统，或对系统进行反控制加固是非常有必要的;
l 终端防护系统：这主要是针对远程桌面或BYOD的，因为访问者的终端种类繁多，安全状态千奇百怪，对访问终端进行适当的安全检查，或限制其访问云服务的权限都是必须的;当然，也可以利用“容器式”的远程桌面，隔离远程终端内本业务与其他系统，保证终端上的病毒、木马不能入侵到云服务内;
l 防病毒：病毒与木马是无孔不入的，对用户流量进行病毒过滤是必要的。当然，防病毒也可以在云朵的入口处实现，但对于应用层的病毒，还是要通过主机监控查杀的方式更为有效。
虚拟化平台上的安全
虚拟化平台上的安全与厂家产品的开放性有直接的关系，可以分为两种情况：
第一种情况是开源的平台，或者是得到了厂家的底层安全API 接口，如VMware 的VMSafe 接口，你可以利用接口插入自己的安全代码，对虚拟机上的流量进行安全检查与控制。
这种方式直接在虚拟化平台的底层hypervisor上控制用户数据流，有些像我们所理解的操作系统分为内核态与用户态，黑客要突破hypervisor 到内核层是比较困难的，想绕过这种安全监控也是十分困难的。
第二种情况是得不到虚拟化平台的底层接口，或者是希望通过第三方的安全控制措施，用户才放心( 虚拟化平台自己管理、自己控制的安全，总让人有些疑惑)。这种方式是目前安全厂家流行的流量牵引的安全控制措施。
实现的思路是利用SDN 技术中的流量牵引控制协议openflow，引导用户业务流量按照规定的安全策略流向，结合安全产品的虚拟化技术，建立防火墙、入侵检测、用户行为审计、病毒过滤等资源池，在用户申请虚拟机资源时，随着计算资源、存储资源一起下发给用户，保证用户业务的安全。
实现的步骤大致如下：
l 对安全资源虚拟池化：先对安全设备进行“多到一”的虚拟化，形成一个虚拟的、逻辑的、高处理能力的安全设备，如虚拟防火墙、虚拟入侵检测等;再对虚拟的安全设备进行“一到多”的虚拟，生成用户定制的、处理能力匹配的虚拟安全设备;
l 部署流量控制服务器：它是流量控制管理的中心，接受并部署用户流量的安全策略，当用户业务虚拟机迁移时，负责流量牵引策略的迁移落地;该服务器可以是双机热备，提高系统安全性，也可以采用虚拟机模式。同时，在虚拟计算资源池内安装流量控制引擎：具体方法是在每个物理服务器内开一个虚拟机运行流量控制引擎，负责引导该物理服务器上所有虚拟机，按照安全策略进行流量的牵引;
l 用户业务流量的牵引分为两种模式：
a) 镜像模式：针对入侵检测、行为审计等旁路接入的安全设备，把用户流量复制出来即可，不影响原先的用户业务流量;
b) 控制模式：针对防火墙等安全网关类安全设备，需要把用户的流量先引导到安全设备虚拟化池中，“清洗”流量以后，再把流量引导到正常的业务处理虚拟机。
l 因为需要改变用户流量的流向，需要对目的MAC、目的IP 进行修改。具体的方案很多，这里我们采用的是MAC in MAC 技术，对数据包二次封装，经过安全设备处理以后的“安全流量”恢复到“正常”状态;在云朵中的物理交换机与虚拟交换机支持SDN 模式时，也可以采用openflow 协议进行导引时的封装;
l 当用户业务服务的虚拟机在不同的物理服务中迁移时，该用户业务的安全策略也随着迁移到目的物理服务内的流量控制虚拟机，继续执行对该用户的业务流量进行引导。
小结
“云朵”方案通过把不同安全需求的业务系统部署在不同的云朵内，降低了对云内业务流隔离的需求，而在云朵内部，通过流量牵引与虚拟机加固等办法，实现网络层面的安全过滤，同时加强业务系统自身的安全管理，如用户权限管理、业务行为审计等，实现应用层面的访问控制，对敏感数据的存储与传输都建议采用加密方式。
“云朵”方案是个过渡性质的方案，等到云朵内的安全隔离与控制技术成熟，多个云朵就可以合成一个云了。
云朵”方案化解“私有云”安全过渡期难题,布布扣,bubuko.com
云朵”方案化解“私有云”安全过渡期难题
标签：文件 数据 os 类 问题 代码
原文地址：http://www.cnblogs.com/hy-dyt/p/3796358.html
