正如Ibrar Ahmed在他关于透明数据库加密（TDE）的博客文章中指出的那样。PostgreSQL在提供透明数据库加密方面是一个令人惊讶的异常值。相反，PostgreSQL开发人员似乎认为加密是一个存储级问题，最好在文件系统或块设备级别解决。我不同意这种观点，根据我去年年底进行的一项民意调查，许多PostgreSQL社区成员也不这么认为。
PostgreSQL需要TDE（透明数据加密）吗？#postgres#security
在数据库内实现的 TDE 至关重要有两个原因：技术原因和非技术原因。在我看来，工程师倾向于关注技术方面，而停留在“技术解决方案存在”上，而在实践中，真正重要的是组织是否能够实施所提供的解决方案。这就是组织问题（尤其是政治）发挥重要作用的地方，尤其是在大型组织中。
例如，实际上只有一小部分可以迁移到PostgreSQL的Oracle（和其他遗留数据库）工作负载被迁移，即使它提供了大量的成本节约和额外的好处，这一切都是因为组织的阻力。
但首先，加密的需求真正来自哪里？在高层次上，其中一些来自了解未加密敏感数据不是一个好主意的技术人员。然而，该行业越来越不依赖于具有常识的工程师，而是依赖于公司需要遵守的既定标准（HIPAA，PCI DSS，SOC 2，ISO 27001）等。
合规性要求通常以相当笼统的术语编写，由合规性团队（和合规性审计团队）将这些要求转换为技术要求，其中许多要求更喜欢（甚至需要）TDE。
透明数据库加密的技术原因
与存储级加密相比，数据库端加密具有多种优势，包括：
- 它在数据库对象的加密（加密的内容、未加密的内容以及使用什么密钥）方面提供了更大的灵活性和粒度。
- 如果复制数据库文件或以其他方式以原始形式公开，则不会公开。例如，存储在开放 S3 存储桶中的物理备份是相对常见的暴露向量。
- 它不需要存储级别的加密功能来提供数据安全性。
- 它增加了深度防御。即使存在存储级别加密，使用 TDE 和存储级别加密也能提供额外的安全层。
TDE 的组织（非技术）原因
即使您找到了一种方法来处理您希望在数据库引擎 （TDE） 中进行加密的所有技术原因，您在选择此路径的组织中也可能面临额外的摩擦。这可能是安全/合规团队的挑战（如上所述），或者需要与负责存储的团队进行额外的协调，以确保正确加密原始数据和所有副本（包括备份）。
虽然这些对于初创公司和小公司来说看起来微不足道，因为所有这些都是单人或联系良好的团队，但您可能会惊讶于这些东西在一些大型组织中的昂贵程度！
云中的加密数据库即服务 （DBaaS） 空间
您可能会争辩说，存储级加密对于云供应商来说似乎已经足够好了。例如，AWS在RDS中提供加密，这对大多数客户来说似乎已经足够了！但是，RDS 环境中的情况大不相同;这是一个相当有限的环境，其中许多技术和组织方面都得到了照顾。例如，如果您创建了一个加密实例，则备份也将自动加密，从而消除了“错误”的可能性。
PostgreSQL 中的 TDE 状态
有趣的是，在PostgreSQL中实现透明数据库加密的挑战不仅是技术上的，而且是组织上的。在我的记忆中，已经有几种实现被包含在PostgreSQL中，但没有一个通过。Cybertec加密补丁存在了很多年，几年前NTT也提交了工作。Highgo似乎也曾在TDE上工作过，其他年份在PgCon上也有过这样的演讲。但是，没有发生的是将功能合并到PostgreSQL Core中。
你可能会说PostgreSQL Core在设计上是保守的，这就是PostgreSQL如此稳定的产品的原因。不过，我认为，人们需要在创新和稳定之间保持平衡;过多地向一侧转移可能会危及项目的长期未来。
注意，我不认为在PostgreSQL Core中包含完整的TDE支持是正确的想法;可能在这个阶段，我们需要通过几个想法和几个实现的竞争来实现创新。PostgreSQL Core可能从可插拔存储接口中受益匪浅，因为它不仅可以实现加密，还可以将数据存储在本地安装的POSIX文件系统以外的其他地方，例如Neon正在做的事情。
超越 PostgreSQL 中的透明数据库加密
虽然我相信PostgreSQL中的透明数据库加密很重要，但我认为这只是一个更大问题的例证。PostgreSQL中的技术治理是为了在未来取得最大的成功，还是更多的是坚持帮助PostgreSQL达到当前成功水平的方法？对于这样一个规模和影响力的项目，用户对PostgreSQL治理的影响似乎出奇地小。PostgreSQL核心团队由“七个具有不同专业的长期社区成员”组成，而不是像许多其他开源组织那样拥有明确的可选举职位。PostgreSQL中的开发过程基于邮件列表，而不是更现代和有组织的问题跟踪和基于拉取请求的开发工作流程。对PostgreSQL错误感兴趣？没有错误数据库可以让您以用户友好的方式轻松查看确认了哪个错误以及修复了哪个版本。相反，您需要挖掘错误邮件列表。
不要误会我的意思，PostgreSQL是一个很棒的数据库，它理所当然地成为年度数据库，而不是任何其他数据库。然而，我相信有一些机会使PostgreSQL更加“面向未来”，并在未来取得更大的成功。
Percona Distribution for PostgreSQL 在单个发行版中提供了来自开源社区的最佳和最关键的企业组件，经过设计和测试以协同工作。
