用IT网络和安全专业人士视角来裁剪云的定义

本文的重点是从专门针对IT网络和安全专业人士的独特视角来裁剪的云的定义。可以用统一分类的一组公用的、简洁的词汇来描述云架构对安全架构的影响，在这个统一分类的方法中，云服务和架构可以被解构，也可以被映射到某个安全、可操作控制、风险评估和管理框架等诸多要素的补偿模型中去，进而符合合规性标准。通过云产品分类，云服务、云架构可以被解构，映射到某个安全和运行控制模型、风险评估框架、管理框架、相应的合规性标准等。

什么是云计算？

云计算（或云）是一个演化中的词汇，它描述了很多现有的计算技术和方法朝各种不同方向的发展。云将应用和信息资源与底层的用以交付它们的基础设施和机制分开。云强化了协作、敏捷、扩展性、可用性，以及通过优化的、更有效率的计算来降低成本的潜能。

更具体地说，云描述了由“资源池”化的计算、网络、信息和存储等组成的服务、应用、信息和基础设施等的使用。这些组件可以迅速策划、置备、部署和退役，并且可以迅速扩充或缩减，提供按需的、效用计算类似的分配和消费模式。

本文的重点是从专门针对IT网络和安全专业人士的独特视角来裁剪的云的定义。可以用统一分类的一组公用的、简洁的词汇来描述云架构对安全架构的影响，在这个统一分类的方法中，云服务和架构可以被解构，也可以被映射到某个安全、可操作控制、风险评估和管理框架等诸多要素的补偿模型中去，进而符合合规性标准。

2 云计算是由什么组成的？

美国国家标准技术研究院（NIST）给云计算定义了五个关键特征、三个服务模型、四个部署模型。如下图1所示，后面将会有详细描述。

2.1 云计算的关键特征

云服务展现出的五个关键特征，代表了它与传统计算方法的关系和区别：

• 按需自服务： 用户可以在需要时自动配置计算能力，例如服务器时间和网络存储，的需要自动计算能力，而无需与服务供应商的服务人员交互。

• 宽带接入：服务能力通过网络提供，支持各种标准接入手段，包括各种瘦或胖客户端平台（例如移动电话、笔记本电脑、或PDA），也包括其它传统的或基于云的服务。

• 虚拟化的资源“池”：提供商的计算资源汇集到资源池中，使用多租户模型，按照用户需要，将不同的物理和虚拟资源动态地分配或再分配给多个消费者使用。虽然存在某种程度上的位置无关性，也就是说用户无法控制或根本无法知道所使用资源的确切物理位置，但是原则上可以在较高抽象层面上来指定位置（例如国家、州、省、或者数据中心）。资源的例子包括存储、处理、内存、网络带宽以及虚拟机等。即使是私有的“云”往往也趋向将资源虚拟“池”化来为组织的不同部门提供服务。

• 快速弹性架构：服务能力可以快速、弹性地供应——在某些情况下自动地——实现快速扩容、快速上线。对于用户来说，可供应的服务能力近乎无限，可以随时按需购买。

• 可测量的服务：云系统之所以能够自动控制优化某种服务的资源使用，是因为利用了经过某种程度抽象的测量能力（例如存储、处理、带宽或者活动用户账号等）。人们可以监视、控制资源使用、并产生报表，报表可以对提供商和用户双方都提供透明。

必须认识到的重要一点是虽然云服务经常和虚拟化技术一起使用，或者云服务基于虚拟化技术，但是并不必然。没有要求将资源抽象与虚拟化技术必须绑在一起。很多云服务产品并没有使用超级监视者（hypervisor）或操作系统容器。进而，应该注意到，多租户并没有成为NIST云计算定义中的某个关键特征，但是，在讨论中被经常称为关键特征。在后面云部署模型之后的“多租户”一节可以找到更多细节。

2.2 云服务模型

云服务的交付可以分为三种模式以及不同的衍生组合。这三种基本类型经常被称为“SPI”模型，其中SPI分别代表软件、平台和基础设施（作为服务）。它们的定义如下：

