数据库加密技术
数据库加密技术
前置代理及加密网关技术
该方案的总体技术思路即在数据库之前增加一道安全代理服务，对数据库访问的用户都必须经过该安全代理服务，在此服务中实现如数据加解密、存取控制等安全策略。然后安全代理服务通过数据库的访问接口实现数据存储。
安全代理服务存在于客户端应用与数据库存储引擎之间，负责完成数据的加解密工作，加密数据存储在安全代理服务中。
利弊分析
前置代理及代理网关加密技术，迈不过去的"坎"。
- 由于在安全增强代理中需要存储加密数据，因此要解决与数据库存储数据的一致性问题，这基本不可实现。
- 数据的联合检索问题：由于在数据库内、外都存在数据，这些数据的联合检索将变得很困难；SQL语法的完全兼容也非常困难。
- 数据库协议开发无法透明问题：数据库协议虽然存在标准，但事实上每个不同的数据库版本都会进行若干变更、扩展和增强，使用了这些特性的用户必须进行改造。不同的数据库产品协议可能也不一样。同时在安全代理中对数据库通讯协议的模拟非常困难。
- 数据库的优化处理、事务处理、并发处理等特性都无法使用：查询分析、优化处理、事务处理、并发处理工作都需要在安全增强器中完成，无法使用数据库在并发处理和查询优化上的优势，系统的性能和稳定性更多地依赖于安全代理。
- 存在巨大的工作量和很高的技术复杂度。需要提供非常复杂的数据库管理功能。如：SQL命令解析、通讯服务、加密数据索引存储管理、事务管理等。
- 此外还有对于对存储过程、触发器、函数等存储程序的实现支持也非常困难，基本无法支持。
应用层改造加密
加密方案的主要技术原理是应用系统通过加密API(JDBC,ODBC,CAPI等)对敏感数据进行加密，将加密数据存储到数据库的底层文件中；在进行数据检索时，将密文数据取回到客户端，再进行解密，应用系统自行管理密钥体系。
利弊分析
应用层加密技术，只是看起来很美。
应用程序必须对数据进行加解密，增加编程复杂度，而且无法对现有系统做到透明，应用程序必须进行大规模改造。这种技术无法利用数据库的索引机制，加密后数据的检索性能大幅下降。
- 业务团队耦合代价大。
- 侵入性大、无法通用。
基于文件级的加解密技术
顾名思义，基于文件级的加解密技术是不与数据库自身原理融合，只是对数据存储的载体从操作系统或文件系统层面进行加解密的技术手段。
这种技术通过在操作系统中植入具有一定入侵性的“钩子”进程，在数据存储文件被打开的时候进行解密动作，在数据落地的时候执行加密动作，具备基础加解密能力的同时，能够根据操作系统用户或者访问文件的进程ID进行基本的访问权限控制。
提示
放眼目前的技术体系，多数商业数据库已经提供了基于存储文件层进行加解密的手段，尽管不同数据库实现机制可能不同，
但是这些技术手段统称为TDE（transparent Data Encryption），并且作为数据库的组件提供用户使用。
利弊分析
跳出“体系”之外，优势与风险同在。
这种技术巧妙的绕过了让各路英雄头疼的问题。对数据库高端特性兼容、查询检索性能保障、统计分析效率等关键技术指标均有较好的适应情况。
然而在这种机制下，存在的问题也会比较明显，包含以下几类:
① 操作系统或文件系统级加解密，对不同平台适应性较差，而且与内核绑定过重，一旦出现程序故障，会对操作系统造成较大影响，容易导致业务中断。
② 操作系统或文件级加解密的权控在系统层，因此无法单独完成对不同数据库账号的访问权限的设置，需要和其他产品与技术进行组合。
③ 操作系统或文件级的加解密针对落地文件进行操作，加解密粒度比较粗糙，无法针对列级进行加密。
基于视图及触发器的后置代理技术
这种技术是使用“视图”+“触发器”+“扩展索引”+“外部调用”的方式实现数据加密，同时保证应用完全透明。
核心思想是充分利用数据库自身提供的应用定制扩展能力，分别使用其触发器扩展能力、索引扩展能力、自定义函数扩展能力以及视图等技术来满足数据存储加密，加密后数据检索，对应用无缝透明等核心需求。
触发器：
通过触发器实现对明文数据的加密，将加密数据插入表中。
视图:
实现对表内数据的过滤、投影、聚集和关联、函数运算，在视图内实现对敏感列的解密函数调用，实现数据的解密。
扩展索引接口：
使用自定义的扩展加密索引，当使用该索引对加密数据进行检索时，可以进行正常的排序与比较，这样就解决了加密后数据检索失效的问题。大幅提升了密文检索的效率。
外部接口调用：
在实现透明加密访问和高效索引访问之外，另一重要目的是，实现对国产加密算法的调用，和独立于数据库之外的权限控制。
利弊分析
后置代理，独自过独木桥。
以传统的列加密DBCoffer为代表的后置代理加密技术，经过几年演进逐步被大家接受，这种技术拥有前置代理和应用改造所不具备的透明性，灵活性以及数据库高端技术的兼容性，可谓率先走过了数据库加密这一风险与挑战都巨大的“独木桥”。
然而向前看，“独木桥”还在。
“应用环境下，单表亿级数据规模，加密后查询检索性能会不会受到明显影响？”
“对密文数据的统计分析操作，如何保证速度基本不下降？”
“实施加密后，对密文数据的运维、迁移、备份等操作，如何将改动降至最低”
“大量的数据加密，会否带来更大量的空间膨胀”……
这些自数据库加密技术问世以来就相伴而生的问题，不仅变成了用户心头的疑云，也成为了后置代理加密技术提供商亟待解决的当务之急。
写在最后
当然，技术的发展总是无止境的。目前还有一种轻量级的实现方式，通过代理/反射/监听/扩展 JDBC Driver，来达到加解密的目的。