Seguridad en MongoDB 101: funciones clave que todo desarrollador debe conocer

MongoDB ofrece un marco de seguridad integral basado en tres principios: autenticación, autorización y cifrado.

Estos pilares conforman una defensa en capas para que un fallo no comprometa todo el sistema. La autorización se rige por el principio de mínimo privilegio (PoLP), garantizando que cada usuario o aplicación tenga solo los permisos imprescindibles para realizar sus tareas. 

Aplicar este enfoque integral y por capas refuerza tu postura de seguridad y reduce de forma significativa la exposición a errores de configuración o brechas. 

Abrir la primera compuerta: autenticación

La autenticación es el paso de seguridad fundamental. Verifica la identidad de todo principal que intenta conectarse. En MongoDB, se consigue habilitando funciones de seguridad que vienen desactivadas por defecto para facilitar el desarrollo local.

1. Comprender la configuración por defecto

De forma predeterminada, tu despliegue de MongoDB solo escucha en localhost y permite acceso sin autenticación. Es intencionado: busca la máxima facilidad en la configuración inicial y la experimentación local.

Para cualquier entorno de producción, hay dos ajustes que requieren tu atención:

• Estado de la autenticación: la autenticación está desactivada por defecto. Puedes habilitar la autorización con --auth o con el ajuste security.authorization. Habilitar la autenticación interna también habilita la autorización de clientes. Ten en cuenta que, una vez activado el control de acceso, los usuarios deben autenticarse.
• Enlace de red (bindIp): Por defecto, los binarios de MongoDB (mongod y mongos) solo se enlazan a localhost. Este valor seguro limita las conexiones a la misma máquina. En producción, debes configurar explícitamente bindIp para listar las IP de tus servidores de aplicaciones autorizados. Si necesitas soporte IPv6, puedes establecer el ajuste del fichero de configuración net.ipv6 o la opción de línea de comandos --ipv6, lo que hará que el binario también se enlace a la dirección IPv6 de localhost. Restringe siempre a las interfaces de red autorizadas.

2. Cómo habilitar la autenticación

Al habilitar la autenticación, MongoDB pasa de ser un entorno local de pruebas a un almacén de datos seguro. Se hace modificando el archivo de configuración de MongoDB (normalmente mongod.conf) y reiniciando el servidor.

Ajuste en el archivo de configuración: define la opción de autorización dentro de la sección security para activar la función:

  authorization: enabled

El primer usuario: una vez habilitada la autenticación, nadie puede conectarse hasta que crees un usuario administrativo. Este usuario inicial debe crearse en la base de datos admin, otorgándole los permisos necesarios para gestionar el sistema y crear otros usuarios.

3. Gestión de usuarios y contraseñas (createUser)

Tras habilitar la autorización, todo acceso a la base de datos queda gobernado por los usuarios y sus roles asociados. Utiliza el comando createUser para definir estas identidades.

Sintaxis y roles: al crear un usuario, especificas su nombre, contraseña y un array de roles. Los roles definen sus permisos (p. ej., readWrite sobre una base de datos concreta).

db.createUser(
   {
     user: "appUser",
     pwd: passwordPrompt(),  // Esta función solicita una contraseña, lo que 
                                              // evita guardar la contraseña en texto plano en el 
                                              // historial del shell y los registros de comandos.
     roles: [ { role: "readWrite", db: "inventory" } ]
   }
)

Estándar SCRAM: MongoDB se basa en el mecanismo de autenticación por desafío con sal (SCRAM) para gestionar contraseñas de forma segura. SCRAM evita almacenar contraseñas en texto plano y utiliza hashing y salado criptográficamente robustos, lo que lo hace resistente a ataques comunes como las rainbow tables.

4. Opciones avanzadas de autenticación

Para organizaciones con fuertes requisitos de cumplimiento o infraestructuras complejas, MongoDB se integra con sistemas de autenticación empresariales existentes:

