Author: 卓刀
很多行业对行业数据的存储都有自己的监管标准，例如：
这些监管标准中都要求数据必须是加密存储的。而为了对数据进行加密存储，首先想到的是文件级加密（FDE)。文件级加密虽然简单直接，但是依赖支持加解密接口的文件系统，或者是其他层面的加解密，例如云盘块存储层面。这对很多系统来说，代价比较高。很多商业数据库管理系统在数据库层面实现了TDE（Transparent Data Encryption），相对于FDE，优势如下：
目前很多数据库已经实现了TDE，我们首先对各个数据库最后TDE 实现的效果有个大体的了解，然后再去探究PostgreSQL 社区当前对TDE 的讨论和一些结论。
MySQL 支持每个tablespace 数据级别的静态数据加密。MySQL 中tablespace 涉及到一个包含一个或者多个InnoDB 表和对应索引的文件（在PostgreSQL 中tablespace 对应一个目录）。 MySQL 8.0.16 支持了redo log 和undo log 的加密和系统表的加密，并且支持了2层加密体系，每个tablespace 在文件头中都存储着自己的密钥。主密钥可以通过keyring 插件来获取。
MySQL 加密redo log 和 undo log 使用和表数据加密不同的密钥。这些密钥存储在redo/undo log 加密后文件的头部。
Oracle DB 支持列级别和tablespace 级别的TDE，都采用了二层加密的结构。主加密密钥（MEK）存放在额外的密钥存储中，支持软硬件的密钥存储。MEK 用来加密列级别和tablespace 级别的密钥。列级别每个表使用相同的加密密钥，tablespace 级别的每个tablespace 使用相同的加密密钥。支持3DES168 和AES (128,192,256 位）的加密算法。列级TDE 默认为AES-192算法，tablespace 级别的TDE 默认为AES-128 算法。在加密 之前，会在明文中增加一点额外信息（比如16字节的随机字符来保证相同明文加密得到不同的密文）。同时还会在密文上增加20字节的完整性检查值来保证密文的完整性，当然可以通过NOMAC 参数取消完整性检查值的填充来提高加密性能。
MS SQL Server 支持数据库级别的TDE，采用了三层的密钥加密构架，并支持对称和非对称加密算法。服务主密钥（Service Master Key 简称为SMK）在初始化数据的时候生成。数据库主密钥（Database Master Key，简称为DMK）在默认数据库中产生，并由SMK 加密存储。DMK 被用来生成证书来保证数据库加密密钥（Database Encryption Key，简称为DEK）的安全。DEK 使用对称加密算法对数据和日志文件进行加解密。
PostgreSQL 社区自2016年已经对TDE 展开了讨论，目前仍然存在很多的争论，但是确认了在PostgreSQL 13 的版本中会输出TDE 第一个版本，实现如下的功能：
在这之前社区会对很多相关的问题进行讨论：
在社区的讨论中，都一再强调一定要明确了TDE 要防护的安全风险模型之后，再去讨论具体的实现。目前基本明确TDE 保护突破了文件系统访问控制的安全威胁：
各个数据库在实现TDE 的时候加密的粒度都是不同的，当前加密的粒度可以分为：
根据上文可知，PostgreSQL 13 第一个版本会实现集群级别的加密，这样的决定主要基于：
当然，社区还是有其他不同的声音，认为更加细粒度的加密比集群级别的加密更具有优势：
当然这样也会引入其他问题，加密数据的表查找将会带来额外的开销。
哪些文件需要加密首先是取决于上文说的加密的粒度。在集群级别的加密中，它将会加密整个数据库集群数据包含所有的表，索引以及SLRU 数据。计划中的PostgreSQL 13 实现的第一个版本将会实现数据集群所有的数据同时也包含WAL 日志，临时文件等等，但是不加密内存中的数据。
另一方面，更细粒度级别的加密，数据库只加密部分数据，一般包含相关的：
在社区的计划中，目前对SLRU 数据，例如clog, commit timestamp, 2pc file 等等以及服务端日志pg_log 不需要进行加密，当然这个结论随着后面讨论的加深可能也会被推翻。另外，对prepared transaction 产生的持久化文件，目前Sawada-san 认为没有任何的重要数据，所以没有必要进行加密。社区目前将这部分作为一个todo list 等待未来继续讨论。
大多数TDE 的实现都是数据在buffer 中的时候是明文，刷到磁盘上的时候进行加密，从磁盘上读取的时候进行解密，保证用于数据处理的时候是明文，而持久化到磁盘上的数据是密文。
不过在具体实现上，仍然有很多问题需要讨论。
社区中讨论了时下多种加密的算法，初步决定使用AES （Advanced Encryption Standard）对数据块进行加密。 对于AES 来说，有三个关键组成部分，包括算法/模式，密钥（key），初始向量（IV）。
计划使用AES 的CTR 模式对WAL 日志和表/索引数据进行加密。
计划使用密钥支持128 或者256位长度，可以在initdb 的时候选择密钥的长度。
为了使得加密的密文随机化，AES 引入了IV。IV 要求每次加密必须是唯一的，但是不需要保密，对外可见。因为每次产生随机数来作为IV，开销比较大，我们可以用一些被加密对象的唯一值来作为IV。
上文社区当前计划使用AES 的加密方法，所以本文接下来讨论的就是AES 的密钥如何来管理。一般情况下，为了减少密钥更换带来重解密重加密的开销，业界的方法都是采用多层密钥管理的结构，例如上文的Oracle，MySQL，MS SQL Server 等。其中Oracle，MySQL 使用的是两层密钥结构，MS SQL Server 使用的是三层密钥结构。
一般两层密钥结构中包含主密钥（master key，简称为MK）和 数据加密密钥（data encryption key，DEK）。MK 用来加密DEK，而且必须保存在数据库之外，例如KMS。DEK 用来加密数据库数据，可以使用MK 加密后保存在数据库本地。 如果我们使用单层密钥结构，更换密钥的时候必须要重新解密并加密。而使用两层密钥结构，我们需要重新加密和使用新MK 解密的只有DEK，更换密钥的速度会非常的快。
上文提到的PostgreSQL 2019 年邮件列表中的提交的tablespace 级别的TDE patch 中就使用两层密钥结构。
MS SQL Server 使用的就是三层密钥结构。但是在PostgreSQL 社区中讨论的结构可能略有不同，包含：
除了上文的两种密钥，社区认为临时文件的加密密钥需要单独拿出来讨论。临时文件密钥只在服务器运行过程中存在，可以只保存在内存中。在并发查询进行中，多个worker 是可以使用同一个临时文件的。所以临时文件的密钥需要多个并发查询worker 共享，其密钥的管理需要单独进行考虑。
无论是两层还是三层的密钥结构，需要更换的只有最顶层的密钥，而且该密钥必须要求存储在数据库之外。目前社区达成一致意见，增加一个类似ssl_passphrase_command 的参数来运行命令得到相应的密钥，例如上文中的支持集群级别的加密 提供了cluster_passphrase_command 参数。
不过，社区中支持tablespace 的patch 中实现了密钥管理的API 用来支持外部的密钥管理服务。
一些前端工具如果需要直接读取数据库文件或者WAL 日志文件需要通过KMS 得到对应的顶层密钥，通过解密数据库中的密文得到加密数据的密钥，从而得到数据明文。
至此，我们已经对PostgreSQL 中实现TDE 的各个各个相关问题进行了讨论，但是目前很多具体的细节并未确认。不过基本确认的是PostgreSQL 13 会推出支持集群级别加密的TDE 功能，敬请期待。