🎨 Sysprovider Code
Sysprovider LogoWiki
🇪🇸Hosting español para ecommerce

Seguridad en bases de datos NoSQL: Cifrado, auditoría y control de acceso en MongoDB 8

Actualizado el 22 de abril de 2026

Introducción: El nuevo paradigma de seguridad en MongoDB 8

La adopción de bases de datos NoSQL ha crecido exponencialmente, y con ella, la necesidad de implementar estrategias de seguridad robustas. MongoDB 8, la última versión estable del popular sistema de gestión de bases de datos orientado a documentos, introduce mejoras significativas en seguridad MongoDB, especialmente en áreas críticas como el cifrado, la auditoría y el control de acceso. Este artículo profundiza en las capacidades de seguridad de MongoDB 8, ofreciendo una guía práctica para administradores de sistemas y arquitectos de datos que buscan cumplir con las normativas datos más exigentes, como GDPR, HIPAA o PCI-DSS.


Cifrado en MongoDB 8: Protegiendo los datos en reposo y en tránsito

El cifrado bases de datos es la primera línea de defensa contra accesos no autorizados. MongoDB 8 ofrece dos modalidades principales: cifrado en tránsito (TLS/SSL) y cifrado en reposo (a nivel de motor de almacenamiento y a nivel de campo).

Cifrado en tránsito con TLS/SSL

Toda comunicación entre clientes, servidores miembros de un replica set y nodos de un clúster compartido debe viajar cifrada. MongoDB 8 exige por defecto conexiones TLS 1.3, aunque permite configurar versiones anteriores para compatibilidad.

Configuración básica en mongod.conf:

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
    CAFile: /etc/ssl/ca.pem
    allowConnectionsWithoutCertificates: false

[TIP] Utiliza certificados firmados por una CA interna en entornos de desarrollo y certificados públicos de confianza en producción. Evita certificados autofirmados en clústeres críticos.

Cifrado en reposo con WiredTiger Encryption at Rest

El motor de almacenamiento WiredTiger, predeterminado en MongoDB 8, soporta cifrado nativo a nivel de página. Utiliza AES-256-CBC o AES-256-GCM, protegiendo los archivos de datos incluso si alguien accede físicamente al disco.

Habilitación del cifrado en reposo:

storage:
  wiredTiger:
    engineConfig:
      encryptWithCipher: "AES256-GCM"
      encryptionKeyManager:
        keyIdentifier: "my-key-id"
        keyVaultNamespace: "admin.keyvault"

[WARNING] El cifrado en reposo no protege contra ataques de inyección ni accesos no autorizados a través de la aplicación. Es solo una capa adicional de seguridad a nivel de almacenamiento.

Cifrado a nivel de campo (Field-Level Encryption)

MongoDB 8 introduce el cifrado determinista y aleatorio a nivel de campo, permitiendo que datos sensibles como números de tarjetas de crédito o historiales médicos se almacenen cifrados incluso dentro de la base de datos. Solo las aplicaciones con las claves adecuadas pueden leerlos.

Ejemplo de configuración con CSFLE (Client-Side Field Level Encryption):

const client = new MongoClient(uri, {
  autoEncryption: {
    keyVaultNamespace: "encryption.__keyVault",
    kmsProviders: {
      local: {
        key: localMasterKey
      }
    },
    schemaMap: {
      "miDB.pacientes": {
        bsonType: "object",
        properties: {
          numeroSeguroSocial: {
            encrypt: {
              bsonType: "string",
              algorithm: "AEAD_AES_256_CBC_HMAC_SHA_512-Deterministic"
            }
          }
        }
      }
    }
  }
});

Auditoría NoSQL en MongoDB 8: Visibilidad total de las operaciones

La auditoría NoSQL es esencial para el cumplimiento normativo y la detección temprana de incidentes. MongoDB 8 amplía su subsistema de auditoría, permitiendo registrar eventos a nivel de sistema, autenticación, autorización y operaciones CRUD.

Configuración del sistema de auditoría

Se habilita en el archivo de configuración del servidor:

auditLog:
  destination: file
  format: JSON
  path: /var/log/mongodb/audit.log
  filter: '{ atype: { $in: ["authenticate", "createCollection", "dropCollection", "authCheck"] } }'

[INFO] El filtro permite reducir el volumen de logs. Para cumplir con normativas estrictas, registra todas las operaciones de escritura (insert, update, delete) y las de autenticación.

Eventos clave de auditoría

Los eventos más relevantes para la seguridad son:

  • authenticate: Inicios de sesión fallidos y exitosos.
  • authCheck: Comprobaciones de autorización para acciones específicas.
  • createUser / dropUser: Creación o eliminación de usuarios.
  • createCollection / dropCollection: Cambios en el esquema.
  • insert / update / delete: Manipulación de datos.

Análisis de logs de auditoría con MongoDB Charts o herramientas externas

Los logs en formato JSON pueden ser ingeridos por herramientas como Elastic Stack o directamente consultados mediante agregaciones:

db.auditLog.aggregate([
  { $match: { atype: "authenticate", result: 0 } },
  { $group: { _id: "$param.user", count: { $sum: 1 } } },
  { $sort: { count: -1 } }
])

Esta consulta identifica los usuarios con más intentos fallidos de autenticación, un indicador temprano de ataques de fuerza bruta.


Control de acceso en MongoDB 8: Modelo basado en roles y privilegios

El control de acceso en MongoDB 8 sigue un modelo RBAC (Role-Based Access Control) granular, permitiendo definir exactamente qué puede hacer cada usuario en cada base de datos.

