Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Cinco Configuraciones de Seguridad Críticas para MongoDB que Debe Implementar Ahora Mismo

Asegure sus datos al instante con esta guía sobre las cinco configuraciones de seguridad innegociables para MongoDB. Aprenda a pasar de configuraciones predeterminadas vulnerables a un entorno altamente protegido mediante la implementación de autenticación de usuario obligatoria, Control de Acceso Basado en Roles (RBAC) estricto, vinculación de IP de red y cifrado TLS de extremo a extremo. También cubrimos prácticas de auditoría cruciales necesarias para el cumplimiento y la detección inmediata de amenazas, proporcionando ejemplos de configuración prácticos para una acción inmediata.

36 vistas

Cinco Configuraciones de Seguridad Críticas de MongoDB que Debe Implementar Ahora

MongoDB es una base de datos de documentos NoSQL potente y flexible utilizada por millones de desarrolladores y empresas en todo el mundo. Sin embargo, la flexibilidad y la facilidad de implementación que hacen que MongoDB sea atractivo también pueden provocar vulnerabilidades de seguridad significativas si las configuraciones predeterminadas no se refuerzan de inmediato. Las primeras versiones de MongoDB sufrieron con frecuencia filtraciones de datos públicas, principalmente porque los valores predeterminados de seguridad eran demasiado permisivos.

Proteger su implementación de MongoDB no es opcional; es fundamental para mantener la integridad de los datos, la confidencialidad y el cumplimiento normativo. Esta guía describe cinco pasos de seguridad no negociables que deben implementarse en todos los entornos de MongoDB de producción y preproducción para evitar el acceso no autorizado y el robo de datos. Al implementar estas configuraciones, pasará de un estado predeterminado vulnerable a un clúster de bases de datos robusto y protegido.

1. Habilitar el Control de Acceso Obligatorio y la Autenticación Fuerte

Uno de los pasos más críticos para asegurar MongoDB es garantizar que la autenticación esté habilitada globalmente. De forma predeterminada, muchas implementaciones de MongoDB permiten conexiones sin credenciales a menos que se configure explícitamente lo contrario. Esta práctica es intrínsecamente peligrosa.

Cómo Habilitar la Autenticación

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

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

# /etc/mongod.conf snippet
security:
  authorization: enabled

Línea de Comandos:

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

Creación del Usuario Administrador

Una vez que el control de acceso está habilitado, debe crear un usuario administrativo con el rol userAdminAnyDatabase o root. Solo puede crear este usuario antes de que se reinicie el servicio con --auth habilitado, o deshabilitando temporalmente la autenticación para el paso de creación inicial si el sistema ya está en ejecución.

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 fuertes y complejas almacenadas de forma segura a través de un gestor de secretos. Nunca codifique credenciales sensibles directamente en scripts o archivos de configuración.

2. Implementar Control de Acceso Basado en Roles Granulares (RBAC)

Después de habilitar la autenticación, el siguiente paso es establecer el Principio del 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 las 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 Aplicación: 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 estrictamente 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 Enlace de Red Estricto y Cortafuegos

La configuración de red es la defensa perimetral de su base de datos. Por defecto, MongoDB a menudo se enlaza a todas las interfaces de red disponibles (0.0.0.0), lo que lo hace potencialmente accesible a toda la red o, peor aún, a la Internet pública si se ejecuta en una instancia en la nube sin las reglas de cortafuegos adecuadas.

Restringir bindIp

La principal medida de seguridad es definir la configuración bindIp en su archivo de configuración. Esto le indica 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 enlazar
# Use 127.0.0.1 solo para acceso local
# Use IP(s) internas solo para acceso desde servidores de aplicación
net:
  port: 27017
  bindIp: 127.0.0.1, 10.0.1.5, localhost

Implementar Cortafuegos Externos (Grupos de Seguridad)

Además de bindIp (que restringe el proceso de MongoDB), debe usar un cortafuegos 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 el tráfico entrante en el puerto de MongoDB (predeterminado 27017) desde sus servidores de aplicación, balanceadores de carga y jump boxes administrativos.

4. Imponer Cifrado para los Datos en Tránsito (TLS/SSL)

Los datos transmitidos entre los clientes (aplicaciones, shells, controladores) y el servidor de MongoDB deben cifrarse utilizando Seguridad de la Capa de Transporte (TLS) o Capa de Conexión Segura (SSL). El envío de credenciales, consultas y resultados a través de conexiones no cifradas expone los datos a posibles escuchas (ataques de intermediario).

MongoDB admite la configuración nativa de TLS/SSL tanto para cifrar el tráfico como para la validación opcional del certificado del cliente.

Habilitación de TLS/SSL

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:
  ssl:
    mode: requireTLS
    # Ruta al archivo combinado de certificado y clave
    serverCertificateKeyFile: /etc/ssl/mongodb.pem
    # Ruta al archivo de la Autoridad Certificadora (para validación del cliente)
    CAFile: /etc/ssl/ca.pem

Conexión del Cliente con TLS

Una vez que el servidor requiere TLS, todos los clientes deben conectarse utilizando las banderas seguras apropiadas:

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

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

5. Habilitar Auditoría y Monitorear Registros de Actividad

Incluso con un fuerte control de acceso y cifrado, 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 las acciones, lo cual es crucial para el cumplimiento normativo, el análisis forense y la detección de comportamientos sospechosos.

La Facilidad de Auditoría de MongoDB puede registrar acciones administrativas, intentos de autenticación, intentos de acceso no autorizados y, potencialmente, lecturas/escrituras de datos.

Configuración para 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
  # Concéntrese en eventos de seguridad clave como la autenticación y los cambios administrativos
  filter: '{ atype: { $in: [ "authenticate", "authorize", "createCollection", "createUser", "dropDatabase" ] } }'

Áreas de Enfoque Esenciales para el Monitoreo

  • 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.
  • Eliminación de Bases de Datos o Colecciones: Se requieren alertas inmediatas para operaciones destructivas.

Integre los registros de auditoría de MongoDB con sistemas de gestión de registros centralizados (por ejemplo, Splunk, ELK Stack, DataDog) para alertas en tiempo real y retención a largo plazo.

Conclusión

La implementación de estas cinco configuraciones críticas mueve su implementación de MongoDB de un estado de vulnerabilidad a uno de resiliencia. La seguridad en MongoDB no es una tarea de configurar y olvidar; es un proceso continuo. Asegúrese de que estas configuraciones —autenticación obligatoria, RBAC granular, enlace de red estricto, cifrado TLS y auditoría integral— se verifiquen durante cada implementación y se revisen periódicamente. Priorizar estos pasos mitigará significativamente el riesgo de acceso no autorizado y compromiso de datos.