PostgreSQL数据库透明数据加密概述

王果壳

发布于 2019-09-30 10:25:21

2.6K0

发布于 2019-09-30 10:25:21

文章被收录于专栏：王硕王硕

最近一段时间，一直在和PostgreSQL社区合作开发TDE（Transparent data encryption，透明数据加密）。研究了一些密码学相关的知识，并利用这些知识和数据库相结合。本文将会以数据库内核开发角度，从以下3个维度和大家讲述TDE。

数据库当前面临的威胁模型
加密策略描述，当前PostgreSQL社区目前的设计状态以及其他数据库TDE方案对比
未来的数据安全畅想

那什么是透明数据加密？

透明数据加密，从字面上来说，可以分为三部分，数据，加密，透明。数据，这里不用过多解释，用户需要保护的明文数据。加密，相信大家也清楚，信息安全一直伴随着世界的发展，加密是信息安全的一种重要手段，常用加密方法目前可以分为流密码加密、分组加密以及公钥加密3种。透明，指的是用户无感知，这是对加密行为的描述。

透明加密技术是近年来针对企业文件保密需求应运而生的一种文件加密技术。是指对使用者来说是无感知的。当使用者在打开或编辑指定文件时，系统将自动对未加密的文件进行加密，对已加密的文件自动解密。文件在硬盘上是密文，在内存中是明文。一旦离开使用环境，由于应用程序无法得到自动解密的服务而无法打开，从而起来保护文件内容的效果。 --摘自《百度百科》

一般涉及到加密码学相关话题时，我们首先要清楚面对的安全威胁是什么？

当前数据库数据面临的威胁模型

不恰当的权限 很多应用或者软件在使用过程中，往往因为使用的便利，将不必要的权限赋予用户；其次，未及时清理无效的用户（比如，离职员工），同样会造成信息的泄露。大多数应用软件不会对于DBA和开发人员进行过多的限制，这同样有数据丢失的风险。权限赋予策略、三权分立或者数据库审计都是有效防范此类威胁的重要手段。
SQL注入攻击 SQL注入攻击一直是数据库面临的重大风险之一。随着B/S模式应用开发的发展，使用这种模式编写应用程序的程序员也越来越多。但是由于程序员的水平及经验也参差不齐，相当大一部分程序员在编写代码的时候，没有对用户输入数据的合法性进行判断，使应用程序存在安全隐患。用户可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据。合理的软件架构设计以及合法的SQL审计，是防范此类威胁的有效方法。
恶意攻击 攻击者可以通过网络窃听、木马攻击等方式影响数据库，造成数据丢失风险。很多厂商往往会因为性能或者资源等原因，没有开启网络传输加密，从而造成数据窃听风险。其次，恶意攻击者可以通过木马病毒等措施，感染合法用户设备，从而窃取数据，造成数据丢失。提高安全措施，比如开启防火墙，开启网络传输加密等，其次加强数据库审计可以方法此类威胁。
弱审计跟踪 由于资源的消耗、性能的下降，很多厂商关闭或者开启较少功能的审计跟踪，这会导致恶意的管理员对于数据的非法侵入。其次，由于审计之后的限制操作比较难以实现，比如对于DBA和非法侵入就难以区分，从而导致审计之后的操作难以防御攻击。网络设备审计是目前最有效的审计方案。
不安全的存储介质 存储介质存储窃取的风险，其次备份存储存储安全设置较低的因素，这都会造成数据丢失。提高物理介质的保护，加密用户数据，加强所有数据存储的安全设置能够防范此类威胁。
不安全的第三方 随着云时代以及5G的到来，更多的厂商将数据存储到云端。这其实存在第三方信任问题。如果第三方存在恶意管理员，非法窃取或读取敏感数据；或者提供存在安全隐患的服务器，这都会造成数据丢失。选择可信任的第三方，加密用户数据，可以避免不安全的第三方威胁。
数据库漏洞或者错误的配置 随着现代数据库软件的功能增多，复杂的程序很可能会存在安全漏洞，而且很多厂商为了保证系统的稳定性不愿意进行版本升级，同样数据面临很大的泄露风险。其次，安全设置不足也存在很高的风险。这里的安全配置不仅仅指的是数据库层面，操作系统层面也需要加强安全配置。定期修复数据库漏洞，加强安全配置。
有限的安全专业知识和教育 据统计，大约有30%的数据泄露事件是由人为疏漏造成的，所以安全教育同样需要加强。定期进行安全专业知识讲座，提高安全防范意识。

