云安全场景的回顾和总结

本文探究云计算用例研讨组发布的 “云计算用例白皮书” 版本 3.0 — 由一个有 900 多位参与者的开放 web 社区创建的一个信息库。最初的研讨组成员只是开放云计算宣言的支持者，但这一队伍迅速壮大，目前成员遍布世界各地。其中社区成员包括来自大中小型公司、政府机构、咨询公司、供应商和用户的代表。

小组一致达成三项原则：

用户通力合作。

保持云计算开放的任何行动应以客户利益为导向。

尽可能沿用现行标准。

“云计算用例白皮书” 版本 3.0 的目标

“云计算用例白皮书” 版本 3.0 的目标是强调云环境中需要标准化的功能和需求，以确保互操作性、集成简易性和可移植性。它必须能够在不使用非开放式专有技术的情况下实现本文描述的所有用例。云计算必须逐渐成为一个开放环境，以最小化供应商锁定并增加客户选择。

“云计算用例白皮书” 涉及的内容很全面，因此我们不打算在一篇文章里涵盖所有内容。对于此次回顾，我们将侧重于小组对安全问题的评估和云中的场景，因为安全性是企业级云计算的首要考虑事项之一。

一般云安全主题

“云计算用例白皮书” 涵盖开发人员和架构师迁移到云中应该考虑的安全问题。它强调，与其他系统环境一样，云计算整体是一个理想示例，可以展示 “一致、透明、基于标准的安全框架” 这一需求。单个云部署模型无关紧要。

如果您认为云中与其他环境中的安全性有一个重大区别，那会是什么呢？它不是一个技术难题...而是企业对敏感数据和应用程序的认知失控，因为云服务供应商控制基础架构。对以下主题的探讨将解决这个问题：

法律法规虽然不是技术问题，但可以决定哪些安全需求优先于功能需求。

云供应商应该能够提供一个最低安全控制列表，使您认为其基础架构对于您来说足够安全。

还有一个最低安全联合模式（机制）列表，基础架构提供者通过它来交付安全控制。

谁使这一切成为可能？

“云计算用例白皮书” 版本 3.0 的编著参与人员有 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。

法律法规问题本质上不完全是技术问题，它相对简单，因此我们先从这一方面入手。一个不争的事实是，许多政府都有严格的数据隐私法律，可以影响某种数据的物理和逻辑配置。类似情况也以策略或行业特定指令的形式存在于企业和非政府组织中。这些也适用于运行在云中的应用程序。遵从这些法律法规比任何其他需求都重要。没有任何办法能绕过这些法律、法规和策略（毕竟，数据和应用程序的所有者可以决定不让您使用它）— 这些可能是影响您进行云技术选择的非技术性考虑事项。

安全控制

“云计算用例白皮书” 探讨充分保护云环境（加上存在的相关标准）所需的以下安全控制。

资产管理。您必须能够管理所有物理/虚拟硬件、网络和软件资产，包括为审计和遵从性目的而访问资产。

加密：密钥和证书管理。对于熟知网站的任何人来说，这有点像是无需动脑的事，这包括采用基于标准的加密功能和服务，以支持静态和动态信息安全。标准：KMIP、OASIS 密钥管理互操作协议。

数据/存储安全。您要能够将数据存储为加密格式。值得指出的是，有些用户需要将其数据独立于其他用户的数据而存储。标准：IEEE P1619，由 IEEE 存储安全工作组制定。

端点安全。用户必须能够确保其云资源端点的安全。这包括能够通过网络协议和设备类型限制端点。

事件审计和报告。这似乎过于明显，不必提及，但是实现安全性的一个关键就是能够知道发生了什么。特别是涉及到系统故障、入侵考核直接攻击时。在这种情况下，适时性很关键。

身份、角色、访问控制和属性。这是云计算联合身份验证方面强有力的标识。如果不能如同在一个可互操作的单一系统上一样访问所有资源，云就不能存在。与此类似，如果不能以 “一致、机器可读的方式” 定义个人及服务属性，云上的安全性就不可能有效。标准：SAML、OASIS 安全声明标记语言和 X.509 Certificates，国际电联公共密钥和属性证书框架建议的一部分。

网络安全。您必须能够保护交换机、路由器和数据包级的网络传输；IP 堆栈本身也应确保安全。

