Overview
En esta página, puedes aprender sobre los beneficios de seguridad del cifrado a nivel de campo del lado del cliente (CSFLE), y cómo CSFLE se compara con otros mecanismos de seguridad compatibles con MongoDB. También puedes ver un escenario ficticio que demuestra el valor de CSFLE en la protección de tus datos.
Encriptación a nivel de campo
El cifrado a nivel de campo del lado del cliente (CSFLE) es una funcionalidad de MongoDB que permite a una aplicación cliente cifrar datos antes de transportarlos a través de la red. 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. CSFLE mantiene seguros los campos cifrados 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
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 utilices CSFLE en producción, debes usar un Sistema de gestión de claves (KMS) remoto para almacenar tu clave de cifrado.
Para ver una guía paso a paso que demuestre cómo usar un KMS remoto con CSFLE, consulta CSFLE Tutorials.
Para ver una lista de todos los proveedores de KMS admitidos, consulta Proveedores de KMS.
Para aprender más sobre por qué deberías utilizar un KMS remoto, consulta Razones para utilizar un sistema de gestión de claves 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
Para aprender más sobre Queryable Encryption, consulta Funcionalidades de Queryable Encryption.
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) | Queryable Encryption (igualdad) + TLS/SSL + E&D | 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 operación | Revela el tamaño de la base de datos y los metadatos de operación | Revela el tamaño de la base de datos y los metadatos de operación |
Exfiltración de base de datos desde disco y memoria (el atacante tiene acceso físico al disco y 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 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. |
Scenario
El siguiente escenario ficticio demuestra el valor del cifrado a nivel de campo del lado del cliente (CSFLE) para proteger la información de tu aplicación y cómo CSFLE interactúa con el otro mecanismo de seguridad que se menciona en esta guía.
En este escenario, se securiza la información sensible en un sistema de gestión de atención médica que almacena información personal de los pacientes, datos de seguros y registros médicos de una empresa ficticia, MedcoMD. Ningún dato del paciente es público, y los datos específicos como el número de seguro social (SSN, un número de identificación emitido por el gobierno de Estados Unidos), el número de póliza de seguro y las mediciones de signos vitales son especialmente sensibles y están sujetos al cumplimiento de las normativas 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 usan el sistema para acceder a los registros médicos de los pacientes, información de seguros y agregar nuevas mediciones de signos vitales.
Los recepcionistas utilizan el sistema para verificar la identidad de los pacientes mediante 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 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.
Encriptar campos sensibles con CSFLE para cumplir con 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.
Permite que los recepcionistas verifiquen la identidad de los pacientes y eviten la divulgación accidental de datos sensibles en la pantalla de un recepcionista visible al público, proporcionando a los recepcionistas un cliente que no esté habilitado para CSFLE.
Permitir que los médicos vean datos sensibles de forma privada en sus consultorios proporcionándoles un cliente habilitado con CSFLE.
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 comenzar a usar CSFLE, se puede consultar el Inicio rápido de CSFLE.