功能
概述
在本页中，您可以了解客户端字段级加密（CSFLE）的安全优势，以及CSFLE与其他MongoDB支持的安全机制的比较。您还可以查看一个虚构的场景，演示CSFLE在保护您的数据中的价值。
客户端字段级加密
客户端字段级加密（CSFLE）是MongoDB的一个功能，它允许客户端在通过网络传输数据之前对数据进行加密。敏感数据由客户端透明地加密和解密，并且以加密的形式仅与服务器进行通信。CSFLE在以下场景中确保加密字段的安全性：
数据库超级用户直接访问加密字段
通过读取服务器的内存访问加密字段
在非安全网络上捕获加密字段
通过读取数据库或备份文件访问磁盘上的加密字段
虽然所有客户端都有访问非敏感数据字段的权限，但只有适当配置的CSFLE客户端才能读取和写入加密数据字段。
重要
远程密钥管理系统
当在生产环境中使用CSFLE时，您必须使用远程密钥管理系统（KMS）来存储您的加密密钥。
要查看演示如何使用远程KMS与CSFLE的逐步指南，请参阅教程.
要查看所有支持的KMS提供商列表，请参阅KMS提供商。
要了解更多关于为什么您应该使用远程KMS的原因，请参阅使用远程密钥管理系统的原因。
其他安全机制
本节介绍了MongoDB支持的安全机制，并解释了它们的使用场景和限制。
基于角色的访问控制
基于角色的访问控制是一种安全机制，允许管理员为用户提供集合级别的权限。通过适当的角色定义和分配，该方案可以防止数据意外泄露和访问。
基于角色的访问控制无法防止以下场景：
在不安全的网络上捕获数据
通过读取数据库或备份文件访问磁盘上的数据
通过读取服务器内存访问数据
数据库超级用户直接访问数据
要了解更多信息，请参阅基于角色的访问控制。
静态加密
静态加密是一种加密磁盘上数据库文件的机制。该机制防止没有数据库凭证但有权访问托管您的数据库的计算机的人查看您的数据。
此机制不能保护您的数据免受以下场景的影响：
在不安全的网络上捕获数据
通过读取服务器内存访问数据
数据库超级用户直接访问数据
要了解更多信息，请参阅静态加密。
传输加密（TLS/SSL）
使用TLS/SSL的传输加密对网络中的数据进行加密。TLS/SSL在数据通过不安全网络传输时保护数据，但不能保护数据免受具有特权的用户或磁盘上的数据的影响。
欲了解更多信息，请参阅使用TLS/SSL的传输加密
功能比较
欲了解更多关于可查询加密的信息，请参阅可查询加密功能。
以下表格描述了潜在的安全威胁以及MongoDB加密功能如何解决这些问题。请一起使用这些机制：基于角色的访问控制、静止加密、传输加密和在使用加密。请注意，您不能在同一个集合中同时使用客户端字段级加密和可查询加密。
重要
这是一份高级概述，用于一般比较。有关详细信息，请参阅可查询加密概述和无状态文档数据库加密方案的设计与分析白皮书。
威胁 | TLS/SSL传输加密 | 静态加密（EaR） | 可查询加密（相等性）+ TLS/SSL + EaR | CSFLE + TLS/SSL + EaR |
|---|---|---|---|---|
网络窃听（攻击者可以访问网络流量） | 泄露操作元数据 | 泄露操作元数据 | 泄露操作元数据 | 泄露操作元数据 |
从磁盘恢复数据库（攻击者可以访问物理磁盘） | 泄露数据库 | 泄露数据库大小和操作元数据 | 泄露数据库大小和操作元数据 | 泄露数据库大小和操作元数据 |
从磁盘和内存中泄露数据库（攻击者可以访问物理磁盘和多个数据库快照） [1] | 泄露数据库 | 泄露数据库 | 泄露数据库大小和操作元数据 | 泄露值的频率和操作元数据 |
高级持续性威胁（攻击者可以长时间、持续地访问网络、磁盘和内存，同时保持未被检测到） | 泄露数据库 | 泄露数据库 | 可查询加密并未设计用于防范高级持续性威胁（ATP）。详见白皮书了解详情。 | CSFLE 并未设计用于防范高级持续性威胁（ATP）。详见白皮书了解详情。 |
| [1] | 此假设数据泄露发生在操作完成后。详见白皮书了解详情。 |
场景
以下虚构场景演示了客户端字段级加密（CSFLE）在保护应用程序数据的价值，以及CSFLE如何与本文档中讨论的其他安全机制交互。
在这个场景中，我们为一家虚构公司MedcoMD的医疗保健管理系统中的敏感数据提供安全保护，该系统存储了患者的个人信息、保险信息和病历。所有患者数据都不是公开的，而且具体数据如他们的社会保障号码（SSN，美国政府颁发的身份证号码）、保险政策号码和生命体征测量值尤其敏感，并受隐私合规性约束。对于公司和患者来说，保持数据私密和安全非常重要。
MedcoMD需要该系统来满足以下用例：
医生使用该系统访问患者的病历、保险信息和添加新的生命体征测量值。
接待员使用该系统通过患者的联系信息验证患者的身份。
接待员可以查看患者的保险政策提供者，但不能查看他们的政策号码。
接待员无法访问患者的病历。
MedcoMD还担心通过以下任何一种方式泄露敏感数据：
在接待员公开可见的屏幕上意外泄露数据。
超级用户（如数据库管理员）直接访问数据库。
在非安全网络上捕获数据。
通过读取数据库服务器的内存访问数据。
通过读取数据库或备份文件访问数据。
MedcoMD可以做些什么来平衡其医疗保健管理系统的功能性和访问限制？
解决方案
MedcoMD 使用以下安全机制来满足其用例并防止敏感医疗数据的泄露：
传输加密（TLS/SSL） 以在网络传输过程中保护数据。
静态加密 以防止通过读取数据库或备份文件泄露数据。
基于角色的访问控制 以限制数据库用户对执行其任务所需的集合的访问。
使用 CSFLE 加密敏感字段以满足以下用例和约束
防止从服务器内存读取数据，因为 CSFLE 加密的数据永远不会以未加密的形式出现在数据库服务器上。
通过为接待员提供非 CSFLE 启用的客户端，允许接待员验证患者的身份，并防止在接待员公开可见的屏幕上意外泄露敏感数据。
通过为医生提供 CSFLE 启用的客户端，允许医生在办公室私密地查看敏感数据。
了解更多
要查看应实施以保护您的 MongoDB 部署的安全措施列表，请参阅安全清单。
要开始使用 CSFLE，请参阅快速入门。