• 云软件作为服务 (SaaS)：提供给用户的能力是使用服务商运行在云基础设施之上的应用。用户使用各种客户端设备通过“瘦”客户界面（例如浏览器）等来访问应用（例如基于浏览器的邮件）。用户并不管理或控制底层的云基础设施，例如网络、服务器、操作系统、存储、甚至其中单个的应用能力，除非是某些有限用户的特殊应用配置项。

• 云平台作为服务 (PaaS)：提供给用户的能力是在云基础设施之上部署用户创建或采购的应用，这些应用使用服务商支持的编程语言或工具开发，用户并不管理或控制底层的云基础设施，包括网络、服务器、操作系统、或存储等，但是可以控制部署的应用，以及应用主机的某个环境配置。

• 云基础设施作为服务 (IaaS)：提供给用户的能力是云供应了处理、存储、网络，以及其它基础性的计算资源，以供用户部署或运行自己任意的软件，包括操作系统或应用。用户并不管理或控制底层的云基础设施，但是拥有对操作系统、存储和部署的应用的控制，以及一些网络组件的有限控制（例如主机防火墙等）。

NIST模型和本文档并没有直接阐述代理的服务模型定义，云服务代理提供仲裁、监视、变革/移植、治理、供应和集成服务，也提供用户和各云服务商之间的谈判。

简而言之，因为创新会驱动快速的解决方案开发，云服务的用户和供应商将会喜欢与云服务交互的各种方法，像开发API接口什么的，所以云服务代理将会成为总体云生态环境中的重要一环。

在通用、开放、标准化的长远解决方案出台之前，云服务代理将各种不兼容的能力和接口进行抽象，为用户提供代理访问手段。所谓长远解决方案是指一种语义层面的能力，使用户流畅而灵活地充分利用最能满足自己特定需求的模型。

很重要的一点是，我们必须看到围绕着开发公开和私有的API方面的各种努力，这些API用于云的管理、安全以及互通。简单列举几个这种API接口，像开放云计算接口工作组（Open Cloud Computing Interface Working Group）, Amazon EC2 API, VMware公司 DMTF提交的 vCloud API, Sun公司的 Open Cloud API, Rackspace API, 以及 GoGrid’s API。开放、标准的API，以及通用容器格式，例如DMTF的开放虚拟化格式OVF（Open Virtualization Format），它们在云可移植性和可交互性方面将会扮演至关重要的角色。

虽然当前有很多工作组、草案以及已发布的规格标准，但是肯定会出现一个整合的过程，各种市场力量、用户需求和经济环境等相互博弈、去粗存精，最后达到一个让用户更方便管理和互操作的状态。

2.3 云部署模型

不管利用了哪种服务模型（SaaS、 PaaS、或 IaaS），存在四种云服务部署模型，以及用以解决某些特殊需求而在它们之上的演化变形。

• 公共云。由某个组织拥有，其云基础设施对公众或某个很大的业界群组提供云服务。

• 私有云。云基础设施特定为某个组织运行服务。可以是该组织或某个第三方负责管理，可以是场内服务（on-premises），也可以是场外服务（off-premises）。

• 社区云。云基础设施由若干个组织分享，以支持某个特定的社区。社区是指有共同诉求和追求的团体（例如使命、安全要求、政策或合规性考虑等）。可以是该组织或某个第三方负责管理，可以是场内服务（on-premises），也可以是场外服务（off-premises）。

• 混合云。云基础设施由两个或多个云（私有的、社区的、或公共的）组成，独立存在，但是通过标准的或私有的技术绑定在一起，这些技术促成数据和应用的可移植性（例如用以云之间负载分担的cloud bursting技术）。

在市场产品消费需求越来越成熟的过程中，将会出现其它的派生的云部署模型，意识到这一点很重要。这方面的一个例子就是虚拟专用云（virtual private clouds）- 以私有或半私有的形式来使用公共云基础设施，通常通过虚拟专网VPN将公共云里的资源连回用户数据中心内部的资源。

方案设计时的架构思路对将来方案的灵活性、安全性、移动性以及协作能力都有很大的影响。作为一条首要原则，“边界化（perimeterized）”的解决方案没有“去边界化（deperimeterized）”的方案更有效，在上述四个部署模型中都这样。同样的道理，采取私有的还是开放的方案也需要仔细考量。

多租户（Multi-Tenancy）

