MongoDB 6.0引入了一个预览功能，它实现了一个近乎神奇的功能，即允许将加密数据用作搜索目标，而无需将密钥传输到数据库。

出于可以理解的原因，可查询加密是MongoDB World 2022的主要吸引力。它引入了一种独特的功能，可在多种使用情况下减少机密数据的攻击面。特别是，数据在插入、存储和查询时保持加密。查询和它们的响应都通过导线加密，并随机化以进行频率分析。

其结果是，应用程序可以支持需要搜索分类数据的用例，而不会在数据存储基础设施中以明文形式公开。出于显而易见的原因，持有私人信息的数据存储是黑客的主要目标。MongoDB的加密字段意味着该信息在数据库中始终是加密安全的，但仍可用于搜索。事实上，数据库根本不保存用于解密数据的密钥。这意味着，即使完全破坏数据库服务器也不会导致私人信息的丢失。

消除了几个突出和复杂的攻击向量。例如：

• 不道德或被黑客入侵的数据库管理员帐户。
• 访问磁盘文件。
• 访问内存数据。

这有点像散列密码。出于同样的原因，我们在数据库中散列密码，因此黑客甚至数据库管理员都无法查看密码。当然，最大的区别在于，散列密码是单向的。您可以验证密码是否正确，但仅此而已。无法查询这样的字段，也无法恢复明文。可查询加密保留了处理字段的能力。

该系统另一个有趣的特点是，字段以随机方式加密，因此相同的值将在不同的运行中输出不同的密文。这意味着系统也能抵抗频率分析攻击。该系统通过控制哪些客户端有权访问密钥，允许严格区分对搜索结果具有查看权限的客户端和没有查看权限的客户。

例如，应用程序可能存储机密信息，如信用卡号，以及不太敏感的信息，如用户名。非特权客户端可以通过不为客户端提供加密密钥，以严格的方式查看用户名，而不是信用卡。有权访问密钥的客户端可以在搜索中查看和使用信用卡，同时在发送、搜索、存储和检索信用卡的步骤中对卡号进行加密。

可查询加密的权衡

当然，所有这些都是有代价的。具体而言，对于涉及加密字段的查询，存在空间和时间要求的成本。（MongoDB指南对加密数据的额外存储要求约为2-3倍，但预计未来会下降）。

查询加密数据是由MongoDB处理的，它将元数据合并到加密集合本身，以及带有其他元数据的单独集合中。这说明了使用这些数据集以及实际加密和解密工作时存储和时间需求的增加。

此外，还存在必须以密钥管理服务（KMS）的形式支持的体系结构复杂性，以及使用它的编码开销以及加密和解密工作本身。

可查询加密的工作原理

在最高级别，它类似于图1。

Figure 1. High-level architecture of queryable encryption

图1说明了系统添加了一个架构组件：KMS。典型事件流的另一个变化是，数据和查询通过MongoDB驱动程序进行加密和解密。KMS提供了该过程的密钥。

自动和手动加密

可查询加密有两种基本模式：自动和手动。在自动模式下，MongoDB驱动程序本身处理加密和解密。在手动中，应用程序开发人员使用KMS中的密钥进行更多的实践工作。

密钥类型：客户主密钥（CMK）和数据加密密钥（DEK）

在可查询加密系统中，有两种类型的密钥：客户主密钥（CMK）和数据加密密钥（DEK）。DEK是用于加密数据的实际工作密钥。CMK用于加密DEK。这提供了额外的安全性。客户端应用程序本身可以仅通过首先使用CMK对DEK进行解密来使用DEK（以及用它加密的数据）。

因此，即使DEK以其加密形式公开，如果攻击者无法访问CMK，它也是无用的。该架构可以被安排为使得客户端应用程序从不持有CMK本身，如下面使用密钥管理服务所述。底线是，双密钥安排是私钥的额外安全层。

数据加密密钥（DEK）存储在额外密钥库集合中，如下所述。

钥匙保管库

数据使用对称密钥加密。这些密钥属于应用程序开发人员，永远不会发送到MongoDB。它们存储在钥匙库中。管理密钥有三种基本场景，按安全性升序如下所述。

本地文件密钥提供程序。

• 仅适用于开发。
• 密钥与应用程序一起存储在本地系统中

KMIP（密钥管理互操作性协议）提供程序。

• 适用于生产，但安全性不如使用KMS提供商。
• 客户主密钥（CMK）被传输到客户端应用程序

完整的KMS（密钥管理服务）提供者。适合生产

• 支持的云KM包括：AWS、Azure和GCP
• 支持本地HSM（硬件安全模块）和KMS
• 只有数据加密密钥传输到客户端应用程序

用于开发的本地密钥提供者

在开发时，应用程序开发人员可以生成密钥（例如，使用OpenSSL）并将其存储在本地。然后，这些密钥用于加密和解密发送到MongoDB实例的信息。这仅用于开发，因为它在密钥中引入了一个主要漏洞，从而降低了可查询加密的许多优势。

KMIP提供商

有许多KMIP实现（包括开源）和商业服务。在这种情况下，CMK存储在KMIP提供程序中，并在需要加密或解密DEK以供使用时传输到客户端应用程序。如果密钥库集合被破坏，数据将保持安全。这种布置如图2所示。

Figure 2. KMIP architecture outline

KMS提供商

通过使用KMS提供商（如AWS、Azure或GCP），客户主密钥永远不会暴露给网络或客户端应用程序。相反，KMS提供加密DEK的服务。DEK本身被发送到KMS，加密后作为密码文本返回，然后存储在MongoDB中的一个特殊密钥库集合中。

然后可以以类似的方式用KMS检索和解密存储的DEK，再次防止CMK本身的暴露。与KMIP一样，如果密钥库集合被破坏，数据将保持安全。

您可以在图3中看到这个布局。

Figure 3. KMS Architecture outline

结论

可查询加密是一种预览功能，目前仅支持相等查询。路线图上还有更多的查询类型，如范围。

尽管它需要额外的设置，可查询加密为需要搜索机密数据的用例提供了一个关键功能，而这是以任何其他方式都无法实现的。这是一种引人注目的独特能力。

有关加密的更多信息：

• 4 hot areas for encryption innovation
• 5 myths about data encryption
• The race for quantum-proof cryptography

Next read this

• The 10 most powerful cybersecurity companies
• 7 hot cybersecurity trends (and 2 going cold)
• The Apache Log4j vulnerabilities: A timeline
• Using the NIST Cybersecurity Framework to address organizational risk
• 11 penetration testing tools the pros use

本文：