云安全模型

云安全参考模型解决的是分类的关系，对于第一次接触云计算的组织和个人来说，需要注意以下的几点问题以避免潜在的陷阱和困惑：

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

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

3. 在企业中正在上演的对信任边界的重组(re-perimeterizati•n)及侵蚀，被云计算放大并加速。无处不在的连接、各种形式的信息交换、无法解决云服务动态特性的传统静态安全控制，这些都要求针对云计算的新思维。针对企业网络的边界重整，Jerich• F•rum开发了相当多的材料，包括很多案例分析。

云的部署和消费模式不能仅仅在“内部”还是“外部”上讨论，因为它们只是与资产、资源和信息的物理位置有关，而是还要讨论由谁消费、谁负责监管、安全和政策标准的合规等。

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

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

· 谁管理?如何管理?

· 选择了哪些控制?如何集成?

· 合规性问题

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

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

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

Jericho 云立方体模型

云立方体模型很形象地阐述了市场上现有云产品的各种排列组合，提出了用以区分云从一种形态(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.