综上所述，目前数据加密能够应对的威胁有有不安全的存储介质，不安全的第三方。而我们知道数据库不仅需要安全因素的考量，同时需要兼顾性能、稳定、易用的因素。那么如何设计数据加密？

加密等级

首先我们回顾一下PostgreSQL整体架构：

通过整体架构来看，我们可以将加密分为6个等级。从上图可以看到，客户端和服务端进行交互，用户数据自客户端起，由服务端接收，并写入到服务端缓存中，再刷入到磁盘内。而PostgreSQL存储物理结构为：集群-->表空间-->数据库-->关系对象。由此我们可以将数据库分为6个层级进行加密，分别是，客户端加密，服务端加密，集簇级加密，表空间级加密，数据库级加密以及表级或对象级加密。下面对这6个层级进行分别阐述：

客户端加密，由用户生成密钥，对字段进行加密；
1. 优点：在某种程度上能够防范DBA以及开发人员；加密粒度小，加密数据量可控。现有的加密插件pgcrypto可以客户端的数据加密功能。
2. 缺点：使用成本较高，需要调整现有应用系统，对数据插入语句进行修改；其次由于从数据生成开始加密，等于是缓存级加密，性能较差，索引无法使用。
服务端加密，建立加密类型，对字段进行加密；
1. 优点：使用成本相对于客户端加密较低，仅需要对数据库进行调整，无需修改应用程序，加密粒度小，加密数据量可控。
2. 缺点，同样是缓存级加密，性能较差，索引无法使用。
集簇级加密，对整个集簇进行加密，初始化时确定集簇是否加密；
1. 优点：架构简单，使用成本低，操作系统缓存级加密（数据缓存刷入、读取磁盘时加解密），性能相对较好；
2. 缺点，加密细粒度大，所有集簇内对象都会加密，会造成性能下降。
表空间级加密，对某一个表空间设置加密属性，所有在加密表空间内都默认加密；
1. 优点：架构简单，使用成本低，操作系统缓存级加密，性能相对较好，加密细粒度降低，能够更好的控制加密数据量，有利于数据加密效率；
2. 缺点：表空间在PostgreSQL的概念不够明确，用户容易误解，其次在备份管理等方面使用成本较高。
数据库级加密，指定某个库为加密库，所有在加密库中的对象默认加密；
1. 优点：架构简单，使用成本低，操作系统缓存级加密，加密细粒度降低，数据加密效率高；
2. 缺点：加密细粒度相对较大。
表级加密或者文件级加密，指定某个对象加密；
1. 优点：架构简单，使用成本低，操作系统缓存级加密，加密细粒度进一步降低，数据加密效率高；
2. 缺点：密钥管理成本较大，开发复杂度较高。其次当需要加密的对象较多时，使用成本较高。

*这里解释以下为什么缓存级加密无法建立索引的原因：建立索引的目的是提高数据建索效率，而加密的原因是保护敏感数据。

那么如果我们在缓存级加密，如果建立索引，这里也需要分为两种情况，基于明文建索引或基于密文建索引。
- 基于明文建索引则需要对明文进行解密，建立索引，后对索引加密，但这样加解密次数过多，会引起性能下降，其次索引本身的顺序也会造成一定的信息泄漏。
- 基于密文建索引则索引无法有效对数据排序，也就难以起到快速减速的能力。
那如果不对索引加密，则会对数据安全产生影响。

