王晓萍，孟 坤

(1.西安文理学院，陕西 西安 710068;2.西安电子科技大学计算机学院，陕西 西安 710071)

0 引言

2007年，凯文·凯利首次提出交互云域［1-4］(Intercloud)的概念，即“云域上的云(Cloud of Clouds)”。如果一个云的计算和存储资源已经饱和，它可能无法响应用户进一步的服务请求。理论上，若云计算有统一的服务接口和管理框架，那每个云都可以直接使用其他云中的计算和存储资源。令人遗憾的是在业界尚未形成统一的标准化体系［5-6］。

云计算在没有标准体系的情况下，各供应商采用不同的底层存储结构，搭建各自的虚拟化平台，对外提供各自的编程接口，且不可互操作。这将直接阻碍云计算的长远发展，且导致跨平台的交互和移植面临诸多挑战。

举例来说，Twitter作为微博客的成功典范，如何应对流量的洪峰是其必须要考虑的关键问题［7］，比如美国年度橄榄球决赛将吸引近一亿美国人观看电视实况转播。可预料的是比赛过程中，Twitter流量必然大幅增长，无法预料的是流量涨幅如何，尤其是洪峰时段，流量会达到多少。为解决这个问题，Twitter公司购置了适量设备以应对无重大事件时的流量压力，同时租赁云计算供应商的设备以应对重大事件来临时的洪峰流量。租赁云计算服务使得计算资源可以按需分配，在需求高的时候自动分配更多的计算资源。由上述例子可以看出“跨平台即服务”模式的各种应用场景和其面临的挑战:

(1)企业可以利用云平台在流量高峰期通过公有云支持最坏情况下的任务处理，缓解企业内部服务器的压力［8］，而私有云只需要应对平时的任务需求。不管出于何种原因致使企业选择外部公有云来支持内部运作，跨平台(私有云到公有云)的交互问题始终是企业或云供应商必须面对和解决的［9］。

(2)如果一个云平台的计算或存储能力达到饱和状态，就不能接受用户进一步的服务请求。再者，当云平台受到网络攻击或由于自身原因导致瘫痪的情况下，也不可能再接受用户进一步的服务请求。处于饱和或瘫痪状态下的云供应商可以通过跨平台服务来将自身的任务转包给其他云供应商。此处的跨平台服务需求并不仅仅是公有云之间数据交互的需求，还应该包括各个平台自身的安全值度量，以及平台的信誉评价等。跨平台即服务模式应提供统一的云平台评价体系，以方便用户的取舍。

(3)如果企业对供应商的服务质量不够满意，或者因为追求更低价格或更高服务性价比的云服务，企业完全可能更换云服务供应商。与传统商业模式不同的是，企业更换不同的服务供应商不仅需要重新签订服务协议SLA，而且需要对企业的应用或数据进行从原平台到新平台的跨平台移植。这种跨平台的数据移植存在很多新的问题，如数据的所有权归属、用户数据能否完整地导出等。

(4)由于业务的多样性，企业可能需要同时选择多个云供应商提供的云服务。多个异构云平台之间的数据交互与整合是企业必须解决的关键问题。

(5)多个企业或机构联合起来共同完成某项任务时需要形成跨平台的临时性合作，此处涉及的多个异构云平台的交互可能是多个私有云之间的数据交互，因此数据的安全性显得更为重要。

可以看出，不同云平台的安全度量以及服务信誉的评价标准还没有形成，跨平台的数据交互和移植行为缺少规范化的监控和约束。

1 跨平台的数据交互和移植

数据是云间交互和移植的关键问题［10］。由于云计算采用虚拟化资源技术，因此数据被放置在云端后，企业永远不知道云中究竟发生了什么。但是，企业必须抓住数据的3大核心问题。

(1)明确数据的所有权。

企业首先要关注的是数据的所有权问题。用户数据存储在云端，虽然使用云平台的存储设施，但是数据的所有权应该归用户所有。企业在签署的服务等级协议(Service-Level Agreement，SLA)中不仅要对数据所有权有明确说明，还必须要求供应商给出合理的数据导出或输出方式，并且明确数据导出的费用应该由哪一方来承担，包括存储介质的费用。最后企业需要关注的是在数据导出以后，原平台是否对数据进行了彻底清除。如果疏于此处的审查，可能导致企业数据的泄漏。

