Docs Menu
Docs Home
/
Manual de MongoDB
/

Encriptación a nivel de campo

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 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 MongoDB para proteger los datos en disco. Considere los siguientes escenarios:

  • Un empleado tiene acceso administrativo al clúster y a sus equipos host. Su nivel de acceso le permite ver datos confidenciales descifrados como parte de sus tareas habituales.

  • Un proveedor externo aloja el clúster de MongoDB. El proveedor sufre una brecha de seguridad en el host o en la base de datos, lo que permite que terceros no autorizados accedan a los datos descifrados.

  • 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 al clúster de MongoDB o a un equipo host puede omitir el cifrado y leer datos privados, privilegiados o confidenciales. El uso del cifrado a nivel de campo del lado del cliente para proteger los datos antes de escribirlos en el servidor mitiga el riesgo de exposición de dichos datos en caso de que se omita el cifrado de red o disco.

Considere 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 del lado del cliente, la aplicación puede cifrar específicamente información confidencial como ssn phoney. 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.

MongoDB admite dos métodos de cifrado a nivel de campo del lado del cliente utilizando los controladores oficiales compatibles con MongoDB 4.2+:

Cifrado explícito (manual) de campos

Los controladores oficiales compatibles con MongoDB +,4.2 mongoshy el shell MongoDB.4 2 o posterior heredado mongo admiten el cifrado o descifrado explícito de campos con una clave de cifrado de datos y un algoritmo de cifrado específicos.

Las aplicaciones deben modificar el código asociado con la construcción de operaciones de lectura y escritura para incluir la lógica de cifrado/descifrado mediante la biblioteca de cifrado del controlador. Las aplicaciones son responsables de seleccionar la clave de cifrado de datos adecuada para cada operación.

Para obtener más información,consulte Cifrado a nivel de campo del lado del cliente explícito (manual).

Cifrado automático de campos

Nota

Característica de la empresa

La función automática de cifrado a nivel de campo solo está disponible en los clústeres MongoDB Enterprise 4.2 o posterior y MongoDB Atlas 4.2 o posterior.

Los controladores oficiales compatibles con MongoDB +,4.2 mongoshy el shell MongoDB.4 2 o posterior heredado mongo admiten el cifrado automático de campos en operaciones de lectura y escritura.

Las aplicaciones deben crear un objeto de conexión a la base de datos (p. MongoClient ej.,) con la configuración de cifrado automático. Esta configuración debe incluir reglas de cifrado automático que utilicen un subconjunto estricto de la sintaxis estándar del borrador de 4 esquema JSON y palabras clave de esquema específicas para el cifrado. Las aplicaciones no tienen que modificar el código asociado con la operación de lectura/escritura. Consulte la sección "Reglas de cifrado automático" para obtener la documentación completa sobre las reglas de cifrado automático.

Para obtener más información,consulte Cifrado automático a nivel de campo del lado del cliente.

Los controladores compatibles con MongoDB 4.2mongosh +, y el shell de MongoDB 4.2 o posterior mongo (hered) descifran automáticamente Binary 6 los objetos del subtipo creados mediante cifrado de nivel de campo del lado del cliente. Para obtener más información sobre el descifrado automático, consulte Descifrado automático de campos.

Importante

El cifrado a nivel de campo del lado del cliente de MongoDB solo permite cifrar campos individuales en un documento. Para cifrar un documento completo, debe cifrar cada campo individual.

El siguiente diagrama ilustra las relaciones entre el controlador y cada componente de cifrado:

Diagrama de relaciones entre el controlador y los componentes de cifrado
  • libmongocrypt Es la biblioteca de criptografía principal de código abierto con licencia Apache, utilizada por 4 los2controladores oficiales compatibles conmongosh MongoDB. +,, y el shell de MongoDB.4 2 o posterior mongo para 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. Consulte la documentación del controlador para obtener información más completa.

  • La biblioteca compartida de cifrado automático admite el cifrado automático a nivel de campo del lado del cliente y solo está disponible con MongoDB Enterprise. Esta biblioteca no realiza funciones criptográficas. Es una alternativa preferida a mongocryptd y no requiere la creación de un nuevo proceso. mongocryptd aún es compatible.

  • El almacén de claves es una colección de MongoDB que almacena todas las claves de cifrado de datos utilizadas para cifrar valores. Estas claves se cifran mediante una clave maestra del cliente (CMK) antes de almacenarse 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 Clave Maestra del Cliente (CMK) utilizada para cifrar las claves de cifrado de datos. MongoDB admite los siguientes proveedores de KMS:

  • El clúster de MongoDB que almacena los datos cifrados también puede aplicar cifrado a nivel de campo del lado del cliente. Consulte "Aplicar esquema de cifrado a nivel de campo" para obtener más información.

El cifrado a nivel de campo del lado del cliente de MongoDB utiliza el enfoque de cifrado y luego MAC, combinado con un vector de inicialización determinista o aleatorio para cifrar los valores de campo. MongoDB solo admite el algoritmo de cifrado AEAD AES-256-CBC con HMAC-SHA-512 MAC.

El algoritmo de cifrado determinista garantiza que un valor de entrada dado se cifre siempre con el mismo valor de salida cada vez que se ejecuta el algoritmo. Si bien el cifrado determinista ofrece mayor compatibilidad con las operaciones de lectura, los datos cifrados con baja cardinalidad son susceptibles a la recuperación mediante análisis de frecuencia.