虽然并不是NIST模型中云计算的本质特性，CSA将多租户识别为云的一个重要元素。云服务模型中的“多租户”意味着满足不同客户场景对策略驱动的安全增强、分段、隔离、监管、服务水平以及相应的计费/返款等模型的不同需求。用户可能会使用公共云服务提供商的服务产品或者是同一家组织内部的云服务，例如不同的业务单元BU（business unit），并不是完全不同的商业组织，它们之间依然需要分享基础设施。

从提供商的角度来看，多租户对架构和设计提出的要求是通过在很多不同客户之间分享基础设施、数据、元数据、服务和应用等，来实现可扩展、可用性、管理、分段、隔离以及运行效率等方面的“经济性”。

依赖于服务商的云服务模型，“多租户”也可以采用不同的定义，因为它可能与在基础设施、数据或应用等不同水平上实现的细节有关。IaaS和SaaS多租户实现上的不同就是一个例子。“多租户”在不同的云部署模型中的重要性也有所不同。然而，即使在私有云中，组织虽然只有一个，但是也存在多个来自第三方的顾问和合同工，也存在对不同业务单元间高等级逻辑分离的期望，因此，也需要考虑“多租户”

2.4 云参考模型

理解云计算模型之间的关系和依赖性对于理解云计算的安全风险非常关键。IaaS 是所有云服务的基础，PaaS建立在IaaS之上，而SaaS又建立在PaaS之上，之间关系参见云参考模型的图示。沿着这个思路，如同云服务能力是继承的那样，信息安全风险和问题也是继承的。重要的一点是，商业云提供商可能并没有与这个模型准确对应，然而，云参考模型对于将真实服务和某个架构框架联系在一起，进而理解需进行安全分析的资源和服务是非常重要的。

IaaS涵盖了从机房设备到其中的硬件平台等所有的基础设施资源层面。它包括了将资源抽象化（或相反）的能力，并交付连接到这些资源的物理或逻辑网络连接，终极状态是IaaS提供商提供一组API，允许用户与基础设施进行管理和其它形式的交互。

PaaS位于IaaS之上，又增加了一个层面用以与应用开发框架、中间件能力以及数据库、消息和队列等功能集成。PaaS允许开发者在平台之上开发应用，开发的编程语言和工具由PaaS支持提供。

类似的，SaaS又位于底层的IaaS和PaaS之上。SaaS能够提供独立的运行环境，用以交付完整的用户体验，包括内容、展现、应用和管理能力。因此，必须清楚，在三个模型中，集成的特色功能、复杂性与开放性（可增强性）以及安全等方面会有一些明显的折中。三种云部署模型之间的折中包括：

• 一般来说，SaaS会在产品中提供最为集成化的功能，最小的用户可扩展性（extensibility），相对来说较高的集成化的安全（至少提供商承担安全的职责）。

• PaaS提供的是开发者在平台之上开发自己应用的能力。因此，它倾向于提供比SaaS更多的可扩展性，其代价是SaaS那些已经用户可用的特色功能。这种折中也会延伸到安全色和能力上，虽然内置的安全能力不够完备，但是用户却拥有更多的灵活性去实现额外的安全。

• IaaS几乎不提供那些和应用类似的特色功能，但却有极大地“可扩展性”。这一般是指IaaS在除了保护基础设施自身之外的安全保护能力和功能更少。IaaS模型要求云用户自己管理和安全保护操作系统、应用和内容。

云安全架构的一个关键特点是云服务提供商所在的等级越低，云服务用户自己所要承担的安全能力和管理职责就越多。在SaaS情况下，这意味着在合同里需要对服务本身和提供商的服务水平、安全、管控、合规性以及责任期望等有明确要求。在PaaS或IaaS情况下，这些内容的管理责任是用户自己的系统管理员，提供商对于安全保护底层平台和基础设施组件以确保基本服务的可用性和安全，其具体要求可能会有一些相关的出入。很明确的一点是用户可以指定/转移责任（responsibility），但不一定非要指定/转移可纠责性（accountability）。

如果将每种云交付模型的范围或具体能力/功能，或它们相互交叉耦合的一些功能缩小一下，将会产生很多衍生的分类。例如存储作为服务（Storage as a Service）就是IaaS家族中的一个具体的子服务。