当然如果加密后不使用索引则不会有任何影响。*

上面提到了缓存级和文件系统级加密接下来从存储架构上来看：

由上图可知，我们可以分为三个等级，数据库缓存级，操作系统缓存级以及文件系统级：

数据库缓存级加密：上述的等级1、2都是数据写入缓存时已经加密，缓存级加密，数据检索时解密，性能最差；操作系统缓存级：等级3、4、5、6都是在PostgreSQL数据刷写磁盘是加密，数据加载时解密，性能相对较好；文件系统级：数据库自身无法实现，需要使用文件系统加密，数据库不可控。

那对于数据库来说应该如何选择？虽然加密是一种很好的数据安全保护手段，但是如何加入到数据库中还需要进行整体性考虑。在对数据库进行加强时，我们需要考虑

开发成本；
安全性；
性能；
易用性。

社区经过多次讨论，目前由于设计难易度以及开发成本的角度，选择了集簇级加密作为TDE的第一个方案。

我们都知道，常用加密目前主要有流式加密、分组加密、公钥加密三种。在使用加密算法的时候，应注意：

加密方法由两部分构成，密钥以及加密算法。通常我们建议使用国际公开、认证的加密算法。
密钥的保护等同于明文的保护。

所以如何进行加密我们将会分为两部分讲述：加密算法的选择以及密钥的管理。

加密算法选择

首先分析一下三种加密方式：

流式加密的特性是，密钥长度与明文数据长度一致，而这在数据库中是难以实现的，所以在这不考虑。
公钥加密是最大的优势在于分为公私密钥，公钥是可以公开的，这就降低了密钥管理的问题，但是其加密性能太差，分组加密算法是公钥加密的几百倍，所以在此也不进行考虑。
分组加密是目前主流的加密算法，性能最优，应用最广。

而当前国际公认的分组加密算法是AES。下面我们简单介绍一下AES。分组加密算法，首先需要分组，AES的加密长度为128bits，也就是说16 bytes。拥有3种密钥长度，128，192以及256。 AES拥有5种加密模式：

ECB mode: Electronic Code Book mode，电子密码本模式 CBC mode: Cipher Block Chaining mode，密码分组链表模式 CFB mode: Cipher FeedBack mode，密文反馈模式 OFB mode: Output FeedBack mode，输出反馈模式 CTR mode: Counter mode，计数器模式

c. 过程： i. 将明文进行分组，以16字节为一组； ii. 初始化计数器，要求所有计数为唯一值； iii. 使用密钥加密计数； iv. 使用加密后的计数和明文异或； v. 得到密文； vi. 重复步骤iii，iv，v； vii. 逆向则解密。

5种模式的异同

上述阐述了，5种mode的加密过程，由此不同的加密过程，则产生异同点：

模式	优点	缺点
ECB mode	简单；快速；支持并行计算	明文中的重复排列会反映在密文中；通过删除、替换密文分组可以对明文进行操作；对保护某些比特错误的密文进行解密时，对应的分组会出错；不能抵御重放攻击；NIST（National Institute of Standards and Technology）不推荐使用
CBC mode	明文中的重复排列不会反映在密文中；支持并行解密；能够解密任意明文分组	对包含某些错误比特的密文进行解密时，第一个分组的全部比特以及后一个分组的相应比特会出错；加密不支持并行计算
CFB mode	不需要填充；支持并行解密；能够解密任意明文分组	加密不支持并行计算；对包含某些错误比特的密文进行解密时，第一个分组的全部比特以及后一个分组的相应比特会出错；不能抵御重放攻击
OFB mode	不需要填充；可事先进行加密和解密的准备；加密、解密使用相同结构；对某些包含错误比特的密文进行解密时，只有明文中相应的比特会出错	不支持并行计算；主动攻击者反转密文分组中的某些比特时，明文分组中对应的别特也会被反转
CTR mode	不需要填充；可事先进行加密和解密的准备；加密、解密使用相同结构；对某些包含错误比特的密文进行解密时，只有明文中相应的比特会出错；支持并行计算	主动攻击者反转密文分组中的某些比特时，明文分组中对应的别特也会被反转

