最近由于工作需要，我对欧洲的通用数据保护条例做了调研和学习，其中有非常重要的一点，也是常识性的一条，就是需要对用户的个人隐私数据做好加密存储，避免用户隐私明文数据泄露。
方案分析
思考如何对用户隐私数据做好加密处理，可以先从分析典型的数据读写链路开始：
按照此链路分析，可以按照数据加密的着手点，划分数据加密的 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 后置处理，对应用完全透明；
- 数据库高级特性：完全兼容；
- 灵活性：可以灵活实现列级数据加密等。
尽管这个方案看起来也很美，但是它依然不完美：
- 反模式：我个人一直抗拒在数据库服务器上管理函数或者触发器等，因为这些东西都不易于管理，更不用说实现版本管理等；
- 数据库兼容性问题：由于依赖数据库提供的特性，在不得不更换数据库等场景下，这套方案基本无法实现快速迁移。
汇总对比
说了这么多，对比下几套方案的差异：
| 方案序号 |
加密所在环节 |
方案简介 |
方案案例 |
优点 |
限制 |
| 1 |
应用 |
由应用在存储前自行加密，在检索后自行解密 |
orm+各类钩子实现 |
灵活/粒度细/兼容性强 |
无法对应用透明，增加开发负担/额外的秘钥管理负担 |
| 2 |
数据库前置代理 |
在应用和数据库之间加入一层代理服务，由代理服务负责加解密 |
腾讯云 CASB |
对应用高程度透明，无开发负担/支持列级别加密 |
SQL 语法兼容性下降，对开发不是完全透明/数据库的优化处理、事务处理、并发处理等特性都无法使用/引入额外的环节，性能以及潜在排障负担/数据膨胀厉害，~4.5倍空间膨胀 |
| 3 |
数据库数据文件 |
工作在文件系统层面，引擎持久化存储前完成加密，数据文件加载到内存中前解密，内存中保留明文数据 |
腾讯云透明数据加密（TDE） |
对应用完全透明/云数据库内置支持，兼容数据库高级特性 |
表空间加密，不支持字段级别加密/无法规避 SQL 注入带来的拖库风险 |
| 4 |
数据库后置处理 |
使用“视图”+“触发器”+“扩展索引”+“外部调用”的方式实现数据加密，同时保证应用完全透明。 |
-- |
对应用完全透明/数据库高级特性兼容性/支持列级别加密 |
需要较强运维，没有云原生支持 |
几种方案共存的问题
前面分析中始终没有去讨论的问题，是不管哪种方案都无法绕开的问题：
- 性能开销：数据加解密过程的额外开销，数据加解密需要大量的计算过程，这个会带来不容忽视的性能开销，在加解密算法的选择上，需要在确保数据安全性的前提下，尽可能选择尽可能高效的加密算法；
- 空间膨胀：除了性能开销会影响加密算法的选择，加密算法可能还会带来空间膨胀的问题，也就是密文比明文变长的问题，如果是空间膨胀，数据库列在各类长度的设计上还需要额外考虑列数据膨胀后的长度。我了解了下，AES 加密算法的 CTR 模式则能实现密文和明文长度一致；
- 密钥管理问题：不管哪种加密方案，都需要想好密钥的私密存储以及定期轮换问题等，否则一旦密钥泄露，加密得再好的数据也可能被一锅端了。
总结
数据存储安全是一个越来越重要，也是应用系统设计阶段必须提前考虑好的问题，因为它涉及的是服务质量和成本平衡的复杂问题。数据加密在业务合规以及隐私保护中正在逐步扮演常识性的地位，如同大家如今都知道密码不能明文存储一样，未来各类个人隐私数据加密也应该会成为系统中的标配设计。