(2)确定哪些数据作为导出数据。

首先应该了解存储在云端的数据种类，才能进一步指出哪些数据在跨平台移植中应该作为导出数据。存储在云端的数据可以归纳为以下3类［9］:

①用户数据。用户数据是指用户输入到云平台上的数据，如电子邮件、用户姓名等。

②关联数据。关联数据是指与用户数据相关的元数据，如电子邮件日志和索引等。这些数据用来帮助云供应商为用户提供更好的服务。

③系统数据。例如系统日志、系统控制信息等，这些数据用来协助系统的运行，但是与用户并不直接相关。

可以看出，跨平台的数据移植中应将用户数据作为导出数据，且仅把其作为导出数据。数据导出后，云端的用户数据和关联数据必须彻底清除，以防企业信息的泄漏。企业在与云供应商签署SLA时，应明确要求云平台的数据架构，将系统数据与用户数据分隔开，以便于用户数据的提取。

(3)规范导出或交互数据的格式。

由于各个供应商的硬件配置、虚拟化技术，存储管理机制等各不相同，导致了用户数据在不同云平台的存储格式存在差异。虽然各大联盟都在极力地推动云计算标准体系的建立，然而仍无法要求所有供应商遵循统一的存储格式，但可以通过SLA要求云供应商提供良好的、规范的数据输出格式。这对于后期数据的跨平台移植或交互至关重要。

可信第三方可以协助企业来规定专有的数据导出或交互格式，也可以直接使用现存的数据标准，如Odata和XML等。另外，可信第三方应实现在不同数据格式之间的快速转换。

企业可以咨询提供跨平台服务的第三方来协助其跨平台数据移植的需求。图1为第三方监控下的跨平台数据移植过程。

图1 第三方监控下的跨平台数据移植过程

2 云平台的安全度量和信誉评价

无论是企业的私有云需要同一个合适的公有云展开合作，还是失效的(计算饱和或瘫痪状态)公有云寻找合适的接替伙伴，都涉及从众多云平台中进行选择的过程。文献［11］中的选择模型没有对各种云平台加以区分。当某个云平台需要调用其他云时，系统搜索所有云平台，将找到的第一个可以调用的云平台返回给需求的发起者。本文通过可信第三方为云平台间的选择提供一个更符合实际需求的平台评价模型。这个评价模型不仅包括云平台自身的安全评价，还包括该平台所提供服务的用户满意度，称之为平台的信誉度。下面将分别讨论云平台的安全度量方法和信誉度量方法。

2.1 云平台的安全度量

对于存储在云平台中的数据，有4个方面的信息安全需要加以考虑，分别是保密性、完整性、可用性和灾难可恢复性。分别针对这4个方面对云平台的安全性加以度量:

(1)保密性。

对于公共云中存储数据的保密性，关键在于用户数据是否真的在云计算存储时经过了加密［11］?如果加密了，使用什么加密算法，又是什么强度的密钥［12］?

假设用SEi来表示云平台i的数据保密性。第三方对所有云平台的加密算法的强度进行统计，用ei来表示平台i加密算法的强度。当云平台未对数据采用任何加密算法或所使用的加密算法未经过标准机构的审核，其加密强度为0，即ei=0。将平台算法加密强度最大的记作Max(ei)。第三方可以根据平台i的加密算法强度同最大加密强度的比值作为平台i的保密性数值。可见，SEi的取值范围在0～1之间，即:

其中i表示任意云平台。

(2)完整性。

数据被安全地保存在云端并不意味着用户的数据就是完整的。当用户向云端存储数据时，用户需要知道数据是否被完整地保存。与传统数据的完整性度量不同的是，从云平台中读取数据是需要支付宽带费用的。用户如果想通过下载全部数据到本地的方法来获知数据的完整性则显得不切实际，而且即便是选择在云端直接验证数据的完整性也变得十分困难，因为用户一旦上传数据至云端，就无从得知数据的真实存储位置，且数据的存储位置可能动态调整和变化。这使得传统保证完整性的技术无法发挥效果。Cong Wand在文献［13］中提出了一种验证动态存储云计算的数据的完整性的方法。