云计算的解决方案正在不断地演进，虽然讨论它的全景图超出了本文档的范围，但下面这张OpenCrowd Cloud Solutions分类图还是给出了一个非常不错的起点，它展示了当前风起云涌的由上述几种部署模型衍生而来的种种云解决方案。

应该注意到，CSA并不特别支持下图所列出的任何解决方案，而只是用来说明当前市场上提供的云解决方案的多样性。

为了提供一个云计算用例的全面视图，Cloud Computing Use Case Group 开发了一个协同任务来描述和定义通用案例并展示云带来的好处，他们的目标设定为：“...让云用户和提供商一起来定义云计算的公共用例…强调云计算环境中需要标准化的能力和要求，以确保互操作性、更易集成、可移植性。”

2.5 云安全参考模型

云安全参考模型解决的是这些分类的关系，并把它们和与其相关的安全控制和顾虑放在一个上下文环境中。对于头一次接触云计算的组织和个人来说，注意到下面的问题以避免潜在的陷阱和困惑是很重要的：

1. 云服务是如何部署的”与“云服务是在哪里提供的”这样的概念频繁混用所带来的困惑。例如，公共或私有可能被描述成外部或内部云，这种互换不是所有情况下都是准确的。

2. 云服务的使用方式经常被描述成与组织的管理或安全边界位置有关（通常定义在某个防火墙上）。虽然了解云计算中安全边界在哪里很重要，但是，“界限清晰的边界”的这一概念是一个时代性错误。

3. 在企业中正在上演的对信任边界的重组（re-perimeterization）及侵蚀，被云计算放大并加速。无处不在的连接、各种形式的信息交换、无法解决云服务动态特性的传统静态安全控制，这些都要求针对云计算的新思维。针对企业网络的边界重整，

Jericho Forum开发了相当多的材料，包括很多案例分析。云的部署和消费模式不能仅仅在“内部”还是“外部”上讨论，因为它们只是与资产、资源和信息的物理位置有关，而是还要讨论由谁消费、谁负责监管、安全和政策标准的合规等。

这里不是在建议某个资产、资源和信息是在“场内”（on-premise）还是“场外”（offpremise）对组织的安全和风险状态没有影响，它们的的确确有影响。但是，这里更想强调的是风险还与这些有关：

• 所要管理的资产、资源和信息类型

• 谁管理？如何管理？

• 选择了哪些控制？如何集成？

• 合规性问题

例如，Amazon AWS EC2里部署的LAMP套件应该分类为公共的、场外的、第三方管理的IaaS解决方案，即使其中的实例、应用、数据是由消费者或某个第三方负责管理。部署在Eucalyptus的某个常规应用，为若干个业务单元服务，由某个公司控制、管理并拥有，可以分类为私有的、场内的、自管理的SaaS解决方案。两个例子都使用了云的弹性架构和自服务能力。

下面的表格总结了这些要点：

另外一个将云服务模型、部署模型、资源物理位置、管理和所有者属性等图形化展示的方法是Jericho Forum （www.jerichoforum.org）的云立方体模型（Cloud Cube Model），如下图所示：

云立方体模型很形象地阐述了市场上现有云产品的各种排列组合，提出了用以区分云从一种形态（formation）转换到另外一种形态的四种准则/维度，以及各种组成的供应配置方式以便理解云计算影响安全路线的方式。

云立方体模型还凸显了在理解云模型并将云模型映射到控制框架和标准上去时的挑战，这些控制框架和标准，像ISO/IEC27002，提供了“一系列指南和通用原则，用以在组织内部启动、部署、维护和提升信息安全管理”。

在ISO/IEC 27002 的6.2节，“外方”（External Parties）控制目标有:“… 组织的信息和信息处理设施的安全不应该因为引入外方产品或服务而降低 …”

因此，三种云服务模型的安全防护在方法和责任上有所不同，这意味着云服务的消费者面临很有挑战性的工作。除非云提供商愿意透露自己的安全控制以及为消费者部署的程度，同时消费者也知晓自己需要哪些控制以保持信息安全，否则，肯定会有可能出现大量的误导下的决策并损失惨重。

这很关键。第一是针对云架构模型对云服务分类。接下来是映射其安全架构，以及业务、监管和其它合规要求；与其相对的是一个差距分析练习。输出的结果决定了某个云服务的一般“安全”状态，以及它如何和某个资产的保障保护要求关联到一起。

