“云管边端”协同的边缘计算安全防护解决方案

摘　要 边缘计算是 5G 重要新技术能力，通过低延时、大流量、高性能服务促进新应用创新。边缘计算能力的实施面临物理、网络、协议、应用、管理等多层面的威胁，急需新安全防护能力支撑。该解决方案利用机器学习、诱骗防御、UEBA 等技术，针对边缘计算的业务和信令特点设计，结合“云管边端”多层面的资源协同和防护处理，实现立体化的边缘计算安全防护处理。

创新互联坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都网站制作、成都网站建设、外贸营销网站建设、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的承留网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！

关键词： 多接入移动边缘计算；边缘云；安全防护；机器学习；诱骗防御；用户及实体行为分析

内容目录 ：

0　引 言

1　5G 及边缘计算

2　边缘计算面临的风险

2.1　基础设施层安全风险

2.2　电信服务层安全风险

2.3　终端应用层安全风险

2.4　管理面安全风险

2.5　租户服务面安全风险

2.6　MEC 安全威胁总结

3　“云管边端”安全防护技术

3.1　功能架构

3.2　主要功能

4　“云管边端”安全防护实践

4.1　应用场景

5　结 　语

“云管边端”协同的边缘计算安全防护解决方案是恒安嘉新针对边缘计算发展提出的全面安全解决方案。方案综合考虑边缘计算产业中用户、租户、运营者多方面的要求，通过多级代理、边缘自治、编排能力，提供高安全性和轻量级的便捷服务。整体方案提供边缘计算场景的专业防护；提供多种部署方式；在提供高性价比服务的同时为边缘云计算输送安全服务价值。

5G 是驱动创新互联网发展的关键技术之一。5G 边 缘 计 算（Multi-access Edge Computing， MEC）提供了强大的云网一体化基础设施，促使应用服务向网络边缘迁移。MEC 的一大特点是同时连通企业内网和运营商核心网，其安全性直接影响企业内网安全以及运营商基础设施安全。随着边缘计算在各行各业商用，MEC 和生产管理流程逐渐融合，安全问题将日益突出， 对于 MEC 的安全防护需求日益强烈 。

采用标准 X.805 模型，MEC 安全防护由 3 个逻辑层和 2 个平面组成。3 个逻辑层是基础设施层（分为物理基础设施子层、虚拟基础设施子层）、电信服务层和终端应用层。2 个平面为租户服务面和管理面。基于此分层划分识别得到如下 MEC 安全风险。

2.1　基础设施层安全风险

与云计算基础设施的安全威胁类似，攻击者可通过近距离接触硬件基础设施，对其进行物理攻击。攻击者可非法访问服务器的 I/O 接口， 获得运营商用户的敏感信息。攻击者可篡改镜像， 利用虚拟化软件漏洞攻击边缘计算平台（Multi- access Edge Computing Platform，MEP） 或者边缘应用（APPlication，APP） 所在的虚拟机或容器， 从而实现对 MEP 平台或者 APP 的攻击。

2.2　电信服务层安全风险

存在病毒、木马、蠕虫攻击。MEP 平台和APP 等通信时，传输数据被拦截、篡改。攻击者可通过恶意APP 对MEP 平台发起非授权访问， 导致用户敏感数据泄露。当 MEC 以虚拟化的虚拟网络功能（Virtual Network Function，VNF）或者容器方式部署时，VNF 及容器的安全威胁也会影响 APP。

2.3　终端应用层安全风险

APP 存在病毒、木马、蠕虫、钓鱼攻击。APP 和 MEP 平台等通信时，传输数据被拦截、篡改。恶意用户或恶意 APP 可非法访问用户APP，导致敏感数据泄露等。另外，在 APP 的生命周期中，它可能随时被非法创建、删除等。

2.4　管理面安全风险

MEC 的编排和管理网元（如 MAO/MEAO） 存在被木马、病毒攻击的可能性。MEAO 的相关接口上传输的数据被拦截和篡改等。攻击者可通过大量恶意终端上的 APP，不断地向用户APP 生命周期管理节点发送请求，实现 MEP 上的属于该用户终端 APP 的加载和终止，对 MEC 编排网元造成攻击。