• Certificados de cliente x.509: permiten a los clientes autenticarse con certificados digitales en lugar de contraseñas, aportando una verificación de identidad sólida, habitual en confianza máquina a máquina.
• LDAP/Kerberos: integra MongoDB con servicios externos como Active Directory u OpenLDAP, permitiendo usar las credenciales corporativas existentes para acceder a la base de datos.
• Autenticación OpenID Connect (OIDC) - Workforce y Workloads: para entornos modernos cloud-native e híbridos, MongoDB admite federación de identidad tanto para Workforce (acceso de usuarios vía IdPs como Azure AD, Okta) como para Workload (autenticación entre servicios usando identidad del proveedor cloud, p. ej., AWS IAM o Google Cloud Service Accounts).

Autorización: definir roles con RBAC

La autenticación confirma quién es un usuario; la autorización determina qué puede hacer. El sistema de control de acceso basado en roles (RBAC) de MongoDB es el mecanismo central de gestión de permisos, asegurando que usuarios y servicios solo interactúen con los datos y comandos estrictamente necesarios.

1. Control de acceso basado en roles

En el modelo RBAC de MongoDB, los permisos se agrupan en roles y estos roles se asignan a usuarios. En lugar de asignar cientos de permisos individuales, asignas un único rol (p. ej., inventoryReader), que ya incluye el conjunto de permisos definidos (p. ej., lectura sobre inventory.products). Esto hace que la gestión de permisos sea escalable y auditable.

2. Roles integrados que todo desarrollador debe conocer

MongoDB incluye un conjunto sólido de roles integrados que cubren los patrones de acceso más comunes. A continuación tienes algunos ejemplos. Para la lista completa, consulta el enlace anterior.

• read y readWrite (acceso a nivel de base de datos): los roles más habituales para usuarios de aplicación. Conceden acceso de solo lectura o lectura/escritura, respectivamente, sobre todas las colecciones no del sistema dentro de una base de datos concreta.
• dbAdmin: otorga permisos administrativos necesarios para gestionar una base de datos específica, como crear, eliminar y modificar índices y colecciones. Es adecuado para equipos de desarrollo o scripts de mantenimiento.
• clusterAdmin (acceso operativo): rol de alto privilegio reservado generalmente para personal de operaciones (DevOps/Ops). Concede permisos para gestionar todo el despliegue de MongoDB, incluida la configuración de réplicas, sharding y copias de seguridad. Los desarrolladores de aplicaciones rara vez necesitan este rol.

3. Implementar el principio de mínimo privilegio

La piedra angular de la seguridad moderna en bases de datos es el principio de mínimo privilegio (PoLP). Establece que cada usuario (especialmente los de aplicación) debe tener los permisos mínimos indispensables para realizar sus tareas, y nada más.

Ejemplo de buena práctica: en lugar de usar un usuario readWrite global, crea usuarios específicos por aplicación. Por ejemplo, si tu servicio de inventario solo interactúa con la base de datos app_data, el usuario de la aplicación solo debería tener acceso readWrite a esa única base de datos. Este compartimentado evita que, si se compromete el servicio, acceda sin autorización a otras bases (como billing o users).

Ejemplo de código: crear un usuario de mínimo privilegio

Este ejemplo crea un usuario (inventory_service) con acceso de lectura/escritura limitado estrictamente a la base de datos app_data.

use admin
db.createUser(
   {
     user: "inventory_service",
     pwd: passwordPrompt(),
     roles: [ 
       { role: "readWrite", db: "app_data" }
     ]
   }
)

4. Crear roles personalizados (cuando lo integrado no basta)

Aunque los roles integrados son potentes, el cumplimiento normativo o lógicas complejas pueden requerir un control muy granular. En estos casos, MongoDB te permite definir roles personalizados con el comando db.createRole().

Definir permisos granulares: los roles personalizados te permiten especificar exactamente qué acciones de privilegio (p. ej., find, update, insert) se pueden realizar sobre recursos a nivel de clúster, base de datos o colección. Las organizaciones pueden aplicar técnicas como redacción a nivel de campo para proteger campos altamente sensibles dentro de una colección por lo demás pública.

