深入认识存储安全的复杂性
2009-01-21 12:13:20 来源:WEB开发网有些设备是在存储网络中进行加密的。这些设备可能是完全基于设备的,但是这对磁带来说并不是一件好事。如果你在压缩之前加密,那么压缩的几率就会降低;你需要做的是,先压缩后加密。这时候又有一个问题,inline设备能够对磁带驱动器进行完全压缩或者加密。随着磁带速度越来越快,这往往需要很高的成本。
那么服务器方面呢?我发现很多HSM应用能够在读取或者向磁带写入数据的时候进行校验和。我还发现当启动校验和的时候,磁带性能就会大幅下滑。
我们都知道,校验和计算的复杂性远低于加密算法的复杂性。加密算法的计算非常密集,而且通用CPU可能并不适用于运行这些复杂算法。这些类型的算法最适宜于在向ASIC或者更快的FPGAs这样专门的硬件上运行。CPU速度越来越快,但是内存带宽的增长速度并没有与CPU性能增长保持一致,将数据移入或者移出内存来在系统I/O处理密集的中加密或者解密数据,这可能无法卯足加密需求以确保设备满足I/O需求。
相关标准
即使有一个专门制定关于密钥管理标准的组织,但这远远不能解决问题,因为这无法解决针对整个数据路径的安全性和密钥管理需求。
因为加密架构需要能够在文件系统内定义加密功能(我发现一些机构希望在内存中加密数据,然后在处理之前解密数据),所以一个加密架构应该能够针对文件系统内的每一份文件支持不同等级的加密功能,确保能够追踪到来源并且在文件生命周期内保留它的来源。
除了这种维护措施之外,还要解决长期拥有的问题。例如,如果一份文件是被一位用户加密,但是需要被另外一位用户使用,那么其他用户是如何获得认证的?如果原始用户并不是在理想状态下创建的文件将会发生什么?文件如何被解密然后送交另一位用户?谁担负这个责任?需要怎样的安全机制来确保文件所有权被迁移、而负责迁移的人不会获得文件访问权?在加密环境下,你拥有根密码并不意味着你能够看到所有数据。
这只是文件系统可能会发生的一些问题。我相信你肯定会设想一个由存储网络、存储控制器和存储设备构成的完全安全的环境。管理架构是一个难题。
标准组织联合起来
因为性能问题和管理复杂性,所有可以说加密是一个很难解决的问题。如果希望能够有效而可管理地加密,需要解决的就不仅仅是密钥管理问题——尽管这可能是重要的第一步,而且还需要从用户一直到设备的标准架构。不同的标准组织应该联合起来,也就是说,像The OpenGroup (POSIX)、IETF、ANSI T10、T11和T13这些组织都应该致力于SAN设备的相关标准,如果FCoE是未来的存储发展趋势,我们还需要把FCoE也纳入其中。
现在加密只能解决单点问题:对磁带进行加密,这样我们运输磁带的时候就不用担心数据安全问题;对磁盘驱动器进行加密,这样如果卸载磁盘驱动器就不能对其进行读取。这些解决方案解决了现实环境中诸多问题,不过还不足以解决TJX相关问题。
我认为,在开始实施端对端加密之前,我们必须解决两个短期内的主要问题。首先,我们需要找出如何不利用CPU在主机加密的方法,因为虽然现有的CPU技术仍然为物理应用提高了足够的计算能力,但是无法以线速率进行加密和解密。
其次,我们需要端对端标准解决数据路径和数据迁移环境中的加密和密钥管理问题。也就是说,必须利用像NFS、ftp、插槽和其他一些迁移方法。这对标准组织和必须执行这些标准的厂商来说都是一个重要要求。
我认为现在我们离数据安全领域还有很长一段路要走。当然,已经有很多厂商推出了专门的解决方案,但如果我们没有一个基于标准的架构,那么可能所有人都是朝着一个方向前进的。
- ››深入理解JAR包
- ››深入分析Volatile的实现原理
- ››深入理解Flash Player的应用程序域(Application ...
- ››深入理解flash函数(AS2)
- ››深入理解Android消息处理系统——Looper、Handler...
- ››深入理解SET NAMES和mysql(i)_set_charset的区别
- ››深入理解Mysql字符集设置
- ››深入浅出实战攻防恶意PDF文档
- ››深入剖析防火墙策略的执行过程:ISA2006系列之六
- ››存储过程中的top+变量(downmoon)
- ››深入JavaScript与.NET Framework中的日期时间(3)...
- ››深入JavaScript与.NET Framework中的日期时间(2)...
更多精彩
赞助商链接