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