功能
Overview
在此页面上，您可以了解 Queryable Encryption 的安全优势、其工作原理以及它与 MongoDB 支持的其他安全机制的比较。您还可以查看一个虚构的场景，该场景演示了 Queryable Encryption 在保护数据方面的价值。
可查询加密
Queryable Encryption 使客户端应用程序能够在通过网络传输数据之前使用完全随机的加密方式对数据进行加密，同时保持数据的可查询性。敏感数据由客户端透明地加密和解密，并且仅以加密形式与服务器进行通信。
与可以使用确定性加密的客户端字段级加密不同，可查询加密使用基于结构化加密的快速、可搜索加密方案。即使给定相同的明文输入，这些方案也会生成不同的加密输出值。
安全考虑因素
Queryable Encryption 不提供任何加密完整性保证，以防止对手访问客户主密钥或数据加密密钥。
可查询加密不提供任何加密完整性保证，以防止对手任意写入包含加密数据的集合。
MongoDB 使用模式验证来实施集合中特定字段的加密。如果没有客户端模式，客户端将下载集合的服务器端模式来确定要加密哪些字段。如要避免此问题，请使用客户端模式验证。
由于 Queryable Encryption 未提供验证模式完整性的机制，因此依赖服务器端模式意味着信任服务器的模式未被篡改。如果攻击者破坏了服务器，他们可以修改模式，让以前加密的字段不再标记为加密。这会导致客户端发送该字段的纯文本值。
有关客户端和服务器端模式配置的示例，请参阅 CSFLE 服务器端字段级加密实施中的 CSFLE 示例。
可查询加密的工作原理
下图展示了如何在客户环境中使用 Queryable Encryption 的流程和架构。
在该图中，用户能够查询完全随机加密的数据，例如 SSN 号码。
在 Queryable Encryption 中，实现这一查询的流程和机制如下：
当应用程序提交查询时，MongoDB 驱动程序首先分析该查询。
驱动程序识别查询是针对加密字段的，并从客户预配的密钥提供商请求加密密钥，例如：
AWS Key Management Service (AWS KMS)
Google Cloud KMS
Azure Key Vault
任何符合 KMIP的提供商
驱动程序将查询提交到 MongoDB 服务器，并将加密字段呈现为密文。
“可查询加密”实现了一种可查询的快速方案，允许服务器在对数据一无所知的情况下处理对完全加密数据的查询。数据和查询本身在服务器上保持加密。
MongoDB Server 将查询的加密结果返回给驱动程序。
查询结果首先使用驱动程序持有的密钥进行解密，然后以明文形式返回给客户端并展示。
Queryable Encryption 在以下数据结构的帮助下发挥作用。至关重要的是，这些内容不能被修改或删除，否则查询结果将不正确。
Queryable Encryption 会将
__safeContent__字段添加到任何具有 Queryable Encryption 加密字段的collection中的文档。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 支持的安全功能及其解决的潜在安全漏洞：
重要
同时使用这些机制
若要确保生产部署，请同时使用基于角色的访问控制、静态加密、传输加密和可选的正在使用的加密安全机制。请注意，不可同时使用客户端字段级加密和可查询加密来加密同一集合中的不同字段。
如要了解有关客户端字段级加密的更多信息，请参阅客户端字段级加密功能。
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，请参阅快速入门。