PostgreSQL 的开源 TDE：pg_tde 是什么，以及你是否需要它
作者: 未指明
日期: 2026-05-29
阅读时间: 6 分钟
分类: PostgreSQL
过去十年的大部分时间里，"PostgreSQL 支持透明数据加密吗？"这个问题的答案一直是：核心不支持，但 EnterpriseDB 有，Crunchy 有另一个不同的，Cybertec 还有另一个，如果你不介意你的 DBA 的威胁模型和审计员的威胁模型现在不一致的话，你也可以用文件系统级加密自己实现。
Percona 现已发布了 pg_tde，这是一个开源的扩展，可以对 PostgreSQL 数据文件进行块级加密。它是真实的，已经达到生产就绪状态（当前版本为 2.1.2），并且其许可足够宽松，可以实际部署。其宣传的性能数据是开销低于 10%，这与专有实现多年来声称的数据相符。
这篇文章面向技术管理层：pg_tde 是什么，它实际能防御什么，不能防御什么，以及你的组织是否应该关注它。
TDE 的实际含义
透明数据加密保护静态数据。"静态"这个词承担了很重的责任。它的意思是：已写入磁盘的字节。它不是指内存中的字节。它不是指传输中的字节。它不是指已登录用户可见的行。TDE 是对抗那些带着备份磁带、退役磁盘或被偷走的（上面运行着你数据库的开发副本的）笔记本电脑溜走的人的手段。
我曾直言不讳地说过"TDE 毫无用处"。那是为了戏剧效果而夸大其词，但 TDE 能够解决的威胁模型非常有限。大多数数据泄露是通过应用层发生的，而不是物理介质，而 TDE 对此无能为力。
TDE 无法阻止 SQL 注入攻击。无法阻止被泄露的应用程序凭证。无法阻止恶意的 DBA。加密密钥由正在运行的数据库持有，而正在运行的数据库会为任何能够认证的人解密数据。
这不是 pg_tde 的缺陷。这是 TDE 的定义。但当你的合规团队开始询问哪些数据被加密时，这是需要注意的事情，因为诚实的答案是"磁盘文件，而且仅仅是磁盘文件。"
pg_tde 加密什么
pg_tde 使用 AES------128 或 256 位，堆数据使用 CBC 模式，WAL 使用 CTR 模式------以及两层密钥层次结构。内部密钥加密实际数据；它们位于 $PGDATA/pg_tde 中。主密钥加密内部密钥；它们位于一个外部密钥管理系统中。支持的 KMS 目标是 HashiCorp Vault、OpenBao 以及任何兼容 KMIP 的服务器。每个数据库有一个主密钥，每个具有不同 OID 的文件都有自己的内部密钥。
该扩展加密：
- 你明确标记为加密的堆表（默认是选择性的；你可以按表选择或全局启用）。
- 这些表上的索引。
- 与这些表关联的 TOAST 表。
- 与这些表关联的序列。
- WAL 流（可以单独启用，这是较新的补充）。
对于威胁模型来说，这是正确的加密集合。但它也明确地不是全部的加密集合，并且这些缺口很重要。
pg_tde 不加密什么
这部分需要仔细阅读。
系统目录未被加密。 包括 pg_class、pg_attribute、pg_proc 等等。如果攻击者可以读取你的数据目录但无法获得主密钥，他们仍然可以看到你的表和列名称、函数定义、视图定义以及统计信息。对于大多数合规框架来说，这是可以接受的------框架关心的是行级数据------但如果你的模式包含敏感信息（例如，你有一个名为 oncology_patient_outcomes_q3 的表），这些信息会以明文形式存在于磁盘上。
临时文件未被加密。 超过 work_mem 的查询会溢出到磁盘。如果你的工作负载包含大型排序、大型哈希连接或大型 CTE，你将定期生成包含与加密堆相同数据的磁盘临时文件。在崩溃后，这些文件可能会持久存在。这是一个真正的缺口。
不支持 pg_upgrade。 这是最大的操作警告。如果你使用 pg_tde 加密了一个 14 版本的集群，并尝试 pg_upgrade 到 18 版本，你将损坏目标集群中的加密元数据。支持的升级路径是逻辑复制或 pg_dump/pg_restore，对于大型数据库来说，这两者都比 pg_upgrade --link 昂贵得多。在计算总拥有成本时请考虑这一点。
逻辑复制不保留加密状态。 加密表的逻辑副本在订阅端不会被加密，除非你单独配置该端。因此，基于复制的灾难恢复需要在两端都配置 pg_tde。
无法就地更新 KMS 配置。 如果你的主密钥提供者需要更改------Vault 换到 KMIP、地址更改等等------目前没有一个干净的迁移路径。
"你需要它吗？"这个问题
对于大多数 PostgreSQL 工作负载，诚实的答案是不需要。文件系统级加密------Linux 上的 LUKS、Windows 上的 BitLocker、AWS 上的加密 EBS 卷------覆盖了相同的威胁模型，操作机制更简单，并且没有数据库级别的开销。如果你的合规表格上有一个写着"静态数据已加密"的复选框，文件系统加密几乎对所有审计员来说都满足要求。
pg_tde 是正确工具，而不是文件系统加密的情况，比营销宣传的要窄：
- 你有一个监管或合同要求，规定数据库本身必须进行静态加密------一些金融和医疗保健框架是这样措辞要求的，而"文件系统对其进行了加密"不被接受为合规。特别是 PCI-DSS 中的某些措辞，一些审计员会严格解释。
- 你需要按表或按数据库的加密粒度------例如，在一个多租户系统中，一些租户拥有使用专用加密密钥的合同权利，而其他租户则没有。文件系统加密是全有或全无；pg_tde 是选择性的。
- 你需要加密密钥与操作系统不在同一个信任域中------即，操作系统 root 用户可以读取数据目录，但加密密钥位于 Vault 中，背后有单独的身份验证边界。这是 TDE 相对于文件系统加密最站得住脚的论点，也是对于具有对抗性操作系统级威胁模型的团队最重要的论点。
如果以上三种情况都不适用，为了你自己好，省掉操作开销，使用文件系统加密。
如果其中一种情况适用，那么 pg_tde 现在是一个可行的开源选择，这是格局中一个有意义的改变。专有的 TDE 产品仍然更完善，与各自供应商生态系统的集成更好，并且仍然附带一个你可以在凌晨 2 点拨打的电话号码。但是，你现在可以在不依赖供应商的情况下拥有 TDE，对于相当多的组织来说，这正是他们想要的权衡。
建议
不要因为你读到了 pg_tde 并且听起来像是一种好做法就部署它。部署它，是因为你有一个文件系统加密无法满足的、明确的书面要求。
如果你确实要部署它：从你的操作手册中移除 pg_upgrade，为主版本升级预算逻辑复制，有意识地配置 KMS 并记录它，并审计你的 work_mem 溢出行为，因为临时文件是意外丢失加密保证的最简单途径。
如果你的审计员接受文件系统加密，那就接受这份礼物，然后继续处理下一个问题。