三代数据库加密技术的演变史

最紧迫却又最拉垮的尴尬现状

在前面的文章中我们分析了现行的网络数据安全法律法规中，对数据加密的规定是最直接且最为严格的：粗略统计来看，100%的法律法规都直接或间接的对数据加密做出了要求。在新一代的网络安全国家级法律体系中，2017年6月1日实施的《网络安全法》最早明确提出了该要求。但是整整7年过去了，数据加密存储落地实施的案例却少的可怜。数据加密存储陷入了“要求最高、落地最差”的尴尬境地，就连在三级等保、密评等评估中，评估专家也对数据加密存储这一环节“睁一只眼闭一只眼”。

完美的数据库加密系统长啥样？

是什么导致了这种尴尬境地呢？核心原因在于市场上缺乏“完美加密技术”。根据我们之前的文章可知，组织对数据库加密产品的要求主要体现在五个方面：

能同时满足这五个方面的数据加密技术，才能算得上可以被用户接受的完美数据库加密技术。

第一代：基于数据库自身机制的扩展

第一代数据库加密技术基于数据库自身的机制实现。通过使用视图、触发器、扩展索引等数据库自身的机制，实现透明加密。

其原理如上图所示：

1）视图用于替代原表，实现透明性。视图是一个虚拟表，它在向请求者返回数据之前就对数据库进行解密；

2）触发器用于替代原语句，实现写入或者更新数据的加密，并建立或者更新索引；

3）在触发器和视图中进行独立的解密授权管理，降低特权用户的权限。

该代产品较好的解决了对加密技术的免重构、降权管理和合规性要求。但是该技术需要基于视图、触发器、扩展索引等数据库自身的机制，而并不是所有的数据库都提供这些机制，所以该技术的兼容性很低，只能支持Oracle等有限的数据库种类。同时，由于需要维护独立的一套密文索引，且密文索引的性能远不如数据库的原生索引，从而导致性能较低，复杂查询的性能可能降低至十倍以上。

第二代：数据库加密网关

鉴于第一代产品的兼容性和性能问题，出现了第二代数据库加密系统。其思路是将数据读写操作的拦截和修改动作前移，在客户端访问数据库的路径上，通过某种机制，截获命令并进行修改。其核心是一个命令改写器：

1）对于数据的写入命令，将数据加密后写入数据库，同时维护密文索引；

2）对于数据的读取命令，将解密命令发送到数据库先执行解密任务，数据库返回解密后的数据。

为了简化该方案的实现，还可以在连接驱动处拦截，比如对JDBC连接驱动进行修改，或者通过切面编程（AOP）机制实现数据库命令的拦截和修改。

第二代技术的优点在于不再依赖数据库的视图、触发器、扩展索引等机制，具有很好的数据库兼容性，甚至可以用于SAAS云数据库的加密。而且性能也比第一代技术有明显提高。但是该技术又引入新的兼容性问题：对数据库命令的兼容难题。对于已经存在于数据库上的命令，比如已经存在的存储过程、函数、触发器等，以及复杂的索引，由于这些命令的执行位于网关之后，所以无法被正确执行，或者兼容的效果很不理想。另外，性能方面仍然存在下降过多的问题：由于修改了访问数据库的命令和存储的数据类型，数据库原来有效的优化策略会失效，导致性能大幅降低。

第三代：动态加密

由于前两代技术都没有完美满足五个要求。历经几年时间，我们又研发了第三代数据加密技术：动态加密。

动态加密通过在数据库服务器的操作系统内核层安装插件来实现数据访问命令和存储命令的拦截和修改。插件分为两个部分。第一部分是授权管理插件，它拦截数据库访问命令，对于授权访问，对命令直接放行；对于受限命令，则将数据加密或者脱敏后再返回，或者直接拒绝访问。第二部分则对数据的读写操作进行拦截，将数据加密后存储到磁盘，或者将数据解密后交给数据库。

性能方面，则采用了异步加密的策略。对于写入到磁盘的数据，并不是立即进行加密，而是在恰当的时机再触发加密操作。触发条件可以是：用户主动触发、空闲时间触发、定时触发等等。这样的处理方式，将加密对性能的影响，降到了最低，甚至接近于加密前的性能。

另外在降权方面也有突出的表现：由于工作在系统内核层，数据一旦进入加密系统的保护范围，哪怕数据还没有被触发加密，对于非授权的访问也只能看到密文，或者被拒绝访问。比如对于数据库文件的非法复制、勒索病毒的勒索加密等，都将会被拒绝。

其动态体现在两个方面。第一是对于非授权访问，动态的将数据加密后返回给访问者；第二是对于存储至磁盘的数据，采用了动态触发的加密措施。

总结

第三代数据库的动态加密技术，在兼容性、免重构、性能、降权管理、合规性这五个方面都取得了非常好的效果。相对于第一代和第二代来说，第三代技术具有更好的可落地性。