Roles integrados y personalizados

MongoDB 8 incluye roles predefinidos como read, readWrite, dbAdmin, userAdmin, clusterAdmin y root. Sin embargo, para un control fino, es recomendable crear roles personalizados.

Creación de un rol personalizado para un equipo de analítica:

use admin;
db.createRole({
  role: "analytics_read_only",
  privileges: [
    { resource: { db: "ventas", collection: "" }, actions: ["find", "collStats"] }
  ],
  roles: []
});

[WARNING] Nunca asignes el rol root a usuarios de aplicaciones. Utiliza roles con privilegios mínimos siguiendo el principio de menor privilegio.

Autenticación SCRAM y autenticación externa

MongoDB 8 soporta múltiples mecanismos de autenticación:

  • SCRAM-SHA-256: Por defecto, más seguro que SCRAM-SHA-1.
  • x.509: Autenticación basada en certificados, ideal para clústeres.
  • LDAP: Integración con directorios corporativos.
  • Kerberos: Para entornos Windows o grandes corporaciones.

Ejemplo de creación de usuario con SCRAM-SHA-256:

use admin;
db.createUser({
  user: "app_user",
  pwd: passwordPrompt(),
  roles: [
    { role: "readWrite", db: "miApp" },
    { role: "read", db: "logs" }
  ],
  mechanisms: ["SCRAM-SHA-256"]
});

Control de acceso a nivel de campo con Redaction

MongoDB 8 introduce redact en el pipeline de agregación, permitiendo ocultar campos sensibles en los resultados de consultas según el rol del usuario. Es útil para cumplir con normativas que exigen minimización de datos.

db.pacientes.aggregate([
  { $match: { _id: ObjectId("...") } },
  {
    $redact: {
      $cond: {
        if: { $eq: ["$rol", "medico"] },
        then: "$$DESCEND",
        else: "$$PRUNE"
      }
    }
  }
])

Cumplimiento de normativas datos con MongoDB 8

Las normativas datos como GDPR (Europa), HIPAA (EE.UU.) o LGPD (Brasil) exigen controles específicos. MongoDB 8 facilita el cumplimiento mediante:

Capacidades clave para normativas

NormativaRequisitoCaracterística de MongoDB 8
GDPRDerecho al olvidoOperación deleteOne con confirmación de auditoría
HIPAACifrado de datos médicosField-Level Encryption con algoritmos aprobados por NIST
PCI-DSSRegistro de accesosAuditoría detallada de todas las operaciones de escritura
SOXSeparación de funcionesRoles personalizados y autenticación multifactor

Política de retención de datos

Para cumplir con el principio de minimización, MongoDB 8 permite configurar TTL (Time-To-Live) en colecciones, eliminando automáticamente datos antiguos:

db.eventos.createIndex({ createdAt: 1 }, { expireAfterSeconds: 2592000 }); // 30 días

Enmascaramiento dinámico de datos

Aunque no es nativo, se puede implementar mediante vistas y funciones de agregación:

db.createView("vista_pacientes_anonimos", "pacientes", [
  { $project: { nombre: 1, edad: 1, diagnostico: 1, "seguroSocial": { $concat: ["***-**-", { $substrCP: ["$seguroSocial", 7, 4] }] } } }
])

Mejores prácticas de seguridad MongoDB 8

Checklist de hardening

  1. Actualizar a MongoDB 8 y aplicar parches de seguridad periódicamente.
  2. Deshabilitar HTTP interface y REST API si no se usan.
  3. Usar redes separadas para tráfico de aplicaciones y administración.
  4. Configurar firewall para permitir solo los puertos necesarios (27017, 27018, 27019).
  5. Activar auditLog con filtros adecuados desde el primer día.
  6. Implementar cifrado en reposo y en tránsito.
  7. Rotar claves de cifrado periódicamente.
  8. Monitorear logs con herramientas SIEM.

Ejemplo de script de hardening con mongosh

// Deshabilitar comandos peligrosos
db.adminCommand({ setParameter: 1, enableLocalhostAuthBypass: false });
db.adminCommand({ setParameter: 1, javascriptEnabled: false });

// Configurar límites de conexión
db.adminCommand({ setParameter: 1, maxIncomingConnections: 500 });

// Forzar TLS
db.adminCommand({ setParameter: 1, sslMode: "requireSSL" });

Conclusión: Seguridad MongoDB como proceso continuo

La seguridad MongoDB en la versión 8 ha alcanzado un nivel de madurez que permite a las organizaciones cumplir con las normativas datos más exigentes sin sacrificar rendimiento. El cifrado bases de datos (en reposo, en tránsito y a nivel de campo), la auditoría NoSQL granular y el control de acceso basado en roles conforman un trinomio inseparable para cualquier implementación seria.

Sin embargo, la seguridad no es un producto, sino un proceso. MongoDB 8 proporciona las herramientas, pero la responsabilidad de configurarlas correctamente recae en los administradores. Implementa las prácticas descritas aquí, revisa periódicamente los logs de auditoría y mantén tus clústeres actualizados. Solo así podrás garantizar la confidencialidad, integridad y disponibilidad de tus datos NoSQL en un entorno cada vez más hostil.

[INFO] Para una guía completa, consulta la documentación oficial de MongoDB 8 Security y el MongoDB Security Reference Architecture.

¿Necesitas ayuda?Son dos de nuestros técnicos, Agustín y Mikel, y están disponibles para resolver cualquier problema.

Hablar con ellos ahora
Agustín y Mikel