假设用SIi来表示平台i的数据完整性。第三方可以根据云平台的历史记录中对数据完整性的失效率来度量其的完整性，即:

(3)可用性。

云供应商无法绝对地保证数据的随时可用性。而可用性对于使用云服务的用户而言是至关重要的，因此可用性是评价云平台安全的重要标志。假设用SUi来表示平台i的数据可用性，第三方可以根据云平台的历史运营状况来度量其可用性，即:

没有任何云计算服务提供商能够在正常运行时间上提供“5个9”(99.999%)的指标。如果能够提供“3个9”，对于用户而言已经是很幸运的了［12］。

(4)灾难可恢复性。

数据灾难恢复是指当数据存储设备发生故障或遭遇意外灾难造成数据意外丢失时，通过相应的数据恢复技术，达到找回丢失数据，降低灾难损失的目的。

云计算中数据的灾难恢复可以通过云端数据的多次备份来实现。备份的次数越多，数据分布的地域越广泛，则数据的灾难可恢复性越高，当然备份的次数越多成本也就越大。云计算存储并不意味着平台会为用户备份存储的数据［12］。例如，存储在Amazon S3、Amazon Simple DB 或者Amazon Elastic Block Store中的数据会在多个物理位置冗余存储，这是服务的正常组成部分，对此不会额外收费。而在Amazon EC2或者Amazon S3及Amazon SimpleDB服务中，对于保存在运行实例中数据，亚马逊Web服务并不对此进行备份，虽然这些数据同样也是用户数据。

假设用SCi来表示平台i的数据灾难可恢复性。第三方通过对所有云平台的备份次数进行统计，用ci来表示平台i的备份次数。显然，未对用户数据进行备份的云服务，其灾难可恢复性为0，即ci=0。将所有平台的最大备份次数记作Max(ci)，第三方可以根据平台i的备份次数同最大备份次数的比值作为平台i的数据灾难可恢复性指标。可见，SCi的取值范围在0～1之间，即:

其中i表示任意云平台。

综上所述，可以从保密性、完整性、可用性和灾难可恢复性等方面来度量云平台或云服务的数据安全性。可信第三方可以为用户分别提供这几个方面的安全信息，也可以根据用户的具体侧重点提供一个综合的安全值。假设用Si来表示平台i的数据安全性，则:

其中，wi(i=1，2，3，4)表示用户的权重向量，默认情况下可以按照 w={0.25，0.25，0.25，0.25}来进行安全值计算。

2.2 云平台的信誉度量

云平台的信誉是指平台在服务中所体现的诚信度和提供服务的能力，它是云平台信誉程度的量化值。某平台i对平台j的信任度评价一般根据两方面的信息来综合:(1)其自身与平台j的直接历史交互记录，称之为直接信任;(2)其它节点提供的有关平台j的信任信息，称之为间接信任。用Tij来表示平台i对平台j的直接信任度，用Tij'来表示平台i对平台j的间接信任度。Tij和Tij'的取值范围为0～1之间的实数，0表示完全不信任，1表示完全信任。为方便表述，用i=0表示可信第三方，并假设所有平台对第三方给予100%的直接信任。因此，Ti0=1，其中i表示任意云平台。

(1)初始化。

第三方收集所有的云平台信息，在初始时刻，平台与平台之间尚未发生任何交易，也就不存在平台信誉的度量。系统初始化时，第三方选择任务大小不同的10个测试用例，分时段对所有云平台进行测试，并用该平台完成任务的多少来评价该平台的信誉，表示为第三方对该平台的信任程度，即:

其中i表示任意云平台。

(2)直接信任函数。

对于任意2个平台i和平台j，平台i对平台j的直接信任度由平台i与平台j的交互历史决定，而且直接信任度的计算不能像第三方初始化所有平台信誉度的方法一样，仅通过完成任务的比率作为度量的指标，而是需要考虑交易的时间间隔。如一桩三年前的交易对节点信誉的影响要远小于今天的一桩交易造成的影响。文献［14］仅通过历史交易中任务完成的比值来计算直接信任度，没有考虑交易之间的时间间隔。文献［15］虽然考虑了时间因素，但是每次都要重新计算所有历史交易的信息。

