云加密管不管用:两点看经过加密的数据是否更安全业界

51CTO-云计算 / / 2015-01-09 16:04
数字世界中的加密就好比是现实世界中的保险箱。数据妥善保管起来,只有拥有相应密钥的那些人才能看见。尤其是,加密为数据安全的机密性提供了一道强有力的保障;如今,加...

 

数字世界中的加密就好比是现实世界中的保险箱。数据妥善保管起来,只有拥有相应密钥的那些人才能看见。尤其是,加密为数据安全的机密性提供了一道强有力的保障;如今,加密在云计算领域正在迅速流行起来。但经过加密的数据就因而变得更安全吗?要是你的密钥以明文格式传输、被人复制或者管理不当,并非如此。

传输到公有云的数据通常安全地传输,文件并不保存在公共网站服务器上,所以明显的安全措施已经落实到位。可是一旦数据进入到存储服务器,数据就不在用户的触及或掌控范围之内。数据在存储时可能经过加密,也可能不是这样;这些数据可能被服务管理员读取,也可能不是这样。数据可能提交给颇有影响力的第三方,比如政府或相关部门,也可能不是这样。要是服务器被人闯入,存储在上面的数据就会遭到危及;如果服务器被人实际劫持,上面的数据就会被人访问。

密钥持有者很重要

任何提供加密功能的正规的存储服务提供商都会将每个客户的数据妥善存储起来,并且使用客户的独特加密密钥对数据进行加密。事实上,提供商保管数据,用户则保管密钥――密钥通常使用某种算法(PBKDF2就是一个典例)由客户的密码获得。

但是情况显得很棘手的是这个问题:通常已存储数据的加密是在提供商的服务器上进行,这就意味着在加密过程中,加密密钥势必由提供商保管。而我们客户除了信任这家服务提供商,别无选择。

在这种加密模式下,提供商会在某个时刻保管其用户的加密密钥;毕竟,提供商需要加密密钥,那样才能够加密和解密信息。用户保管密钥,提供商保管经过加密的数据。无论用户何时需要访问其数据,就必须在“代理安全性模式”(security by proxy model)下,将密钥暂时借给提供商。这一步是通过登录到服务实现的。

Web应用程序或编译的程序毫无两样。密码在点到点加密隧道(通常是SSL/TLS隧道)里面传输,这意味着密码以明文格式存放在客户端和服务器端的存储区域。密钥已被复制。

所以要是提供商有其他不太明确、不太诚实的企图或者受到胁迫,它们可能偷偷保管一份加密密钥的副本,对用户数据进行解密。要是没有额外的机制,客户基本上无法减小这种风险。比如说,TrueCrypt卷有望解决这个问题――不过,如果采用这个解决办法,却又存在很多缺点,而且灵活性大打折扣,更不用说潜在的完整性问题了,如果试图共享TrueCrypt卷中的文件,更是如此。要是不使用这类工具,必须面对这个简单的事实:不管数据有没有经过加密,客户完全是信任在线存储服务提供商,才会让它保管自己的数据。

数据安全与信任

抛开信任问题不说,需要讨论一下数据安全的优点与代理安全性的影响。

如果用户要求其在在线存储环境中的数据安全可靠,那么他们不应该使用代理安全性模式。他们必须使用这样一种方法:确保提供商根本没有足够的信息可以解密,或者为解密已存储的客户数据提供便利。这样一种加密模式可以实现数据安全,从而确保提供商在其系统中根本没有足够的信息可以对数据进行解密吗?是的,很自然,现在有一些协议和方法就能做到这一点;毫无疑问,将来会出现多得多的解决方案。

不过到目前为止,这样一种模式还不存在,因为许多提供商被要求允许执法部门或人员访问客户信息,以便将信息交给有关当局。

目前的云存储服务提供了加密,或者增添了加密服务,它们采用的是“代理安全性”模式。因而不管在什么情况下,用户无法得到这个保证:提供商无法访问其数据。提供商基本上不费吹灰之力,就能访问客户的数据,如果它们想这么做的话。

正是由于这个原因,用户总是应该可以访问远程存储系统中保管的数据,那样万一数据遭到危及,用户可以确定数据的价值。(要是自拍裸照在网上泄露的名人们停下来在这方面思索一番,原本或许可以防止这场名人私照门。)在此期间,在线存储服务提供商应该竭力提供保障,直到加密技术完全成熟起来。



1. 遵循行业规范,任何转载的稿件都会明确标注作者和来源;2. 的原创文章,请转载时务必注明文章作者和"来源: ",不尊重原创的行为 或将追究责任;3.作者投稿可能会经 编辑修改或补充。


阅读延展

1
3
Baidu
map