Overview概述
On this page, you can learn about the security benefits of Queryable Encryption, how it works, and how it compares to other security mechanisms supported by MongoDB. You can also view a fictional scenario that demonstrates the value of Queryable Encryption in securing your data.在此页面上，您可以了解可查询加密的安全优势、工作原理以及与MongoDB支持的其他安全机制的比较。您还可以查看一个虚构的场景，演示可查询加密在保护数据方面的价值。
Queryable Encryption可查询加密
Queryable Encryption enables a client application to encrypt data before transporting it over the network using fully randomized encryption, while maintaining queryability. Sensitive data is transparently encrypted and decrypted by the client and only communicated to and from the server in encrypted form.可查询加密使客户端应用程序能够在使用完全随机化加密通过网络传输数据之前对其进行加密，同时保持可查询性。敏感数据由客户端透明地加密和解密，并且仅以加密形式与服务器通信。
Unlike Client-Side Field Level Encryption that can use Deterministic Encryption, Queryable Encryption uses fast, searchable encryption schemes based on structured encryption. These schemes produce different encrypted output values even when given the same cleartext input.与可以使用确定性加密的客户端字段级加密不同，可查询加密使用基于结构化加密的快速、可搜索的加密方案。即使给定相同的明文输入，这些方案也会产生不同的加密输出值。
How Queryable Encryption Works可查询加密的工作原理
The diagram below shows the process and architecture of how Queryable Encryption is used in a customer environment.下图显示了如何在客户环境中使用可查询加密的过程和架构。
In this diagram, the user is able to query on fully randomly encrypted data such as SSN number.在该图中，用户能够查询完全随机加密的数据，如SSN号。
The process and mechanisms that make this possible within Queryable Encryption are as follows:在可查询加密中实现这一点的过程和机制如下：
When the application submits the query, MongoDB drivers first analyze the query.当应用程序提交查询时，MongoDB驱动程序首先分析查询。The driver recognizes the query is against an encrypted field and requests the encryption keys from the customer-provisioned key provider such as:驱动程序识别出查询是针对加密字段的，并向客户提供的键提供商请求加密键，例如：AWS Key Management Service (AWS KMS)AWS键管理服务（AWS KMS）Google Cloud KMS谷歌云KMSAzure Key VaultAzure键库Any KMIP-compliant key provider任何符合KMIP标准的键提供商
The driver submits the query to the MongoDB server with the encrypted fields rendered as ciphertext.驱动程序将查询提交给MongoDB服务器，加密字段呈现为密文。Queryable Encryption implements a fast, searchable scheme that allows the server to process queries on fully encrypted data, without knowing anything about the data. The data and the query itself remain encrypted at all times on the server.可查询加密实现了一种快速、可搜索的方案，允许服务器在不知道任何数据的情况下处理对完全加密数据的查询。数据和查询本身在服务器上始终保持加密状态。The MongoDB server returns the encrypted results of the query to the driver.MongoDB服务器将查询的加密结果返回给驱动程序。The query results are decrypted with the keys held by the driver and returned to the client and shown as plaintext.查询结果用驱动程序持有的键解密，并返回给客户端，以明文形式显示。
Queryable Encryption functions with the help of the following data structures. It is critical that these are not modified or deleted, or query results will be incorrect.可查询加密功能借助以下数据结构。至关重要的是，不要修改或删除这些内容，否则查询结果将不正确。
Queryable Encryption adds a可查询加密为任何有可查询加密加密字段的集合中的文档添加__safeContent__field to documents in any collection where there's a Queryable Encryption encrypted field.__safeContent__字段。Queryable Encryption creates two internal metadata collections in the same database as the collection where there's a Queryable Encryption encrypted field. These are named as follows:可查询加密在同一个数据库中创建了两个内部元数据集合，该集合中有一个Queryable Encryptions加密字段。这些名称如下：enxcol_.<collectionName>.escenxcol_.<collectionName>.ecoc
Warning
Do not modify these data structures or query results will be incorrect and security could be impacted.不要修改这些数据结构，否则查询结果将不正确，安全性可能会受到影响。
Queryable Encryption keeps encrypted fields secure in the following scenarios:可查询加密可在以下情况下保护加密字段的安全：
Direct access to encrypted fields by a database superuser数据库超级用户直接访问加密字段Access to encrypted fields by reading the server's memory通过读取服务器内存访问加密字段Capture of encrypted fields over an insecure network在不安全的网络上捕获加密字段Access to on-disk encrypted fields by reading database or backup files通过读取数据库或备份文件访问磁盘上的加密字段Frequency analysis attacks by identifying patterns in documents with encrypted fields通过识别具有加密字段的文档中的模式进行频率分析攻击
While all clients have access to the non-sensitive data fields, only appropriately-configured Queryable Encryption clients are able to run read and write queries using the encrypted data fields.虽然所有客户端都可以访问非敏感数据字段，但只有经过适当配置的可查询加密客户端才能使用加密数据字段运行读写查询。
Important
Remote Key Management System远程键管理系统
When you use Queryable Encryption in production, you must use a remote Key Management System (KMS) to store your encryption key.当您在生产中使用可查询加密时，您必须使用远程键管理系统（KMS）来存储加密键。
To view a step-by-step guide demonstrating how to use a remote KMS with Queryable Encryption, see Queryable Encryption Tutorials.要查看演示如何使用具有可查询加密的远程KMS的分步指南，请参阅可查询加密教程。
To view a list of all supported KMS providers, see KMS Providers.要查看所有支持的KMS提供程序的列表，请参阅KMS提供程序。
To learn more about why you should use a remote KMS, see Reasons to Use a Remote Key Management System.要了解有关为什么应该使用远程KMS的更多信息，请参阅使用远程键管理系统的原因。
Other Security Mechanisms其他安全机制
This section describes the following security mechanisms supported by MongoDB and explains their use cases and limitations:本节描述了MongoDB支持的以下安全机制，并解释了它们的用例和限制：
Role-Based Access Control基于角色的访问控制Encryption at Rest静态加密Transport Encryption (TLS/SSL)传输加密（TLS/SSL）
Role-Based Access Control基于角色的访问控制
Role-Based Access Control is a security mechanism that allows administrators to grant and restrict collection-level permissions for users. With the appropriate role definition and assignment, this solution prevents accidental disclosure of data and access.基于角色的访问控制是一种安全机制，允许管理员授予和限制用户的集合级权限。通过适当的角色定义和分配，此解决方案可以防止数据和访问的意外泄露。
Role-Based Access control cannot protect against the following scenarios:基于角色的访问控制无法防止以下情况：
Capture of the data over an insecure network通过不安全的网络捕获数据Access to on-disk data by reading database or backup files通过读取数据库或备份文件访问磁盘上的数据Access to data by reading the server's memory通过读取服务器内存访问数据Direct access to data by a database superuser数据库超级用户直接访问数据
To learn more, see Role-Based Access Control.要了解更多信息，请参阅基于角色的访问控制。
Encryption at Rest静态加密
Encryption at Rest is a mechanism that encrypts database files on disk. This mechanism prevents a person who lacks database credentials, but has access to the computer hosting your database, from viewing your data.静态加密是一种对磁盘上的数据库文件进行加密的机制。此机制可防止缺乏数据库凭据但可以访问托管数据库的计算机的人查看数据。
This mechanism does not protect your data against the following scenarios:此机制无法保护数据免受以下情况的影响：
Capture of the data over an insecure network通过不安全的网络捕获数据Access to data by reading the server's memory通过读取服务器内存访问数据Direct access to data by a database superuser数据库超级用户直接访问数据
To learn more, see Encryption at Rest.要了解更多信息，请参阅静态加密。
Transport Encryption (TLS/SSL)传输加密（TLS/SSL）
Transport Encryption using TLS/SSL encrypts your data over the network. TLS/SSL protects your data as it travels over an insecure network, but cannot protect your data from a privileged user or as it sits on disk.使用TLS/SSL的传输加密通过网络加密数据。当数据在不安全的网络上传输时，TLS/SSL会保护数据，但无法保护数据免受权限用户或磁盘上的攻击。
To learn more, see Transport Encryption using TLS/SSL要了解更多信息，请参阅使用TLS/SSL的传输加密
Comparison of Features特征比较
To learn more about Client-Side Field Level Encryption, see Client-Side Field Level Encryption Features.要了解有关客户端字段级加密的更多信息，请参阅客户端字段级密码功能。
The following table describes potential security threats and how MongoDB encryption features address them. Use these mechanisms together: Role-Based Access Control, Encryption at Rest, Transport Encryption, and In-Use Encryption. Note that you can't use both Client-Side Field Level Encryption and Queryable Encryption in the same collection.下表描述了潜在的安全威胁以及MongoDB加密功能如何应对这些威胁。一起使用这些机制：基于角色的访问控制、静态加密、传输加密和使用中加密。请注意，您不能在同一集合中同时使用客户端字段级加密和可查询加密。
Important
This is a high-level summary meant for general comparison. For detailed information, see the Overview of Queryable Encryption and Design and Analysis of a Stateless Document Database Encryption Scheme whitepapers.这是一个用于一般比较的高级总结。有关详细信息，请参阅可查询加密概述和无状态文档数据库加密方案的设计和分析白皮书。
| Threat | CSFLE + TLS/SSL + EaR | |||
|---|---|---|---|---|
| Reveals | ||||
| Database exfiltration from Disk and Memory (attacker has physical disk access and multiple database snapshots) [1] | Reveals database | Reveals database | Reveals size of database and operation metadata | Reveals frequency of values and operation metadata |
| Advanced Persistent Threat (attacker has long-term, continuous access to network, disk, and memory while remaining undetected) | Reveals database | Reveals database | Queryable Encryption is not designed to protect against an ATP. See whitepaper for details. | CSFLE is not designed to protect against an ATP. See whitepaper for details. |
| [1] | This assumes exfiltration occurs between completed operations. See whitepaper for details. |
Warning
Queryable Encryption defends against data exfiltration, not against adversaries with persistent access to an environment, or those who can retrieve both database snapshots and accompanying query transcripts/logs.可查询加密可防止数据泄露，而不是针对对环境具有持久访问权限的对手，或者那些可以检索数据库快照和附带的查询记录/日志的对手。
When using Queryable Encryption, equality and range queries offer similar security against attackers with database snapshots. However, an attacker with access to both database snapshots and query information is beyond the scope of Queryable Encryption's security guarantees. 使用可查询加密时，相等和范围查询通过数据库快照提供了类似的安全性，可以抵御攻击者。但是，可以访问数据库快照和查询信息的攻击者超出了可查询加密的安全保证范围。This is especially true for range queries, even if only a small number of query transcripts or logs are retrieved. 对于范围查询尤其如此，即使只检索到少量的查询转录或日志。See 6.1: Range Queries in the Persistent Model in the overview whitepaper for details.有关详细信息，请参阅概述白皮书中的6.1:持久模型中的范围查询。
Scenario场景
The following fictional scenario demonstrates the value of Queryable Encryption in securing your application's data, and how Queryable Encryption interacts with the other security mechanism discussed in this guide.以下虚构场景演示了可查询加密在保护应用程序数据方面的价值，以及可查询加密如何与本指南中讨论的其他安全机制交互。
In this scenario, we secure sensitive data on a medical care management system that stores patients' personal information, billing information, and medical records for a fictional company, MedcoMD. None of the patient data is public, and specific data such as their social security number (SSN, a US government-issued ID number), patient ID number, billing information, and medication information are particularly sensitive and subject to privacy compliance. It is important for the company and the patient that the data is kept private and secure.在这种情况下，我们在医疗管理系统上保护敏感数据，该系统存储了虚构公司MedcoMD的患者个人信息、账单信息和医疗记录。所有患者数据都不是公开的，具体数据，如他们的社会保障号码（SSN，美国政府颁发的身份证号码）、患者身份证号码、账单信息和药物信息，都特别敏感，需要遵守隐私规定。对公司和患者来说，数据保密和安全非常重要。
MedcoMD needs this system to satisfy the following use cases:MedcoMD需要这个系统来满足以下用例：
Doctors use the system to access patients' medical records, billing information, and update medications.医生使用该系统访问患者的病历、账单信息和更新药物。Receptionists use the system to verify patients' identities using their contact information.接待员使用该系统通过患者的联系信息验证患者的身份。Receptionists can view a patient's billing information, but not their patient ID number.接待员可以查看患者的账单信息，但不能查看他们的患者ID号。Receptionists cannot access a patient's medical records.接待员无法访问患者的病历。
MedcoMD is also concerned with the disclosure of sensitive data through any of the following methods:MedcoMD还关注通过以下任何一种方法披露敏感数据：
Accidental disclosure of data on a receptionist's publicly-viewable screen.接待员的公开屏幕上意外泄露数据。Direct access to the database by a superuser such as a database administrator.超级用户（如数据库管理员）直接访问数据库。Capture of data over an insecure network.通过不安全的网络捕获数据。Access to data by reading the database server's memory.通过读取数据库服务器的内存来访问数据。Access to data by reading database or backup files.通过读取数据库或备份文件访问数据。
What can MedcoMD do to balance the functionality and access restrictions of their medical care management system?MedcoMD可以做些什么来平衡其医疗管理系统的功能和访问限制？
Solution解决方案
MedcoMD uses the following security mechanisms to satisfy their use cases and protect against the disclosure of sensitive medical data:MedcoMD使用以下安全机制来满足其用例并防止敏感医疗数据的泄露：
Transport Encryption (TLS/SSL)传输加密（TLS/SSL）to secure data as it travels over the network.以保护数据在网络上传输时的安全。Encryption at Rest静态加密to protect against disclosure of data by reading database or backup files.通过读取数据库或备份文件来防止数据泄露。Role-Based Access Control基于角色的访问控制to limit the access of database users to the collections necessary for them to perform their tasks.限制数据库用户对执行任务所需的集合的访问。Encrypting sensitive fields with Queryable Encryption to satisfy the following use cases and constraints:使用可查询加密对敏感字段进行加密，以满足以下用例和约束：Prevent reading data from server memory as the Queryable Encryption encrypted data is never on the database server in an unencrypted form.防止从服务器内存读取数据，因为可查询加密加密数据永远不会以未加密的形式出现在数据库服务器上。Allow receptionists to verify patients' identities and prevent accidental disclosure of sensitive data on a receptionist's publicly viewable screen by providing receptionists with a client that is not Queryable Encryption enabled.允许接待员验证患者的身份，并通过向接待员提供未启用可查询加密的客户端，防止敏感数据在接待员的公开屏幕上意外泄露。Allow doctors to view sensitive data privately in their offices by providing doctors with a Queryable Encryption enabled client.通过为医生提供支持可查询加密的客户端，允许医生在办公室私下查看敏感数据。
Learn More了解更多
To view a list of security measures you should implement to protect your MongoDB deployment, see the Security Checklist.要查看您应该实施的保护MongoDB部署的安全措施列表，请参阅安全检查表。
To start using Queryable Encryption, see the Queryable Encryption Quick Start.要开始使用可查询加密，请参阅可查询加密快速入门。