Ejemplo de código: crear un rol personalizado

Este ejemplo crea un rol personalizado (product_creator) que solo puede insertar documentos en la colección products de la base de datos app_data.

use app_data
db.createRole(
   {
     role: "product_creator",
     privileges: [
       {
         resource: { db: "app_data", collection: "products" },
         actions: [ "insert" ]
       }
     ],
     roles: []
   }
)

Protección de datos integral: aislamiento de red y cifrado

Aunque una buena autenticación y autorización controlan el acceso, la seguridad completa exige proteger los datos en sí, tanto cuando viajan por la red (en tránsito) como cuando se almacenan en disco (en reposo).

1. Proteger los datos en tránsito con TLS/SSL

Toda transmisión de datos por red, ya sea interna en un centro de datos o externa en la nube, debe cifrarse para evitar escuchas y ataques man-in-the-middle (MITM). MongoDB usa Transport Layer Security/Secure Sockets Layer (TLS/SSL) para cifrar todas las comunicaciones entre clientes (como tu aplicación) y el servidor.

Sin TLS/SSL, credenciales, parámetros de consulta y resultados sensibles viajarían en texto plano, fáciles de interceptar. Al habilitar TLS/SSL, los datos se cifran durante la transmisión.

Habilitar TLS/SSL: se hace principalmente mediante ajustes de configuración, donde indicas los certificados que usará el servidor para verificar su identidad e intercambiar claves de cifrado:

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem

• net.ssl.mode: requireTLS obliga a que todas las conexiones entrantes usen TLS/SSL, rechazando intentos inseguros.
• certificateKeyFile apunta a tu certificado TLS/SSL generado y al fichero de la Autoridad Certificadora, respectivamente.

2. Cortafuegos y segmentación de red

La segmentación de red añade una capa clave de defensa al limitar las interfaces físicas o virtuales que pueden conectarse a la base de datos. Incluso si un atacante alcanza la red, aún deberá superar tu perímetro.

• Restringir acceso mediante listas blancas de IP: con el ajuste bindIp o configurando cortafuegos, puedes permitir solo direcciones IP específicas.
• Mejor práctica: el servidor de MongoDB debe estar expuesto solo a tus servidores de aplicaciones, balanceador o capa de proxy. Nunca debería ser accesible directamente desde Internet. Esta segmentación mantiene la base de datos protegida tras el perímetro de seguridad de tu infraestructura de aplicaciones.

3. Cifrado en reposo (cifrado del motor de almacenamiento)

Proteger los datos en reposo garantiza que, si se compromete el disco físico o el host, los ficheros sigan siendo ilegibles. MongoDB lo consigue con cifrado del motor de almacenamiento.

• Cómo funciona: el motor de almacenamiento WiredTiger puede configurarse para cifrar todos los ficheros de datos, configuración y journal en disco. Los datos se cifran de forma transparente al escribirlos y se descifran al leerlos, con una clave de cifrado gestionada por el sistema.
• Consideración crucial: aunque es una capa crítica, el cifrado nativo en reposo suele ser una función de MongoDB Enterprise y depende de servidores KMIP (Key Management Interoperability Protocol) externos o de claves locales para gestionar las claves de cifrado.

4. Client-Side Field Level Encryption (CSFLE): el estándar de oro para desarrolladores

Mientras que el cifrado en reposo protege toda la base de datos, la Client-Side Field Level Encryption (CSFLE) da al desarrollador precisión quirúrgica sobre los datos sensibles, permitiendo cifrar campos concretos antes de enviarlos a la base de datos.

