数据库数据加密的 4 种常见思绪的对比

• 应用层加解密方案
  
• 数据库前置处理方案
  
• 磁盘存取环节：透明数据加密
  
• DB 后置处理
  

最近由于工作需要，我对欧洲的通用数据掩护条例做了调研和学习，此中有非常告急的一点，也是常识性的一条，就是需要对用户的个人隐私数据做好加密存储，克制用户隐私明文数据泄露。
方案分析
思考如何对用户隐私数据做好加密处理，可以先从分析典型的数据读写链路开始：

按照此链路分析，可以按照数据加密的着手点，分别数据加密的 4 类办理方案：

• 应用层加解密：由应用程序自行负责数据的加解密，这是最自由，但也是最繁琐的一种方案；
  
• DB 前置处理：在数据库服务器开始服务之前嵌入加密逻辑，典型代表是数据库署理服务；
  
• 磁盘存取环节：这种方案的基本思绪则是绕到数据库的身后，在文件体系中注入钩子进程，这样可以在磁盘数据读写之前嵌入加密逻辑，一样平常
  
• DB 后置处理：在数据库服务之后嵌入加密逻辑，依赖数据库提供的触发器以及函数定制功能等。
  

下面就这几类方案睁开分析。
应用层加解密方案
采用这种方案的话，数据加解密对数据库无感知，由应用在存入数据前完成加密，在读取数据后完成解密。这种方案的优点是：

• 迁移性好：因为不依赖任何数据库特性大概操纵体系特性，只需要摆设代码即可运行；
  
• 实现灵活：逻辑放在应用层，各种定制大概扩展都非常方便举行，可以轻松实现按表/按列的加密存储。
  

其时，缺点也非常明显：

• 影响使用数据库高级特性：好比数据库索引以及执行计划等;
  
• 大幅影响数据库查询性能：好比 Like 的前缀查询以及 Where 的范围查询等，都会因为数据加密后而只能全表扫描；
  
• 开辟维护成本高：每次新增需要加解密数据时都需要对应完成开辟调试与测试，开辟人员在应用里既要关注核心业务逻辑，还要关注大量的数据加解密的逻辑，当有多个应用大概体系需要集成加解密功能时，每个应用大概体系都需要重复建立此本领。
  

在应用层实现加解密方案的话，实现上可以考虑团结各类 orm 的回调函数机制，如 golang 中流行的 ORM 框架 gorm 所提供的 Callbacks 机制，又大概是 Ruby on Rails 框架中 Active Record 的 Callbacks 机制，这些机制都能有效资助我们将业务代码和控制代码举行相互隔离。
数据库前置处理方案
采用数据库前置处理方案，算是对应用层加解密方案的优化，本质思想是将加解密的关注点独立，从应用内部完全抽离，独立服务，同时实现加解密逻辑的复用性。
使用数据库前置处理，能够集成应用层加密方案的一些优点，同时办理了后者存在的一些标题：

• 灵活性：数据库署理同样具备较好的灵活性，可以实现列级的加解密；
  
• 复用性较好：多个应用大概体系不再需要重复建立，使用独立维护服务的数据库署理，能够实现快速的加解密功能的接入；
  
• 较高的透明度：应用开辟人员无需在自身内部关注加解密逻辑，但是由于数据库署理的 SQL 兼容性降落，应用开辟过程中不得不保持对 SQL 兼容性的明白。
  

数据库前置处理方案也有自身的一些缺陷：

• 稳固性降落，加大运维负担：因为整体架构引入了额外的服务节点，会给整体的服务成本以及标题排障场景增长负担，在碰到数据处理标题时，需要卷入数据库署理服务的维护人员一起排查故障；
  
• 无法利用数据库高级特性：和应用层数据加解密方案类似，此方案下，由于数据加密后经过数据库存储和索引，在查询场景中，涉及范围范例的数据检索都会导致扫表；
  
• 一致性标题：由于需要在数据库署理中维护业务数据表/或列的元信息，引入了署理层的配置信息和业务数据库计划的一致性标题。
  

