安全组织JerichoForum提出了一个有趣的有关云计算安全的方法。他首先描述了云层。然后提出了安全性和身份认证管理是跨所有层的元素,并提供了一个设计模式。他们把这个设计模式称之为协作导向架构(CollaborationOrientedArchitectureCOA) 。
由于奠定了这个基础,他们把云计算的安全定义为一个立体形状的模型。大约在同一时间,云计算安全联盟和他们的想法很相似。最后修正云计算以三种形式交付:
1.基础设施服务(IaaS)
2.平台即服务(PaaS)
3.软件即服务(SaaS)
进而确定云消费模式:
1.私人
2.公共
3.管理
4.混合
云计算安全联盟定义的堆叠模式是很复杂的。虽然我并不反对他们的参考模型,但请允许我在这里讲几点不同的观点。安全的三个基本的原则是:
1.保密
2.可用性
3.完整性
显然,在云计算中,特别是在公共/外部的情况,我们已经没有任何控制。一旦bits“离开我们的网络”,这时就失去了控制。通常失去了一个控制,我们就会增加其他方面的控制。
下面来介绍一些其他方面的控制。
保密性
我们通过技术保密,如加密和访问控制。虽然我们仍然可以加密,但是想象一下接下来大数据集会发生什么。它会被发送,或装配到云上,这时仍然是加密的形式,然后被传送给我们进行处理。
一旦数据在我们这里,我们这时就要给数据解密,随着操作的需求,再重新加密传送到云上。这种方法虽然可行,但这里的性能税是巨大的,我们仍然需要付出沉重的代价。
在保密性内的另一个其他因素是破坏数据的能力。由于云不是我们的,所以我们无法控制,同样我们也不能控制存储介质。相同的介质很大程度上可能会用于其他目的。这些存储桶是动态的,并且服务/平台/应用软件提供商可能会把他们分配给其他用户。
很多情况下共享存储介质,这要求可以核实数据超出有效期后是否真的毁灭掉了。我们必须遵循严格的制度,这些制度包括它会指出数据需要存储多长时间,什么时候由谁来毁灭它,以及如何核实这种破坏。由于给磁带消磁或粉碎光盘是可不能的,因此我们必须要部署更多更加灵活的软件,以保证可以销毁。
当我们要更改某一硬盘驱动器上的数据时,事情变得更加复杂。数据通常会在驱动的存储位置之间移动,但此时我们并不能管理驱动。唯一可行的解决办法就是要求服务提供商定期清理存储介质。
可用性
当处理云计算资源时,多亏了网络,远程服务器,以及任何控制都是适用的。但是我们一直在承受风险,用户对他们的信息是非常敏感的。为了避免风险,我们通常会在系统上创建冗余。这样做大概会增加线路,服务器,网络设备和人员。但对一个企业冗余的复杂度意味着什么呢?什么是操作的真正成本呢?
让我们看看一个例子:我们有一个有时延伸10倍的数据卷,这时,云计算似乎是完美的解决方案。因此,接下来我们可能会:
1.我们询问云服务供应商有关提供数据存储爆炸的可用性。
2.我们要求我们的网络服务供应商创建另一个冗余和高可用性路径提供给云服务供应商。
3.现在我们必须考虑当我们没有把数据提供给云的时候,如果这种数据爆炸发生,我们要做什么。立刻处理?停止运作?当然不是。因此不管我们是否使用云服务,我们必须有计划的存储这些数据。
完整性
在他们更改后,我们可以检测这些变化。从散列到冗余校验,从数字签名到布线,我们都能够确定发生了变化。但我们不再阻止这些改变。尤其是我们谈到云计算时。
事实上,云泛滥可能导致直接针对数据的攻击。虽然大多数托管公司将会保证他们会监测,安全性好,但事实上,云数据的配置已经面临危险。
他们现在可以同时改变数据和相关的有效载荷,直接到达预定目的地。因此,我们还面临一些国家方面法律的问题:
1.我们如何遵守法律?
2.如果我们的数据是有关欧盟的会怎么样?
3.当我们对审计和美国证券交易委员会披露风险信息,我们必须要做什么?
4.我们如何遵守有关CALEA的规则?电子发现?数据取证?
最后,我们知道数据有生命周期。如果云数据被视为不信任的数据?那么它还有没有价值,这点谁也不知道,也许只有时间能告诉我们。