• Introducción a CSFLE: con CSFLE, el cifrado ocurre en el driver de la aplicación antes de que los datos salgan del servidor de aplicaciones. El servidor de MongoDB nunca ve los datos sensibles en claro; solo almacena el ciphertext. Los datos sensibles permanecen cifrados en todo momento en el servidor, incluida la memoria, los registros y el almacenamiento.
• La herramienta más potente del desarrollador: CSFLE es el estándar de oro para el cumplimiento (p. ej., RGPD, HIPAA), ya que asegura que, incluso ante una brecha total, los campos sensibles (como PII o información financiera) sigan cifrados y protegidos. Los desarrolladores deben decidir activamente qué cifrar, integrando la lógica de cifrado en su código.

5. Cifrado en uso con Queryable Encryption

Queryable Encryption es una evolución de CSFLE que resuelve el reto de consultar campos cifrados. Permite realizar consultas de igualdad (p. ej., buscar documentos donde un campo cifrado sea igual a un valor) directamente sobre el ciphertext. Aporta la seguridad de CSFLE manteniendo la utilidad de los datos, cifrándolos efectivamente en uso.

Auditoría: la herramienta para el post mortem

Las medidas de seguridad se centran en la prevención, pero la auditoría trata de la responsabilidad y la detección. El marco de auditoría integrado de MongoDB permite registrar eventos relevantes de seguridad, creando un registro inmutable esencial para forense, cumplimiento y detección proactiva de amenazas.

1. ¿Qué es la auditoría y por qué importa?

La auditoría registra toda acción crítica sobre la base de datos, creando un historial detallado. Esto incluye:

• Eventos de autenticación: intentos de inicio de sesión correctos y fallidos.
• Cambios de autorización: creación, modificación o eliminación de usuarios y roles.
• Cambios de configuración: modificaciones de parámetros del sistema que afectan a la seguridad.

Este registro es valioso para análisis tras incidentes (la herramienta de «post mortem») o para cumplir normativas.

2. Configuración y filtrado

Habilitar la auditoría es sencillo, a menudo con una sola línea en la configuración para activar el sistema y definir el destino del log (fichero, syslog o consola).

auditLog:
  destination: file
  format: BSON
  path: /var/log/mongodb/audit.bson
  filter: '{ atype: { $in: [ "authenticate", "createRole", "dropUser" ] } }'

• Filtrado: el sistema de auditoría permite un filtrado muy granular con una sintaxis similar a consultas. Es clave para gestionar el volumen de logs. Centra el filtro en eventos críticos de seguridad, como gestión de usuarios, cambios en configuración de seguridad e intentos de autenticación.

Resumen y próximos pasos

MongoDB proporciona un conjunto de funciones de seguridad que, bien desplegadas, crean una sólida estrategia de defensa en profundidad. Tu misión como desarrollador es ir más allá de los valores por defecto de desarrollo e implementar estos controles clave.

Antes de llevar cualquier aplicación a producción, recuerda estos tres mandatos clave:

• Cifra los datos en tránsito: usa TLS/SSL en todas las conexiones de red (net.ssl.mode: requireTLS).
• Cifra los datos en reposo: asegura los ficheros en disco con cifrado a nivel de volumen o sistema de ficheros, o con el cifrado del motor WiredTiger (disponible en MongoDB Enterprise) para protegerte ante accesos no autorizados a los ficheros de la base de datos.
• Cifra los datos en uso: usa Client-Side Field Level Encryption (CSFLE) y Queryable Encryption para campos altamente sensibles, garantizando que sigan cifrados incluso mientras la base de datos está en funcionamiento.

La seguridad evoluciona constantemente. Para profundizar y ver configuraciones avanzadas, consulta la documentación oficial:

• Centro de seguridad de MongoDB: explora guías para reforzar despliegues y prácticas operativas de seguridad.
• Documentación de cifrado en uso: aprende a implementar Client-Side Field Level Encryption (CSFLE) y su capacidad avanzada, Queryable Encryption (QE), para que tus datos sensibles sigan siendo confidenciales y a la vez consultables de forma eficiente mientras están en uso.

También te recomiendo echar un vistazo al curso Introduction to Using MongoDB for Data Science in Python.