2.5　租户服务面安全风险

对于存在的病毒、木马、蠕虫、钓鱼攻击， 攻击者近距离接触数据网关，获取敏感数据或篡改数据网管配置，进一步攻击核心网；用户面网关与 MEP 平台之间传输的数据被篡改、拦截等。

2.6　MEC 安全威胁总结

基于对上述风险的认识，可以看出：MEC跨越企业内网、运营商服务域、运营商管理域等多个安全区域，应用了基于服务化接口的多类 5G 专用接口和通信协议，网络中存在面向应用、通信网、数据网的多维度认证授权处理， 传统的简单 IDS、IPS、防火墙等防护方式很难满足 MEC 安全防护的要求，需要新的具备纵深防御能力的专业性的解决方案处理。

3.1　功能架构

“云管边端”安全防护解决方案总体功能架构如图1 所示。解决方案利用机器学习、诱骗防御、UEBA 等技术，针对边缘计算的业务和信令特点设计，结合“云管边端”多层面的资源协同和防护处理，实现立体化的边缘计算安全防护处理。解决方案由五个层面的功能组件实现，分别为可视化层、中心安全云业务层、边缘安全编排层、安全能力系统层、数据采集层。

图 1 MEC 安全防护解决方案功能架构

在可视化层，产品通过 MEC 安全防护统一管理平台提供安全资源管理、安全运维管理、安全运营管理、统一门户、租户门户、安全态势感知服务。在中心安全云业务层，产品通过MEC 安全云实现基础数据资源统管、安全运算资源统管、安全能力编排。

边缘安全能力层部署适应虚拟化基础环境的虚拟机安全等服务能力，这些能力由 DDoS 攻击防护系统、威胁感知检测系统、威胁防护处理系统、虚拟防火墙系统、用户监控及审计系统、蜜网溯源服务系统、虚拟安全补丁服务系统、病毒僵木蠕钓鱼查杀系统以及边缘侧 5G 核心安全防护系统。

边缘安全编排层由安全微服务和引擎管理微服务构成。数据采集层主要提供信令面和数据面的流量采集，并对采集到的信令面流量进行分发，对用户面流量进行筛选和过滤。

3.2　主要功能

“云管边端”安全防护解决方案提供如下八个方面的特色安全功能。

（1）基本安全

提供基础的安全防护功能，包括防欺骗、ACL 访问控制、账号口令核验、异常告警、日志安全处理等能力。

（2）通信安全

提供针对 MEC 网络的通信安全防护能力， 包括防 MEC 信令风暴、防 DDoS、策略防篡改、流量镜像处理、恶意报文检测等能力。

（3）认证审计

提供针对 MEC 网络的认证审计和用户追溯安全防护能力，可以处理 5GC 核心网认证交互、边缘应用和服务的认证交互、以及 5G 终端的认证交互，并可以进行必要的关联性管理和分析。

（4）基础设施安全

提供对 MEC 基础设施的安全防护能力， 包括关键基础设施识别，基础设施完整性证实，边缘节点身份标识与鉴别等。并可以提供Hypervisor 虚拟化基础设施的安全防护处理，保障操作系统安全，保障网络接入安全。

（5）应用安全

提供完善的 MEC 应用安全防护能力，包括APP 静态行为扫描、广谱特征扫描和沙箱动态扫描，保护 APP 和应用镜像安全。

（6）数据安全

提供多个层面的 MEC 数据安全防护能力。在应用服务中提供桌面虚拟镜像数据安全能力， 避免应用数据安全风险。在身份认证过程中， 结合 PKI 技术实施双因子身份认证，保护认证信息安全。通过安全域管理和数据动态边界加密处理，防范跨域数据安全风险。

（7）管理安全

提供完善的管理安全防护能力。包括安全策略下发安全防护，封堵反弹 Shell、可疑操作、系统漏洞、安全后门等常规管理安全处理，以及针对 MEC 管理的 N6 及 N9 接口分析及审计。实现对于管理风险的预警和风险提示。

