云计算安全解决方案白皮书(三)

云计算安全解决方案白皮书

Jack zhai

三、云计算安全解决方案的设计思路

云计算架构的显著特点是数据和业务的集中处理,加上VM的动态迁移,各个的业务VM就混在一起,要将这些VM之间完全隔离是十分困难的。业务VM之间是需要互通的,如虚拟桌面需要与服务器连通,网站服务器要与数据库服务器通信,中间件服务器要提供服务支持等等。虽然可以通过虚拟交换机上的访问控制,让VM之间逻辑隔离开来,互通时到外边的三层网关上做流量过滤,但这会成倍地增加循环流量,让虚拟交换机不堪重负。

局部难以解决的问题,我们可以开拓眼界,把它放到更大的领域中,问题或许就变得简单了。因此,我们方案思路是先做安全的预处理,将重大的隔离问题放在整体网络安全规划中解决,先整体,再局部,将安全问题逐步分解。至于云的内部,能做到实时地动态监控,对VM之间的不安全流量报警,及时处理即可。

1、网络安全规划------云朵方案

虚拟化网络只是延展了网络边界,并没有改变网络的路由交换模式,传统的安全域规划同样是非常必要的。为了弥补在一个虚拟化池内部,做到两个信息系统之间强隔离的困难,我们在网络安全总体规划时,建议安全需求较大的两个信息系统就不要部署在一个虚拟化池中。比如等级保护二级系统与三级系统不要部署在一个虚拟化池中,可以部署在不同的虚拟化池里,每个虚拟化池都形成了一个“云朵”,这个设计思路就称为“云朵”方案。

云朵方案的设计思想如下:

  • 分别按照安全需求建立不同的虚拟池,如二级的办公业务池、三级的核心业务池;每个虚拟池如同一个传统安全域,有自己的云朵管理平台;(也可以在一个虚拟化池内,设立不同的服务区,同一区内的业务VM不能迁移到其他区域里,这样就形成物理服务器的不同区域)
  • 建立统一的安全运维管理中心,通过与各个云朵管理平台的互通,了解云朵内部的运行状态;
  • 核心互联域与外网互联域与“3+1”安全域功能基本一致;
  • 用户接入域分为两个:一是传统的物理终端接入域,一是虚拟终端接入域。

采用云朵方案的设计思路,将安全问题分为两个方面:一是云朵之间的安全,因为域边界位置明确,采用传统边界安全设计思路即可;二是云朵内的安全,是我们接下来的设计的重点。此时云朵内的各个业务系统安全需求接近,可访问的用户群大多一样,相互之间的隔离需求相对较弱。实现安全监控与审计,就可以满足业务系统的安全需求了。

2、云朵内安全方案:两头加固,中间导流控制

一个云朵就是一个虚拟化资源池,就是一个独立的安全域,包括服务器资源池、存储资源池,也包括安全资源池,还包括作为支撑虚拟资源池连接的虚拟网络。对于用户来讲,可以看见的只是云朵的门户而已。

云朵内的安全包括三部分:

  • 用户端与门户:门户是访问云朵的大门,用户端是访问的起点。用户端到门户可以通过多种网络路径,专网、互联网、移动网络等。其最大的特点,就是终端与访问网络的安全状态是不可控的。但在用户端与门户,可以做一些“门槛式”的安全加固措施,为云朵内的安全提供一些“初级攻击者的流量清洗与未授权行为的阻断”。
  • 用户端:专用的办公电脑可以安装指定的安全措施,如终端安全管理,强制终端的环境是安全可控的。但个人电脑、手机等智能终端,严格限制用户安装软件的方法就不太现实了,采用“容器”式终端软件运行模式,或者是虚拟终端模式,能够让用户访问服务时,尽量少地受终端上其他不安全软件的影响;
  • 云朵的门户:作为进入云计算服务的大门,流量很大,不适合做细粒度的安全措施,但部署网络层的控制与流量清洗是可以的:
  • 身份鉴别与授权管理:确保访问者有合法的授权;
  • Anti_DDOS:清洗以阻断带宽为目的DDOS攻击流量,保证门户的畅通;
  • 恶意代码检测:针对文件型的恶意代码进行APT检测,一般采用并联方法,不影响业务性能;对于已知的,采用特征检测方法,对于未知的,采用“沙箱”技术,释放文件,通过行为判断是否为恶意代码,可以检测未知的木马、病毒、蠕虫等(建立已经检测文件的特征库,减少在线检测的数量)。发现恶意代码,立即报警,通知安全管理中心,针对具体的访问连接进行进一步处理。
  • 虚拟机:业务系统“看到”的是服务器,就是VM,由于系统升级兼容等问题,OS与DB的很多漏洞无法及时打补丁,所以针对性的安全加固是必须的:
  • 安全基线增强:VM服务于特定的应用,对于不需要的服务端口、不需要的账户、不需要的第三方软件等应该关闭,对于不能修改的系统文件应该安全保护;
  • 反控制加固:服务器安全底线是不做“肉鸡”,因此,建立进程的黑白红策略,禁止账户权限随意更改,禁止木马进程启动,保护注册表,保护系统文件不被替换等策略,都是必须的;若每个VM都做到这样的“自律”,入侵者即使有幸入侵到你的云内部,也会寸步难行,无所建树的;
  • 敏感信息防护:入侵者多以获取系统管理员权限为攻击目标,我们建立强制性访问控制策略(系统权限与敏感信息访问权限分开管理),把系统管理员的敏感信息访问权限降低,这样即使入侵者获得管理员权限,仍然不能看到敏感信息的目录或文件。等保三级的信息系统就需要支持强制性访问控制的安全加固。
  • 网络区域:云朵内的网络不仅有物理网络,而且有虚拟网络。如何让每个用户的访问流量先流经相应的安全措施,再进入VM?再明确一点,就是让用户流量不再按照原来的IP方式路由转发,而是按照我们定义的安全策略重新安全路径。这就是我们云朵内安全解决方案的核心支持平台:云导流(流引导与控制)

