网站有多少个,做外贸的网站有哪些,学校网站建设运行简介,公司网站模板 html应用层加解密方案数据库前置处理方案磁盘存取环节#xff1a;透明数据加密DB 后置处理
最近由于工作需要#xff0c;我对欧洲的通用数据保护条例做了调研和学习#xff0c;其中有非常重要的一点#xff0c;也是常识性的一条#xff0c;就是需要对用户的个人隐私数据做好加…应用层加解密方案数据库前置处理方案磁盘存取环节透明数据加密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/
