功能
Overview
在此页面上，您可以了解 Queryable Encryption 的安全优势、其工作原理以及它与 MongoDB 支持的其他安全机制的比较。您还可以查看一个虚构的场景，该场景演示了 Queryable Encryption 在保护数据方面的价值。
可查询加密
Queryable Encryption 使客户端应用程序能够在通过网络传输数据之前使用完全随机的加密方式对数据进行加密，同时保持数据的可查询性。敏感数据由客户端透明地加密和解密，并且仅以加密形式与服务器进行通信。
与可以使用确定性加密的客户端字段级加密不同，可查询加密使用基于结构化加密的快速、可搜索加密方案。即使给定相同的明文输入，这些方案也会生成不同的加密输出值。
可查询加密的工作原理
下图展示了如何在客户环境中使用 Queryable Encryption 的流程和架构。
在该图中，用户能够查询完全随机加密的数据，例如 SSN 号码。
在 Queryable Encryption 中，实现这一查询的流程和机制如下：
当应用程序提交查询时，MongoDB 驱动程序首先分析该查询。
驱动程序识别查询是针对加密字段的，并从客户预配的密钥提供商请求加密密钥，例如：
AWS Key Management Service (AWS KMS)
Google Cloud KMS
Azure Key Vault
任何符合 KMIP 协议的密钥提供程序
驱动程序将查询提交到 MongoDB 服务器，并将加密字段呈现为密文。
“可查询加密”实现了一种可查询的快速方案，允许服务器在对数据一无所知的情况下处理对完全加密数据的查询。数据和查询本身在服务器上保持加密。
MongoDB Server 将查询的加密结果返回给驱动程序。
查询结果首先使用驱动程序持有的密钥进行解密，然后以明文形式返回给客户端并展示。
Queryable Encryption 在以下数据结构的帮助下发挥作用。至关重要的是，这些内容不能被修改或删除，否则查询结果将不正确。
可查询加密功能将
__safeContent__字段添加到任意集合中具有可查询加密功能的加密字段的文档。Queryable Encryption 在与具有 Queryable Encryption 加密字段的集合相同的数据库中创建两个内部元数据集合。这些名称如下：
enxcol_.<collectionName>.escenxcol_.<collectionName>.ecoc
警告
请勿修改这些数据结构，否则查询结果将不正确，并可能影响安全性。
Queryable Encryption 可在以下场景中确保加密字段的安全：
数据库超级用户直接访问加密字段
通过读取服务器内存来访问加密字段
通过不安全的网络捕获加密字段
通过读取数据库或备份文件访问磁盘加密字段
通过识别具有加密字段的文档中的模式进行频率分析攻击
虽然所有客户端都能访问非敏感数据字段，但只有经过适当配置的可查询加密客户端才能使用加密数据字段运行读写查询。
重要
远程密钥管理系统
在生产中使用 Queryable Encryption 时，必须使用远程密钥管理系统 (KMS) 来存储加密密钥。
要查看分步指南，了解如何使用带有 Queryable Encryption 的远程 KMS，请参阅教程。
要查看所有受支持的 KMS 提供商的列表，请参阅 KMS 提供商。
要详细了解为什么要使用远程 KMS，请参阅使用远程密钥管理系统的理由。
其他安全机制
本节介绍 MongoDB 支持的以下安全机制，并解释其使用案例和局限性：
基于角色的访问控制
基于角色的访问控制是一种安全机制，允许管理员授予和限制用户的集合级别权限。通过适当的角色定义和分配，此解决方案可防止意外泄露数据和访问。
基于角色的访问控制无法针对以下情况提供防护：
通过不安全的网络捕获数据
通过读取数据库或备份文件访问磁盘数据
通过读取服务器内存来访问数据
数据库超级用户直接访问数据
要了解更多信息，请参阅基于角色的访问控制。
静态加密
静态加密是一种对磁盘上的数据库文件进行加密的机制。此机制可防止缺少数据库凭据但有权访问托管数据库的计算机的人员查看您的数据。
该机制无法在以下情况下保护您的数据：
通过不安全的网络捕获数据
通过读取服务器内存来访问数据
数据库超级用户直接访问数据
要了解详情，请参阅静态加密。
传输加密 (TLS/SSL)
使用 TLS/SSL 的传输加密会加密您通过网络的数据。TLS/SSL 在数据通过不安全的网络传输时保护数据，但无法保护数据免受特权用户侵害或保护磁盘上的数据。
若要了解详情，请参阅使用 TLS/SSL 进行传输加密
功能对比
如要了解有关客户端字段级加密的更多信息，请参阅客户端字段级加密功能。
下表描述了潜在的安全威胁以及MongoDB加密功能如何解决这些威胁。 同时使用这些机制：基于角色的访问控制、静态加密、传输加密和正在使用的加密。 请注意，您不能在同一集合中同时使用客户端字段级加密和可查询Queryable Encryption。
重要
这是用于一般比较的高级摘要。 有关详细信息，请参阅 Queryable Encryption概述 无状态文档数据库加密方案的设计与分析 白皮书。
威胁 | TLS/SSL 传输加密 | 静态加密 (EaR) | Queryable Encryption （相等）+ TLS/SSL + EaR | CSFLE + TLS/SSL + EaR |
|---|---|---|---|---|
网络侦听（攻击者可以访问权限网络流量） | 显示操作元数据 | 显示操作元数据 | 显示操作元数据 | 显示操作元数据 |
从磁盘恢复数据库（攻击者具有物理磁盘访问权限） | 显示数据库 | 显示数据库和操作元数据的大小 | 显示数据库和操作元数据的大小 | 显示数据库和操作元数据的大小 |
显示数据库 | 显示数据库 | 显示数据库和操作元数据的大小 | 显示值和操作元数据的频率 | |
高级持续性威胁（攻击者长期持续访问权限网络、磁盘和内存，而不被发现） | 显示数据库 | 显示数据库 |
| [1] | 假设泄露发生在已完成的操作之间。 请参阅 白皮书 了解详细信息。 |
警告
可查询Queryable Encryption可防止数据泄露，但不能防止对环境具有持久访问权限的攻击者，或者可以检索数据库快照和附带的查询脚本/日志的攻击者。
使用Queryable Encryption时，相等和范围查询可针对使用数据库快照的攻击者提供类似的安全性。 但是，同时访问权限数据库快照和查询信息的攻击者超出了 Queryable Encryption 的安全ACID 一致性保证范围。 对于范围查询来说尤其如此，即使只检索到少量的查询副本或日志。6.1有关详细信息，请参阅概述白皮书中的 ：持久模型中的范围查询。
Scenario
以下虚构场景演示了 Queryable Encryption 在保护应用程序数据方面的价值，以及 Queryable Encryption 如何与本指南中讨论的其他安全机制交互。
在这种情况下，我们要确保医疗保健管理系统中敏感数据的安全，该系统为一家虚构公司 MedcoMD 存储的患者个人信息、账单信息和医疗记录。所有患者数据都不是公开的，其社会安全号码（SSN，美国政府颁发的 ID）、患者 ID、账单信息和药物信息等特定数据特别敏感，需要遵守隐私要求。对于公司和患者来说，保持数据的私密性和安全性非常重要。
MedcoMD 需要该系统来满足以下使用案例：
医生使用该系统查看患者的医疗记录、账单并更新药物信息。
导医使用该系统，通过患者的联系信息来验证其身份。
导医可以查看患者的帐单信息，但不能查看其患者 ID 号。
导医无法访问患者的病历。
MedcoMD 还关注通过以下任何一种方法披露敏感数据：
在导医的可公开查看的屏幕上意外泄露数据。
由超级用户（如数据库管理员）直接访问数据库。
通过不安全的网络捕获数据。
通过读取数据库服务器的内存来访问数据。
通过读取数据库或备份文件来访问数据。
MedcoMD 可以做些什么来平衡其医疗保健管理系统的功能和访问限制？
解决方案
MedcoMD 使用以下安全机制来满足其用例，并防止敏感医疗数据泄露：
传输加密 (TLS/SSL)，确保数据在网络上传输时的安全。
静态加密，防止通过读取数据库或备份文件泄露数据。
基于角色的访问控制，将数据库用户访问权限限制在执行任务所需的集合范围内。
使用 Queryable Encryption 对敏感字段进行加密以满足以下用例和约束：
防止从服务器内存读取数据，因为 Queryable Encryption 加密的数据永远不会以未加密的形式出现在数据库服务器上。
向接待员提供未启用 Queryable Encryption 的客户端，从而允许接待员验证患者的身份，防止在接待员的可公开查看的屏幕上意外泄露敏感数据。
为医生提供支持 Queryable Encryption 的客户端，从而允许医生在办公室私下查看敏感数据。
了解详情
要查看为保护 MongoDB 部署而应实施的安全措施列表，请参阅安全清单。
要开始使用 Queryable Encryption，请参阅快速入门。