总结起来:云朵内部的安全是两头加固,中间导流的模式。门户的加固提高了入侵者的攻击门槛,服务器的安全加固提高了入侵者攻击的技术难度,中间网络层通过流量引导,将传统的安全措施部署进来,进一步提高访问控制、安全检测、行为审计的能力。

3、流引导与控制------先定义流

顾名思义,流引导是以流为控制的核心,流是什么?流就是跟某个信息系统相关的所有网络流量。因为业务系统提供服务都是通过网络进行的,所以可以说服务器网卡上的所有流量就是我们需要控制的流。其内容无非一下几个方面:

  • 用户访问业务服务器的流量;
  • 服务器与其他数据库、中间件服务器通信的流量;
  • 系统与其他系统数据共享的流量,如数据交换、数据备份等;
  • 业务系统运维管理的流量
  • 服务器系统运维管理的流量;
  • 日志输出的流量;
  • 系统维持各种网络协议、系统管理的通信流量。

流在网络里分为外部用户通过门户进入的“南北流量”,有虚拟机之间的“东西流量”;由于VM的迁移,流量在那个交换机上是不确定的,可以说,在网络层上看,流是交织在一起的。我们希望通过流量的引导,让每个业务系统还原出逻辑的网络拓扑,可以部署了安全措施的网络拓扑。

用流的概念让每个信息系统从“复杂”的网络里脱离出来,每个信息系统的流是分离的,安全管理人员看到的是一个逻辑网络层,展示的是每个信息系统的逻辑网络拓扑图。有了这个逻辑网络层,我们就可以按照业务系统自身的安全需求定义其安全属性。

定义了流,如何引导流呢?

TCP/IP协议规定了数据包是按目的IP进行路由转发的,每个网络设备(交换机、路由器等)都有自己的路由表,保证数据包从自己设备转发出去时是正确的下一跳。这就好比练车场上,本来车是可以随便走的,但画上行道线,车就要按照定义好的行车线,先过红绿灯,再到立交桥…因此,流的引导与控制就是对数据包重新路由的一个过程。这样我们可以让安全措施不再跟着VM去迁移,可以固定在某给位置,而是让信息流绕个弯,流经相应的安全设备。

时间: 2024-10-11 10:20:07

云计算安全解决方案白皮书(三)的相关文章

云计算安全解决方案白皮书(一)

云计算安全解决方案白皮书 Jack zhai 研究云的安全有两三年了,但形成完整的安全思路,还是去年的事,这也是"流安全"思路形成的主要阶段. 云计算的安全问题之所以突出,是因为虚拟机的动态迁移,以及多业务系统交织在一起,这让传统的网卡边界就是安全部署点的方法不在适用.流安全不再关注被保护服务器的物理位置,转而关注访问该服务器的数据流.通过对数据流的重新"路由",保证对数据流的安全清洗,从而实现对服务器的网络保护.在访问控制模型中,有一类流模型,就是针对数据流进行保

云计算安全解决方案白皮书(二)

云计算安全解决方案白皮书 Jack zhai 二.云的安全是阻碍云计算普及的最大障碍   A:云计算让传统信息安全防御体系面临尴尬 信息安全是保障信息系统业务安全的,采用云计算技术后,并非只是增加了一个虚拟化管理软件的安全风险那么简单,最重要的是,它让多年来信息安全保障基本思路---边界安全防御思路面临尴尬. 1.什么是边界安全防御思路 多年来信息安全防御是基于边界安全思路进行设计的,这源自于美国人的IATF(信息保障技术框架),很早以前就提出了网络安全的保障思路.把网络按功能分为不同的安全域,

云计算安全解决方案白皮书(四)