（8）安全态势感知

通过对资产、安全事件、威胁情报、流量进行全方位的分析和监测，实现针对 MEC 网络的安全态势感知。

4.1　应用场景

“云管边端”安全防护解决方案不仅为基础电信企业提供 5G 场景下 MEC 基础设施的安全保护能力和监测 MEC 持续运营安全风险的工具，而且赋能基础电信企业向 MEC 租用方提供安全保护增值服务，推动 5G 安全产业链上下游协同发展。整体解决方案支持私有边缘云定制部署，边缘云合作运营，安全服务租用等多种商业模式。

企业通过部署“云管边端”安全防护解决方案，能够有效实现将网络安全能力从中心延伸到边缘，实现业务快速网络安全防护和处理，为 5G 多样化的应用场景提供网络安全防护。因此，企业更有信心利用 5G 部署安全的智能化生产、管理、调度系统，从而丰富工业互联网应用，促进工业互联网智能化发展 。

4.2　主要优势

“云管边端”安全防护解决方案具备如下优势：

（1）专为边缘计算环境打造，整体方案在分级架构、安全编排、安全性能、协议分析等多方向优化，提供 MEC 最佳防护方案。

（2）多种模式适应各类应用场景需求，企业可根据自身需求和特点灵活选择。可以选择租用模式，无需专业技术人员即获得最新 MEC 安全技术服务。也可以选择定制模式，深度研发适配企业特性的安全防护处理。

（3）高效融合 MEC 各个层面的安全保护能力，降低综合安全防护成本，支持多种收费模式，降低入门门槛，让MEC 安全保护不留死角。

（4）创造安全服务价值，安全策略自动化以及与网络和云服务能力的联动，深度优化MEC 安全运维管理，创造边缘云服务安全价值。

本解决方案当前已在多个实际网络中部署，实现对于智慧港口、智慧工厂、智慧医疗、工业互联网等重要信息化应用资产的安全防护。例如，随着 5G 网络的发展，可以实施对于工业大型工程设备的 5G 远程控制改造，实现远程实时控制，完成高清视频回传，从而提升生产效率。但远控过程中的各类网络安全风险可能威胁到生产稳定性，造成重大损失。通过本解决方案的实施，可以保障 5G 远程控制改造实施，保护生产运行的高效运转。

引用文本：张宝山,庞韶敏“. 云管边端”协同的边缘计算安全防护解决方案[J].信息安全与通信保密,2020(增刊1):44-48.

张宝山，硕士，高工，主要研究方向为核心网、边缘计算、网络功能虚拟化、物联网、网络安全等； 庞韶敏 ，硕士，高工，主要研究方向为核心网、边缘计算、物联网、网络安全、主机安全等。 选自《信息安全与通信保密》2020年增刊1期（为便于排版，已省去原文参考文献）

云计算时代安全综述-秘钥交换（上）

离上篇文章认证加密（下）发表已经过去好久了，笔者一直在思考要不要继续写安全基础类的文章，直到本周日晚上陪孩子看朗读者节目的时候，特别是节目组邀请到了53岁的清华大学高等研究院杨振宁讲座教授王小云，介绍了她在密码学中的贡献。孩子和家人在观看节目的时候，对MD5是什么，为什么这么重要，特别是王教授谈到基于MD5设计的国家加密标准已经广泛应用到银行卡，社保卡等领域，让加密这个古老但年轻的领域走入更多人的视野。

咱们前边介绍的内容主要围绕对称加密，从这篇文章开始，我们的焦点shift到非对称加密算法上，非对称加密也称作是公钥加密算法，整个算法有个非常关键的环节：秘钥交换。秘钥交换“人”如其名，解决的本质问题是如何安全的交换秘钥。咱们还是请出老朋友爱丽斯女王和鲍勃领主来说明一下。假设爱丽丝女王和鲍勃领主要安全的通信，那么爱丽斯女王和鲍勃领主就把各自的秘钥发给对方。结果是通信的双方都持有这个共享的秘钥，这个共享的秘钥就可以被用来后续信息安全的交互。

