原文地址：
https://www.percona.com/blog/transparent-data-encryption-for-postgresql-release-candidate-is-here/
毫无疑问，PostgreSQL 是世界上最受欢迎的开源数据库之一。
https://db-engines.com/en/ranking
为什么？原因有很多，但如果只能选一个，我会说是可扩展性。PostgreSQL 不仅仅是一个数据库；它是一个扩展生态系统，可以对其进行转型以应对任何即将到来的挑战。通过让开发人员无需付费即可扩展数据库功能，PostgreSQL 不仅保持了相关性，而且凭借不断增长的数千个扩展的生态系统蓬勃发展。但是，能力越大，责任越大（是的，本叔叔，我说过），而 PostgreSQL 一直落后于其他现代数据库的一个领域就是静态数据加密……直到现在。
https://www.percona.com/blog/open-source-postgresql-pg-tde-beta/
合规时代
虽然最近人工智能、数据隐私法以及机器学习的伦理使用备受关注，但传统的数据安全法规却丝毫未减。事实上，它们正随着科技进步而不断发展。感觉每周都有新的法规、安全框架或其他合规性要求需要勾选，而要时刻关注每一次变化可能会让人不知所措。
多年来，许多数据库专业人士一直在争论透明数据加密 (TDE) 是否多余，声称静态加密要求可以在存储层满足。尽管数据库专业人士仍在讨论 TDE 的必要性，但受现代数据保护期望的驱动，企业一直在朝着更安全的方向发展。监管标准日益严格，一些案例明确指出，单靠存储加密是不够的。一个典型的例子是 PCI DSS 4.0，它规定主账号 (PAN) 必须在数据库内部加密；这意味着单靠存储或磁盘级加密已不再足够。PCI DSS 只是众多不断发展的法规之一，这些法规明确推动更强大的数据库加密。
应用程序级加密
如果存储级加密不够用，那么应用级加密呢？理论上，这是最安全的方法，因为它强制执行严格的访问控制，符合零信任原则，并确保只有授权的应用程序（和用户）才能解密敏感数据。然而，在实践中，应用级加密通常过于昂贵、复杂，对许多组织（尤其是依赖遗留系统的组织）来说根本不可行。
许多大型企业仍在使用数十年历史的应用程序，这些应用程序在设计时并未考虑加密功能。对其进行改造以支持应用层加密需要进行大量的代码修改、基础设施革新以及新的密钥管理策略。对于许多企业而言，由于成本、时间和技术负担等原因，这种程度的转型并非可行之举。
标记化
另一种潜在的方法是标记化，即将敏感数据替换为非敏感占位符。虽然这可能是一种强大的合规性解决方案，但它通常需要专有的第三方软件和重大的应用程序级更改。此外，它还带来了新的挑战，例如管理标记化性能以及如何确保与现有业务流程的无缝集成。如果说应用程序级加密通常因其产生的成本而无法实施，那么对于许多仍然需要安全性的解决方案来说，标记化通常成本过高且具有破坏性，难以大规模实施。
透明数据加密
这就引出了透明数据加密 (TDE)。TDE 在安全性和实用性之间实现了务实的平衡。它在数据库级别加密数据，防止未经授权的访问，同时对应用程序保持完全透明。无需代码更改，无需架构改造，只需在数据存储位置进行安全保护。
由于合规性越来越严格，加上遗留限制导致许多人无法采用应用层加密或标记化，TDE 不再只是一种“可有可无”的功能，而成为一种必需品。
最后，我们考虑以下选择：
标记化——很好，但需要新的软件（通常是专有的）和应用程序级别的更改。
应用程序级加密——超级安全，但价格昂贵且复杂。并非所有人都愿意重写整个应用程序。
透明数据加密 (TDE) – 最简单的方法，数据库无缝处理加密而无需更改应用程序。
从我们的角度来看，最佳、最具成本效益且易于实施的解决方案是 TDE。
透明数据加密 (TDE) 的候选版本 (RC)
我们很高兴地宣布，随着Percona Distribution for PostgreSQL 17.4.1-1 的发布，我们已经发布了TDE 的候选版本 (RC) ！https://docs.percona.com/postgresql/17/release-notes-v17.4.html
即将投入生产的正式版 (GA) 即将发布，但实现这一目标并非易事。我们的开源 TDE 之旅充满了实验、迭代和重新设计：
tde_heap_basic
WAL加密
使用 tde_heap 重新设计表加密
随着 RC 版本的发布，我们正式弃用 tde_heap_basic 。GA 版本将完全依赖tde_heap 。
我们的第一次尝试，tde_heap_basic与未修改的 PostgreSQL 社区服务器一起工作，但也存在明显的缺点：
对移入和移出内存（而不是存储）的数据进行加密的性能成本。
索引未加密，因此它只是一个部分解决方案。
我们通过tde_heap解决了这些挑战， 这是一种新方法，它基于 PostgreSQL 本身的几个小补丁，与 PostgreSQL 的存储管理器 (SMGR) 和预写日志 (WAL) 集成。这些细微的改进使数据库更具可扩展性，同时确保了高效全面的加密。
SMGR 补丁基于 Neon 之前的成果，并针对更通用的用例（包括 TDE）进行了改进。我们已经将其提交给社区审核，如果您是 PostgreSQL 爱好者，请务必查看！https://commitfest.postgresql.org/patch/5616/
重新思考 WAL 加密
最初的 WAL 加密方法遇到了一些挑战，尤其是在复制和替换加密密钥方面。在对各种方案进行全面测试和评估后，我们实施了一些修改，这需要对代码进行大量的修改。
最新的 WAL 加密方法已作为技术预览版纳入 RC 版本，我们欢迎社区提出宝贵意见。由于 WAL 加密是一项可选功能，其改进不会影响 TDE 的正式发布。尽管如此，我们仍致力于及时交付可用于生产的 WAL 加密解决方案，确保其性能和可靠性。
pg_tde 有了新家
如果你一直关注我们到现在，那你肯定很感兴趣。所以，再来更新一下：pg_tde 迁移啦！
您现在可以在 Percona Server for PostgreSQL 仓库中找到它。由于tde_heap_basic即将消失，而tde_heap需要已打补丁的 PostgreSQL，我们不想单独托管它，以免造成混淆。
查看并在 GitHub 上为该项目点赞，并在新主页中查看我们的 TDE 解决方案
https://github.com/percona/postgres/tree/TDE_REL_17_STABLE/contrib/pg_tde
短期内会发生什么？
交付可用于生产的 TDE 解决方案版本
实现与市场上领先的安全解决方案的集成
提供故障排除材料和文档以确保更容易采用
如果您使用特定的 KMS 并希望将其集成，或者看到 TDE 当前无法适当解决的用例，请告知我们！
我们需要您的反馈！
只有社区参与，开源才能蓬勃发展。无论您是否投入了足够的精力读到这里，或者您只是滚动到文章底部查看结尾说明。无论如何，请帮助我们！
尝试 TDE并分享您的想法- 您的反馈将影响 最终产品。https://docs.percona.com/postgresql/17/postgresql-server.html
加入我们的社区论坛的讨论——更多声音=更好的解决方案。https://forums.percona.com/c/postgresql/pg-tde-transparent-data-encryption-tde/82
给我们一个GitHub 星标– 它可以帮助更多人发现该项目。https://github.com/percona/postgres/tree/TDE_REL_17_STABLE/contrib/pg_tde
在会议上与我们会面——我们喜欢与用户面对面交谈！
透明数据加密将彻底改变 PostgreSQL 的格局。我们对此里程碑感到兴奋不已，希望您也同样如此。现在，就去加密数据吧！