Para los campos sensibles que no se utilizan en operaciones de lectura, las aplicaciones pueden usar cifrado aleatorio para mejorar la protección contra la recuperación del análisis de frecuencia.

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. Si bien el cifrado aleatorio ofrece las mayores garantías de confidencialidad de los datos, también impide la compatibilidad con operaciones de lectura que deban operar en el campo cifrado para evaluar la consulta.

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 personal_information phone_numbers campos y con el algoritmo de cifrado aleatorio, se cifra todo el objeto. Si bien esto protege todos los campos anidados bajo ellos, también impide realizar consultas sobre ellos.

Para los campos sensibles que se utilizan en operaciones de lectura, las aplicaciones deben usar cifrado determinista para mejorar el soporte de lectura en campos cifrados.

Los BinData metadatos del blob incluyen la clave _id de cifrado de datos y el algoritmo de cifrado utilizado para cifrar los datos binarios. Los 4.2controladores compatibles conmongosh +,, y 4 el2 shell MongoDB. o mongo posterior,, utilizan estos metadatos para intentar el descifrado automático de BinData los 6 objetos del subtipo. El proceso de descifrado automático funciona de la siguiente manera:

  1. Verifique los BinData metadatos del blob para conocer la clave de cifrado de datos y el algoritmo de cifrado utilizado para cifrar el valor.

  2. Compruebe el almacén de claves configurado en la conexión de base de datos actual para la clave de cifrado de datos especificada. Si el almacén de claves no contiene la clave especificada, el descifrado automático falla y el controlador devuelve el blob BinData.

  3. Verifique los metadatos de la clave de cifrado de datos para la clave maestra del cliente (CMK) utilizada para cifrar el material de la clave.

  4. Para Amazon Web Services KMS, Azure Key Vault o Google Cloud Platform KMS, envíe la clave de cifrado de datos al proveedor de KMS para su descifrado. Si la CMK no existe o si la configuración de la conexión no permite el acceso a ella, el descifrado falla y el controlador devuelve el BinData blob.

    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.

  5. Descifre el BinData valor utilizando la clave de cifrado de datos descifrados y el algoritmo apropiado.

Las aplicaciones con acceso al servidor MongoDB que también no tienen acceso a la clave maestra requerida y a las claves de cifrado de datos no pueden descifrar los BinData valores.

Para obtener más información sobre cómo configurar la conexión de base de datos para el cifrado a nivel de campo del lado del cliente, consulte el Mongo() constructor o consulte la documentación para conocer el método de construcción de cliente de su controlador preferido.

A partir de MongoDB,4.2 el servidor admite la validación de esquemas para aplicar el cifrado a campos específicos de una colección. Utilice las palabras clave de la regla de cifrado automático con el $jsonSchema objeto de validación para indicar qué campos requieren cifrado. El servidor rechaza cualquier operación de escritura en esa colección si los campos especificados no son Binary (BinData) 6 objetos del subtipo.

Por ejemplo, el siguiente comando modifica collMod la hr.employees colección para incluir validator un. El $jsonSchema objeto de validación incluye palabras clave de cifrado a nivel de campo del lado del cliente para indicar que:

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 realizan cifrado explícito (manual) a nivel de campo deben encrypt como mínimo taxid taxid-short en los campos y utilizando las mismas configuraciones que el remoto $jsonSchema antes de emitir la operación de escritura.

Los clientes que realizan cifrado automático a nivel de campo del lado del cliente tienen un comportamiento específico según la configuración de la conexión de la base de datos:

Nota

El cifrado automático a nivel de campo del lado del cliente solo está disponible con MongoDB Enterprise 4.2 o posterior.

  • Si el objeto de conexión ClientSideFieldLevelEncryptionOptions schemaMap contiene una clave para la colección especificada, el cliente utiliza dicho objeto para realizar el cifrado automático a nivel de campo e ignora el esquema remoto. Las reglas locales deben cifrar, como mínimo, los taxid taxid-short campos y.

  • Si el ClientSideFieldLevelEncryptionOptions schemaMap objeto de conexión 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 cuenta con un esquema válido para el cifrado automático a nivel de campo. El cliente solo 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.

Dado que el servidor MongoDB no puede descifrar ni introspeccionar 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 ID de clave o algoritmos de cifrado para un campo específico. Si bien algunas cargas de trabajo pueden requerir implementaciones de cifrado independientes a nivel de campo, la implementación inconsistente de las opciones de cifrado para un campo en diferentes clientes puede provocar un comportamiento incorrecto o inesperado en las consultas sobre el campo cifrado.

Por ejemplo, el cliente A cifra el campo PII mediante cifrado aleatorio, mientras que el cliente B cifra el campo PII mediante cifrado determinista. El algoritmo de cifrado aleatorio siempre devuelve un valor único diferente, mientras que el algoritmo determinista siempre devuelve el mismo valor. Las consultas que esperan datos cifrados deterministamente para ese campo generan resultados inconsistentes, ya que el servidor no puede encontrar ninguno de los campos cifrados aleatoriamente.

El cifrado a nivel de campo del lado del cliente de MongoDB 4.2 solo está disponible con las siguientes versiones oficiales de controladores compatibles con 4.2+:

Controlador
Versiones compatibles
Guías de inicio rápido / Tutoriales

3.4.0+

3.12.0+

1.13.0+

3.10.0+

2.10.0+

1.17.5

1.2+

2.8.0+

1.6.0+

2.12.1+

Consulte la documentación de referencia del controlador para obtener ejemplos de sintaxis e implementación.

Volver

Rotar claves

En esta página