MAQ Módulo 2 — Seguridad: lo que el checklist no te dice
Este post es parte de la serie sobre el Módulo 2 del MAQ. Si no has leído la introducción, puedes empezar por MAQ Módulo 2: Implementación — primeras impresiones.
El subapartado de Seguridad del MAQ me ha resultado el más interesante hasta ahora. No porque descubra nada que no supiera — es que te obliga a ordenarlo todo y a cuestionarte si realmente lo aplicas o simplemente crees que lo aplicas.
Hay una diferencia enorme entre “sé que debería hacer X” y “tengo evidencia de que X está configurado correctamente en producción”. El MAQ va a por lo segundo.
Lo que más me ha hecho pensar
El módulo estructura la seguridad en cuatro bloques: buenas prácticas generales, autenticación, seguridad del usuario y seguridad del contenido. Todo razonable, todo conocido. Pero hay detalles que me han detenido.
El registro del sitio y las alertas de seguridad. Moodle tiene un mecanismo para recibir notificaciones de seguridad directamente en el correo del administrador — basta con registrar el sitio en Administración > General > Registro y activar las notificaciones. Suena obvio. ¿Cuántos sitios en producción lo tienen configurado? En mi experiencia, bastantes menos de los que debería.
La autenticación multifactor desde 4.3. El MFA lleva disponible como estándar desde Moodle 4.3 y aún hay administradores que no lo han activado porque “complica el acceso a los usuarios”. Entiendo el argumento. No lo comparto. En entornos con datos sensibles de alumnos, el MFA no es opcional.
El acceso de invitados no auditado. El módulo pregunta algo que parece inocente: ¿has visitado tu propio sitio como usuario no autenticado? Yo lo hice hace tiempo en una instalación de cliente y encontré cursos con material sensible accesibles sin login. Nadie lo había configurado conscientemente — simplemente nadie lo había revisado.
El caso de estudio que más resuena
El módulo incluye un caso sobre Petr, un administrador checo que descubre que estudiantes adolescentes estaban inyectando scripts maliciosos en cursos. La causa: un Gestor había asignado a esos estudiantes como profesores editores para que aprendieran a editar cursos.
La solución de Petr fue desactivar la capacidad trustsubmittedcontent para el rol de profesor y crear un rol personalizado para los casos justificados.
Lo que me llama la atención no es la solución técnica — es la causa raíz. Alguien tomó una decisión de gestión (enseñar a los alumnos a editar cursos) sin evaluar las implicaciones de seguridad. Eso pasa constantemente. Los problemas de seguridad en Moodle raramente son fallos del software — casi siempre son decisiones de configuración tomadas sin pensar en las consecuencias.
Sobre la seguridad del contenido
El bloque de seguridad de contenido del MAQ toca algo que en entornos grandes es un problema real: el contenido generado por usuarios. Foros, blogs, comentarios, etiquetas — todo eso es superficie de ataque.
Las recomendaciones son sensatas: ClamAV para antivirus, deshabilitar EMBED/OBJECT, revisar el informe de spam periódicamente. Pero lo que más valoro es la pregunta implícita: ¿tienes una política para esto, o simplemente tienes la configuración por defecto y esperas que no pase nada?
La configuración por defecto de Moodle es razonablemente segura. Pero “razonablemente segura por defecto” no es lo mismo que “segura para tu contexto específico”.
Diario: evaluación de vulnerabilidades
Una de las tareas del MAQ en este módulo es la siguiente: imagina que recibes una notificación de seguridad con una lista de vulnerabilidades corregidas en tu versión de Moodle. ¿Cómo evaluarías el impacto?
Mi proceso cuando llega una de estas notificaciones:
Primero, clasificar por severidad. El foro de anuncios de seguridad de Moodle usa una escala: Grave, Mayor, Menor, Insignificante. Las Graves son actualización inmediata, sin debate. Las Mayores, en menos de una semana. Las Menores, en el siguiente ciclo de mantenimiento planificado.
Segundo, leer el CVE si existe. Moodle publica los detalles técnicos con un retraso para dar tiempo a actualizar. Cuando están disponibles, hay que entender qué vector de ataque cubre — autenticación, XSS, inyección SQL, escalada de privilegios. No todas las vulnerabilidades tienen el mismo impacto en todos los entornos.
Tercero, evaluar el contexto propio. Una vulnerabilidad que requiere rol de profesor para explotar tiene un impacto muy diferente en una universidad pública (profesores externos, muchos usuarios) que en una empresa con formación interna (profesores empleados, entorno controlado).
Cuarto, verificar si el exploit está disponible públicamente. Si hay prueba de concepto publicada, la ventana de actualización se cierra drásticamente.
Quinto, documentar la decisión. Si decides no actualizar de forma urgente por alguna razón (ventana de congelación de cambios, exámenes en curso), documenta por qué y establece una fecha límite. Eso es lo que separa la gestión profesional de la improvisación.
Diario: acceso de invitados en Mount Orange School
La segunda tarea del módulo: acceder al sitio de demostración de Moodle e identificar qué cursos tienen acceso como invitado habilitado.
Mount Orange School es el sitio demo oficial de Moodle. Al visitarlo sin autenticarse, se pueden ver cursos con acceso de invitado habilitado — normalmente los de demostración y algunos de muestra para educadores.
Las razones legítimas para habilitar el acceso de invitado en un curso real son pocas pero válidas:
- Cursos de presentación institucional: contenido que cualquier interesado puede ver antes de matricularse
- Recursos de acceso libre: materiales que la institución quiere compartir públicamente
- Demos para potenciales alumnos: mostrar cómo es la experiencia antes de formalizar la matrícula
Lo que no es una razón válida: “no sé cómo funciona la inscripción y así al menos pueden entrar”. Eso lo he visto. Más veces de las que debería.
La regla que aplico: si un curso tiene acceso de invitado, debe ser una decisión consciente con justificación documentada, no el resultado de no haber configurado nada.
Siguiente en esta serie: MAQ Módulo 2 — Privacidad
Siguiente en esta serie: MAQ Módulo 2 — Privacidad: el RGPD no es un formulario, es una responsabilidad