为了让后续的讨论更加接地气，咱们假设爱丽斯女王和鲍勃领主从来都没有见过面，那么我们该如何让女王和领主安全的通信呢？这个问题也是秘钥交换算法适用的最原始应用场景。为了确保女王和领主之间通信的隐私性，双方需要一个共享的秘钥，但是安全的沟通共享秘钥并没有想象中那么简单。如果恶意攻击者窃听了女王和领主的电话通信，或者邮件通信（假设传输的明文信息），那么恶意攻击者会窃取到女王和领主共享的秘钥，后续双方所有的通信内容，都可以通过这个秘钥来破解，女王和领主的所有私密通信不安全了，通信内容已经成为整个王国茶余饭后的谈资。

如何解决这个问题呢？这是秘钥交换算法要解决的核心问题，简单来说，通过秘钥交换算法，爱丽丝女王和鲍勃领主就可以安全的实现共享秘钥交换，即便是有恶意攻击者在监听所有的通信线路，也无法获取双方通向的秘钥，女王和领主终于可以无忧无虑的八卦了。

秘钥交换从通信双方生成各自的秘钥开始，通常情况下非对称加密算法会生成两个秘钥：公钥和私钥（public key和private key）。接着通信的双方分别把自己的公钥发送给对方，公钥的”公“在这里是公开的意思，这就意味着恶意攻击者也可以获得通信双方生成的公钥信息。接着女王和领主分别用收到的公钥和自己持有的私钥结合，结果就是共享的通信秘钥。大家可以站在恶意攻击者的角度看这个公钥，由于恶意攻击者没有任何一方的私钥，因此恶意攻击者是无法获取女王和领主通信用的”共享“秘钥。关于共享秘钥在女王和领主侧产生的过程，如下图所示：

了解了秘钥交换算法的大致工作机制后，接着我们来看看秘钥交换算法是如何解决爱丽斯女王和鲍勃领主安全通信问题。如上图所展示的过程，女王和领主通过秘钥交换算法确定了可以用作安全通信的秘钥，这个秘钥可以被用作认证加密的秘钥，因此即便是MITM（中间人攻击者）截获了女王和领主通信的数据，但是由于没有秘钥，因此通信的内容不会被破解，这样女王和领主就可以安全的通信了，如下图所示：

不过这里描述的内容稍微不严谨，我们顶多只能把这种场景称作passive MITM，大白话是说恶意攻击者是被动的在进行监听，和active MITM的主要却别是，active中间人会截获秘钥交换算法交换的数据，然后同时模拟通信双方对端的角色。具体来说，中间人会actively来同时和女王以及领主进行秘钥交换，通信双方”以为“和对方对共享秘钥达成了共识，但是本质上女王和领主只是和中间人达成了共享秘钥的共识。大家可以思考一下造成这种错误认知的原因是啥？

其实背后的原因不难理解，因为通信的双方并没有其他手段判断收到的公钥和通信的对端的持有关系，我们也称作这种秘钥交换为”unauthentiated“秘钥交换，如下图所示：

那么如何解决active MITM攻击呢？相信大家能够猜到authenticated key exchange，咱们先通过一个具体的业务场景来看看，为啥我们需要这种authenticated的模式。假设我们开发了一套提供时间信息的服务，服务被部署在阿里云上，我了预防时间数据被恶意攻击者修改，因此我们使用MAC（message authentication code），如果大家对MAC没有什么概念，请参考笔者前边的文章。

MAC需要秘钥来对数据进行机密性和完整性保护，因此我们在应用部署的时候，生成了一个秘钥，然后这个秘钥被以某种方式非法给所有的客户端用户，应用运行的非常稳定，并且由于有秘钥的存在，守法遵纪的所有客户端都可以读取到准确的时间。但是有个客户学习了本篇文章后，发现这个秘钥可以用来篡改数据，因此我们的网站受到大量客户的投诉，说读到的时间不准确，造成系统的业务运行和数据处理出现问题。