5种模式的加解密效率

加密：

解密：

注：以上数据仅是单进程下的对比。

数据库中如何选择加密模式

开发成本：使用openssl自带的加密算法，加密算法开发成本低；其中除ECB外都需要额外的使用向量或计数器，开发成本相当；由于CBC和ECB需要进行填充数据，考虑到WAL流复制过程，不推荐使用。最优选择为CFB，OFB和CTR。安全性：ECB不予考虑，其他皆可。性能：由于是在刷写磁盘时进行加解密，那么考虑到读取和写入的并行要求，以及加密算法的性能，CTR mode是最优选择。易用性：在此不需要考虑。

以上，从各个层面来说，CTR都是最优的加密mode，社区同样选择了CTR mode作为加密模式。

数据库中如何使用CTR mode

要添加CTR mode到数据库，需要了解CTR的加密过程。从上面的加解密流程可以知道，CTR加解密时需要4部分共同协作，明/密文，算法，计数器，密钥。

算法本身是调用openssl的CTR mode，所以这里无需开发，只需要熟读openssl的文档即可。
明/密文，根据加密等级的介绍，数据库是将缓存刷入磁盘时进行加密的，也就是说将会对page进行加解密，其大小为8192 bytes，正好是加密块的整数倍；其次在考虑流复制的特殊性，我们也会对recode进行加解密。
计数器，根据NIST的加密算法说明，我们可以知道，这里的计数器不要求强随机，只要是保证不重复即可。其次，计数同样需要保存在数据库中。因此考虑使用page页上的LSN来作为计数器的一部分，（这里要说明的是，LSN是存在重复的可能性。社区目前有人提供一个新的补丁来防止LSN重复的可能），其次使用文件名以及也的顺序作为其中的一部分。以此来保证其唯一性。
密钥，密钥的保护等于密文的保护。所以密钥如何生成、管理是非常重要的。将由下面这个章节进行说明。

密钥管理

密钥管理由四部分构成：密钥生成、密钥交换、密钥保存以及密钥轮转。

密钥生成

上面的章节介绍了我们将会选择对称分组加密方法进行加解密，那么我们的密钥即是对称密钥。而对称密码生成方法有：

随机数作为密钥
基于口令的密钥生成
HKDF（HMAC-based Extrac-and-Expand Key Derivation Function）

随机数作为密钥：这很用以理解，使用强随机数生成器，生成密钥。
基于口令的密钥生成：根据用户口令生成密钥并使用它进行加解密的方法。具体方法如下：

HKDF：密钥派生函数(KDF)是密码系统的基本组成部分。它的目标是获取一些初始的密钥材料，并从中派生出一个或多个安全强度很大的密钥。
提取，使用强随机数和输入的信息使用hmac方法进行hash运算；
扩展，通过多次hash计算，对上面结果进行扩展，扩展到我们需要的长度。

密钥保存

密钥的生成无论是随机数的还是基于口令的，都有一部分是目前难以记忆的，所以这就需要存储密钥了（也可能是salt）。密钥不能与数据存储在同一位置，否则等于是钥匙挂在门上，没有任何意义。我们一般需要将密钥存储在文件内，放到保险柜等安全的存储位置或者安全的密钥分配中心。当时当密钥数量达到一定数量时，我们就需要另一种密钥，KEK（Key encryption key，密钥加密密钥）。这是由于密钥如果不进行加密，窃取后，盗取者很容易使用密钥对数据解密了。同样，管理多个密钥难度远远大于单个密钥。所以可以考虑使用KEK来保存密钥的一种方式，当然KEK也需要存储在安全的位置。

密钥交换

密钥交换目前有4种：事先共享密钥，使用密钥分配中心，使用公钥密码以及Diffie-Hellman密钥交换方法。

