Overview
En esta página, puede conocer las ventajas de seguridad del cifrado consultable, su funcionamiento y su comparación con otros mecanismos de seguridad compatibles con MongoDB. También puede ver un escenario ficticio que demuestra el valor del cifrado consultable para proteger sus datos.
Queryable Encryption
Queryable Encryption permite que una aplicación cliente encripte datos antes de transportarlos a través de la red utilizando cifrado totalmente aleatorio, manteniendo la capacidad de consulta. Los datos confidenciales se encriptan y desencriptan de manera transparente por parte del cliente y solo se comunican hacia y desde el servidor en forma cifrada.
Unlike El cifrado a nivel de campo del lado del cliente, que puede usar cifrado determinista, utiliza esquemas de cifrado rápidos y con capacidad de búsqueda basados en cifrado estructurado. Estos esquemas generan diferentes valores de salida cifrados incluso con la misma entrada de texto sin cifrar.
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 de Queryable Encryption son los siguientes:
Cuando la aplicación envía la consulta, los controladores MongoDB primero analizan la consulta.
El controlador reconoce que la consulta se realiza en un campo cifrado y solicita las claves de cifrado al proveedor de claves proporcionado por el cliente, como:
Servicio de administración de claves de AWS (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.
El cifrado consultable funciona con las siguientes estructuras de datos. Es fundamental que no se modifiquen ni eliminen, ya que los resultados de las consultas serán incorrectos.
Queryable Encryption añade una
__safeContent__campo a documentos en cualquier colección donde haya un campo cifrado con Queryable Encryption.El cifrado consultable crea dos colecciones de metadatos internos en la misma base de datos que la colección donde hay un campo cifrado de cifrado consultable. Estas se nombran de la siguiente manera:
enxcol_.<collectionName>.escenxcol_.<collectionName>.ecoc
Advertencia
No modifique estas estructuras de datos o los resultados de la consulta serán incorrectos y la seguridad podría verse afectada.
El cifrado consultable 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
Ataques de análisis de frecuencia mediante la identificación de patrones en documentos con campos 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 utiliza cifrado consultable en producción, debe utilizar un sistema de administración de claves (KMS) remoto para almacenar su clave de cifrado.
Para ver una guía paso a paso que demuestre cómo usar un KMS remoto con Queryable Encryption, consulte Tutoriales de Queryable Encryption.
Para ver una lista de todos los proveedores de KMS compatibles, consulte Proveedores de KMS.
Para obtener más información sobre por qué debería utilizar un KMS remoto, consulte Razones para utilizar un sistema de administración de claves remotas.
Otros mecanismos de seguridad
Esta sección describe los siguientes mecanismos de seguridad compatibles con 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 otorgar y restringir permisos a nivel de colección para los usuarios. Con la definición y asignación de roles adecuadas, esta solución evita la divulgación accidental de datos y el acceso.
El control de acceso basado en roles no puede proteger contra los siguientes escenarios:
Captura de datos a través de una red insegura
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,consulte 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 datos a través de una red insegura
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 sus datos en la red. TLS/SSL protege sus datos mientras viajan por una red insegura, pero no los protege de usuarios privilegiados ni mientras se almacenan en el disco.
Para aprender más, consulta Cifrado de transporte usando TLS/SSL
Comparación de funcionalidades
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.
La siguiente tabla describe las posibles amenazas de seguridad y cómo las funciones de cifrado de MongoDB las abordan. Utiliza estos mecanismos juntos: Control de acceso basado en roles, cifrado en reposo, cifrado de transporte y encriptación en uso. Ten en cuenta que no puedes usar tanto el cifrado a nivel de campo del lado del cliente como Queryable Encryption en la misma colección.
Importante
Este es un resumen a alto nivel destinado a la comparación general. Para obtener información detallada, consulta la Descripción general de Queryable Encryption y Diseño y análisis de un esquema de cifrado para bases de datos de documentos sin estado documentos técnicos.
Amenaza | Cifrado de transporte TLS/SSL | cifrado en reposo (EaR) | Cifrado consultable (igualdad) + TLS/SSL + EaR | CSFLE + TLS/SSL + EaR |
|---|---|---|---|---|
Espionaje de red (el atacante tiene acceso al tráfico de red) | Revela los metadatos de operaciones | Revela los metadatos de la operación | Revela los metadatos de la operación | Revela los metadatos de la operación |
Recuperaciones de bases de datos desde disco (el atacante tiene acceso físico al disco) | Revela la base de datos | Revela el tamaño de la base de datos y los metadatos de la operación | Revela el tamaño de la base de datos y los metadatos de la operación | Revela el tamaño de la base de datos y los metadatos de la operación |
Exfiltración de bases de datos desde el disco y la memoria (el atacante tiene acceso al disco físico y a múltiples instantáneas de la base de datos) []1 | Revela la base de datos | Revela la base de datos | Revela el tamaño de la base de datos y los metadatos de la operación | Revela la frecuencia de valores y los metadatos de la operación |
Amenaza Persistente Avanzada (el atacante tiene acceso a largo plazo y continuo a la red, disco y memoria sin ser detectado) | Revela la base de datos | Revela la base de datos | Queryable Encryption no está diseñada para proteger contra un ATP. Consulta el whitepaper para más detalles. | CSFLE no está diseñado para proteger contra un ATP. Consulta whitepaper para más detalles. |
| [1] | Esto asume que la exfiltración ocurre entre operaciones completadas. Consulte libro blanco para obtener más detalles. |
Advertencia
El cifrado consultable defiende contra la exfiltración de datos, no contra adversarios con acceso persistente a un entorno o aquellos que pueden recuperar instantáneas de bases de datos y transcripciones/registros de consultas correspondientes.
Al utilizar Queryable Encryption, las queries de igualdad y rango ofrecen una seguridad comparable contra atacantes que posean snapshots de bases de datos. Sin embargo, un atacante con acceso tanto a las snapshots de la base de datos como a la información de query escapa del alcance de las garantías de seguridad de Queryable Encryption. Esto es especialmente cierto para las consultas de rango, incluso si solo se recupera un pequeño número de transcripciones o registros de consultas. Consulta 6.1: Consultas de rango en el modelo persistente en el documento técnico general para más detalles.
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 por ejemplo 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 detransporte (TLS/SSL) para proteger los datos mientras 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.
Cifrado de campos sensibles con cifrado consultable para satisfacer los siguientes casos de uso y restricciones:
Evita la lectura de datos desde la memoria del servidor, ya que los datos cifrados con cifrado consultable nunca están en el servidor de base de datos en forma no cifrada.
Permita que los recepcionistas verifiquen las identidades de los pacientes y evite la divulgación accidental de datos confidenciales en la pantalla visible públicamente de un recepcionista proporcionándoles un cliente que no tenga habilitado el cifrado consultable.
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 las medidas de seguridad que debe implementar para proteger su implementación de MongoDB, consulte la Lista de verificación de seguridad.
Para empezar a usar Queryable Encryption, consulta el Inicio rápido de Queryable Encryption.