Bastionado de seguridad de MongoDB (autorización, TLS, roles, auditoría)

Runbook por escenarios para bastionar un MongoDB en ejecución (servidor independiente, replica set o sharded cluster) sin tiempo de inactividad: auditoría de seguridad de solo lectura, autorización rolling con keyFile + transitionToAuth, custom roles y usuarios con privilegios mínimos, SCRAM-SHA-256, bindIp y firewall, transición allowTLS → preferTLS → requireTLS, autenticación de miembros x.509, audit log (Enterprise/Percona) y encryption at rest; al final se repite la auditoría para demostrar que los riesgos están cerrados. En sistemas instalados con las guías de instalación de este sitio, la autorización y el keyfile ya están habilitados: empiece por la auditoría y aplique solo los escenarios que informen RIESGO. La operación diaria y el backup se tratan en guías de MongoDB separadas.

Topología: Servidor independiente, replica set de 3+ miembros o sharded cluster

Escenarios

• Auditoría del estado de seguridad (solo lectura) — No cambia nada. El acceso sin autenticación, las direcciones de escucha, TLS, los mecanismos de autenticación, los usuarios con privilegios elevados, la auditoría y el estado de encryption at rest se informan como OK / AVISO / RIESGO. Elija esta opción si no sabe por dónde empezar.
• Bastionado completo (todo en orden) — Auditoría → internal auth + autorización (sin tiempo de inactividad con transitionToAuth) → usuarios con privilegios mínimos → SCRAM-SHA-256 → bindIp/firewall → TLS (allowTLS → preferTLS → requireTLS) → auditoría (Enterprise/Percona) → auditoría final. En un replica set se hace de forma rolling; cada paso de riesgo pide confirmación.
• Autorización deshabilitada: habilitar la autorización (keyFile, sin tiempo de inactividad) — Cualquiera puede conectarse sin nombre de usuario ni contraseña. En un replica set y en un sharded cluster se habilita de forma rolling y sin tiempo de inactividad con keyFile + transitionToAuth; un servidor independiente necesita un único reinicio breve.
• Usuarios con privilegios mínimos y custom roles (aplicación, backup, monitorización) — Las aplicaciones se conectan con root o con una cuenta de administrador compartida. Se crea un custom role que concede a la aplicación solo las operaciones que necesita en su propia base de datos, junto con usuarios separados para backup y monitorización; se muestra cómo guardar las contraseñas de forma segura en el lado de cron/aplicación.
• Deshabilitar SCRAM-SHA-1, solo SCRAM-SHA-256 — Las credenciales de los usuarios antiguos se almacenan con SHA-1, o la auditoría encontró SCRAM-SHA-1 habilitado. Los usuarios se migran a SHA-256 y después se restringe authenticationMechanisms con un reinicio rolling.
• Restringir el acceso de red (bindIp 0.0.0.0, firewall) — mongod escucha en todas las interfaces (0.0.0.0, bindIpAll) o el puerto está abierto a todo el mundo. bindIp se reduce a localhost + la IP interna del servidor, y el firewall solo permite a los miembros y a la red de aplicaciones. Rolling, sin tiempo de inactividad.
• Cifrar las conexiones: TLS (allowTLS → preferTLS → requireTLS) — El tráfico entre la aplicación y los miembros, y entre los propios miembros, va sin cifrar. Se distribuyen los certificados, los miembros pasan primero a allowTLS con un reinicio rolling, después a preferTLS en caliente y a requireTLS cuando las aplicaciones están preparadas. Opcional: autenticación x.509 entre miembros.
• Habilitar el audit log (Enterprise / Percona) — Debe registrarse quién inició sesión y cuándo, los cambios de usuarios/roles y las operaciones drop. En MongoDB Enterprise y Percona Server for MongoDB se habilita con auditLog; Community no tiene esta funcionalidad (se muestra una alternativa).
• Encryption at rest (cifrar los datos en disco) — Si se roba un disco o un backup, los datos no deben poder leerse. En Enterprise/Percona, el cifrado de WiredTiger se habilita reconstruyendo los miembros uno a uno con un initial sync; en Community el disco de datos se cifra con LUKS.

Antes de empezar

