云计算用例白皮书
云计算用例研讨组
版本 3.0
2010 年 2 月 2 日
致谢：Dustin Amrhein、Patrick Anderson、Andrew de Andrade、Joe Armstrong、Ezhil Arasan B、James Bartlett、Richard Bruklis、Ken Cameron、Reuven Cohen、Tim M. Crawford、Vikas Deolaliker、Andrew Easton、Rodrigo Flores、Gaston Fourcade、Thomas Freund、Valery Herrington、Babak Hosseinzadeh、Steve Hughes、William Jay Huie、Nguyen Quang Hung、Pam Isom、Sam Johnston、Ravi Kulkarni、Anil Kunjunny、Thomas Lukasik、Bob Marcus、Gary Mazzaferro、Craig McClanahan、Meredith Medley、Walt Melo、Andres Monroy-Hernandez、Dirk Nicol、Lisa Noon、Santosh Padhy、Greg Pfister、Thomas Plunkett、Ling Qian、Balu Ramachandran、Jason Reed、German Retana、Bhaskar Prasad Rimal、Dave Russell、Matt F. Rutkowski、Clark Sanford、Krishna Sankar、Alfonso Olias Sanz、Mark B. Sigler、Wil Sinclair、Erik Sliman、Patrick Stingley、Robert Syputa、Doug Tidwell、Kris Walker、Kurt Williams、John M Willis、Yutaka Sasaki、Michael Vesace、Eric Windisch、Pavan Yara 和 Fred Zappert。
本作品基于Creative Commons Attribution Share Alike 3.0 Unported License
获得许可。
目录
1简介 (3)
2 定义及分类 (4)
2.1 云计算概念的定义 (4)
2.2 分类 (7)
2.3标准和分类间的关系 (9)
2.4 应用程序编程接口 (API） (11)
3 用例场景 (13)
3.1 最终用户到云 (14)
3.2企业到云到最终用户 (15)
3.3 企业到云 (17)
3.4企业到云到企业 (19)
3.5 私有云 (20)
3.6更改云供应商 (21)
3.7 混合云 (23)
3.8 交叉引用：需求和用例 (24)
4 客户场景 (26)
4.1 客户场景：薪资的云处理 (26)
4.2 客户场景：云物流和项目管理 (27)
4.3 客户场景：云中央政府服务 (28)
4.4 客户场景：混合云中的地方政府服务 (29)
4.5 客户场景：天文数据处理 (30)
5 开发人员需求 (32)
6 安全场景 (34)
6.1 法规 (34)
6.2 安全控制 (35)
6.3 安全联合模式 (36)
7 安全用例场景 (37)
7.1 云计算能力 (37)
7.2 基于云的开发与测试 (38)
7.3 云存储 (39)
7.4 交叉引用：安全控制和客户场景 (40)
7.5 交叉引用：安全联合模式和客户场景 (40)
8 结论和建议 (42)
关于版本3：在版本 3 中主要关注安全，包括技术要求、用例和安全模式。请参阅第44 页的变更小结，了解详细信息。
1简介
云计算用例研讨组汇集了云计算的用户和供应商，共同定义云计算中常见的使用场景。这些场景尽可能建立在最广泛的用户需求之上，展示了云计算的性能和经济价值。
该白皮书旨在强调云计算环境中需要进行标准化的功能和要求，以确保其互操作性、易集成性和便携性。在不使用封闭专利技术的情况下，必须能够实施本白皮书中的所有用例。云计算必须逐步演变为开放式环境，最大程度的减少供应商锁定，扩大用户的选择空间。用例将：
?提供实用的、基于用户使用经验的材料，便于读者针对互操作性和各种标准进行讨论。
?明确哪些地方应使用现有标准。
?引发业界对开放式云计算重要性的关注。
?明确应对哪些地方进行标准化。假如某特定用例当前不能实现，或者只能通过专有API 和产品实现，业界就需要定义明确的标准，使之得以实现。
用例明确指出共同的任务，也概括了可能遇到的挑战，这是对任何的标准努力最有力的支持。
《开放云计算宣言》(https://www.doczj.com/doc/4b17034468.html,) 阐释了维护云计算开放性的重要原则。在宣言公布后的两个月内，已有 250 家企业作为支持者签署了该宣言。本研讨组的所有活动均依照《开放云计算宣言》的六大原则进行：
?云计算提供者必须通力合作，确保通过公开合作和适度采用标准，解决采用云计算的过程中可能遇到的挑战。
?云计算提供者应尽可能采用现有标准。IT 行业已在现有标准和标准组织中投入很大，没有必要进行重复投入或重新改造。
?如果需要新的标准(或调整现有标准)，我们必须谨慎、务实，避免定制过多的标准。
必须确保标准能够促进创新，而不是阻碍创新。
?围绕开放云计算的任何社区计划都应该由用户需求来主导，而不只是取决于云计算提供者的技术需求，且应该根据实际的用户需求进行检测或验证。
?云计算标准组织、倡议团体与社区应该通力合作、保持协调一致，确保各项计划不会互相冲突或重叠。
?云计算提供者不得利用自己的市场地位，将用户锁定于自己的特定平台，也不得限制用户对云计算提供者的选择。
本白皮书将贯彻我们的长远计划，最终使这些原则得以实现。
2 定义及分类
本白皮书收录的下列定义和分类概述了云计算的概念。但本文的重点不是介绍云计算本身，而是基于实际的应用和需求定义云计算场景和用例。不论这些场景在分类中的定义和位置如何，我们都希望能为您提供清晰、有趣和实用的用例场景。
2.1 云计算概念的定义
云计算：云计算是一种能使用户便捷、随需应变地对共享的可配置计算资源共享池（如网络、服务器、存储器、应用程序和服务）进行网络访问的模型。该模型可在最少的管理投入或服务供应商介入的情况下快速实现资源的提供与发布。（本定义来自于美国国家标准和技术研究所颁布的最新版《NIST 云计算工作定义》试行稿1。）
2.1.1 交付模型
云计算的 NIST 定义定义了以下三种交付模型：
?软件即服务 (SaaS)：用户可以使用某应用程序，但不能控制运行该程序的操作系统、硬件或网络基础设施。
?平台即服务 (PaaS)：用户将托管环境用于其应用程序。用户能控制环境中运行的应用程序（也可能对托管环境具有一定控制权），但不能控制运行应用程序的操作系统、硬件或网络基础设施。平台通常是一个应用程序框架。
?基础架构即服务 (IaaS)：用户可以使用“基本的计算资源”，如处理能力、存储器、网络部件或中间件。用户能控制操作系统、储存器及部署的应用程序，也有可能控制网络部件（如防火墙和负载均衡器），但不能管理或控制底层的云计算基础设施。
2.1.2 部署模型
NIST 定义了以下四种部署模型：
?公有云：简单来说，公有云服务指的是用户通过互联网从第三方供应商获取的云计算服务。“公有”并不意味着这一服务无需付费，只是说服务可能免费或使用成本比较低。公有云也不意味着用户的资料会公诸于众，因为服务供应商通常会为用户设置一个访问控制机制。公有云提供了一种灵活、经济有效的部署解决方案。
?私有云：私有云具备公有云计算环境的许多优点，如灵活性强、以服务为基础等。两者的区别在于，基于私有云的服务中，在企业内部进行数据和流程管理时，可以不受网络带宽、安全风险和法规要求等的限制，而使用公有云服务则受以上限制。除此之
1
在以下网址的“NIST 云计算”页面可找到完整文档：https://www.doczj.com/doc/4b17034468.html,/groups/SNS/cloud-computing/。文档声明：“本材料虽属 NIST 但为公版著作。可自由复制和翻译。”本白皮书中所讨论的基本特征、交付模型和部署模型均基于 09 年 8 月 9 日的本文档第 15 版。
外，鉴于私有云所使用的用户访问和网络都被严格控制和标识，因此，私有云能为供应商和用户提供更好的云基础架构控制，同时提高了安全性和恢复能力。2
?社区云：社区云由一群共享利益（如特定安全需求或共同目标）的企业管理和使用。
社区的成员共享云中的数据和应用程序。
?混合云：混合云是公有云和私有云的融合，且两者可互操作。在此模型下，用户通常将非业务关键型信息和流程转移至公有云处理，而将业务关键型服务和数据留在自己的掌控下。3
2.1.3 基本特征
NIST 定义描述了云计算的五个基本特征：
?快速伸缩：伸缩性是指根据需要向上或向下扩展资源的能力。对用户来说，云计算的资源数量没有界限，他们可按照需求购买任何数量的资源。这是 NIST 定义中有关云计算的一个主要特征。
?服务可度量：在可度量服务下，由云计算供应商控制和监测云计算服务的各方面使用情况。这对于计费、访问控制、资源优化、容量规划和其他任务具有重要的意义。
?按需自助服务：云计算的按需服务和自助服务意味着用户可以在需要时直接使用云计算服务，而不必与服务供应商进行人工交互。
?无所不在的网络访问：这意味着供应商的资源可以通过互联网获取，并可以通过瘦客户端或富客户端以标准机制访问。4
?资源池：资源池允许云计算供应商通过多用户共享模式服务于用户。物理和虚拟资源可根据用户需求进行分配和重新分配。资源池具有地点独立性，客户一般无法控制或了解所提供资源的确切位置，但可以在高端提取层面（如地区、国家或数据中心）指定位置。5
2.1.4 其他术语
互操作性：互操作性讨论的是不同系统间的通信能力。接收系统必须能够识别通讯信息。在云计算的世界里，这代表与多个云计算供应商合作时编写代码的能力（不考虑供应商间的差异）。6
便携性：便携性指在某环境下运行另一环境中的组件和系统的能力。在云计算领域，这包
2
私有云可由第三方掌控，也可以不架构在企业内部。私有云不一定由使用该服务的企业管理或掌控。
3
混合云技术属社区云的范畴，因此，两种部署模式的需求将在本文第 3 节中的混合云部分中共同讨论。
4
这不一定仅指互联网访问。理论上来讲，只有越过防火墙才能访问私有云。不管所使用的网络类型如何，云计算服务的访问不限于特定类型的客户。
5
大部分情况下，隐私法和其他法规要求云计算供应商的资源设在特定的地点。供应商和用户必须共同合作遵守这些规则。
6
关于互操作性、便携性和易集成性的定义，请参见https://www.doczj.com/doc/4b17034468.html,/interop_et_al.htm。
括软件和硬件环境（即物理环境和虚拟环境）。
整合性：整合是把不同的组件和系统融合到一个整体系统的过程。基于云计算的组件和系统的整合将受到多用户共享、云联合和政府法规等因素的影响。
服务等级协议 (SLA)：服务等级协议是服务供应商与客户间的合同，它明确了用户的要求以及网络服务供应商提供的具体服务。通常，服务等级协议包括服务正常运行时间、客户隐私、安全性和备份过程等项目。
云联合：云联合是在不同系统上将数据和用户身份相结合的操作。云联合可以由服务供应商或云代理实现。
代理：代理没有自己的云资源，但能依据客户所需的服务等级协议在用户与服务商之间配对。用户不了解代理不掌控资源的事实。
多用户共享：多用户共享是指来自不同企业的多个系统、应用程序或数据托管在同一个物理硬件的特性。这在大多数基于云计算的系统中非常普遍。
云爆发：云爆发是混合云根据需要向私有云提供多余资源的技术。私有云有足够的处理能力应对工作负载时无需混合云。如果私有云的处理能力无法满足工作负载需要，混合云可以自动将多余的资源分配给私有云。
策略：策略是操作过程的统称。例如，安全策略可能指定对某特定云服务的所有请求加密。
监管：监管指确保所有策略均加以执行的控制和过程。
虚拟机 (VM)：一个文件（通常称为映像），在执行时，对用户而言等同于真机。云基础架构即服务可以作为虚拟机映像提供给用户，并能按照用户需求随时启动或停止。在虚拟机运行时对其所作的更改能够储存在磁盘上并永久保留。
应用编程接口 (API)：应用编程接口是指导开发人员如何编写代码以与某些系统进行交互的合同。API 描述了系统所支持操作的语法。对于每一个操作，API 指定了应输入系统的信息、系统应该输出的信息以及可能发生的错误情况。
?API 可以通过具体的编程语言定义或通过诸如 WSDL 或 IDL 的中性格式定义。
REST 规范通常没有机器可读语言，但也定义了 API。
?API 还可包含协议（如 HTTP 协议）和数据格式（例如 JSON 或 XML Schema）的细节。
?API 需要人类智能来理解数据和操作符的意义。机器能够识别出完成方法 X 需要两个整数作为参数，但只有开发人员（人类）才能辨别使用哪两个整数。
2.2 分类
下图定义了云计算的分类：
在该图表中，服务用户使用云计算提供的服务，服务供应商管理云基础架构，服务开发人员自己创建服务。（注意以上角色的交互需要开放式标准。)每种角色都将在下文详细讨论。
2.2.1 服务用户
服务用户指的是真正使用服务的终端用户或企业，不管所使用的服务
是云计算软件、平台还是基础架构。
根据服务的类型和用途，用户需要接触不同的用户界面和程序接口。
某些用户界面与其他应用程序类似，用户在使用时不需要了解云计算；
另外一些用户界面则提供了管理功能，如启动或停止虚拟机，或是管
理云存储等。根据所编写的应用程序不同，用户编写应用程序代码所
使用的程序接口也不同。
用户还需要签署服务等级协议和合同。这些通常在用户和服务供应商
的协商下通过人工干预的方式完成。用户对产品的期望和供应商的声
誉是协商的关键部分。
2.2.2 服务供应商
服务供应商向用户提供服务。根据服务类型不同，供应商的任务也有所区别：?对于云计算软件即服务，供应商安装、管理和维护软件。供应商并不一定拥有运行软件的物理基础架构，但用户只能使用应用程序，无法接触到该基础架构。
?对于云计算平台即服务，供应商管理平台的云基础架构，通常是某特定类型程序的框架。用户的应用程序不能访问平台下的架构。
?对于云基础架构即服务，供应商维护存储器、数据库、消息队列或其他中间件，或者是虚拟机的托管环境。用户可以把服务作为磁盘驱动器、数据库、消息队列或机器使用，但不能访问托管服务的架构。
在服务供应商图表中，堆栈最底层是固件和硬件，它们构成其他所有组件的基础。往上是软件核，也就是操作系统或在云计算下托管基础架构的虚拟机管理员。虚拟资源和映像包含了基本的云计算服务，诸如处理能力、存储器和中间件。虚拟机管理员控制的虚拟映像包括映像本身和管理映像所需的元数据。
对服务供应商操作具有决定作用的是管理层。从低层次来说，管理层通过计量确定服务的使用对象和使用程度，通过自动配置确定分配给用户的资源，通过监测跟踪系统的状态和资源使用情况。
从较高层次上来说，管理层通过计费收回服务成本，通过容量规划满足客户的需求，通过服务等级协议管理确保供应商和用户达成的服务条款已全部履行，并向管理人员进行汇报。
服务供应商的所有操作都涉及安全性。（安全需求的不同等级超出本书讨论范围。）开放式标准同样适用于这些操作。一套全面的标准能够简化供应商的操作，并与其他供应商实现互操作。
2.2.3 服务开发人员
服务开发人员创建、发布和监管云计算服务。这些通常是直接通过
SaaS 模型交付给终端用户的“业务”应用程序。在 IaaS 和 PaaS层
次编写的应用程序以后也能供 SaaS 开发人员和云计算供应商使用。
创建服务的开发环境多种多样。如果开发人员创建的是 SaaS 程序，
他们很可能为供应商托管的环境编写代码。在这种情况下，发布服务
就是将其部署到供应商的架构中。
在服务创建阶段，服务尚未发布给用户之前，分析包括进行远程调试
以测试服务。服务发布之后，分析允许开发人员监测服务性能，并在
必要时进行更改。
2.3 标准和分类间的关系
标准可通过四种方式对云计算用例场景产生影响。这四种方式分别是在每种类型的云计算服务内、跨不同类型的云计算服务、在企业和云计算之间以及在企业的私有云内。
2.3.1 跨云计算服务类型的标准
随着云计算日渐普遍，应用程序很可能会使用不同种类的云计算服务。应用程序可能会利用云存储服务、云消息队列并管理（启动/停止/监测）云中运行的虚拟机等。明确不同服务间的协作标准具有重要的意义。
2.3.2 云计算服务类型内部标准
在每一类云计算服务内（IaaS、 PaaS 或 SaaS），开放式标准都能够避免供应商对用户的锁定。
对于云基础架构即服务，用于处理云数据库的 API 标准集允许应用程序处理来自多个供应商的数据。常用 API 能使用户无需做出重大改变即可自由迁移到其他云数据库供应商，也能便于将新数据资源与现有应用程序的整合。针对其他云计算架构服务（如存储、消息队列和 MapReduce）的常用 API 具备数据与数据交换通用格式相似的作用。对于虚拟机来说，常用虚拟机格式意义重大。用户获取虚拟机将其部署在云计算供应商处之后，还能在不进行任何更改的情况下将其部署给另一个云计算供应商。
对于云计算平台即服务，云计算中提供的大部分平台都是应用程序框架。框架通常提供了常用的服务，如用户界面、存储和数据库等，但这些服务只能通过该框架的 API 获得。对于云计算软件即服务，开放式标准适用于应用程序层。这种类型的标准很少特定于云，因此它们超出本文的讨论范围。例如，某基于云计算的文字处理程序应支持文档便携性标
准，而文字处理程序中的标准要求与程序是否在云中运行无关。
2.3.3 云计算与企业程序间的标准
尽管云计算逐渐兴起，企业架构诸如 Java EE 等并没有淘汰。定义企业程序如何与云数据库或云消息队列等资源进行通讯的标准可使现有程序在无需重大更改的情况下利用云计算服务。解决云计算与现有架构和开发范式之间的整合将成为这部分的主要挑战。
2.3.4 企业内部标准
企业内部标准的决定因素是互操作性、数据审计、安全性和管理等方面的需求，同时企业内部标准还将构建适用于企业和云计算的标准。企业将与集合了私有云、公有云和混合云的部署模式进行交互。
2.4 应用程序编程接口 (API）
构建云计算解决方案的主要机制是云计算供应商提供的 API。云计算 API 在四个不同的层次上发挥作用，可分为五个基本类型。
2.4.1 API层次
API 有四种不同的层次。每个层次都需要开发人员将重点放在不同的任务和数据结构上。
层次1 - 线路：在本层次上，开发人员直接写入请求的有线格式。如果该服务基于 REST，则开发人员创建相应的 HTTP 标头，创建请求负载并打开一个到服务的 HTTP 连接。REST 服务返回数据，同时返回 HTTP 响应代码。由于许多 REST 服务的直接性，在这个层次编写代码相对比较有效。
如果该服务基于 SOAP，则开发人员创建 SOAP 封套，添加相应的 SOAP 标头，用数据载荷填充 SOAP 封套主体。SOAP 服务通过包含请求结果的 SOAP 封套实现响应。使用SOAP 服务需要解析封套的 XML 内容；出于这个原因，大多数 SOAP 服务通过更高层次的 API 实现调用。
层次2 - 特定语言工具包：本层次上的开发人员使用一个特定语言工具包来处理 SOAP 或REST 请求。虽然开发人员仍将重点放在穿越线路的数据格式和结构上，但很多细节（例如处理响应代码和计算签名）由工具包进行处理。
层次3 – 特定服务工具包：开发人员使用一个更高级别的工具包处理特定的服务。在这个层次上工作时，开发人员能够专注于业务对象和业务流程。开发人员专注于对组织至关重要的数据和程序时可以提高生产力，而不用将精力放在线路协议上。
层次4 - 中立服务工具包：这是 API的最高层次。在这一层次工作的开发人员使用连接多个云计算供应商的通用接口。与层次 3 相同的是，开发人员仍将重点放在业务对象和业务流程上。不同的是，在层次 4 工作的开发人员不必担心他们正在使用哪个云服务。使用中立服务工具包编写的应用程序应该能够使用不同的云计算供应商（请参阅第21 页的更改云供应商），且尽可能减少对代码的改动。
2.4.2 API 分类
编程接口可分为五类：
分类1 - 普通编程：C＃、PHP、Java等中通用的应用程序编程接口。此分类中没有特定的云计算。
分类2 - 部署：将应用程序部署到云计算的编程接口。除特定于云的包装技术外，此分类中包括 .NET 程序集和 EAR/WAR 文件在内的传统包装机制。
分类3 - 云服务：与云服务协同工作的编程接口。正如上一节讨论，云服务 API 可以是特定服务或中立服务。这些 API 分为云存储服务、云数据库、云消息队列和其他云服务等分类别。使用云服务 API 编写代码的开发人员知道他们正在使用云。
分类4 – 映像和基础架构管理：管理虚拟机映像和基础架构细节的编程接口。映像的 API 支持上传、部署、启动、停止、重新启动和删除映像。基础架构管理 API 控制如防火墙、节点管理、网络管理和负载平衡等细节。
分类5 - 内部接口：云基础架构不同部分之间内部接口的编程接口。如果要改变云架构内存储层的供应商，那么将用到这些 API。
2.4.3 开发人员角色
在讨论对开发人员的要求时，明确开发人员的角色十分重要。对 API 和云服务的要求会因角色的不用而不同。下面是我们将要在本文档中讨论的角色，同时给出他们使用的 API 的类别：
客户端应用程序开发人员：为最终用户编写基于云的客户端应用程序。这些开发人员使用云服务的（分类3）API。
应用程序开发人员：编写使用云的传统应用程序。这些开发人员使用普通 API（分类1）以及云服务的 API（分类3）。
部署人员：包装、部署和维护使用云的应用程序。生命周期管理也是属于此处要考虑的问题之一。这些开发人员使用 API 实现部署、云服务和映像管理（分类2、3 和4）。
管理员：在多个层次处理应用程序，包括部署和基础架构管理。这些开发人员利用分类2、3和 4 中的 API。
云供应商：处理云产品下的基础架构。这些开发人员使用分类 5 中的 API。
3 用例场景
企业云使用场景旨在描述最为典型的云用例，而并非要列出云环境下的所有现实情况。
本节中的图形自始至终都有若干共同元素。如果某给定的元素不适用于某一特定用例，则该元素变灰或以虚线绘制。例如，私有云用例不涉及最终用户或公有云，因此只有企业云是彩色的。
最终用户到云应用程序在云上运行，由最终用户
访问
企业到云到最
终用户应用程序在公有云上运行，由员工和客户访问
企业到云云应用程序与内部 IT 功能集成
企业到云到企
业云应用程序在公有云上运行，与合作伙伴的应用程序交互操作（供应
链）
私有云由组织在其防火墙内托管的云
更改云供应商一个使用云服务的组织决定转换
云供应商或使用其他供应商
混合云多个云协同工作，由负责联合数据、应用程序、用户身份、安全和
其他细节的云代理进行协调
3.1 最终用户到云
在该场景下，最终用户访问云中的数据或应用程序。这种类型的常见应用包括电子邮件托管和社交网站。Gmail、Facebook 或 LinkedIn 用户可通过任何设备上的任何浏览器访问应用程序和数据。用户不希望记住密码以外的任何信息；其数据的存储和管理都在云中进行。
最重要的是，用户无需了解底层的基础架构是如何发挥作用的。只要可以访问互联网，他们就可以得到期望数据。
3.1.1 要求
?身份：云服务必须验证最终用户。
?开放的客户端：对云服务的访问不应限制特定平台或技术。
?安全：安全（包括隐私）是对所有用例的一个常见要求，尽管要求的细节会因用例的不同而发生很大变化。对云计算中安全性的完整讨论不属于在本文范围。
?服务等级协议 (SLA)：虽然最终用户的服务等级协议通常比企业的服务等级协议简单得多，但云供应商必须清楚他们提供什么样的服务保证。
3.2企业到云到最终用户
在这种情况下，企业利用云向最终用户提供数据和服务。最终用户与企业交互时，企业访
问云以检索数据和/或对其进行操作，并将结果发送到最终用户。最终用户可以是企业内部人员或外部客户。
3.2.1要求
?身份：云服务必须验证最终用户。
?开放的客户端：对云服务的访问不应限定于特定的平台或技术。
?联合身份：除最终用户所需的基本身份外，企业用户很可能要有企业身份。理想状态是企业用户管理单一身份标识，同时基础架构联合云服务可能需要的其他身份。
?位置感知：根据企业代表用户管理的数据类型，对存储数据的物理服务器位置可能存在法律限制。虽然这违背了用户不必知道物理基础架构细节这一云计算的理想状态，但这一规定是必要的。云供应商提供 API 用于确定实现云服务的物理硬件的位置之前，许多应用程序无法迁移到云中。
?计量和监测：所有的云服务必须接受成本控制、退款和自动配置的计量和监测。
?管理和控制：公有云供应商使账户的开通和启用更加便捷；这种易用性将带来风险，因为企业中的个人将主动使用云服务。需要对虚拟机和诸如存储、数据库和消息队列等云服务进行管理，以跟踪所使用的服务。
要确保无论何地使用云计算都遵守政策和政府法规，控制是关键。其他管理要求将因行业和地域而异。
?安全：任何涉及企业的用例都比涉及单一最终用户的用例具有更为复杂的安全要求。
同样，较先进的企业用例会有更高级别的安全要求。
?虚拟机常见文件格式：为一个云供应商平台创建的虚拟机应该可以移植到另一个供应商平台。针对这一需求的任何解决方案必须考虑云计算供应商向虚拟机分配存储的方式上的差异。
?云存储和中间件的通用 API：企业用例需要通用 API 来访问云存储服务、云数据库，以及其他云中间件服务，如消息队列。
编写仅供特定供应商的云服务使用的定制代码，将企业锁定在该供应商的系统之中，失去了云计算提供的部分经济效益和灵活性。
?数据和应用程序联合：企业应用程序需要结合多个基于云来源的数据，且它们需要协调在不同的云内运行的应用程序活动。
?服务等级协议和基准：除最终用户所需基本服务等级协议以外，以服务等级协议为基础签订合同的企业需要一个衡量性能的标准方法。该方式必须能明确定义云供应商将提供什么服务，并衡量实际交付的内容。（服务等级协议会对云安全产生附加影响；
详见第 6 节有关服务等级协议、审计和监测的讨论。）
?生命周期管理：企业必须能够管理应用程序和文档的生命周期。这项要求包括应用程序的版本控制以及数据的保留和销毁。发现此类数据是许多组织面临的一个主要问题。如果某些数据不再可用，则会导致重大的法律责任。除了数据保留外，在某些情况下企业希望确保数据在某种程度上遭到破坏。
3.3 企业到云
这一用例涉及企业就其内部流程使用云服务。由于赋予了企业最大控制权，这可能是在云计算早期阶段最常见的用例。
在这种情况下，企业使用云服务补充其所需要资源：
?使用云存储进行备份或存储很少用到的数据
?使用云中的虚拟机，增加在线处理器处理峰值负载（不再需要的时候关闭虚拟机）?使用云中的应用程序 (SaaS)，实现某些企业功能（电子邮件、日历、客户关系管理等）
?将云数据库用作某一应用程序处理过程的一部分。与合作伙伴、政府机构等共享该数据库时，这可能非常有用
3.3.1要求
企业到云用例的基本要求与云到企业到云到最终用户的用例大致相同。开放的客户端、联合身份、位置感知、计量和监测、管理和控制、安全、虚拟机通用格式、云存储和中间件通用 API、数据和应用程序联合、服务等级协议以及生命周期管理均适用。
该用例的其他要求是：
?部署：创建虚拟机映像，必要时将其部署到云，应当比较简单。虚拟机映像一旦建立，应该可以将其从一个云供应商转移到另一个云供应商，补偿厂商用以分配虚拟机存储的不同机制。将应用程序部署到云也同样比较简单。
?特定行业标准和协议：企业之间的许多云计算解决方案使用现有标准，如 RosettaNet
或 OAGIS。适用的标准将因应用程序和行业而异。
3.4企业到云到企业
这个用例涉及使用相同的云的两个企业。此处重点是在云中托管资源，方便企业应用程序交互操作。供应链是该用例中一个最明显的示例。
3.4.1要求
企业到云到企业用例的基本要求与企业到云的用例大致相同。身份、开放的客户端、联合身份、位置感知、计量和监测、管理和控制、安全、特定行业标准、云存储和中间件通用 API、数据和应用程序联合、服务等级协议以及生命周期管理均适用。
该用例的其他要求是：
?事务和并发：对于不同企业间共享的应用程序和数据，事务和并发至关重要。如果两个企业都使用相同的云托管应用程序、虚拟机、中间件或储存，任何一方企业所做的