Cinco configuraciones críticas de seguridad de MongoDB que debe implementar ahora

Los problemas de seguridad de MongoDB generalmente comienzan con un simple error: una base de datos escucha donde no debería, acepta usuarios que no debería o envía tráfico sin cifrado. Su configuración de MongoDB necesita autenticación explícita, roles limitados, exposición de red privada, TLS y registros de auditoría útiles.

Esta guía muestra cinco comprobaciones de producción que reducen la posibilidad de acceso no autorizado y facilitan la investigación de actividades sospechosas.

---

1. Habilitar el control de acceso obligatorio y la autenticación sólida

Comience asegurándose de que la autorización esté habilitada. Sin ella, un cliente que pueda alcanzar el servidor podría leer o cambiar datos dependiendo de cómo se inició y configuró la implementación.

Cómo habilitar la autenticación

La autenticación generalmente se habilita a través del archivo de configuración (mongod.conf) o los indicadores de línea de comandos durante el inicio.

Archivo de configuración (/etc/mongod.conf):

# Fragmento de /etc/mongod.conf
security:
  authorization: enabled

Línea de comandos:

mongod --auth --dbpath /var/lib/mongodb

Creación del usuario administrador

Cree el primer usuario administrativo antes de habilitar la autorización, o use la excepción de localhost de MongoDB durante la configuración inicial. Después de que exista el primer usuario, reinicie con la autorización habilitada y use cuentas nombradas para todo el acceso.

Ejemplo: Creación del usuario raíz a través de mongosh

Primero, conéctese a la base de datos (si ya se está ejecutando sin autenticación, o usando la excepción de localhost):

use admin
db.createUser(
  {
    user: "mongoAdmin",
    pwd: passwordPrompt(), // Solicita la contraseña de forma segura
    roles: [ { role: "root", db: "admin" } ]
  }
)

Advertencia: Utilice siempre contraseñas seguras almacenadas en un administrador de secretos. Nunca codifique credenciales sensibles en scripts o archivos de configuración.

2. Implementar control de acceso basado en roles (RBAC) granular

Después de habilitar la autenticación, el siguiente paso es establecer el Principio de Mínimo Privilegio (PoLP). Esto significa que cada usuario, aplicación y cuenta de servicio solo debe tener los permisos mínimos necesarios para realizar sus tareas requeridas.

Evite usar los roles root o readWriteAnyDatabase para conexiones de aplicaciones. En su lugar, defina roles personalizados que otorguen permisos específicos en bases de datos o colecciones específicas.

Pasos prácticos de RBAC

1. Definir roles personalizados: Si los roles integrados (read, readWrite) son insuficientes, cree roles con acciones de acceso detalladas (por ejemplo, solo insert y find en una colección específica).
2. Separar usuarios de aplicaciones: Cree usuarios dedicados para diferentes niveles de aplicación (por ejemplo, app_rw para el backend, reporting_ro para análisis).
3. Limitar el acceso de herramientas externas: Asegúrese de que las herramientas de administración solo se conecten usando cuentas privilegiadas cuando sea absolutamente necesario.

Ejemplo: Creación de un usuario de solo lectura para una base de datos específica

use users_db
db.createUser(
  {
    user: "reporting_svc",
    pwd: passwordPrompt(),
    roles: [ { role: "read", db: "users_db" } ] // Solo acceso de lectura a users_db
  }
)

3. Configurar la vinculación de red estricta y los firewalls

La configuración de red es la defensa perimetral de su base de datos. Muchas instalaciones empaquetadas de MongoDB se vinculan a localhost de forma predeterminada, pero las imágenes de contenedor, las líneas de comandos personalizadas y los archivos de configuración copiados pueden exponer 0.0.0.0. Siempre verifique el bindIp efectivo en lugar de asumir que el valor predeterminado es seguro.

Restringir bindIp

La medida de seguridad principal es definir la configuración bindIp en su archivo de configuración. Esto le dice explícitamente a MongoDB en qué direcciones IP o nombres de host debe escuchar.

Archivo de configuración (/etc/mongod.conf):

# Lista de IPs o nombres de host a los que vincularse
# Use 127.0.0.1 para acceso solo local
# Use IP(s) interna(s) para acceso solo desde servidores de aplicaciones
net:
  port: 27017
  bindIp: 127.0.0.1, 10.0.1.5, localhost

