MongoDB
Explica cómo proteger conexiones MongoDB mediante autenticación, certificados TLS, connection strings seguras y separación de credenciales por entorno.
Autenticación confirma la identidad que se conecta; TLS protege la comunicación y permite verificar que el cliente habla con el servidor correcto. Son controles diferentes y ambos son necesarios.
red permitida
→ TLS y validación del certificado
→ autenticación
→ autorización por rolesExponer MongoDB a Internet, desactivar validación de certificados o compartir credenciales administrativas rompe esta cadena.
SCRAM autentica mediante usuario y contraseña sin enviar la contraseña en texto plano. El usuario existe en una authentication database, frecuentemente admin.
mongodb://orders-api:secret@db/app?authSource=adminLa base de trabajo app no tiene que coincidir con authSource.
Buenas prácticas:
X.509 puede autenticar clientes mediante certificados. Es útil en infraestructuras que ya operan PKI, pero requiere gestionar:
Un certificado cliente no debe copiarse entre todos los servicios.
Plataformas administradas y ediciones específicas pueden soportar autenticación federada o identidades de cloud. Su disponibilidad depende de versión, driver y oferta. Prefiere credenciales cortas o workload identity cuando reduzcan secretos estáticos, pero conserva least privilege.
TLS ofrece:
No basta con cifrar: el cliente debe validar CA y hostname. Aceptar cualquier certificado permite ataques man-in-the-middle.
Un certificado de servidor debe:
El driver debe conectarse usando un nombre presente en SAN. Conectarse por IP cuando el certificado solo contiene DNS puede fallar correctamente.
En self-managed deployments puede utilizarse una CA privada. Los clientes necesitan el bundle correcto:
const client = new MongoClient(uri, {
tls: true,
tlsCAFile: '/run/secrets/mongo-ca.pem'
});No incluyas private keys ni certificados sensibles en la imagen Docker.
Opciones equivalentes a aceptar certificados inválidos o hostnames incompatibles solo sirven para diagnóstico local controlado. En producción eliminan la garantía de identidad aunque el tráfico siga cifrado.
La autenticación no reemplaza aislamiento de red. Aplica:
Una contraseña fuerte no justifica 0.0.0.0/0.
Los miembros también deben autenticarse entre sí mediante keyfile o X.509 según deployment. El secreto interno debe tener permisos de archivo estrictos y rotación planificada.
Clientes deben usar una URI que permita discovery:
mongodb://db1,db2,db3/app?replicaSet=rs0&tls=trueNo hardcodees únicamente el primary.
En Atlas, network access, database users, private endpoints, TLS y roles son capas separadas. Una IP permitida no concede acceso sin credenciales, y una credencial válida no debería poder entrar desde cualquier red.
Procedimiento sin downtime:
crear nueva credencial o certificado
→ desplegar clientes
→ comprobar conexiones
→ revocar anterior
→ auditar procesos rezagadosConsidera pools que mantienen conexiones existentes. Verifica tanto nuevas conexiones como reconexiones después de failover.
No expongas:
.env real en Git;Sanitiza errores del driver y registra solo host lógico, categoría y operation ID.
Distingue:
No conviertas todos en “base de datos caída”. Cada causa tiene un runbook distinto.
Puedes usar una CA de desarrollo o conexión local aislada. No copies flags inseguros a producción. Para probar transacciones, configura replica set y autenticación de manera cercana al entorno real.
authSource incorrecto;La conexión segura requiere defensa en profundidad: red privada, TLS validado, autenticación fuerte y autorización mínima. SCRAM, X.509 o identidad federada resuelven quién se conecta; TLS protege el canal y la identidad del servidor. La rotación debe probar conexiones nuevas, no solo procesos ya conectados.
authSource?Field-Level Encryption y Queryable Encryption.