安全策略。要使访问控制和资源分配有效，您必须能够以一种统一、可靠的方式定义、解决和执行安全策略。只有通过统一、可靠的方式才能实现对安全策略的自动执行。标准：XACML、OASIS 可扩展访问控制标记语言。

服务自动化。您应当有一个自动方式来管理和分析安全控制流和进程 — 如同违反安全策略或客户许可协议的报告事件 — 以支持安全遵从性审计。

工作负载和服务管理。您要能够遵循已定义的安全策略和客户许可协议配置、部署和监控服务。标准：SPML、OASIS 服务提供标记语言。

安全联合模式

联合身份验证 是使云计算成为可能的一个基本概念。联合是多个独立资源 — 资产、身份、配置等 — 充当单一资源的能力。本文概括以下联合模式，帮助定义供应商实现安全控制要求的方式。

信任。双方能够通过身份验证机构定义信任关系的能力。这一身份验证机构能够交换凭证（通常为 X.509 证书），然后使用这些证书确保消息安全，创建署名安全令牌（通常为 SAML）。联合信任是所有其他安全联合模式的基础。

身份管理。定义接受用户凭证（用户名和密码、证书等）的身份提供者并返回可以识别用户的署名安全令牌的能力。信任身份提供者的服务供应商可以使用该令牌给予用户适当的访问权限，即使在服务供应商对用户并不了解的情况下也是如此。

访问管理。编写用于检查安全令牌以管理云资源访问的策略（通常为 XACML）的能力。对云资源的访问可以由多个因素控制。

单点登录和登出。根据来自可信机构的凭证进行联合登录的能力。单点登录模式通过身份管理模式启用。

审计和遵从性。收集分布在多个域（包括混合云）的审计和合规数据的能力。联合审计对于确保和记录服务等级协议和法规要求的遵从性非常必要。

配置管理。为服务、应用程序和虚拟机联合配置数据的能力。

现有安全最佳实践的含义正如其名 — “安全最佳实践”。由于最佳实践以标准告终，作者建议设计人员或开发人员首先以现有标准为机制来提供联合模式。

安全用例场景

“云计算用例白皮书” 版本 3.0 的作者设计了涵盖一系列应用程序类型、部署模型、模式和角色的常用场景，以实现以下公式：

客户云计算体验 + 安全需求 = 成功的云应用

白皮书中的用例旨在：

提供实用、基于客户体验的上下文来支持对互操作性和标准的讨论。

界定在哪里使用现有标准。

强调需要在哪里创建标准。

展示开放云计算对业务的重要性。

每一节都从通用场景入手并：

使用直接来自 “云计算用例白皮书” 版本 3.0 的语言描述问题场景。

讨论如何使用一个云解决方案解决问题。

提供一份要求和控制以及联合模式清单来实现解决方案。

敏感数据，私有基础设施不堪重负

场景：

某保险公司拥有一套索赔应用程序，用于收集保单持有人及其财产损失的相关数据。一场飓风预计将袭击美国的墨西哥湾地区，有可能造成巨大财产损失。这将导致索赔诉求急剧增加，反过来对企业 IT 基础设施带来巨大的负担。

该公司决定利用公有云提供商提供虚拟机来处理预期需求。

公司必须在企业系统与云供应商托管的虚拟机之间控制访问，仅允许公司授权代理人访问。

公司必须在公司防火墙内安全传输应用程序云实例创建的任何数据。

云供应商必须确保关闭虚拟机时，不留任何应用程序或数据的痕迹。

所解决的客户问题：公有云环境将允许公司处理比之前高达一个数量级的工作负载。卸载这个一次性事件的资本成本比购买物理性能来长期处理该负载要便宜得多。

要求和控制：

要求：对应用程序的访问仅限于特定角色。
安全控制：身份、角色、访问控制和属性；资产管理；和网络安全。

要求：关闭虚拟机时必须删除所有应用程序或数据痕迹。
安全控制：工作负载和服务管理。

联合模式：信任、访问管理、配置管理。

资源有限，需要新应用程序

场景：

一家在线零售商需要开发一种新的 Web 2.0 店面应用程序，但不希望给 IT 人员和现有资源增加负担。