你让架构师赶紧处理，架构师给出了每个用户都生成独享秘钥的方案，虽然能够止血，但是很快你会发现这种方案不可行，不可运维，随着用户数量激增，我们如何配置和管理这些秘钥就变成了一个大问题，还别说定期更换。秘钥交换算法在这里可以派上用场，我们要做的是在服务端生成秘钥，然后为每个新用户提供公钥信息。由于用户端知道服务端的公钥信息，因此MITM攻击就无法在中间双向模拟，我们也称这种模式为：authenticated key exchange。

我们继续分析这个场景，中间人虽然说也可以和服务进行秘钥交换，但是这个时候中间人和普通的客户端就没有差异了，因此也就无法执行active MITM攻击了。

随着科技的发展，互联网几乎在我们生活中无孔不入，如何安全的在通信双方之间确立秘钥就变得极其重要。但是咱们前边介绍的这种模式扩展性不强，因为客户端需要提前预置服务端的公钥，这在互联网场景下尤其明显。举个例子，作为用户，我们希望安全的和多个银行网站，社保网站进行数据通信，如果需要手机，平板，台式机都预置每个网站的公钥信息才能安全的进行访问，那么你可以考虑便利性会有多差，以及我们如何安全的访问新开发的网站？

因此读者需要理解一个非常重要的点，秘钥交换非常重要，但是有上边介绍的扩展性问题，而这个问题的解决是靠数字签名技术，数字签名和秘钥交换结合起来是我们后边要介绍的SSL技术的基础，要讲清楚需要的篇幅会很长，因此咱们后续用专门的章节来介绍SSL原理。不过为了后续介绍的顺畅性，咱们接下来聊几个具体的秘钥交换算法，以及背后的数学原理。

咱们先从笔者系列文章第一篇中提到的Diffie-Hellman秘钥交换算法说起，Whitfield Diffie和Martin E. Hellman在1976年发表了一篇开创新的论文来介绍DH（Diffie-Hellman）秘钥交换算法，论文中把这个算法称作”New Direction in Cryptography“。这篇论文被冠以开创性的主要原因是论文两个第一：第一个秘钥交换算法以及第一次公开发表的公钥加密算法（或者说非对称加密算法）。

DH算法的数据原理是群论（group theory），这也是我们今天所接触到的所有安全机制的基石。因为笔者并不是数学专业毕业，数学基础也不是太牢固，因此一直犹豫要如何继续在安全的角度继续深入下去。为了让这个算法更加容易被读者理解，因此后边的内容会稍微涉及到一些数据基础知识，相信有过高中数学知识的同学，应该都能看懂。

要介绍群论，首要问题是定义清楚什么是群（group）。笔者查阅了相关资料，群在数学领域中有如下两个特征：

1，由一组元素组成

2，元素之间定义了特殊的二元运算符（比如➕或者✖️）

基于上边的定义，如果这组元素以及之上定义的二元操作符满足某些属性，那么我们就称这些元素组成个group。对于DH算法来说，背后使用的group叫做multiplicative group：定义了乘法二元运算符的元素集合。读者可能会问，那么这个multiplicative group具体满足那些属性呢？由于这部分的内容较多，咱们来一一罗列介绍：

- Closure（闭包）。集合中的两个元素通过定义的运算符计算后，结果也在集合中。举个例子，比如我们有集合M，M中有元素a，b和c（c=a*b），那么这三个元素就符合closure属性，集合上定义的运算符是乘法。

- Associativity（可结合性）。这个和中学数学中的结合性概念一致，你能理解数学公式a × (b × c) = (a × b) × c就行。

- Identity element（单位元素）。集合中包含单位元素，任何元素和单位元素经过运算符计算后，元素的值不发生变化。比如我们有集合M，包含的元素（1，a，b，c....），那么1就是单位元素，因为1*a = a，a和单位元素1通过运算符计算后，结果不变。

- Inverse element（逆元素）。集合中的任何元素都存在逆元素，比如我们有集合元素a，那么这个元素的逆元素是1/a，元素a和逆元素通过运算符计算后，结果为1。

