Seguridad en Bases de Datos NoSQL 2025: Mejores Prácticas y Herramientas

Introducción: El desafío de la seguridad en el mundo NoSQL

Durante años, las bases de datos relacionales dominaron el panorama, y con ellas, un conjunto de prácticas de seguridad bien establecidas. Sin embargo, la adopción masiva de bases de datos NoSQL como MongoDB, Cassandra, Couchbase o Redis ha introducido nuevos vectores de ataque y configuraciones erróneas que pueden exponer datos críticos. A diferencia de SQL, donde la inyección es el riesgo principal, en NoSQL los problemas suelen residir en la falta de autenticación por defecto, el cifrado ausente y una gestión de permisos demasiado permisiva.

La seguridad NoSQL no es un lujo; es una necesidad. Un solo clúster de MongoDB mal configurado puede filtrar millones de registros en cuestión de horas. Este artículo explora las mejores prácticas y herramientas esenciales para blindar tus bases de datos NoSQL, centrándose en MongoDB y Cassandra, dos de los motores más populares.

1. El problema de la configuración por defecto: El talón de Aquiles

Uno de los mayores errores de seguridad en entornos NoSQL es asumir que la configuración por defecto es segura. Nada más lejos de la realidad.

1.1. Autenticación: La primera línea de defensa

Tanto MongoDB como Cassandra, en sus configuraciones iniciales, suelen no requerir autenticación. Esto significa que cualquiera que pueda alcanzar el puerto de la base de datos (ej. 27017 para MongoDB, 9042 para Cassandra) puede conectarse y operar sin restricciones.

MongoDB:
Para habilitar la autenticación, debes arrancar el servicio con el flag --auth o configurarlo en el archivo de configuración (mongod.conf):

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

Luego, crea un usuario administrador:

use admin
db.createUser(
  {
    user: "adminUser",
    pwd: passwordPrompt(), # O una contraseña segura
    roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
  }
)

[WARNING] Nunca uses contraseñas por defecto o débiles. Implementa políticas de rotación y, si es posible, integra con un sistema de gestión de identidades (LDAP, Kerberos).

Cassandra:
En Cassandra, la autenticación se habilita en el archivo cassandra.yaml:

# cassandra.yaml
authenticator: PasswordAuthenticator
authorizer: CassandraAuthorizer

Después de reiniciar el nodo, deberás crear usuarios con roles específicos:

-- cqlsh
CREATE ROLE admin WITH PASSWORD = 'ClaveSegura123' AND LOGIN = true AND SUPERUSER = true;

1.2. Autorización: Principio de mínimo privilegio

No basta con autenticar; hay que autorizar. El principio de mínimo privilegio dicta que un usuario o aplicación debe tener solo los permisos necesarios para realizar su tarea.

En MongoDB, los roles integrados como readWrite o dbAdmin deben asignarse por base de datos, no de forma global. Crea roles personalizados si es necesario.

En Cassandra, los permisos se asignan a nivel de keyspace, tabla o función:

GRANT SELECT ON keyspace1.table1 TO user_app;
GRANT MODIFY ON keyspace1.table1 TO user_app;

2. Cifrado: Protegiendo datos en reposo y en tránsito

El cifrado es la segunda capa de defensa. Sin él, un atacante con acceso físico o lógico al disco puede leer los datos directamente.

2.1. Cifrado en tránsito (TLS/SSL)

Todos los motores NoSQL modernos soportan conexiones cifradas mediante TLS. Esto evita ataques Man-in-the-Middle (MITM).

MongoDB:
Habilita TLS en el servidor y obliga a los clientes a usar conexiones seguras:

# mongod.conf
net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem
    CAFile: /etc/ssl/ca.pem

Cassandra:
Configura el cifrado en cassandra.yaml:

# cassandra.yaml
client_encryption_options:
  enabled: true
  keystore: /etc/cassandra/keystore.jks
  keystore_password: <contraseña>
  require_client_auth: true

2.2. Cifrado en reposo (Encryption at Rest)

Proteger los datos cuando están almacenados en disco es crítico. Existen dos enfoques principales:

Cifrado a nivel de aplicación: La aplicación cifra los datos antes de insertarlos. Esto da control total, pero complica las consultas y los índices.
Cifrado a nivel de sistema de archivos: Usar herramientas como LUKS o dm-crypt para cifrar todo el volumen donde residen los datos.
Cifrado nativo del motor: Tanto MongoDB Enterprise como Cassandra ofrecen cifrado en reposo integrado.

[TIP] Para MongoDB Community (gratuito), la opción más práctica es el cifrado a nivel de sistema de archivos. Para Enterprise, activa el cifrado nativo:

# mongod.conf (Enterprise)
security:
  enableEncryption: true
  encryptionKeyFile: /etc/mongodb/encryption-key
  encryptionCipherMode: AES256-CBC