该公司选择云供应商，通过托管的开发工具及源代码库提供基于云的开发环境。同时选择另一家云供应商提供测试环境，这样新的应用程序可以与许多不同类型的机器和大量的工作负载进行交互。

选择两家供应商来处理基于云的开发和测试意味着联合将变得至关重要。

所解决的客户问题：从开发的角度来看，利用云托管开发工具无需在每个开发人员的机器上安装、配置和管理工具。如果您有大型产品需要构建，云基础设施会向上扩展来满足规模需求。如果云中有一个新版文件需要测试，您的测试环境可以达到最新。

从测试的角度来看，针对更高交互式 Web 2.0 接口（而非静态 Web 页面）的测试将更好地决定应用程序在实际环境中的弹性（它扩展和适应更高负载和更广虚拟机映像的能力）。

要求和控制：

要求：在一个中央位置安装和维护的开发工具。
安全控制：资产管理。

要求：关闭虚拟机时必须删除所有应用程序或数据痕迹。
安全控制：工作负载和服务管理。

要求：开发和测试云单点登录。
安全控制：加密；端点安全；身份、角色、访问控制和属性；以及网络安全。

要求：对源代码和测试计划的受控访问。
安全控制：资产管理以及身份、角色、访问控制和属性。

要求：构建和测试必须自动启动和关闭虚拟机。
安全控制：服务自动化。

要求：构建和测试必须报告关于虚拟机使用情况和性能的统计信息。
安全控制：事件审计和报告。

联合模式：信任、身份管理、访问管理、单点登录、审计和遵从性、配置管理。

存储和访问商业机密

场景：

某金融投资公司向其代理人和分支机构推出新的投资产品。制作了许多视频教公司代理人和分支机构认识新产品的收益和特征。这些视频体积庞大，需要按需即时提供，因此将其存放在云中可以减轻公司基础设施的负担。

但是，必须严格控制这些视频的访问权限。出于竞争的原因，只有通过认证的公司代理才可以观看视频。另一个更为严格的限制就是，按规定，要求公司在产品上市前的平静期，对包括视频在内的产品细节保密。

该公司决定利用公有云存储供应商，扩展安全托管和视频流。

云解决方案必须通过强制执行公司安全策略的可稽核访问控制机制，对视频进行控制。

所解决的客户问题：通过公有云存储，该公司不必增加其自己的数据中心资源来管理海量数据。本例中涉及的政府监管层面（超出企业关注范围）意味着，云服务供应商必须能够保证遵从性，否则将不予考虑。

要求和控制：

要求：对视频的访问仅限于特定角色。
安全控制：身份、角色、访问控制和属性；资产管理；网络安全；以及策略。

要求：必须保证存储在云中的数据的安全。
安全控制：加密和数据/存储安全。

要求：存储在云中的数据必须在公司防火墙内传回。
安全控制：加密、数据/存储安全、端点安全和网络安全。

联合模式：信任、身份管理、访问管理、审计和遵从性。

交叉引用安全控制，联合模式，以及场景

下面两个表格总结了安全控制、联合模式和场景间的关系。表 1 总结了安全控制与客户场景之间的关系，表 2 总结了联合模式与场景之间的关系。

表 1. 安全控制与场景

表 2. 安全联合模式和场景

结束语

“云计算用例白皮书” 版本 3.0 的作者指出，“在客户试图将其数据和应用程序迁移到云中时，安全性常常是最大的问题。”

“云计算用例白皮书” 版本 3.0 得出的关于云中安全性的结论很明确：

云计算不引入新的安全问题，这些问题在管理员、规划人员和开发人员考虑一般 IT 安全性时已经不会再遇到。

关于一般 IT 安全性与云安全性的实现和执行方式，主要区别在于，使用公有云时总会涉及到第三方。（预置云则是另一回事。）

云提供商提供有意义的透明度和适当的披露是很有必要的。

如果有一个现有标准能满足安全需求，云用户一定坚持要求提供商使用它；如果没有这样的标准，要求社区开发一个。

该总结和回顾提供了场景基准和概述，阐述了云安全法规和控制。我们建议您学习原版本的 “云计算用例白皮书”，因为在该书中，云计算用例研讨组全面地分析了开发人员和规划人员应当向云提供商要求什么，才能为宝贵的数据和应用程序提供一个安全的环境。