磁盘存取环节：透明数据加密
目前各家云服务厂商基本都提供了这个方案的服务，简称透明数据加密（TDE）。这个方案的实现原理比较巧妙，它工作于操纵体系层面，作用于数据库数据文件，通过 i/o 的钩子进程，在数据库存储引擎读写数据到文件体系的时间嵌入加解密逻辑，在写入数据前完成加密，而在数据读取后要返回给存储引擎进程之前执行解密，而整个过程对数据库存储引擎是完全透明的。
这个方案的优点诱人得多：

• 透明性：因为方案在数据库服务器上发挥作用，以是对应用完全透明，应用仍旧直连数据库，而且完全不用担心 SQL 兼容性标题等；
  
• 支持全部数据库高级特性：由于这套方案同时也是对数据库引擎完全透明，在数据库视角，是否加解密在数据检索逻辑以及执行计划优化、事务管理等各个方面都没有区别，以是这种方案能够完善保留数据库的高级特性；
  

固然，没有完善的方案，这个方案存在肯定限定：

• 仅能表级加密：由于这个方案是对数据文件举行的无感加解密，以是它最大的限定是无法实现指定数据表中部门列的加密，固然，如果你的业务里，能够计划出刚好全表大概几乎全部列需要加密的结构，这种限定完全不是标题；
  
• 平台兼容性标题：由于依赖了操纵体系层面的计划，以是这套方案可能只能运行于特定的平台之上；另外如果是云场景之下，还需要考虑不同公有云所提供的方案差别，特殊是使用方式上的细节差别，这些都可能导致同一套体系在云厂商之间迁移时出现不服水土的标题。
  

在我本身的业务体系的计划方案中，我们引入了用户隐私域的概念，在计划上会将用户隐私数据和业务流程数据分离，自然实现用户隐私数据的会合存储，于是全表数据加密对我们是最合适的选择。
DB 后置处理
DB 后置处理是基于数据库的触发器和自定义函数功能等，在数据库服务器执行查询过程中触发自定义加解密逻辑的执行。这种方案可以说是办理了前面几个方案存在标题：

• 透明性：DB 后置处理，对应用完全透明；
  
• 数据库高级特性：完全兼容；
  
• 灵活性：可以灵活实现列级数据加密等。
  

只管这个方案看起来也很美，但是它依然不完善：

• 反模式：我个人一直抗拒在数据库服务器上管理函数大概触发器等，因为这些东西都不易于管理，更不用说实现版本管理等；
  
• 数据库兼容性标题：由于依赖数据库提供的特性，在不得不更换数据库等场景下，这套方案基本无法实现快速迁移。
  

汇总对比
说了这么多，对比下几套方案的差别：

几种方案共存的标题
前面分析中始终没有去讨论的标题，是不管哪种方案都无法绕开的标题：

• 性能开销：数据加解密过程的额外开销，数据加解密需要大量的计算过程，这个会带来不容忽视的性能开销，在加解密算法的选择上，需要在确保数据安全性的前提下，尽可能选择尽可能高效的加密算法；
  
• 空间膨胀：除了性能开销会影响加密算法的选择，加密算法可能还会带来空间膨胀的标题，也就是密文比明文变长的标题，如果是空间膨胀，数据库列在各类长度的计划上还需要额外考虑列数据膨胀后的长度。我了解了下，AES 加密算法的 CTR 模式则能实现密文和明文长度一致；
  
• 密钥管理标题：不管哪种加密方案，都需要想好密钥的私密存储以及定期轮换标题等，否则一旦密钥泄露，加密得再好的数据也可能被一锅端了。
  

总结数据存储安满是一个越来越告急，也是应用体系计划阶段必须提前考虑好的标题，因为它涉及的是服务质量和成本均衡的复杂标题。数据加密在业务合规以及隐私掩护中正在逐步扮演常识性的职位，犹如各人如今都知道密码不能明文存储一样，将来各类个人隐私数据加密也应该会成为体系中的标配计划。


转发自：https://blog.hackerpie.com/posts/architecture/data-encrpytion/

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。