数据库加密的向量

使用现代企业数据库环境的Crunchy Data客户最需要的功能之一是某种形式的数据加密。然而，当人们说“我们需要加密我们的数据”时，准确地确定他们的意思往往是一个挑战，因为实际需求没有得到充分澄清甚至理解。因此，在任何人尝试实现数据库加密之前，了解需要加密的内容以及所采用的方法实际获得的好处至关重要。这篇博文不会讨论加密的任何深层技术实现。相反，让我们讨论一下任何给定的加密方法都会缓解哪些攻击向量，因为这将在您甚至还未达到任何开发或部署阶段之前极大地影响哪种方法是有效的。

将加密应用于数据库环境可以分为三种不同的方法：

1.静态数据

2.传输中的数据

3.正在使用的数据

静态数据

在谈到数据库时，静态数据可能是人们谈论最多、要求最多的加密方法之一，所以让我们先来谈谈这个方法。这种方法对哪些攻击向量有效？

• 令人担忧的攻击向量是当数据未被使用时

• 数据在不使用时必须始终保持加密

• 所有数据必须加密

• 对硬件的物理访问是一种可感知的威胁

这种加密方法什么时候无效？

• 令人担忧的攻击向量是一个完全受损的主机

• 关注的攻击向量不是物理访问

• 令人担忧的攻击向量是数据传输

基于上述陈述，静态数据加密的解决方案可以揭示其有效或无效的原因。最常见的解决方案是全磁盘加密，它完全独立于任何RDBMS或正在使用的应用程序。这可以在硬件或软件级别上完成，访问该数据的客户端通常在一开始就不知道该数据已加密，并且很少需要做任何事情来加密或解密数据。这也是为什么一个完全受损的主机，无论是存储数据的服务器还是访问该数据的客户端，都会完全破坏许多人首先想要的加密保护。
实现静态数据的另一种常见方法是透明数据加密（TDE）。与全磁盘加密类似，这在文件系统、硬件或数据库级别进行处理，而且客户端完全不知道正在使用加密。这与上面提到的全磁盘加密具有类似的优点和问题，但是，在一般文件系统级加密无法提供的情况下，数据库级的TDE可以提供一些额外的保护。根据正在使用的数据库级TDE，数据可能只能直接通过数据库获得，而不能从系统级获得。

从版本14开始，PostgreSQL的社区版本没有内置TDE，但目前正在为未来版本开发。TDE目前可通过脆硬的Postgres获得。
如果你主要担心的是有人走进你的办公室或数据中心，然后带着你的硬盘或服务器离开，那么这种方法可以有效地解决这个问题。然而，静态数据加密还有其他问题，以及这些问题的解决方案，因此让我们继续讨论上面提到的其他两种方法。

传输中的数据

最容易实现的加密方法之一，但不幸的是，在讨论数据库加密时没有经常提到，就是在数据传输到数据库或从数据库传输出去时保护数据。这种方法什么时候有效？

• 令人担忧的攻击向量是传输过程中的数据可见性

• 令人担忧的攻击向量是局部网络危害

• 令人担忧的攻击向量是互联网上的数据传输

这种方法什么时候无效？

• 令人担忧的攻击向量是一个完全受损的主机

• 令人担忧的攻击向量是物理访问

• 令人担忧的攻击向量是存储中的数据可见性

注：当传输中的数据是唯一的加密方法时，这些向量无效。当与静态数据或使用中的数据解决方案相结合时，可以解决存储中的物理访问和数据可见性问题。

传输数据的最常见解决方案是使用TLS证书管理来保护您的网络流量。谢天谢地，包括PostgreSQL在内的几乎所有现代数据库服务器和客户端都有实现该证书管理的方法。

正在使用的数据

最后一种方法通常不是经常提到的方法，但实际上是在大多数情况下保护数据的最有效方法。

• 令人担忧的攻击向量是数据库内的数据可见性

• 对未加密数据的访问是基于权限的

• 应用程序控制加密/解密过程

• 只有特定项目需要加密（例如每列）

• 可以同时解决静态数据和传输中的数据问题

在以下情况下，它仍然可能无效：

• 令人担忧的攻击向量是一个完全受损的客户端主机

• 令人担忧的攻击向量是对应用服务器的物理访问

使用中的数据加密最好在应用层进行处理，因为在任何时候，私钥都不会出现在数据库系统的任何位置。最常见的方法是某种保险库凭证系统，应用程序在需要数据时请求访问解密密钥。然后，数据在应用服务器或数据库和客户端之间的某个服务器上解密。
这可以完全缓解静态数据加密的最大漏洞之一，因为这种加密方法的本质要求数据库服务器上的某个位置存在私钥或密码，以允许对该数据进行透明解密。虽然内存中的攻击很少见，也很困难，但它们仍然有可能发生。因此，如果该攻击向量是一个问题，那么如果数据从未在数据库服务器本身上解密，则可以完全消除该攻击向量。因此，它还解决了许多静态数据问题。虽然从技术上讲，就数据本身而言，它可以解决许多传输中的数据问题，但最好还是实施某种端到端的TLS解决方案，尤其是当数据在互联网上传输时。

使用中的数据加密的主要问题是客户端或应用程序服务器的安全隐患。然而，这些问题仍然与静态数据和传输中的数据有关。因此，解决这个问题通常不在解决加密本身的实际过程的范围内。

虽然使用中的数据解决方案可能需要更多的规划和开发时间来实施，但如果数据的安全性至关重要，那么这是迄今为止保持数据安全的最有效方法之一。

备份

最后，数据库加密经常被忽略的另一个地方是备份。以上三种方法也需要在备份中解决。

• 静态数据

• 文件系统备份可以备份文件的未加密版本

• 独立于静态数据系统加密备份

• PGbackback支持S3/Azure/GCS客户端加密

• 传输中的数据

• 使用ssh传输备份和存档的WAL文件

• 正在使用的数据

数据库服务器的文件系统备份通常不应破坏这种加密方法，因为数据本身永远不会在数据库服务器上解密。

如果逻辑备份使用解密系统转储数据的未加密版本，则可能会备份未加密的数据。

结论

对于实际实现这些不同的加密方法，有许多不同的解决方案。云、Kubernetes或VM上的松脆数据产品都在静止和传输过程中提供加密。我们还提供具有透明数据加密（TDE）的脆硬Postgre。

我们希望这篇关于数据库加密方法的概述能够帮助您规划哪些解决方案最适合您的环境，并实际提供您希望实现的安全性。

原文标题：The Vectors of Database Encryption
原文作者：Keith Fiske
原文链接：https://www.crunchydata.com/blog/the-vectors-of-database-encryption