下图给出了一个很好的例子说明，如何通过对云服务组件和安全控制策略集的映射来确定哪些安全控制是存在或缺失的，这些安全控制分别由客户，云服务提供商或第三方提供。这也可以与合规框架或者强制要求（如PCI DSS）来进行比较，同样如下图所示。

完成差距分析后，按照监管方和合规方面的要求，决定需要做哪些以填入风险评估框架就容易多了。相应地，这也可以帮助决定如何对待这些安全“差距”或最终的风险 – 接受、转移、或降低。

需要意识到的重要一点是，使用云计算作为一种运行模型并不会自然地提供或妨碍达成合规性。对于任何要求的合规是服务、所使用的部署模型、以及对范围内的资源的设计、部署、管理等的直接结果。下面是几个对控制框架非常好的全面总结，它们提供了上面提及的通用控制框架的精彩阐述，包括开放安全架构小组（Open Security Architecture Group）的安全架构模式文档，还有最近刚刚更新的NIST 800-53 revision 3 - Recommended Security Controls for Federal Information Systems and Organizations.

3 什么是云计算的安全？

云计算中的安全控制其主要部分与其它IT环境中的安全控制并没有什么不同，然而，基于采用的云服务模型、运行模式以及提供云服务的技术，与传统IT解决方案相比云计算可能面临不同的风险。

即使有些运行责任落在某个或某些第三方伙伴身上，云计算的一个独特点就是能够在适度地失去控制的同时又能保持可纠责性（accountability）。

一个机构的安全态势的特征取决于成熟度、有效性以及实现基于风险调节的安全控制的完全程度，这些安全控制可以在一层或多层上实现，包括设备（物理安全）、网络基础设施（网络安全）、IT系统（系统安全），一直到信息和应用（应用安全），更多的控制还包括人员和过程层面的，职责分离和变更的管理等。

本文前面已提到，在不同云服务模型中，提供商和用户的安全职责有很大的不同。例如，Amazon的 AWS EC2架构作为服务包括了一直到hypervisor安全的供应商的安全责任，也就是说它们只能解决物理安全、环境安全和虚拟化安全这些安全控制，而用户则负责与IT系统（事件）相关的安全控制，包括操作系统、应用和数据。

Salesforce.com的客户资源管理CRM SaaS提供的正好相反，因为整个“栈”都由Salesforce.com提供，提供商不仅负责物理和环境安全还必须解决基础设施、应用和数据相关的安全控制，这减轻了用户的许多运行责任。

云计算的吸引力之一在于由经济上的可扩展性、重用和标准化提供的成本效率，为了支撑这种成本效率，云提供商提供的服务必须足够灵活，以服务最大可能的用户数、最大化他们的市场，不幸的是，将安全集成到这些服务方案中常被认为使得方案变得僵化。

这种僵化常与传统IT相比，表现在云环境不能部署同等的安全控制，这主要是由于基础设施的抽象化、缺少可视化、缺少集成多种熟悉的安全控制手段的能力，特别是在网络层上。

下图表明了这些问题：在SaaS环境中，安全控制及其范围在服务合同中进行协商；服务等级、隐私和符合性等也都在合同中关系到。在IaaS中，低层基础设施和抽象层的安全保护属于提供商职责，其它职责则属于客户。PaaS则居于两者之间，提供商为平台自身提供安全保护，平台上应用的安全性及如何安全地开发这些应用则为客户的职责。

架构之上：关键关注领域

组成云安全的其它12个域突出了对云计算安全的关注领域，并特别设法去解决云计算环境中战略和战术安全的隐患，从而可应用于各种云服务和部署模式的结合。

这些域分成了两大类：治理（governance）和运行。治理域范畴很宽，解决云计算环境的战略和策略，而运行域则关注于更战术性的安全考虑以及在架构内的实现。

4 总结

在部署云计算模型时，理解架构、技术、流程和人力资本如何变化、或者保持不变非常关键。如果对较高架构层面上的影响没有清楚的理解，就不可能理性地解决那些细节问题。和其它12个关键域一道，这个架构总揽将会带给读者一个扎实的基础，就云计算环境中的安全进行评估、运行化、管理、治理等。