下面简单描述一下4种方法： 事先共享密码：双方加密前通过安全途径交换密钥，但是在数据库中，双方为服务端和磁盘，即密钥和磁盘在同一区域，不安全，所以数据库不会考虑这种方式。

使用公钥密码：由于我们这里使用对称加密体系，所以不考虑公钥。但是这可以作为密钥交换的一部分使用。

使用密钥分配中心：将密钥存储到可信任的第三方，使用时通过第三方获取密钥。在需要使用密钥时，向第三方通讯，生成会话密钥，使用会话密钥加密密钥进行发送密钥。这里的会发密钥可以使用公钥加密体系。

DIffie-Hellman密钥交换： DIffie-Hellman是1976年由Whitfield Diffie和Martin Hellman共同发明的一种算法。该算法可以通过交换可以公开的信息就能够生成共享的秘密数字，从而达到共享密钥的目的，其过程如下图所示：

1. DB server向Key server（以下简称D和K）发送两个质数P，G；
2. D生成一个随机数A；
3. K生成一个随机数B；
4. D将GA mod P 发送给K；
5. K将GB mod P 发送给D；
6. D使用K发过来的数B', 计算B’mod P，这就是数据加密密钥；
7. K使用D发过来的数A'，计算A' mod P，这个和D计算得到的加密密钥是相等的；

当然再加入数据库时，同样需要使用安全第三方作为信息交换，但这减少了密钥被窃听的可能性。

密钥轮转

密钥轮转，分为密钥更新和作废两部分。密钥更新，更新可以提高密钥暴力破解的难度，其次即便是过去的密钥被破解也无法获取当前的数据。密钥作废，在更新后要及时对密钥进行作废，这里的作废不仅仅指的是删除，而是要达到无法还原密钥的目的。

TDE的密钥管理方法

以上密钥管理方法没有明确不推荐的情况下，都是可以使用的。笔者再和社区沟通的过程中推荐的是，基于口令的密钥生成，使用KEK存储密钥，DIffie-Hellman密钥交换的方案。

当前社区经过多轮讨论后，目前由两种方案2层密钥管理以及3层密钥管理：. 相面对其进行介绍：

2层密钥管理：

2层密钥管理使用的是，基于口令的密钥生成，使用KEK存储密钥以及使用密钥分配中心3者的结合，架构体系如下图：

这和之前讲到的基于口令的密码很相似，不过数据加密密钥将会存储到数据库服务器，这有别于基于口令的密码存储到外部服务器。

3层密钥管理：

这里使用的是，基于口令的密钥生成，HKDF，使用KEK存储密钥以及使用密钥分配中心4者的结合，架构体系如下图：

1. 用户输入口令；
2. 系统生成随机数，与用户口令进行hash计算，得到密钥加密密钥；
3. 随机数存储至安全处；
4. 系统生成随机数作为MDEK（master data encryption key），存储至安全处；
5. 使用MDEK和加密文件信息得到数据加密密钥；
6. 使用数据加密密钥对数据进行加解密。

目前密钥管理还有一定争议，我个人比较赞同第二种方式，为后期更小加密细粒度做准备。

其他数据库TDE方案对比

做任何事情都不是闭门造车，现阶段，很多数据库已经支持了TDE，我们对此进行对比，以此来确定最优的方案：

Oracle
- 加密等级：Tablespace-level，Column-level
- 加密算法：AES，3DES
- 密钥管理：主密钥和数据加密密钥
SQL Servel
- 加密等级：Database-level
- 加密算法：AES，3DES
- 密钥管理：系统密钥，主密钥，系统证书，数据加密密钥
DB2
- 加密等级：Database-level
- 加密算法：AES，3DES
- 密钥管理：主密钥和数据加密密钥
MySQL
- 加密等级：Tablespace-level，Column-level
- 加密算法：AES，3DES
- 密钥管理：OASIS Key Management Interoperability Protocol (KMIP) TC

未来的数据安全畅想

