MongoDB Queryable Encryption：前缀、后缀和子字符串查询现已发布

上周，我们宣布 MongoDB Queryable Encryption 全面支持前缀、后缀和子字符串查询。这些功能将 Queryable Encryption 的应用范围扩展到等式和范围查询之外，现在可以完全支持生产工作负载。

MongoDB Queryable Encryption 是一项开创性的、业内首创的正在使用的加密技术，由 MongoDB 密码学研究小组开发。它使能够客户能够对敏感的应用程序数据进行加密，以加密形式存储在 MongoDB 中，并在该加密数据上运行表达性查询，而无需对其进行解密。数据库永远不会以明文形式查看数据。

组织现在可以在生产环境中对加密数据运行灵活的文本搜索，匹配部分名称、单词或标识符，从而在明确的 ACID 一致性保证下保护根本的数据。这意味着更强大的数据保护、更简单的合规，并且不需要外部搜索索引等变通方法。所有这些都只需极少的代码更改，无需新的基础设施。

通过对 Queryable Encryption 中前缀、后缀和子字符串查询的支持，MongoDB 使组织能够在其整个生命周期中保护敏感数据：静态、传输中和使用中。因此，团队可以构建安全的隐私保护应用程序，而不会影响功能。Queryable Encryption 在 MongoDB Atlas、MongoDB Enterprise Advanced 和 MongoDB Community Edition 中提供，不收取额外费用。

挑战：数据只有在需要使用之前受到保护

大多数组织都会存储敏感数据：个人身份信息 (PII)，如姓名和社会保障号码，或受保护的健康信息 (PHI)，如医疗记录。保持这些数据在存储或跨网络移动时的安全是众所周知的。静态加密和传输中加密是当今的标准做法。

但是，查询这些数据则完全是另一回事。传统加密会使数据变得无法读取，这意味着如果没有先对其进行解密，数据库就无法对其进行搜索。例如，一家医疗保健提供商需要查找诊断包含单词"edema"的所有患者；如果不解密记录，数据库就无法搜索该术语。

为了解决这个问题，许多组织将敏感字段保持在未加密状态，或者构建外部搜索索引，以使能够其应用程序所需的查询。这两种方法都会增加运营开销。两者也都会增加未经授权访问的风险，尤其是在敏感数据暴露最严重的时刻。

在监管压力下，这变得更加困难。像健康保险可移植性与责任法案 (HIPAA)、支付卡行业数据安全标准 (PCI-DSS) 和一般数据保护条例 (GDPR) 等标准越来越期望组织证明敏感数据在每个阶段都受到保护，而不仅仅是在静态和传输中。在数据主动使用时提供保护是大多数加密方法无法解决的问题。

为了充分保护敏感数据并满足合规要求，组织需要一种方法来搜索加密数据，而无需对其进行解密，也不必牺牲性能或添加新基础设施。

零暴露数据保护

MongoDB Queryable Encryption 的构建旨在弥补这一差距。它使敏感数据在主动搜索时保持加密状态，这是其他加密方法无法达到的阶段。

借助 Queryable Encryption，即使在数据库服务器本身上，敏感字段也永远不会以纯文本形式存储、传输、处理或返回。查询在加密数据上运行。没有解密，也没有数据暴露的窗口。

这是可能的，因为 Queryable Encryption 构建于一种结构化加密方案，该方案使数据在服务器上进行查询处理时始终保持加密状态。该方案完全开源且可独立验证，而不是供应商的黑盒声明。这是一种业界首创的方法：如今还没有其他数据库技术能提供这种级别的正在使用的加密，并且它不依赖于安全 enclave 等专用硬件。

组织已经信任 Queryable Encryption 来保护其一些最敏感的数据。法国内部安全部队 (ANFSI) 依靠它来保护敏感记录，并得到政府级安全查看的支持。

对于处理 PII、PHI 或其他受监管数据的团队来说，这意味着敏感信息可能会暴露的地方减少了一个，即使是直接访问数据库的内部人员也是如此。

更具表现力的搜索，内置

