Seguridad en bases de datos NoSQL: Cifrado, auditoría y control de acceso en MongoDB 8
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
roota 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
| Normativa | Requisito | Característica de MongoDB 8 |
|---|---|---|
| GDPR | Derecho al olvido | Operación deleteOne con confirmación de auditoría |
| HIPAA | Cifrado de datos médicos | Field-Level Encryption con algoritmos aprobados por NIST |
| PCI-DSS | Registro de accesos | Auditoría detallada de todas las operaciones de escritura |
| SOX | Separación de funciones | Roles 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
- Actualizar a MongoDB 8 y aplicar parches de seguridad periódicamente.
- Deshabilitar HTTP interface y REST API si no se usan.
- Usar redes separadas para tráfico de aplicaciones y administración.
- Configurar firewall para permitir solo los puertos necesarios (27017, 27018, 27019).
- Activar auditLog con filtros adecuados desde el primer día.
- Implementar cifrado en reposo y en tránsito.
- Rotar claves de cifrado periódicamente.
- 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.