笔者必须承认由于我粗浅的数学知识，可能导致对上边的这四个属性的解释让大家更加迷惑了，因此准备了下边这张图，希望能对群具备的4个属性有更加详细的补充说明。

有了前边关于群，群的属性等信息的介绍，咱们接着来具体看看DH算法使用的group具体长啥样。DH算法使用的群由正整数组成，并且大部分情况下组成群的元素为素数，比如这个群（1，2，3， ....，p-1)，这里的p一般取一个很大的素数，为了保证算法的安全性。

注：数学上对素数的定义就是只能被自己和1整除的数，比如2，3，5，7，11等等。素数在非对称加密算法中有非常广泛的应用。计算机专业的同学在大学期间应该写过寻找和打印素数的程序，算法的核心就是按顺序穷举所有的数字，来判断是否是素数，如果是就打印出来。不过从算法的角度来看，这样穷举的模式效率不高，因此业界也出现了很多高效的算法，很快就能找到比较大的素数。

DH算法使用的群除了元素是素数之外，另外一个属性是模运算符，具体来说叫modular multiplication运算。咱们先从模运算开始，模运算和小学生的一些拔高数学题很类似，关注的是商和余数。比如我们设modulus为5，那么当数字大于5的时候，就会wrap around从1重新开始，比如数字6对5求模计算后，结果是1，7的结果是2，以此类推。对于求模计算最经典的例子莫过于钟表了，一天24个小时，因此当我们采用12小时计数的时候，13点又被成为下午1点，因为13 = 1*12 + 1（其中12为modulo）。

接着我们来看modular multiplication的定义，我们以6作例子，6 = 3 ✖️ 2， 如果modulo是5的话，我们知道6全等于（congruent to）1 modulo 5，因此我们的公式就可以写成：

3 × 2 = 1 mod 5

从上边的等式我们得出了一个非常重要的结论，当我们把mod 5去掉后，就得出3 × 2 = 1，那么3和2就互为逆元素。

最后我们来总结一下DH算法base的群的两个特征：

- Commutative（交换律），群中两个元素计算具备交换律，也就是ab=ba，通常我们把具备交换律的群成为Galois group

- Finite field（有限域），关于有限域的特征我们下边详细介绍

DH算法定义的group也被称作为FFDH（Finite Field Diffie-Hellman），而subgroup指的是group的一个子集，我们对子集中的元素通过定义的运算符操作后，会到到另外一个subgroup。

关于群论中有个非常重要的概念是cyclic subgroup，大白话的意思是通过一个generator（或者base）不断的和自己进行乘法运算，如下变的例子，generator 4可以了subgroup 1和4：

4 mod 5 = 4

4 × 4 mod 5 = 1

4 × 4 × 4 mod 5 = 4 (重新开始，这也是cylic subgroup的体现)

4 × 4 × 4 × 4 mod 5 = 1

等等

当我们的modulus是素数，那么群中的每个元素都是一个generator，可以产生clylic subgroup，如下图所示：

最后我们完整的总结一下群和DH定义的Galois群：

- group就是一组定义了二元操作的元素集合，并具备closure, associativity, identity element, inverse element属性

- DH定义的群叫Galois group，组成群的元素是素数，并在群上定义了modular multiplication运算

- 在DH定义的群中，每个元素都是一个generator，重复和自己相乘后，产出subgroup

Groups是很多加密算法的基础，笔者这是只是稍微的介绍了一点皮毛知识，如果读者对这部分感兴趣，可以查阅相关的材料。有了群的初步认识了，咱们下篇文章来介绍DH算法背后的工作原理，敬请期待！

云计算应用存在哪些问题，采取哪些安全防护措施

云计算存在的一些问题:

虚拟化安全问题：如果物理主机受到破坏，其所管理的虚拟服务器由于存在和物理主机的交流，有可能被攻克，若物理主机和虚拟机不交流，则可能存在虚拟机逃逸。如果物理主机上的虚拟网络受到破坏，由于存在物理主机和虚拟机的交流，以及一台虚拟机监控另一台虚拟机的场景，导致虚拟机也会受到损害。

