供具体的物理层设备基础。虚拟基础设 备服务端A3为IaaS，即基础设施服务（Infrastructure-as-a-Service)，有时候也叫做 Hardware-as-a-Service。当试图在办公室或者公司的网站上运行一些企业应用，需要买 服务器或其他高昂的硬件来控制实施本地应用。而当有IaaS后，你可以将硬件外包到别 的地方去。IaaS公司会提供场外服务器、存储和网络硬件，可以进行租用，节省了维护成本 和办公场地，公司可以在任何时候利用这些硬件来运行其应用。云平台服务端A2为PaaS， Platform-as-a-Service (平台服务），亦称中间件，公司所有的开发都可以在这一层进行， 节省了时间和资源。PaaS公司在网上提供各种开发和分发应用的解决方案，比如虚拟服务 器和操作系统，节省了在硬件上的费用，也让分散的工作室之间的合作变得更加容易，包括 网页应用管理、应用设计、应用虚拟主机、存储、安全以及应用开发协作工具等。云应用服务 端Al即Software-as_a-Service(软件服务即应用服务），这一层是和生活每天接触的一 层，大多是通过网页浏览器来接入。任何一个远程服务器上的应用都可以通过网络来运行， 就是SaaS 了。消费的服务完全是从网页如Netflix, MOG, Google Apps, Box. net, Dropbox或 者苹果的iCloud那里进入这些分类，尽管这些网页服务是用作商务和娱乐或者两者都有， 但这也算是云技术的一部分。
[0045] SaaS (通常也称为〃随需应变（on demand) 〃软件）：SaaS是最抽象的层，也是最为 成熟、最出名，也是得到最广泛应用的一种云计算模式。在这种模式下，应用软件安装在厂 商或者服务供应商那里，用户可以通过某个网络来使用这些软件，通常使用的网络是互联 网。提供商将确定服务器、虚拟机和网络设备等一切事情。企业只需通过浏览器访问这些 资源。IaaS是在云范围的另一端。IaaS公司提供场外服务器，存储和网络硬件，你可以租 用。节省了维护成本和办公场地，公司可以在任何时候利用这些硬件来运行其应用。IaaS 公司包括 Amazon 云平台、Windows Azure、VMffare、Rackspace 和 Red Hat 等。不过这些公 司又都有自己的专长，比如Amazon和微软Windows Azure给你提供的不只是IaaS，他们还 会将其计算能力出租给你来host你的网站。PaaS介于IaaS和SaaS之间，是把计算环境、 开发环境等平台作为一种服务提供的商业模式。云计算服务提供商可以将操作系统、应用 开发环境等平台级产品通过Web以服务的方式提供给用户。例如，微软的Windows Azure 或者Google的App Engine向你提供一些工具以开发移动应用程序、社交应用程序、网站、 游戏等等。云应用服务端Al与云平台服务端A2进行数据通信，云平台服务端A2与虚拟基 础设备服务端A3进行数据通信，虚拟基础设备服务端A3基于物理层设备A4进行数据处理 操作，通过云平台服务端A2和虚拟基础设备服务端A3,云应用服务端Al实现对物理层设备 A4的数据处理操作。
[0046] 其中，多个分布式云环境下的特征主要包括以下几点：
[0047] (1)授权需求，为建立一种安全可信的分布式云计算基础架构，要求多云架构的设 计者必须提出授权需求。
[0048] (2)多租户和虚拟，不同策略域中侧边信道攻击和干扰构成分布式云中严峻的挑 战。侧边信道攻击以从物理实现方面获取信息为主（如时间或带宽监视攻击等），内侧信道 攻击的出现是由于对共享的物理资源缺乏授权机制，租户间的干扰存在主要是因为在有缺 陷的访问控制策略下，一些隐秘的信道所致，这些有缺陷的访问控制策略允许未授权的信 息流。
[0049] (3)分散管理，分散管理可由本地自主原理来表示其特征，与集中管理方式相反， 其涵义为每一服务模型仅在其自身所拥有的资源范围保留管理控制权。这意味在控制资源 方面自主性有所损失，当涉及若干独立的云时，这便不是一种理想的系统特征。此外，精细 访问控制的需要可能对设计使用大量授权规则的访问控制策略提出一些基本的需求。这些 规则随着分撒性资源增加及用户量和由云所支持的服务的增加而会可能明显地增多。建立 在各种规则集成基础上的集中化设计可能会形成一些严峻的挑战。
[0050] (4)分布式安全合作，为支持分散化环境，对于服务分发，云基础架构应该允许水 平和垂直策略相交叉。由于云的复杂性质，资源和服务策略会使用要求在各种策略间无缝 互操作的不同模型。这些策略必须正确地规范化，经过认证，且强制实施。服务级别认定协 议可以提供安全合作并确保按照预先建立的规则提供服务。
[0051] (5)资格联盟，因为一个用户可能会穿越多个云来唤醒所需的服务，所以访问控制 策略必须支持一种控制机制，这种机制可将顾客的资格穿越多个访问层传递给所需的访问 服务与资源。这种需求包含了一种措施用于在授权模型内的一种分散性单点登录机制，它 可通过客户识别和资格权限穿越各个云系持续激活授权。
[0052] (6)约束规范，云计算环境的合作性质需要语义与语境方面的约束规范以确保对 服务与资源方面的适当保护，尤其对于各种移动服务。当确定对服务和资源的访问时，必须 对语义约束（如，各种职责隔离等）和语境约束（诸如在一个访问请求中所包含的临时或 环境约束）进行评估。在访问控制策略中应规定语义与语境约束条件。
[0053] 基于以上多个分布式云环境下的特征进行安全访问控制架构的设计时考虑，要确 保穿越多个分布式云环境的资源共享性质取决于其合作环境。如图1所示，示出了能够满 足前述授权需求的三种合作类型，分别为联盟、松散耦合、动态自组。
[0054] (1)联盟合作，联盟合作以具有高度的互关性和在相互合作的云间的诚信为特征， 并支持长期的互操作。为保安全，这种合作需要一种与相互合作的云的局部策略相一致的 全局性的元策略。如果全局的元策略需要通过集成各云的策略产生，则一种组合策略架构 (见图1顶部方框）便是必须的。
[0055] (2)松散親合合作，在松散親合合作环境中，局域策略支配着参与合作的各云间 的相互作用。与联盟合作方式对比，这种合作在访问策略和资源管理方面具有更多的灵活 性和自主性。两个合作的云可以将其所拥有的资源虚拟化，并允许对资源的自主共享。每 个云可共享的虚拟化资源与服务的信息存储在一个虚拟全局目录服务中（简称VGDS，既 virtual global directory service)，该目录服务在服务级别协议各方可清楚地显现。图 1中的中部方框示出了关于松散耦合各合作云的安全与私密策略符合协议规范的认证。
[0056] (3)动态自组合作，在动态自组合作方式下，用户仅需了解少量的远程共享服务。 由于对于用户或云来说，在一次服务时段的开始，有关全部的应用服务要求可能没有获得， 所以一个云可能会拒绝对其资源的访问。为确保在云可以以一种临时自组链接介入或离开 的动态互操作环境中，通过所探查到的资源和服务进行安全的互操作，需要开发一些适当 的验证和授权机制。
[0057] 在分布式环境中，我们可以建立一个基于这些合作设计的安全性访问结构。这些 合作方式的比较主要基于互操作度、自主性、隐秘度及认证复杂度。基于以上分析，我们提 出了基于联盟和松散耦合合作方式结合的资源与服务访问结构（安全访问控制架构）。
[0058] 还包括虚拟资源管理器A5和分布式访问控制模块A6,虚拟资源管理器A5,即 VRM-virtual resource manager，用于提供和配置虚拟资源，维护与其配置关联的虚拟需 求资源表，虚拟需求资源表包括整个虚拟全局目录服务库中的本地和远程资源。云应用服 务端AU云平台服务端A2和虚拟基础设备服务端A3均安装虚拟资源管理器A5,基于云 环境中虚拟资源的复杂多样性和散粒性，要求在云的第一层均驻留一个虚拟资源管理器 A5 (VRM)，每层的VRM负责提供和配置虚拟资源，它保持维护着一张与其配置关联的虚拟需 求资源表，包括整个VGDS(虚拟全局目录服务，见图1)中的本地和远程资源。
[0059] 分布式访问控制模块A6,即分布式访问控制模块ACM-access control module，用 于强化访问控制策略，其包括策略决策点、策略强化点和策略库。云应用服务端AU云平台 服务端A2和虚拟基础设备服务端A3均分布式访问控制模块A6,每一层驻留一个ACM，以强 化该层的访问控制策略，如图4所示，分布式访问控制模块A6包括策略决策点组件A51、策 略强化点组件A52、资格评估器A53、语义评估器A54、策略定点组件A55。
[0060] 在分布式云环境下，如图3a所示，针对本地云的访问（类型2)可以包括以下步 骤：
[0061] 第一步，用户访问云应用服务端A1。根据云应用服务端Al的分布式访问控制模 块A6的验证判断，通过云应用服务端Al的虚拟资源管理器A5获取云平台服务端A2的访 问资源