Overview
En esta página, puede conocer las ventajas de seguridad del cifrado a nivel de campo del lado del cliente (CSFLE) y compararlo con otros mecanismos de seguridad compatibles con MongoDB. También puede ver un escenario ficticio que demuestra el valor de CSFLE para proteger sus datos.
Encriptación a nivel de campo
El cifrado a nivel de campo del lado del cliente (CSFLE) es una función de MongoDB que permite a una aplicación cliente cifrar datos antes de transportarlos por la red. El cliente cifra y descifra los datos confidenciales de forma transparente, y solo se comunican hacia y desde el servidor de forma cifrada. CSFLE mantiene los campos cifrados seguros en los siguientes casos:
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 el disco mediante la lectura de archivos de base de datos o de respaldo
Si bien todos los clientes tienen acceso a los campos de datos no confidenciales, solo los clientes de CSFLE debidamente configurados pueden leer y guardar los campos de datos cifrados.
Importante
Sistema de gestión remota de claves
Cuando utiliza CSFLE 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 demuestra cómo usar un KMS remoto con CSFLE, consulte Tutoriales de CSFLE.
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 los 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 base de datos en disco. Este mecanismo impide que una persona sin credenciales de base de datos, pero con acceso al equipo que la aloja, pueda ver sus datos.
Este mecanismo no protege sus datos ante los siguientes escenarios:
Captura de datos a través de una red insegura
Acceso a los 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 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 características
Para obtener más información sobre el cifrado consultable, consulte Características del cifrado consultable.
La siguiente tabla describe las posibles amenazas a la seguridad y cómo las funciones de cifrado de MongoDB las abordan. Utilice estos mecanismos en conjunto: Control de Acceso Basado en Roles, Cifrado en Reposo, Cifrado de Transporte y Cifrado en Uso. Tenga en cuenta que no se puede usar el Cifrado a Nivel de Campo del Lado del Cliente y el Cifrado Consultable en la misma colección.
Importante
Este es un resumen general para fines comparativos. Para obtener información detallada, consulte la sección "Descripción general del cifrado consultable".y documentos técnicos sobre diseño y análisis de un esquema de cifrado de bases de datos de documentos sin estado.
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 la red) | Revela metadatos de la operación | Revela metadatos de la operación | Revela metadatos de la operación | Revela 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 metadatos de operación |
Amenaza persistente avanzada (el atacante tiene acceso continuo y a largo plazo a la red, el disco y la memoria sin ser detectado) | Revela la base de datos | Revela la base de datos | CSFLE no está diseñado para proteger contra un ATP. Consulta whitepaper para más detalles. |
| [1] | Esto supone que la exfiltración se produce entre operaciones completadas. Consulte el informe técnico para obtener más información. |
Scenario
El siguiente escenario ficticio demuestra el valor del cifrado a nivel de campo del lado del cliente (CSFLE) para proteger los datos de su aplicación y cómo CSFLE interactúa con los demás mecanismos de seguridad analizados en esta guía.
En este escenario, protegemos datos confidenciales en un sistema de gestión de atención médica que almacena información personal, información de seguros e historiales médicos de pacientes para una empresa ficticia, MedcoMD. Ninguno de los datos de los pacientes 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.), número de póliza de seguro y mediciones de constantes vitales son particularmente confidenciales y están sujetos a las normas 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, a la información del seguro y agregar nuevas mediciones de signos vitales.
Los recepcionistas utilizan el sistema para verificar la identidad de los pacientes utilizando su información de contacto.
Los recepcionistas pueden ver el proveedor de la póliza de seguro de un paciente, pero no su número de póliza.
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 visible públicamente de una recepcionista.
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 insegura.
Acceso a los datos mediante la lectura de la memoria del servidor de base de datos.
Acceso a los datos mediante la lectura de bases de datos o archivos de respaldo.
¿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 confidenciales:
Cifrado detransporte (TLS/SSL) para proteger los datos mientras viajan por la red.
Cifrado en reposo para proteger contra la divulgación de datos mediante la lectura de 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 CSFLE para satisfacer los siguientes casos de uso y restricciones:
Evite la lectura de datos desde la memoria del servidor, ya que los datos cifrados por CSFLE nunca se encuentran en el servidor de base de datos sin cifrar.
Permitir que los recepcionistas verifiquen las identidades de los pacientes y evitar la divulgación accidental de datos confidenciales en la pantalla visible públicamente de un recepcionista proporcionándoles un cliente que no esté habilitado para CSFLE.
Permita que los médicos vean datos confidenciales de forma privada en sus consultorios proporcionándoles un cliente habilitado para CSFLE.
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 obtener más información sobre CSFLE y el cumplimiento, consulte este artículo.
Para comenzar a usar CSFLE, se puede consultar el Inicio rápido de CSFLE.