Cifrado a nivel de campo del lado del cliente

Incluso con TLS y cifrado en reposo, el servidor de MongoDB ve los datos en texto plano una vez descifrados del disco. Una cuenta de administrador de bases de datos comprometida, un ingeniero de la nube malintencionado con acceso al disco o una filtración de una copia de seguridad de la base de datos podrían exponer campos confidenciales. Client-Side Field Level Encryption (CSFLE) resuelve este problema cifrando campos confidenciales individuales —como números de la Seguridad Social, números de tarjetas de crédito o datos de salud— dentro del controlador del cliente, antes de que los datos lleguen al servidor. El servidor solo almacena texto cifrado.

CSFLE utiliza dos capas de claves. La Customer Master Key (CMK) se almacena en un sistema externo de gestión de claves (AWS KMS, Azure Key Vault, GCP KMS o una clave local). La CMK cifra una Data Encryption Key (DEK), que se almacena en una colección de MongoDB llamada Key Vault. El controlador obtiene y descifra la DEK mediante la CMK en el momento de la consulta y, a continuación, utiliza la DEK para cifrar o descifrar los valores de campos individuales. El servidor nunca ve la CMK ni la DEK en texto plano.

CSFLE ofrece dos modos de cifrado. Automatic CSFLE (requiere MongoDB Enterprise o Atlas) cifra y descifra campos de forma transparente según un esquema JSON; el código de su aplicación no cambia. Explicit (Manual) CSFLE está disponible en el controlador Community y requiere que la aplicación llame explícitamente a los métodos de cifrado y descifrado. El modo automático es mucho más práctico para proyectos nuevos; el explícito proporciona el máximo control sobre los campos que se cifran en cada operación.

Antes de cifrar datos, cree una colección Key Vault: una colección especial de MongoDB que almacena claves de cifrado de datos. El almacén de claves es simplemente una colección normal (por ejemplo, encryption.__keyVault), pero debe tener un índice único en el campo keyAltNames. Las DEK se almacenan como documentos BSON cuyo material de clave está cifrado mediante su CMK; incluso el almacén de claves solo guarda texto cifrado.

Use el asistente ClientEncryption para crear una DEK. La clave se cifra mediante su CMK (en este caso, una clave maestra local para desarrollo) y se almacena en el almacén de claves. En producción, sustituya el proveedor local por aws, azure o gcp y proporcione las credenciales de KMS. Puede crear varias DEK; por ejemplo, una por cada inquilino en una aplicación multiinquilino.

Para CSFLE automático, defina un encrypted fields map que indique al controlador qué campos debe cifrar y con qué algoritmo. AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic produce el mismo texto cifrado para el mismo texto plano, lo que permite realizar consultas de igualdad sobre campos cifrados. AEAD_AES_256_CBC_HMAC_SHA_512-Random produce un texto cifrado diferente cada vez; es más seguro, pero no permite realizar consultas.

Para habilitar CSFLE automático, configure MongoClient con la opción autoEncryption, proporcionando el espacio de nombres del almacén de claves, las credenciales de KMS y el mapa de campos cifrados. El controlador cifrará automáticamente los campos coincidentes al insertar o actualizar, y los descifrará al leerlos. No es necesario modificar las consultas de su aplicación.

Con el cifrado determinista, puede realizar consultas de igualdad sobre campos cifrados: el controlador cifra el valor de la consulta con la misma DEK antes de enviarlo al servidor, de modo que el servidor compara textos cifrados. Con el cifrado aleatorio, las consultas de igualdad no son posibles porque el mismo texto plano produce un texto cifrado diferente cada vez. CSFLE no admite consultas por rango ni consultas regex sobre campos cifrados.

CSFLE explícito le proporciona control por operación. Llame a encryption.encrypt() antes de insertar y a encryption.decrypt() después de leer. Esto funciona con los controladores de la edición Community sin requerir la biblioteca compartida de CSFLE automático. Es más detallado, pero ofrece flexibilidad total: puede cifrar distintos campos en distintos documentos con distintas DEK.

Rote las DEK periódicamente para limitar el periodo de exposición en caso de que una clave se vea comprometida. La rotación de claves en CSFLE consiste en crear una DEK nueva, volver a cifrar todos los documentos que utilizan la DEK antigua (campo por campo) y eliminar después la DEK antigua del almacén de claves. Este proceso puede realizarse mediante un script de migración en segundo plano sin tiempo de inactividad. La rotación de CMK en KMS (envolver la DEK) no requiere modificar en absoluto los documentos cifrados.

CSFLE tiene limitaciones importantes que debe prever: no se admiten operaciones del servidor sobre campos cifrados (no se admiten agregaciones, ordenaciones ni consultas por rango sobre campos cifrados, salvo las consultas de igualdad en campos deterministas); los cambios de esquema requieren reutilizar la DEK o volver a cifrar; CSFLE automático requiere MongoDB Enterprise o Atlas; y la sobrecarga de rendimiento del cifrado y descifrado en el controlador añade latencia. Diseñe su modelo de datos para minimizar los campos que necesitan cifrado.

En esta lección ha aprendido lo siguiente: CSFLE cifra los campos confidenciales dentro del controlador antes de que los datos lleguen al servidor, por lo que ni siquiera MongoDB ve otra cosa que texto cifrado; el cifrado determinista permite consultas de igualdad, mientras que el cifrado aleatorio ofrece mayor seguridad, pero no permite realizar consultas; y el modelo de claves de dos niveles (CMK en KMS que envuelve la DEK en el almacén de claves) mantiene las claves de cifrado fuera de MongoDB. A continuación exploraremos los patrones de diseño de esquemas de MongoDB.