来源https://postgr.es/p/9kMPostgreSQL 的开源 TDEpg_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溢出行为因为临时文件是意外丢失加密保证的最简单途径。如果你的审计员接受文件系统加密那就接受这份礼物然后继续处理下一个问题。相关二十年两个 RCE自 2005 年以来 pgcrypto 一直在做什么pgcrypto 的二十年里面还有什么
DeepSeek总结的PostgreSQL 的开源 TDE：pg_tde
来源https://postgr.es/p/9kMPostgreSQL 的开源 TDEpg_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溢出行为因为临时文件是意外丢失加密保证的最简单途径。如果你的审计员接受文件系统加密那就接受这份礼物然后继续处理下一个问题。相关二十年两个 RCE自 2005 年以来 pgcrypto 一直在做什么pgcrypto 的二十年里面还有什么