本文在对直接信任度进行更新时，加入时间衰减因子γ，其函数如下:

其中Δt表示前后2次交易的时间差。

假设平台i与平台j上次交易结束后，平台i对平台j的信任度为t1。用数值k表示平台i交给平台j的最新任务的完成情况，若完成，则k=1;否则k=0。新任务结束后，更新Tij为:

(3)间接信任函数。

假设信任具有传递性，即当平台i对平台j的直接信任度为Tij，同时平台j对平台k的直接信任度为Tjk，那么平台i仅通过平台j获取对平台k的间接信任度为:

由此可知，当平台i仅能通过第三方获取平台k的间接信任度时，Tik'=Ti0T0k=T0k。如图2(a)所示。

当平台i可以通过至少一个其他平台j获取对平台k的间接信任度时，不再使用第三方的初始化时的信息，如图2(b)所示。

当平台i可以且仅可以通过平台j和平台k获取平台m的间接信任度时，计算平台i对平台m的间接信誉度Tim'可以通过证据理论的合并公式计算如下:

图2 间接信任度的计算

3 结束语

本文首先通过分析跨平台服务的各种场景和其面临的种种挑战得出构建“跨平台即服务”模式的必要性和必然性;其次，通过可信第三方来实现跨平台服务，为云平台之间的数据交互问题以及众多云平台的选择问题提供了解决思路，且为用户提供云平台的安全度量和信誉度量2种平台评价方式，以方便用户按照自身需求进行选择。笔者下一步工作将深挖跨平台数据交互的细节知识，并将云平台的2种度量方式进行改进和整合，使之更符合实际需求。

［1］Mell P，Grance T.The NIST Definition of Cloud Computing［DB/OL］.http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf，2011-09-30.

［2］Dean J，Ghemawat S.MapReduce:Simplified data processing on large clusters［J］.Communications of the ACM，2008，51(1):107-113.

［3］Ercolani G.Cloud computing services potential analysis:An integrated model for evaluating software as a service［C］//The Fourth International Conference on Cloud Com-puting，GRIDs，and Virtualization.2013:77-80.

［4］Bernstein D，Ludvigson E，Sankar K，et al.Blueprint for the intercloud-protocols and formats for cloud computing interoperability［C］//2009 Fourth International Conference on Internet and Web Applications and Services.2009:328-336.

［5］Zhang Yu，Ren Shu Qin，Chen Shi Bin，et al.Differ-CloudStor:Differentiated quality of service for cloud storage［J］.IEEE Transactions on Magnetics，2013，49(6):2451-2458.

［6］Bruneo D，Distefano S，Longo F，et al.Workload-based software rejuvenation in cloud systems［J］.IEEE Transactions on Computers，2013，62(6):1072-1085.

［7］张为民，等.云计算:深刻改变未来［M］.北京:科学出版社，2009.

［8］Armbrust M，Fox A，Griffith R，et al.Above the Clouds:A Berkeley View of Cloud Computing［R］.EECS Department，University of California，Berkeley，Tech.Rep.UCB/EECS-2009-28，2009.

［9］吴朱华.云计算核心技术剖析［M］.北京:人民邮电出版社，2011.

［10］Ahmed S.Data Portability:Key to Cloud Portability and Interoperability［DB/OL］.http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1712565，2010-11-11.

［11］Di Costanzo A，De Assuncao M D，Buyya R.Harnessing cloud technologies for a virtualized distributed computing infrastructure［J］.IEEE Internet Computing，2009，13(5):24-33.

［12］Mather T，Kumaraswamy S，Latif S.Cloud Security and Privacy:An Enterprise Perspective on Risks and Compliance［M］.O’Reilly Media，Inc.，2009.

［13］Wang C，Wang Q，Ren K，et al.Ensuring data storage security in cloud computing［C］//Proceedings of the 17th International Workshop on Quality of Service.2009.

［14］袁禄来，曾国荪，姜黎立，等.网格环境下基于信任模型的动态级调度［J］.计算机学报，2006，29(7):1217-1224.

［15］刘莉平，陈志刚.网格实体行为可信度评估模型［J］.计算机工程与应用，2007，43(34):29-31.