Overview
En esta página, puedes aprender sobre los beneficios de seguridad de Queryable Encryption, cómo funciona y cómo se compara con otros mecanismos de seguridad soportados por MongoDB. También puedes ver un escenario ficticio que demuestra el valor de Queryable Encryption para proteger tus datos.
Queryable Encryption
Queryable Encryption es una funcionalidad de MongoDB que permite a una aplicación cliente cifrar datos antes de transportarlos por la red utilizando cifrado completamente aleatorio, manteniendo la capacidad de consulta. Los datos sensibles son cifrados y descifrados de manera transparente por el cliente y solo se comunican hacia y desde el servidor en forma cifrada. Las garantías de seguridad para los campos sensibles que contienen tanto datos de baja cardinalidad (de baja frecuencia) como datos de alta cardinalidad son idénticas.
Unlike El cifrado a nivel de campo del cliente que puede usar cifrado determinístico, Queryable Encryption utiliza esquemas de cifrado rápidos y buscables basados en cifrado estructurado. Estos esquemas producen diferentes valores de salida cifrados incluso cuando se les da la misma entrada de texto claro.
Consideraciones de seguridad
Queryable Encryption no proporciona ninguna garantía de integridad criptográfica contra adversarios que tengan acceso a su llave maestra de cliente o llaves de cifrado de datos.
Queryable Encryption no proporciona ninguna garantías de integridad criptográfica contra adversarios con acceso arbitrario de guardar a colecciones que contienen datos cifrado.
MongoDB utiliza la validación de esquema para aplicar el cifrado de campos específicos en una colección. Sin un esquema del lado del cliente, el cliente descarga el esquema del lado del servidor para la colección, a fin de determinar qué campos va a cifrar. Para evitar este problema, utilice la validación de esquemas del lado del cliente.
Dado que Queryable Encryption no proporciona un mecanismo para verificar la integridad de un esquema, depender de un esquema del lado del servidor implica confiar en que el esquema del servidor no ha sido alterado. Si un adversario compromete el servidor, puede modificar el esquema para que un campo previamente cifrado ya no esté etiquetado para cifrado. Esto provoca que el cliente envíe valores en texto plano para ese campo.
Para ver un ejemplo de configuración para los esquemas del cliente y del servidor, consulta el ejemplo de CSFLE en Implementación de la aplicación de cifrado a nivel de campo del lado del servidor de CSFLE.
Cómo funciona Queryable Encryption
El siguiente diagrama muestra el proceso y la arquitectura de cómo se utiliza Queryable Encryption en un entorno de cliente.
En este diagrama, el usuario puede consultar datos completamente cifrados de forma aleatoria, como un número de SSN.
El proceso y los mecanismos que hacen posible esto dentro del marco de Queryable Encryption son los siguientes:
Cuando la aplicación envía la query, los drivers de MongoDB primero analizan la query.
El driver reconoce que la query es sobre un campo cifrado y solicita las claves de cifrado al proveedor de claves proporcionado por el cliente, como:
AWS Key Management Service (AWS KMS)
Google Cloud KMS
Azure Key Vault
Any KMIP-proveedor de claves compatible
El conductor envía la query al servidor MongoDB con los campos cifrados procesados como texto cifrado.
Queryable Encryption implementa un esquema rápido y soporta búsquedas que permite al servidor procesar consultas sobre datos totalmente cifrados, sin saber nada sobre los datos. Los datos y la query en sí misma permanecen cifrados en todo momento en el servidor.
El servidor de MongoDB devuelve los resultados cifrados de la query al driver.
Los resultados de la query son descifrados con las claves mantenidas por el driver, devueltos al cliente y mostrados como texto claro.
Funciones de Queryable Encryption con la ayuda de las siguientes estructuras de datos. Es fundamental que estos no se modifiquen ni borren, o los resultados de la query serán incorrectos.
Queryable Encryption añade una
__safeContent__campo a documentos en cualquier colección donde haya un campo cifrado con Queryable Encryption.Queryable Encryption crea tres colecciones de metadatos en la misma base de datos que la colección en la que hay un campo cifrado de Queryable Encryption. Estos se nombran de la siguiente manera:
enxcol_.<collectionName>.escenxcol_.<collectionName>.eccenxcol_.<collectionName>.ecoc
Advertencia
No modifiques estas estructuras de datos, o los resultados de la query serán incorrectos y la seguridad podría verse afectada.
Queryable Encryption mantiene los campos cifrados seguros en los siguientes escenarios:
Acceso directo a campos cifrados por parte de un superusuario de base de datos
Acceso a campos cifrados mediante la lectura de la memoria del servidor
Captura de campos cifrados a través de una red insegura
Acceso a campos cifrados en disco mediante la lectura de la base de datos o archivos de copia de seguridad
Análisis de frecuencia mediante la identificación de patrones en documentos cifrados
Mientras que todos los clientes tienen acceso a los campos de datos no sensibles, solo los clientes de Queryable Encryption debidamente configurados pueden ejecutar consultas de lectura y escritura utilizando los campos de datos cifrados.
Importante
Sistema de Gestión Remota de Claves
Cuando utilices Queryable Encryption en producción, debes utilizar un sistema remoto de gestión de claves (KMS) para almacenar tu llave de cifrado.
Para ver una guía paso a paso que demuestre cómo utilizar un KMS remoto con Queryable Encryption, consulte Tutoriales.
Para ver una lista de todos los proveedores de KMS admitidos, consulta Proveedores de KMS.
Para más información sobre por qué debes utilizar un KMS remoto, consulta Razones para utilizar un KMS remoto.
Otros mecanismos de seguridad
Esta sección describe los siguientes mecanismos de seguridad admitidos por MongoDB y explica sus casos de uso y limitaciones:
Control de acceso basado en roles
El Control de Acceso Basado en Roles es un mecanismo de seguridad que permite a los administradores conceder y restringir permisos a nivel de colección para los usuarios. Con la definición y asignación de roles adecuada, esta solución previene la divulgación accidental de datos y el acceso no autorizado.
El control de acceso basado en roles no puede proteger ante los siguientes escenarios:
Captura de los datos a través de una red no segura
Acceso a los datos en disco leyendo archivos de bases de datos o de copias de seguridad
Acceso a datos mediante la lectura de la memoria del servidor
Acceso directo a los datos por parte de un superusuario de la base de datos
Para obtener más información, consulta Control de acceso basado en roles.
Cifrado en reposo
El cifrado en reposo es un mecanismo que cifra los archivos de la base de datos en el disco. Este mecanismo impide que una persona que carece de credenciales de base de datos, pero que tiene acceso a la computadora que aloja la base de datos, vea sus datos.
Este mecanismo no protege sus datos frente a los siguientes escenarios:
Captura de los datos a través de una red no segura
Acceso a datos mediante la lectura de la memoria del servidor
Acceso directo a los datos por parte de un superusuario de la base de datos
Para aprender más, consulte cifrado en reposo.
Cifrado de transporte (TLS/SSL)
El cifrado de transporte mediante TLS/SSL cifra tus datos a través de la red. TLS/SSL protege sus datos mientras viajan por una red insegura, pero no puede protegerlos de un usuario con privilegios o cuando están almacenados en disco.
Para aprender más, consulta Cifrado de transporte usando TLS/SSL
Comparación de funcionalidades
El siguiente diagrama describe las funcionalidades de seguridad que MongoDB admite y las posibles vulnerabilidades de seguridad que abordan:
Importante
Usa los mecanismos juntos
Para asegurar una implementación de producción, utiliza Control de Acceso Basado en Roles, cifrado en reposo, cifrado en tránsito y, opcionalmente, los mecanismos de seguridad de encriptación en uso juntos. Tenga en cuenta que no puede usar tanto el cifrado a nivel de campo del lado del cliente como el cifrado consultable para cifrar diferentes campos en la misma colección.
Para aprender más sobre el cifrado a nivel de campo del lado del cliente, consulte Funcionalidades del cifrado a nivel de campo del lado del cliente.
Scenario
El siguiente escenario ficticio demuestra el valor de Queryable Encryption para proteger los datos de su aplicación y cómo Queryable Encryption interactúa con el otro mecanismo de seguridad discutido en esta guía.
En este escenario, protegemos datos confidenciales en un sistema de gestión de atención médica que almacena la información personal, de facturación y los historiales médicos de los pacientes para una empresa ficticia, MedcoMD. Ningún dato del paciente es público, y datos específicos como su número de seguro social (SSN, un número de identificación emitido por el gobierno de EE. UU.), el número de identificación del paciente, la información de facturación y la información sobre medicamentos son especialmente confidenciales y están sujetos al cumplimiento de privacidad. Es importante para la empresa y el paciente que los datos se mantengan privados y seguros.
MedcoMD necesita este sistema para satisfacer los siguientes casos de uso:
Los médicos utilizan el sistema para acceder a los registros médicos de los pacientes, información de facturación y actualizar la medicación.
Los recepcionistas utilizan el sistema para verificar la identidad de los pacientes mediante su información de contacto.
Los recepcionistas pueden ver la información de facturación de un paciente, pero no su número de ID de paciente.
Los recepcionistas no pueden acceder a los registros médicos de un paciente.
MedcoMD también está preocupado por la divulgación de datos sensibles a través de cualquiera de los siguientes métodos:
Divulgación accidental de datos en la pantalla de una recepcionista visible al público.
Acceso directo a la base de datos por parte de un superusuario como un administrador de base de datos.
Captura de datos a través de una red no segura.
Acceso a los datos leyendo la memoria del servidor de base de datos.
Acceso a los datos mediante la lectura de la base de datos o de las copias de seguridad.
¿Qué puede hacer MedcoMD para equilibrar la funcionalidad y las restricciones de acceso de su sistema de gestión de atención médica?
Solución
MedcoMD utiliza los siguientes mecanismos de seguridad para satisfacer sus casos de uso y protegerse contra la divulgación de datos médicos sensibles:
Cifrado de transporte (TLS/SSL) para proteger los datos a medida que viajan por la red.
Cifrado en reposo para protegerse contra la divulgación de datos al leer bases de datos o archivos de respaldo.
Control de acceso basado en roles para limitar el acceso de los usuarios de la base de datos a las colecciones necesarias para que puedan realizar sus tareas.
Cifrar campos sensibles con cifrado consultable para satisfacer los siguientes casos de uso y restricciones:
Prevenir la lectura de datos de la memoria del servidor, ya que los datos cifrados con Queryable Encryption nunca se encuentran en el servidor de la base de datos en una forma sin cifrar.
Permitir que los recepcionistas verifiquen la identidad de los pacientes y eviten la divulgación accidental de datos sensibles en la pantalla visible al público de un recepcionista al proporcionar a los recepcionistas un cliente que no tenga habilitado Queryable Encryption.
Permitir que los médicos vean datos confidenciales de manera privada en sus consultorios proporcionando a los médicos un cliente habilitado con Queryable Encryption.
Obtén más información
Para ver una lista de medidas de seguridad que se deben implementar para proteger la implementación de MongoDB, consulte la Lista de verificación de seguridad.
Para empezar a usar Queryable Encryption, consulte la Guía de primeros pasos.