现在5G的来临，云时代的来临，我想未来的IT架构，更多的都是基于云的设计。更多的数据存储在云上，那么云厂商如果对用户数据窃取、分析，那都会严重侵犯我们的隐私。之前在威胁模型中也说到的恶意DBA和开发人员，他们往往具有较高的数据库权限，哪怕没有权限，他们如果有读取缓存的方法，那么数据同样会泄露。那么如何保护我们的数据呢？

同态加密

同态加密是基于数学难题的计算复杂性理论的密码学技术。对经过同态加密的数据进行处理得到一个输出，将这一输出进行解密，其结果与用同一方法处理未加密的原始数据得到的输出结果是一样的。 --摘自《百度百科》

同态加密（Homomorphic Encryption）是很久以前密码学界就提出来的一个Open Problem。早在1978年，Ron Rivest, Leonard Adleman, 以及Michael L. Dertouzos就以银行为应用背景提出了这个概念。

一般的加密方案关注的都是数据存储安全。即，我要给其他人发个加密的东西，或者要在计算机或者其他服务器上存一个东西，我要对数据进行加密后在发送或者存储。没有密钥的用户，不可能从加密结果中得到有关原始数据的任何信息。只有拥有密钥的用户才能够正确解密，得到原始的内容。我们注意到，这个过程中用户是不能对加密结果做任何操作的，只能进行存储、传输。对加密结果做任何操作，都将会导致错误的解密，甚至解密失败。同态加密方案最有趣的地方在于，其关注的是数据处理安全。同态加密提供了一种对加密数据进行处理的功能。也就是说，其他人可以对加密数据进行处理，但是处理过程不会泄露任何原始内容。同时，拥有密钥的用户对处理过的数据进行解密后，得到的正好是处理后的结果。

如果不是很理解他的概念，那么我们可以看下图：

同态加密你可以想象，DBA和开发人员或者恶意的云管理员，他们就像是操作工人（攻击者），必须带着手套在加锁的盒子里（加密算法）处理金子，没有钥匙（密钥）打不开，如此，他们是无法窃取金子（数据）的。

那么未来如何使用同态加密呢？

Alice通过Cloud，以Homomorphic Encryption（以下简称HE）处理数据的整个处理过程大致是这样的： Alice对数据进行加密。并把加密后的数据发送给Cloud； Alice向Cloud提交数据的处理方法，这里用函数f来表示； Cloud在函数f下对数据进行处理，并且将处理后的结果发送给Alice； Alice对数据进行解密，得到结果。

那么为什么现在还没有大规模应用呢？根据IBM团队的研究，直到2016年，该技术都还存在性能瓶颈，巨大的性能开销让人无奈至极。同态加密的发明者克雷格•金特里(Craig Gentry)带领IBM的研究团队进行了一系列同态加密尝试。最初的时候，同态加密的数据处理速度比明文操作慢“100万亿倍”，后来在16核服务器上执行，速度就提升了200万倍，但还是比明文操作慢很多。因此，IBM继续改进HElib，其发布在GitHub上的最新版就重新实现了同态线性变换，性能得到极大提升，速度加快了15-75倍。国际密码学研究协会的一篇论文中，IBM密码研究团队的谢•哈勒维(Shai Halevi)和纽约大学库朗数学研究所教授维克多•舒普（Victor Shoup，同时供职IBM苏黎世研究实验室）阐述了速度提升的方法。

所以当前同态加密的性能无法满足正常需要，如果商用到数据库层面，我认为还需要密码学家的进一步研究。请大家期待吧。

写在最后

以上所有方法都是软件层面的操作，目前关于数据加密其实涌现了很多硬件解决方案，比如FPGA卡加解密，以提高其性能；还有Intel的基于可信执行环境技术（TEE，Trusted Execution Environment）的可信计算等等。加密也仅仅是数据库安全的一小部分，更多的内容需要大家的共同努力，也希望在未来能够看到更多的人从事到数据库安全领域当中。