3. Hardening de red y segmentación

Una base de datos NoSQL nunca debería estar expuesta directamente a Internet. Esto es un error clásico que ha provocado innumerables brechas.

3.1. Firewall y reglas de acceso

No expongas puertos NoSQL al público. Usa firewalls (iptables, nftables, security groups en la nube) para restringir el tráfico solo a rangos IP de confianza.
Usa redes privadas (VPC). Los clústeres deben comunicarse entre sí a través de una red interna, nunca por IP pública.

Ejemplo de regla iptables para MongoDB:

# Permitir solo tráfico desde la subred interna 10.0.0.0/8 al puerto 27017
iptables -A INPUT -p tcp --dport 27017 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 27017 -j DROP

3.2. Proxy inverso y VPN

Para acceder de forma remota, usa un proxy inverso (Nginx, HAProxy) con autenticación adicional o una VPN (WireGuard, OpenVPN). Nunca conectes directamente.

4. Auditoría y monitoreo continuo

No puedes proteger lo que no ves. La auditoría te permite rastrear quién hizo qué y cuándo.

4.1. Registro de auditoría

MongoDB:
Habilita la auditoría en el archivo de configuración:

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

Cassandra:
Usa CassandraAuditWriter o integra con herramientas como Auditd del sistema operativo.

4.2. Herramientas de monitoreo

Prometheus + Grafana: Para métricas de rendimiento y detección de anomalías.
ELK Stack (Elasticsearch, Logstash, Kibana): Para centralizar logs de auditoría y buscar patrones sospechosos.
MongoDB Atlas / Datastax Astra: Ofrecen paneles de seguridad integrados si usas versiones cloud.

5. Herramientas de seguridad específicas para NoSQL

Además de las configuraciones nativas, existen herramientas diseñadas para escanear y proteger bases de datos NoSQL.

Herramienta	Enfoque	Compatibilidad
NoSQLMap	Herramienta de pentesting open source para inyección y enumeración en NoSQL	MongoDB, CouchDB, Cassandra
MongoDB Ops Manager	Gestión y monitoreo con alertas de seguridad	MongoDB
DataStax Enterprise	Seguridad empresarial para Cassandra (cifrado, auditoría, RBAC)	Cassandra
Acra	Cifrado de campo y protección de datos en tiempo real	MongoDB, PostgreSQL

[INFO] Realiza auditorías de seguridad periódicas con NoSQLMap para identificar vulnerabilidades comunes como la inyección NoSQL o la exposición de puertos.

6. Casos específicos: MongoDB y Cassandra

6.1. Seguridad en MongoDB

MongoDB es quizás la base de datos NoSQL más atacada debido a su popularidad. Puntos clave:

Inyección NoSQL: A diferencia de SQL, la inyección en MongoDB explota operadores como $where, $gt, $regex. Sanitiza siempre las entradas del usuario y evita usar $where si no es estrictamente necesario.
BindIp: Por defecto, MongoDB escucha en 0.0.0.0. Cámbialo a 127.0.0.1 o a la IP privada del servidor.
SCRAM: Usa el mecanismo de autenticación SCRAM-SHA-256 en lugar del antiguo MONGODB-CR.

6.2. Seguridad en Cassandra

Cassandra está diseñada para alta disponibilidad, pero la seguridad puede ser compleja en entornos multi-datacenter.

Internode encryption: Cifra la comunicación entre nodos para evitar sniffing en la red interna.
JMX security: El puerto JMX (7199) es crítico. Protégelo con autenticación y SSL.
Rol basado en tablas: Cassandra permite permisos muy granulares. Úsalos para separar aplicaciones.

7. Mejores prácticas resumidas

Para cerrar, aquí tienes una lista de verificación rápida:

Habilitar autenticación en todos los nodos.
Aplicar el principio de mínimo privilegio en roles y usuarios.
Cifrar datos en tránsito con TLS/SSL.
Cifrar datos en reposo (nativo o a nivel de SO).
No exponer puertos a Internet; usar VPN o proxy.
Auditar todas las operaciones críticas.
Mantener actualizado el motor NoSQL (parches de seguridad).
Realizar pentesting periódico con herramientas como NoSQLMap.

Conclusión

La seguridad en bases de datos NoSQL no es inherentemente más difícil que en SQL, pero requiere un cambio de mentalidad. La flexibilidad que ofrecen estos sistemas no debe traducirse en puertas abiertas. Implementar autenticación robusta, cifrado completo y una arquitectura de red segmentada son pasos fundamentales.

Recuerda: la seguridad no es un producto, es un proceso. Monitorea, actualiza y prueba constantemente tu infraestructura NoSQL. Con las herramientas y prácticas adecuadas, puedes disfrutar de la escalabilidad y agilidad de NoSQL sin comprometer la confidencialidad de tus datos.