Implementar firewalls externos (grupos de seguridad)

Además de bindIp (que restringe el proceso de MongoDB), debe usar un firewall externo (como iptables, Grupos de Seguridad de AWS o Grupos de Seguridad de Red de Azure) para filtrar el tráfico antes de que llegue al servidor.

Mejor práctica: Solo permita tráfico entrante en el puerto de MongoDB (predeterminado 27017) desde sus servidores de aplicaciones, balanceadores de carga y cajas de salto administrativas.

4. Aplicar cifrado para datos en tránsito (TLS)

Los datos transmitidos entre clientes, shells, controladores y MongoDB deben cifrarse con Seguridad de la Capa de Transporte (TLS). Enviar credenciales, consultas y resultados a través de conexiones no cifradas expone los datos a escuchas y ataques de intermediario.

MongoDB admite la configuración TLS nativa tanto para tráfico cifrado como para la validación opcional de certificados de cliente.

Habilitación de TLS

Para habilitar el cifrado, debe generar u obtener certificados TLS válidos y especificar su ubicación en el archivo de configuración.

Archivo de configuración (/etc/mongod.conf):

net:
  tls:
    mode: requireTLS
    # Ruta al archivo combinado de certificado y clave
    certificateKeyFile: /etc/ssl/mongodb.pem
    # Ruta al archivo de la Autoridad Certificadora (para validación del cliente)
    CAFile: /etc/ssl/ca.pem

Conexión de cliente con TLS

Una vez que el servidor requiere TLS, todos los clientes deben conectarse usando los indicadores seguros apropiados:

mongosh "mongodb://[email protected]/admin?authSource=admin" --tls --tlsCAFile /path/to/ca.pem

Consejo: Use mode: requireTLS en producción para asegurar que todas las conexiones estén protegidas. El modo preferTLS generalmente solo se usa durante la migración o las pruebas.

5. Habilitar la auditoría y monitorear los registros de actividad

Incluso con un control de acceso y cifrado sólidos, las amenazas de seguridad pueden surgir de cuentas internas comprometidas o escalada de privilegios. Habilitar una auditoría integral proporciona un registro histórico de acciones, que es crucial para el cumplimiento normativo, el análisis forense y la detección de comportamientos sospechosos.

La función de auditoría de MongoDB puede registrar acciones administrativas, intentos de autenticación, fallos de autorización y operaciones de datos seleccionadas. La disponibilidad depende de su edición o plataforma de MongoDB; por ejemplo, la auditoría está disponible en MongoDB Enterprise y MongoDB Atlas, mientras que las implementaciones comunitarias autogestionadas necesitan otros enfoques de registro y monitoreo.

Configuración para la auditoría

La auditoría se configura a través de la sección auditLog en el archivo de configuración. Puede especificar el destino (archivo, syslog, consola) y los criterios de filtro.

Archivo de configuración (/etc/mongod.conf):

auditLog:
  destination: file
  path: /var/log/mongodb/audit.log
  format: JSON
  # Enfocarse en eventos de seguridad clave como autenticación y cambios administrativos
  filter: '{ atype: { $in: [ "authenticate", "authCheck", "createCollection", "createUser", "dropDatabase" ] } }'

Áreas de enfoque de monitoreo esenciales

• Intentos de autenticación fallidos: Un aumento repentino indica un posible ataque de fuerza bruta.
• Creación/eliminación de usuarios/roles: Todos los cambios de privilegios deben registrarse y revisarse.
• Eliminaciones de bases de datos o colecciones: Se requieren alertas inmediatas para operaciones destructivas.

Integre los registros de auditoría de MongoDB con sistemas centralizados de gestión de registros como Splunk, Elastic Stack o Datadog para alertas y retención.

Conclusión

Revise estos cinco controles durante cada implementación de MongoDB: la autorización está habilitada, los usuarios de la aplicación tienen roles limitados, bindIp y los firewalls limitan el acceso a la red, los clientes requieren TLS y los eventos de seguridad fluyen hacia su sistema de monitoreo. Estas comprobaciones no reemplazan las copias de seguridad, la aplicación de parches o la rotación de secretos, pero cierran primero las brechas de configuración más comunes.