2.数据集中的安全问题：用户的数据存储、处理、网络传输等都与云计算系统有关，包括如何有效存储数据以避免数据丢失或损坏，如何对多租户应用进行数据隔离，如何避免数据服务被阻塞等等。

3.云平台可用性问题：用户的数据和业务应用处于云平台遭受攻击的问题系统中，其业务流程将依赖于云平台服务连续性、SLA和IT流程、安全策略、事件处理和分析等提出了挑战。另外，当发生系统故障时，如何保证用户数据的快速恢复也成为一个重要问题。

4.云平台遭受攻击的问题：云计算平台由于其用户、信息资源的高度集中，容易成为黑客攻击的目标，由此拒绝服务造成的后果和破坏性将会明显超过传统的企业网应用环境。

5.法律风险：云计算应用地域弱、信息流动性大，信息服务或用户数据可能分布在不同地区甚至是不同国家，在政府信息安全监管等方面存在法律差异与纠纷;同时由于虚拟化等技术引起的用户间物理界限模糊可能导致的司法取证问题也不容忽视

云计算的安全防护措施：

1基础设施安全

基础设施安全包括服务器系统安全、网络管理系统安全、域名系统安全、网络路由系统安全、局域网和VLAN配置等。主要的安全措施包括安全冗余设计、漏洞扫描与加固，IPS/IDS、DNSSec等。考虑到云计算环境的业务持续性，设备的部署还须要考虑到高可靠性的支持，诸如双机热备、配置同步，链路捆绑聚合及硬件Bypass等特性，实现大流量汇聚情况下的基础安全防护。

2数据安全

云数据安全包含的内容远远不只是简单的数据加密。数据安全的需求随着三种服务模式，四种部署模式(公共云、私有云、社区云、混合云)以及对风险的承受能力而变化。满足云数据安全的要求，需要应用现有的安全技术，并遵循健全的安全实践，必须对各种防范措施进行全盘考虑，使其构成一道弹性的屏障。主要安全措施包括对不同用户数据进行虚拟化的逻辑隔离、使用身份认证及访问管理技术措施等，从而保障静态数据和动态数据的保密性、完整性、可用性、真实性、授权、认证和不可抵赖性。

3虚拟化安全

虚拟化的安全包括两方面的问题：一是虚拟技术本身的安全，二是虚拟化引入的新的安全问题。虚拟技术有许多种，最常用的是虚拟机(VM)技术，需考虑VM内的进程保护，此外还有Hypervisor和其他管理模块这些新的攻击层面。可以采用的安全措施有：虚拟镜像文件的加密存储和完整性检查、VM的隔离和加固、VM访问控制、虚拟化脆弱性检查、VM进程监控、VM的安全迁移等。

4身份认证与访问管理(IAM，IdentityandAccessManagement)

IAM是用来管理数字身份并控制数字身份如何访问资源的方法、技术和策略，用于确保资源被安全访问的业务流程和管理手段，从而实现对企业信息资产进行统一的身份认证、授权和身份数据集中化的管理与审计。IAM是保证云计算安全运行的关键所在。传统的IAM管理范畴，例如自动化管理用户账号、用户自助式服务、认证、访问控制、单点登录、职权分离、数据保护、特权用户管理、数据防丢失保护措施与合规报告等，都与云计算的各种应用模式息息相关。

IAM并不是一个可以轻易部署并立即产生效果的整体解决方案，而是一个由各种技术组件、过程和标准实践组成的体系架构。标准的企业级IAM体系架构包含技术、服务和过程等几个层面，其部署体系架构的核心是目录服务，目录服务是机构用户群的身份、证书和用户属性的信息库。

5应用安全

由于云环境的灵活性、开放性以及公众可用性等特性，给应用安全带来了很多挑战。云计算的应用主要通过Web浏览器实现。因此，在云计算中，对于应用安全，尤其需要注意的是Web应用的安全。要保证SaaS的应用安全，就要在应用的设计开发之初，制定并遵循适合SaaS模式的安全开发生命周期规范和流程，从整体生命周期上去考虑应用安全。可以采用的防护措施有访问控制、配置加固、部署应用层防火墙等。