云计算安全解决方案白皮书 Jack zhai 四.云朵内的安全设计思路---云导流方案 云朵内不同于传统的安全设计思路就是云导流方案.它实现了云朵内以流为核心,重塑信息系统逻辑网络拓扑的过程,同时,定义了该信息系统的安全属性,即部署的网络安全措施. 云导流方案包括三个核心的组成部分:策略管理平台.安全资源池.导流网络. 1.流量引导与控制模块(CFC:云导流模块) 流引导的范围就是导流控制的网络.该网络与虚拟机紧挨着,保证进出VM的流能得到正确的引导:该网络与安全资源池相邻,保证引导的数据包进入

【G】开源的分布式部署解决方案(三) - 一期规划定稿与初步剖析

G.系列导航 [G]开源的分布式部署解决方案 - 预告篇 [G]开源的分布式部署解决方案(一) - 开篇 [G]开源的分布式部署解决方案(二) - 好项目是从烂项目基础上重构出来的 [G]开源的分布式部署解决方案(三) - 一期规划定稿与初步剖析 抱歉 首先我先说声抱歉,因为上一篇结尾预告第三篇本该是“部署项目管理”,那为什么变成本篇呢? 请容我解释一下,在预告篇到现在为止,经常会有人问我这个项目到底是干什么的.或许之前写的比较粗糙.那我相信目前定稿后的功能概览图应该会给大家一个比较清晰的认识.

JS组件系列——BootstrapTable+KnockoutJS实现增删改查解决方案(三):两个Viewmodel搞定增删改查

前言:之前博主分享过knockoutJS和BootstrapTable的一些基础用法,都是写基础应用,根本谈不上封装,仅仅是避免了html控件的取值和赋值,远远没有将MVVM的精妙展现出来.最近项目打算正式将ko用起来,于是乎对ko和bootstraptable做了一些封装,在此分享出来供园友们参考.封装思路参考博客园大神萧秦,如果园友们有更好的方法,欢迎讨论. KnockoutJS系列文章: JS组件系列——BootstrapTable+KnockoutJS实现增删改查解决方案(一) JS组件

云计算的设计模式(三)——补偿交易模式

云计算的设计模式(三)--补偿交易模式 撤消由一系列的步骤,它们共同限定了终于一致性操作中,假设一个或多个步骤失败运行的工作.依照终于一致性模型,业务实现复杂的业务流程和工作流的云托管的应用程序中非经常见. 背景和问题 在云中运行的应用程序频繁改动数据. 此数据可跨在各种地理位置的所保持的数据源的一个品种传播. 为了避免争用,并提高在分布式环境中,比如这种性能,应用程序不应该试图提供强事务一致性.相反,应用程序应该实现终于一致性. 在该模型中,一个典型的业务操作由一系列的独立的步骤.而正在运行这

常用 Gulp 插件汇总 —— 基于 Gulp 的前端集成解决方案(三)

前两篇文章讨论了 Gulp 的安装部署及基本概念,借助于 Gulp 强大的 插件生态 可以完成很多常见的和不常见的任务.本文主要汇总常用的 Gulp 插件及其基本使用,需要读者对 Gulp 有一个基本的了解.如果你对 Gulp 还不是很了解,可以通过下面两篇文章快速了解 Gulp . 由于几乎所有的插件都有非常友好的使用文档,所以本文不讨论涉及插件使用的东西,仅是一个汇总.排名不分先后. 本系列文章导航: 一.基于 Gulp 的前端集成解决方案 —— 在windows下安装gulp 二.基于 G

云计算设计模式翻译(三):Compensating Transaction Pattern(事务修正模式)

先说明一下:这个模式的中文我一直找不到一个比较恰当的中文来表述,姑且在本文中称之为事务修正模式吧,如果各位觉得有更合适的称呼欢迎提出. 这个模式指的是对于一个由一系列步骤组成.并遵循最终一致性的操作来说,如果一个或多个中间步骤发生错误,那么就必须要对这次操作的步骤进行撤销.对于一个实现了复杂业务逻辑和工作流的云端应用来说,遵循最终一致性的操作随处可见,所以本模式应用场景还是比较多得. Context and Problem 运行在云端的应用程序通常会频繁地修改数据,而这些数据通常会在分布在不同物

Java Web乱码分析及解决方案(三)——响应乱码

响应乱码 请求乱码是客户端向服务器发送数据时,服务器解码错误.响应乱码则是服务器处理完请求后,输出到浏览器的数据被浏览器错误解码造成的显示乱码,这类乱码是最常见也是最直接的.造成这类乱码的情况最直接的一点就是服务器对Content-Type响应报文设置错误. 页面编码: 我们的页面一般来说,可能是通过下面两种方式生成的,也就是常说的静态页面和动态页面: (1)静态页面:我们用记事本或其他IDE工具编写的页面(比如.html),这些页面在编写的时候就需要指定一个字符编码,比如我们指定为ISO-88