到目前为止，Queryable Encryption 已在正式发布版本中支持等值查询和范围查询。这涵盖了精确匹配和有界数值查找，但应用程序通常需要更灵活的查找方式：部分名称查找、自动完成或部分单词过滤器。随着前缀、后缀和子字符串查询现已正式发布，这一差距得以弥补。

现在可以直接对加密字段进行以下操作：

• 前缀查询会返回字段值以特定字符序列开头的文档。示例，查找所有姓氏以"Mac."开头的客户数。

• 后缀查询返回字段值以特定序列结尾的文档。示例，匹配加密社会安全号码的最后四位数字。

• 子字符串查询返回特定序列出现在字段中任意位置的文档。子字符串搜索涵盖不超过50个字符的短结构字段，搜索2到6个字符的术语。例如，搜索加密作业标题字段中的"eng"，匹配"Engineer"和"Engineering 经理"。

• 范围查询（现有）返回字段值落在指定下限和上限（如加密薪资范围）内的文档。

• 等式查询（现有的）返回字段值完全匹配的文档，例如特定的加密电子邮件地址。

这些查询类型运行通过 MongoDB 的原生查询引擎和驱动程序，与其他所有查询类型使用的引擎和驱动程序相同。无需设置外部搜索索引，无需维护中间件，应用程序代码也只需进行极小的修改。团队可以使用他们已经在运行的架构对加密数据进行富有表现力的部分匹配搜索。

合规是可以证明的，而不仅仅是声明

满足 HIPAA、PCI-DSS 和 GDPR 等要求意味着证明敏感数据受到保护，而不仅仅是断言。当无法独立验证加密声明时，这会很困难，如果声明未涵盖主动使用的数据，则会更加困难。

Queryable Encryption 为合规和风险团队提供了可辩护的回答。其结构化加密方案是完全开源的，因此其背后的密码学可以独立查看，而不是凭空相信。而且，因为它通过查询处理来保护数据，而不仅仅是在静态和传输中，所以它解决了大多数合规计划无法解决的阶段。

随着前缀、后缀和子字符串查询的全面可用，同样的证据已扩展到更多使用案例：部分姓名和电子邮件搜索、自由文本字段中的部分词汇过滤器以及部分 ID 匹配。无论工作负载是在本地部署、混合环境中运行还是跨多个云运行，其结果是减少了 Atlas 审核漏洞，也减少了需要整合的碎片化工具。

团队现在可以构建的内容

随着 Queryable Encryption 中全面提供前缀、后缀和子字符串查询，以下是组织现在可以实现的一些示例：

• 用于合规和可用性的个人身份信息搜索：GDPR 和 HIPAA 等法规要求对个人信息进行严格保密。通过前缀查询，团队可以检索姓氏或电子邮件前缀的用户，同时使根本的 数据保持加密。这使合规更简单，且不会牺牲搜索功能。

• 结构化字段的部分词过滤器：诊断等结构化字段通常需要部分匹配。有了子字符串查询支持，团队可以在加密的健康状况字段中搜索诸如“diabet”之类的术语，匹配“diabetes”和“diabetic”。

• 安全的 ID 验证：身份工作流程通常依赖于部分标识符，例如社会安全号码、保险号码或 Aadhaar 号码的最后四位数字。后缀查询使能够在加密字段上执行这些查找，而无需显示完整值，从而降低了受监管环境中数据泄露的风险。

• 公共机构的案例管理：公共部门应用程序中的案例编号和参考 ID 通常遵循结构化格式。前缀查询允许机构使用基于地区或办公室的前缀（例如“NYC-”或“EUR-”）检索记录，而无需暴露敏感的案例元数据。

开始使用 Queryable Encryption

前缀、后缀和子字符串查询使团队能够在搜索敏感数据时获得更高水平的灵活性，而无需他们在安全和功能之间进行选择。无论是为了满足合规要求、降低基础设施复杂性，还是仅仅为了构建更好的应用程序，这些功能现在都可以投入生产。

前缀、后缀和子字符串查询为团队搜索敏感数据提供了新的灵活性。这些新的查询类型有助于保护敏感数据免遭未经授权的访问，并满足合规要求，同时降低基础架构和运营复杂性。