Nuevo en la versión 4.2.
Los controladores oficiales compatibles con MongoDB 4.2+ ofrecen un marco de cifrado a nivel de campo del lado del cliente. Las aplicaciones pueden cifrar campos en los documentos antes de transmitir los datos al servidor. Solo las aplicaciones que cuentan con acceso a las llaves de cifrado correctas pueden descifrar y leer los datos protegidos. Eliminar una llave de cifrado hace que todos los datos cifrados con esa llave sean permanentemente ilegibles.
Por ejemplo, un clúster de MongoDB que aplica La autenticación utiliza cifrado TLS para proteger los datos en tránsito. El clúster también utiliza el motor de almacenamiento cifrado de MongoDB para proteger los datos en disco. Considera los siguientes escenarios:
Un empleado tiene acceso administrativo al clúster y sus máquinas host. El nivel de acceso del empleado les permite ver datos de alta sensibilidad en un estado descifrado como parte de sus deberes normales.
Un proveedor externo aloja el clúster de MongoDB. El proveedor ha sufrido una violación de la seguridad a nivel de máquina host o base de datos, donde partes no autorizadas han accedido a los datos en estado descifrado.
Una firma de análisis de datos externa tiene acceso a datos que incluyen información privada, personal o confidencial. La firma de terceros carga los datos descifrados en un volumen de almacenamiento de datos no seguro al que pueden acceder terceros no autorizados.
En cada escenario, un usuario con acceso privilegiado tanto al clúster de MongoDB como a una máquina host puede eludir el cifrado y leer datos que son privados, privilegiados o confidenciales. El uso de cifrado a nivel de campo en el lado del cliente para proteger los datos antes de que se escriban en el servidor, mitiga el riesgo de exponer esos datos en caso de que se evite el cifrado de red o de disco.
Considera el siguiente documento:
{ "name" : "John Doe", "address" : { "street" : "1234 Main Street", "city" : "MongoDBVille", "zip" : 99999 }, "phone" : "949-555-1212", "ssn" : "123-45-6789" }
Con el cifrado a nivel de campo en el lado del cliente, la aplicación puede cifrar específicamente información sensible como la ssn
y phone. Los campos cifrados se almacenan como binary data con subtipo 6:
{ "name" : "John Doe", "address" : { "street" : "1234 Main Street", "city" : "MongoDBVille", "zip" : 99999 }, "phone" : BinData(6,"U2FsdGVkX1+CGIDGUnGgtS46+c7R5u17SwPDEmzyCbA="), "ssn" : BinData(6,"AaloEw285E3AnfjP+r8ph2YCvMI1+rWzpZK97tV6iz0jx") }
Para ver una lista completa de los controladores oficiales compatibles con 4.2+ con soporte para cifrado a nivel de campo del lado del cliente, consulta la Tabla de compatibilidad de controladores.
Para un procedimiento de extremo a extremo para configurar el cifrado a nivel de campo utilizando controladores compatibles selectos de MongoDB 4.2+, consulte la Guía de cifrado a nivel de campo del lado del cliente.
Métodos de cifrado compatibles
MongoDB admite dos métodos de cifrado a nivel de campo de lado del cliente utilizando los controladores oficiales de MongoDB 4.2+ compatibles:
- Cifrado explícito (manual) de campos
Los controladores oficiales compatibles con MongoDB 4.2+,
mongoshy de MongoDB 4.2 o posteriores soporte de shell heredadomongopermiten cifrar o descifrar explícitamente campos con una llave de cifrado de datos específica y un algoritmo de cifrado.Las aplicaciones deben modificar cualquier código asociado con la construcción de operaciones de lectura y escritura para incluir la lógica de cifrado y descifrado mediante la librería de cifrado de driver. Las aplicaciones son responsables de seleccionar la llave de cifrado de datos adecuada para el cifrado/descifrado en función de cada operación.
Para obtener más información, consulta Cifrado explícito (manual) a nivel de campo del lado del cliente.
- Cifrado automático de campos
Nota
Característica de la empresa
La funcionalidad automática del cifrado a nivel de campo solo está disponible en MongoDB Enterprise 4.2 o posterior y en los clústeres de MongoDB Atlas 4.2 o posterior.
Los controladores compatibles con MongoDB 4.2+ oficiales,
mongosh, y la compatibilidad con shells heredados de MongoDB 4.2 o versiones posterioresmongoadmiten de forma automática el cifrado de campos en operaciones de lectura y escritura.Las aplicaciones deben crear un objeto de conexión a la base de datos (por ejemplo,
MongoClient) con los ajustes de configuración de cifrado automático. Las configuraciones deben incluir reglas de cifrado automático utilizando un subconjunto estricto de la JSON schema Draft 4 sintaxis estándar y las palabras clave de esquema específicas para cifrado. Las aplicaciones no tienen que modificar el código asociado con la operación de lectura/guardar. Consulta Reglas automáticas de cifrado para obtener la documentación completa sobre las reglas automáticas de cifrado.Para obtener más información, consulta Cifrado automático del lado del cliente a nivel de campo.
Los controladores compatibles con MongoDB 4.2+, mongosh, y el shell heredado de MongoDB 4.2 o posterior mongo descifran automáticamente Binary objetos de subtipo 6 creados utilizando la encriptación de nivel de campo del lado del cliente. Para obtener más información sobre el descifrado automático, consulta Descifrado automático de campos.
Importante
La MongoDB cifrado a nivel de campo del lado del cliente solo admite cifrar campos individuales en un documento. Para encriptar un documento completo, debe encriptar cada campo individual en el documento.
Componentes de cifrado
El siguiente diagrama ilustra las relaciones entre el controlador y cada componente de cifrado:
libmongocryptes la librería de criptografía central de código abierto licenciada bajo Apache utilizada por el MongoDB oficial 4.2+ controladores compatibles,mongosh, y la versión 4.2 o posterior del shell legacy de MongoDBmongopara potenciar el cifrado a nivel de campo del lado del cliente. Algunos controladores pueden requerir pasos de integración específicos para instalar o vincular la biblioteca. Para obtener información más completa, consulta la documentación del controlador.La Librería Compartida de encriptación automática es compatible con cifrado a nivel de campo del lado del cliente y solo está disponible con MongoDB Enterprise. La librería compartida de cifrado automático no realiza funciones criptográficas. La librería compartida es una alternativa preferida a
mongocryptdy no requiere iniciar un nuevo proceso.mongocryptdtodavía es compatible.La Key Vault es una colección de MongoDB que almacena todas las claves de cifrado de datos utilizadas para cifrar valores. Las llaves de cifrado de datos se cifran también utilizando una llave maestra de cliente (CMK) antes de su almacenamiento en la colección. El almacén de claves puede residir en un clúster de MongoDB diferente al que almacena los datos cifrados.
El Servicio de Gestión de Claves (KMS) almacena la llave maestra de cliente (llave maestra de cliente) utilizada para cifrar las llaves de cifrado de datos. MongoDB admite los siguientes proveedores de KMS:
El clúster de MongoDB que almacena los datos cifrados también puede imponer el cifrado a nivel de campo del lado del cliente. Consulte Aplicar esquema de cifrado a nivel de campo para obtener más información.
Algoritmos de cifrado
El cifrado a nivel de campo del lado del cliente de MongoDB utiliza el enfoque cifrar-luego-MAC combinado con un vector de inicialización determinista o aleatorio para cifrar valores de campo. MongoDB sólo admite el algoritmo de cifrado AEAD AES-256-CBC con MAC HMAC-SHA-512.
Cifrado determinista
El algoritmo de cifrado determinista garantiza que un valor de entrada dado se encripte siempre al mismo valor de salida cada vez que se ejecute el algoritmo. Si bien el cifrado determinista proporciona mayor soporte para operaciones de lectura, los datos cifrados con baja cardinalidad son susceptibles a la recuperación por análisis de frecuencia.
Para campos confidenciales que no se utilizan en operaciones de lectura, las aplicaciones pueden usar Cifrado aleatorio para mejorar la protección contra la recuperación mediante análisis de frecuencias.
Cifrado aleatorio
El algoritmo de cifrado aleatorio garantiza que un valor de entrada dado se cifre siempre en un valor de salida diferente cada vez que se ejecuta el algoritmo. Si bien el cifrado aleatorio ofrece las garantías más sólidas de confidencialidad de los datos, también impide el soporte para cualquier operación de lectura que deba operar sobre el campo cifrado para evaluar la query.
La encriptación aleatoria también admite el cifrado de objetos o arreglos completos. Por ejemplo, considere el siguiente documento:
{ "personal_information" : { "ssn" : "123-45-6789", "credit_score" : 750, "credit_cards" : [ "1234-5678-9012-3456", "9876-5432-1098-7654"] }, "phone_numbers" : [ "(212) 555-0153" ] }
Al cifrar los campos personal_information y phone_numbers mediante el algoritmo de cifrado aleatorio se cifra el objeto completo. Si bien esto protege todos los campos anidados bajo esos campos, también impide consultar esos campos anidados.
Para campos confidenciales que se utilicen en operaciones de lectura, las aplicaciones deben usar cifrado determinista para mejorar el soporte de lectura en campos cifrados.
Descifrado de campos automático
Los metadatos de blob BinData incluyen la llave de cifrado de datos _id y el algoritmo de cifrado utilizado para cifrar los datos binarios. Los controladores compatibles 4.2+, mongosh, y el shell MongoDB 4.2 o posterior mongo utilizan estos metadatos para intentar la descifrado automático de objetos de subtipo BinData 6. El proceso de descifrado automático funciona de la siguiente manera:
Comprueba los metadatos
BinDatade blob para la llave de cifrado de datos y el algoritmo de cifrado utilizados para cifrar el valor.Verifique el almacén de claves configurado en la conexión de la base de datos actual para la clave de cifrado de datos especificada. Si el Key Vault no contiene la llave especificada, la descifrado automático fallará y el controlador devolverá el blob
BinData.Verifique los metadatos de la clave de cifrado de datos para la Clave maestra del cliente (CMK) utilizada para cifrar el material clave.
Para el KMS de Amazon Web Services, Azure Key Vault o KMS de Google Cloud Platform, envía la llave de cifrado de datos al proveedor de KMS para su descifrado. Si la llave maestra de cliente no existe o si la configuración de la conexión no concede acceso a la llave maestra de cliente, la desencriptación falla y el controlador devuelve el blob
BinData.Para la clave localmente gestionada, debe recuperar la clave local y descifrar la clave de cifrado de datos. Si la clave local especificada en la configuración de la base de datos no se utilizó para cifrar la clave de cifrado de datos, la descifrado fallará y el driver devolverá el blob
BinData.Desencripta el valor
BinDatausando la llave de cifrado de datos desencriptada y el algoritmo apropiado.
Las aplicaciones con acceso al servidor MongoDB que tampoco tienen acceso a la clave principal requerida y a las claves de cifrado de datos no pueden descifrar los valores BinData.
Para obtener más información sobre cómo configurar la conexión de la base de datos para el cifrado a nivel de campo del lado del cliente, consulta el constructor Mongo() o consulta la documentación del método de construcción del driver preferido.
Aplicar el esquema de cifrado a nivel de campo
A partir de MongoDB 4.2, el servidor admite el uso de la validación de esquema para aplicar el cifrado de campos específicos en una colección. Utiliza las palabras clave de las reglas de cifrado automático con el objeto de validación $jsonSchema para indicar qué campos requieren cifrado. El servidor rechaza cualquier operación de escritura en esa colección en la que los campos especificados no sean objetos del subtipo Binary (BinData) 6.
Por ejemplo, el siguiente comando collMod modifica la colección hr.employees para incluir un validator. El objeto de validación $jsonSchema incluye palabras clave de cifrado a nivel de campo del lado del cliente para indicar que:
El campo
taxiddebe estar cifrado. Los clientes deben utilizar la llave de cifrado de datos especificada y el algoritmo de cifrado aleatorizado al cifrar el campo.El campo
taxid-shortdebe estar cifrado. Los clientes deben utilizar la llave de cifrado de datos especificada y el algoritmo de cifrado determinista para cifrar el campo.
db.getSiblingDB("hr").runCommand( { "collMod" : "employees", "validator" : { "$jsonSchema" : { "bsonType" : "object", "properties" : { "taxid" : { "encrypt" : { "keyId" : [UUID("e114f7ad-ad7a-4a68-81a7-ebcb9ea0953a")], "algorithm" : "AEAD_AES_256_CBC_HMAC_SHA_512-Random", } }, "taxid-short" : { "encrypt" : { "keyId" : [UUID("33408ee9-e499-43f9-89fe-5f8533870617")], "algorithm" : "AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic", "bsonType" : "string" } } } } } } )
Los clientes que realicen un cifrado explícito (manual) a nivel de campo deben encrypt como mínimo los campos taxid y taxid-short utilizando la misma configuración que la instancia remota $jsonSchema antes de efectuar la operación de escritura.
Los clientes que realizan cifrado automático a nivel de campo en el lado del cliente presentan comportamientos específicos según la configuración de conexión a la base de datos:
Nota
El cifrado automático a nivel de campo del lado del cliente está disponible solo con MongoDB Enterprise 4.2 o posterior.
Si la conexión
ClientSideFieldLevelEncryptionOptionsschemaMapel objeto contiene una clave para la colección especificada, el cliente utiliza ese objeto para realizar cifrado automático a nivel de campo e ignora el esquema remoto. Las reglas locales deben cifrar como mínimo los campostaxidytaxid-short.Si la conexión
ClientSideFieldLevelEncryptionOptionsschemaMapobjeto no contiene una clave para la colección especificada, el cliente descarga el esquema remoto del lado del servidor para la colección y lo utiliza para realizar el cifrado automático a nivel de campo.Esta configuración requiere que el cliente confíe en que el servidor tiene un esquema válido con respecto al cifrado automático a nivel de campo. El cliente sólo utiliza el esquema remoto para realizar el cifrado automático a nivel de campo y no aplica ninguna otra regla de validación especificada en el esquema.
Como el servidor de MongoDB no puede descifrar ni inspeccionar el contenido del campo cifrado, no puede validar que los clientes hayan utilizado las opciones de cifrado especificadas para cifrar un campo determinado. Esto permite que dos clientes inserten datos cifrados utilizando diferentes keyID o algoritmos de cifrado para un campo específico. Si bien algunas cargas de trabajo pueden requerir implementaciones independientes de cifrado a nivel de campo, una implementación inconsistente de las opciones de cifrado para un campo entre clientes puede resultar en un comportamiento incorrecto o inesperado de las consultas en contra del campo cifrado.
Por ejemplo, el cliente A cifra el campo PII utilizando cifrado aleatorio, mientras que el cliente B cifra el campo PII utilizando cifrado determinista. El algoritmo de cifrado aleatorio siempre devuelve un valor único diferente, mientras que el algoritmo determinístico siempre devuelve el mismo valor. Las queries que esperan datos cifrados de forma determinista para ese campo devuelven resultados incoherentes, ya que el servidor no puede hacer coincidir ninguno de los campos cifrados aleatoriamente.
Tabla de compatibilidad de controladores
El cifrado a nivel de campo del lado del cliente de MongoDB 4.2 solo está disponible con las siguientes versiones oficiales compatibles del driver 4.2+ :
Controlador | Versiones compatibles | Inicios rápidos / tutoriales |
|---|---|---|
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
|
Consulta la documentación de referencia del controlador para obtener ejemplos de sintaxis e implementación.