• Acceso root/sudo en todos los servidores mongod… y mongos…; SSH desde el primer servidor a los demás (para copiar el keyfile y los certificados).
• …El replica set está sano: todos los miembros PRIMARY/SECONDARY, lag bajo. No se hace ninguna operación rolling en un cluster que no está sano.…mongod está en ejecución.…
• Lista de aplicaciones y sus responsables: la cadena de conexión de cada aplicación se actualizará antes de que la autorización/TLS sean obligatorios. La cadena de conexión debe incluir todos los miembros y replicaSet= (para no perder la conexión durante los reinicios rolling).
• Ventana de mantenimiento: las operaciones rolling no causan tiempo de inactividad, pero cada cambio de primary hace esperar las escrituras unos segundos. En un servidor independiente, habilitar la autorización/TLS requiere una interrupción breve.
• Si la autorización ya está habilitada en un sharded cluster: el primary de cada shard debe tener un usuario shard-local (root) con el mismo nombre y contraseña que … en mongos. Los pasos por miembro (rs.stepDown en el reinicio rolling, setParameter, auditoría) se conectan directamente a los miembros del shard; los usuarios de mongos no son válidos allí. Comprobación: en un miembro del shard, mongosh --port <puerto del shard> y db.getSiblingDB("admin").auth("…", passwordPrompt()).
• Un backup completo actual cuya restauración se haya probado.
• Una licencia de MongoDB Enterprise o Percona Server for MongoDB para la auditoría y encryption at rest. Community no tiene estas funcionalidades.
• Los nombres de los miembros se resuelven en todos los servidores (DNS o /etc/hosts); con TLS, las conexiones usan estos nombres.

Fases de la guía

• Preparación: red de seguridad y herramientas auxiliares — Copia de seguridad de la configuración y el estado · Instalar PyYAML · Escribir la herramienta de edición YAML (dbatlas-yaml) · Escribir la herramienta de reinicio rolling (dbatlas-mongod-restart) · Escribir la contraseña del administrador en un archivo temporal
• Auditoría del estado (solo lectura) — Red, proceso y permisos de archivos: … · Red y proceso: … · Autorización, TLS y parámetros: … · Autorización, TLS y parámetros: … · Usuarios, roles y mecanismos de autenticación · Asignar los hallazgos a los escenarios
• Autorización: diagnóstico y keyfile — Diagnóstico: ¿está realmente deshabilitada la autorización? · Inventariar las conexiones de las aplicaciones · Crear el keyfile · Copiar el keyfile a los demás servidores · Permisos del keyfile: … · Permisos del keyfile: …
• Autorización: usuario administrador — Crear el usuario administrador (…) · Administrador shard-local: …
• Usuarios con privilegios mínimos y custom roles — Crear un custom role para la aplicación (…@…) · Crear el usuario de la aplicación (…) · Usuarios de backup y monitorización · Verificar los privilegios mínimos (…) · Guardar las contraseñas de forma segura en el lado de la aplicación y de cron
• Autorización: verificar que no quedan conexiones no autenticadas — Conexiones de clientes no autenticadas: …
• Aplicar la autorización obligatoria (servidor independiente) — authorization: enabled · Reiniciar el servicio de forma segura (…)
• Autorización: verificación — ¿Se rechaza el acceso no autenticado? · Verificar los privilegios mínimos (…) · Vía de vuelta atrás (si hace falta)
• SCRAM-SHA-256: migrar los usuarios — Usuarios con credenciales SHA-1 · Reducir los usuarios a solo SCRAM-SHA-256
• SCRAM-SHA-256: verificación — ¿Se rechaza el inicio de sesión con SHA-1?
• Acceso de red: firewall — Reglas de firewall
• Acceso de red: verificación — Direcciones de escucha: …
• TLS: certificados — Estado actual de TLS · Generar la CA interna y los certificados de servidor · Distribuir los certificados · Permisos y verificación de certificados: … · Permisos de certificados: …
• TLS: migrar las aplicaciones — Pasar las aplicaciones a TLS y contar las conexiones TLS
• TLS: verificación — ¿Se rechazan las conexiones sin TLS?: …
• Audit log: comprobación previa — ¿Admite auditoría este mongod?: …
• Audit log: verificación y rotación — ¿Se están escribiendo registros de auditoría?: … · Alternativa para Community: vigilar los logs de autenticación
• Encryption at rest: comprobación previa y backup — Soporte de cifrado y espacio en disco: … · ¿Se ha hecho un backup completo?
• Encryption at rest: marcador de prueba — Escribir un marcador en texto plano
• Encryption at rest (Community): disco de datos con LUKS — Preparar el disco LUKS: … · Trasladar los datos al disco cifrado: …
• Auditoría final (tras el bastionado) — Red, proceso y permisos de archivos: … (estado final) · Red y proceso: … (estado final) · Autorización, TLS y parámetros: … (estado final) · Autorización, TLS y parámetros: … (estado final) · Usuarios, roles y mecanismos de autenticación (estado final)
• Limpieza y pasos siguientes — Eliminar el archivo temporal de contraseña · Pasos siguientes: monitorización y tareas periódicas