云时代该如何掌控企业数据安全

　云时代该应该这样掌控企业数据安全，在2016年的安全界盛会RSA 2016上DLP（Data Loss Prevention, 数据防泄密）成为企业用户关注度最高的产品，大会的DLP分类厂商多达88家，从本次大会上，可以看到企业数据防泄露产品的一些发展趋势。

DLP与网关功能整合

将DLP与网关类产品的传统安全功能进行整合，实现从内容层面的安全检测和防御，比如将DLP功能加入Web网关、将DLP功能加入URL与反垃圾邮件网关等，代表厂商有Forcepoint、ClearSwift等。

基于终端加密与权限控制的DLP+

从数据泄露的源头上对其进行封堵。在终端对文档进行不同的访问权限、操作权限和外发权限控制，并对发送者和接收者制定不同的权限策略。数据在外发的时候是加密的，只有被信任的接收者才能够看到文件内容或对文件执行对应的操作。代表企业Vera、Fasoo。

针对特定应用的DLP

只针对特定应用（如Exchange、outlook、office365、SharePoint）或特定通道（Email Cloud Service）的DLP检测。这类产品会在终端进行访问、打印、拷贝等操作的权限控制，并针对文件类型、收发件人、以及文件内容定义敏感信息检测策略，实现固定终端和移动终端的DLP检测。代表厂商有Messageawre、Mimecast等。

公有云环境下CASB成为重要方向

随着国外（特别是美国）企业对SaaS（Office365、DropBox、Box、Facebook等云服务）的依赖程度日益增高，已经将很多数据、业务迁移到云服务和云平台上，企业员工对公有云环境的使用也会成为一个安全问题。数据泄露已经成为云安全面临的首要威胁，通过Office365、DropBox等云服务和云存储上传或共享文件时，都有可能带来数据泄露的问题。CASB（Cloud Access Security Broker，云访问安全代理）的方法是一种解决思路，实现在“任何时间、任何地点”保护企业数据不被泄露。基于CASB的DLP实现可以分为两种形式：

形式一：应对企业内部DLP问题

保持原有DLP产品的软硬件形态不变，在原有网关上增加对云服务和云应用的支持，可以部署在企业网的终端和边界处。代表厂商Symantec、Intel Security（McAfee）、AvePoint等传统DLP厂商。

形式二：应对企业员工移动办公的DLP问题

CASB作为一种云服务，部署在企业员工使用的云平台上，在云中为用户提供单点登录、访问控制、行为监控、数据防护、安全合规等服务。DLP是CASB要考虑的重要问题，也是产品落地的明确方向，CASB也在积极寻求与传统DLP厂商的合作。对于DLP而言，相对于传统边界部署上方案，CASB的区别在于其结合了用户、设备、内容和应用这几个维度，来理解数据是如何在云环境中被共享或被使用的，从而做出相应的策略配置。基于CASB的DLP产品形态也从传统的Network+Endpoint+Storage DLP变成了Cloud+Mobile DLP。代表厂商有Skyhigh、BlueCoat等。

云时代该如何掌控企业数据安全

数据是企业中最重要也是最需要保护的资产，因此数据安全也变得越来越重要。随着公有云和BYOD技术的不断发展，数据防泄密（Data Loss Prevention, DLP）作为数据安全领域最重要的技术产品，也面临着“实现云中数据泄露防护”的挑战。虽然目前国内企业和个人用户对云服务和应用的依赖还较小，但Cloud+Mobile的DLP将成为DLP产品的发展趋势，国内的DLP产品，也需要快速适应从on-premise到cloud-based的转变。

数据防泄密系统：这是一套从源头上保障数据安全和使用安全的软件系统。包含了文件透明加解密、内部文件流转功能、密级管控、离线管理、文件外发管理、灵活的审批流程、工作模式切换、服务器白名单等功能。从根本上严防信息外泄，保障信息安全。

分享题目：云计算信息安全解决方案图 云计算云安全
网站路径：http://scyanting.com/article/doejdoh.html