¿Cómo diferencia Moodle cada sesión?
Varios alumnos, una misma IP pública: cómo diferencia Moodle cada sesión
Qué registra realmente la plataforma, dónde viven las sesiones activas, qué consultas permiten demostrar concurrencia, hasta dónde llega esa prueba y cómo correlacionarla con el servidor web cuando una auditoría lo exige.
Diez trabajadores hacen un curso desde la misma oficina. Todos salen a Internet con la misma dirección IP. Llega una auditoría y pregunta cómo se sabe que cada uno hizo su propio curso. Antes de entrar en tablas y consultas, la respuesta en lenguaje llano.
El asunto, sin tecnicismos
La respuesta corta. Se sabe perfectamente, pero no por la IP. La dirección IP no sirve para esto: en una oficina es la misma para todo el mundo, siempre. Que coincida es lo normal, no lo sospechoso.
Lo que sí sirve. Moodle no reconoce a la gente por su dirección de red, sino por su usuario y su contraseña. Cada persona deja su propio rastro: qué abrió, cuándo, cuánto tardó, qué contestó en el test, qué nota sacó. Dos cuentas producen dos rastros distintos aunque los equipos estén uno al lado del otro. Ese rastro es la prueba, y es sólida.
Hasta dónde llega. Ningún registro técnico puede demostrar quién estaba delante del teclado. Lo que acredita es que dos cuentas distintas generaron actividad individualizada y coherente. Es lo mismo que ocurre con una firma en una hoja de asistencia, y es suficiente en la práctica, pero conviene saberlo antes de prometer más de la cuenta.
El aviso importante. Ese rastro puede haber desaparecido. De fábrica Moodle no borra nada: la opción viene como «no eliminar nunca los registros». El problema es que esa tabla crece sin freno y llega a pesar decenas de gigas, ralentiza el sitio y hace eternas las copias de seguridad, así que es muy frecuente que el proveedor de alojamiento o un administrador anterior fijara un plazo —seis meses, un año— para aliviar el rendimiento. Se hace pensando en el servidor, no en la auditoría, y nadie avisa. Si la comprobación llega dos años después, la prueba ya no existe y no hay forma de recuperarla. Es lo único de todo este asunto sin solución a posteriori: merece la pena entrar hoy y ver en qué está el ajuste en cada plataforma. Es un minuto por instalación.
Lo que hay que llevar a la auditoría. El historial de actividad de cada alumno y sus calificaciones, no un informe sobre direcciones de red. Y si hiciera falta llegar al navegador o al dispositivo concreto, eso está en el registro del servidor web, que es otro sitio y con su propio plazo de borrado.
En una línea. La coincidencia de IP no es un problema; el problema sería descubrir, el día de la inspección, que los registros se borraron hace año y medio.
Hasta aquí lo esencial. El resto del artículo entra en el detalle técnico: qué contiene exactamente cada tabla, qué consultas permiten acreditar el uso simultáneo, cómo se correlaciona con el servidor web y qué límites tiene cada fuente.
Merece la pena la precisión, porque circula bastante material que atribuye a Moodle capacidades de registro que la plataforma no tiene. Construir una defensa sobre datos inexistentes es la peor manera de afrontar una comprobación.
1. El punto de partida: la traducción de direcciones
La red local asigna a cada equipo una dirección privada. El router aplica NAT y traduce todas esas direcciones a una única IP pública de salida. Desde el servidor, en la capa de red, solo se observa esa IP compartida.
[ PC 1: 192.168.1.10 ] ──┐
├──> [ Router / NAT ] ──> ( IP pública única ) ──> [ Servidor Moodle ]
[ PC 2: 192.168.1.11 ] ──┘
La consecuencia es que la IP pública tiene valor discriminante nulo dentro de esa organización. No identifica al usuario ni permite contar dispositivos. No es un defecto de la plataforma: es el comportamiento esperado de cualquier red corporativa, y afecta por igual a Moodle y a cualquier otro servicio web.
2. Qué contiene el registro de eventos
El almacén estándar guarda cada evento en mdl_logstore_standard_log, con estas columnas:
id · eventname · component · action · target · objecttable · objectid crud · edulevel · contextid · contextlevel · contextinstanceid userid · courseid · relateduserid · anonymous · other timecreated · origin · ip · realuserid
- No existe columna de User-Agent. El registro estándar no almacena la cadena del navegador. Esa información vive en el log de accesos del servidor web, que es otro sistema y otra política de retención.
- No existe columna de identificador de sesión. El session id aparece únicamente dentro del campo serializado
otherde determinados eventos, y no de todos los que cabría suponer. timecreatedse expresa en segundos, no en milisegundos. Es una marca Unix del tipo1690948462. Dos acciones simultáneas comparten valor y el orden real lo da elidautoincremental.
3. Dónde viven las sesiones activas: mdl_sessions
Es la tabla que responde a la pregunta «¿quién está conectado ahora y desde dónde?».
id bigint Identificador interno state bigint Estado interno de la sesión sid varchar(128) Identificador único de sesión — el valor de la cookie userid bigint Usuario autenticado (0 = visitante sin autenticar) sessdata longtext Datos de sesión serializados (puede ser NULL) timecreated bigint Inicio de la sesión timemodified bigint Última actividad registrada firstip varchar(45) IP desde la que se inició la sesión lastip varchar(45) IP de la última petición
- No hay una columna
ip, sino dos.firstipylastip. Si difieren, la sesión ha cambiado de dirección de salida durante su vida. Suele deberse a un cambio de red —de la wifi corporativa a datos móviles, o a una VPN que se activa—, aunque también puede producirlo la rotación de direcciones de un operador o de una CDN, así que conviene contrastarlo antes de concluir nada. sessdatasuele estar vacío. Solo contiene la carga serializada cuando el gestor de sesiones es la propia base de datos. Con almacenamiento en ficheros —el habitual— la fila existe para custodiar elsidy el contenido vive enmoodledata/sessions, en un archivo llamadosess_<sid>.- Contiene mucho ruido. Cualquier visita anónima, incluidos los rastreadores que cargan la portada, genera una fila con
userid = 0. Al analizar concurrencia hay que filtrarlas siempre. - Es volátil, no es un archivo histórico. Las filas desaparecen al cerrar sesión o al ejecutarse la tarea programada de limpieza. Sirve para el presente, no para reconstruir lo ocurrido el trimestre pasado.
Precaución de seguridad. El campo sid es una credencial de sesión viva: quien la posee puede suplantar esa sesión mientras siga activa. No debe volcarse en informes, capturas ni correos. Para una evidencia de auditoría basta con acreditar que existen sesiones distintas; no hace falta exponer sus identificadores.
4. Consultas para demostrar el uso concurrente
El objetivo no es identificar dispositivos, sino acreditar que dos identidades distintas produjeron actividad entrelazada.
A · Sesiones activas en este momento
SELECT s.userid,
u.username,
s.firstip,
s.lastip,
FROM_UNIXTIME(s.timecreated) AS inicio,
FROM_UNIXTIME(s.timemodified) AS ultima_actividad
FROM mdl_sessions s
JOIN mdl_user u ON u.id = s.userid
WHERE s.userid <> 0
ORDER BY s.timemodified DESC;
Dos filas con userid distintos, la misma lastip y actividad simultánea acreditan dos sesiones independientes coexistiendo tras el mismo NAT. Obsérvese que se ha omitido deliberadamente el sid. El JOIN con la tabla de usuarios descarta por sí solo las filas anónimas, y el filtro explícito se mantiene por claridad.
B · Cronología histórica desde una IP
SELECT FROM_UNIXTIME(l.timecreated) AS momento,
l.userid,
u.username,
l.eventname,
l.origin,
l.ip
FROM mdl_logstore_standard_log l
JOIN mdl_user u ON u.id = l.userid
WHERE l.ip IN ('203.0.113.25', '2001:db8:abcd::/48')
AND l.timecreated BETWEEN UNIX_TIMESTAMP('2026-03-02 00:00:00')
AND UNIX_TIMESTAMP('2026-03-02 23:59:59')
ORDER BY l.timecreated ASC, l.id ASC;
Rendimiento. La columna ip no figura entre los índices de la definición estándar de la tabla —conviene confirmarlo en cada instalación con SHOW INDEX—, de modo que filtrar solo por ella provoca un recorrido completo sobre millones de filas. Acote siempre con timecreated, que sí está indexada.
Doble pila IPv4 e IPv6. Si la red del cliente y el servidor admiten ambos protocolos, la misma oficina puede aparecer unas veces con una dirección IPv4 y otras con una IPv6, y filtrar por una sola deja fuera media jornada. Identifique primero qué direcciones usó esa sede en el periodo, agrupando por ip, antes de dar por buena una cronología.
El desempate por id tampoco es un adorno: al registrarse los tiempos en segundos, es lo único que restituye el orden real entre eventos del mismo segundo.
C · Detección de solapamiento entre cuentas
SELECT l.userid,
u.username,
COUNT(*) AS eventos,
FROM_UNIXTIME(MIN(l.timecreated)) AS primera_accion,
FROM_UNIXTIME(MAX(l.timecreated)) AS ultima_accion
FROM mdl_logstore_standard_log l
JOIN mdl_user u ON u.id = l.userid
WHERE l.ip = '203.0.113.25'
AND l.timecreated BETWEEN UNIX_TIMESTAMP('2026-03-02 09:00:00')
AND UNIX_TIMESTAMP('2026-03-02 14:00:00')
GROUP BY l.userid, u.username
ORDER BY primera_accion;
Qué demuestra esta consulta y qué no. Si los intervalos de dos cuentas se solapan y sus acciones aparecen intercaladas, queda acreditado que dos sesiones autenticadas estuvieron activas a la vez tras esa salida a Internet. Eso ya es mucho: descarta el escenario de una única sesión secuencial.
Lo que no demuestra es que hubiera dos dispositivos ni dos personas. Dos sesiones simultáneas caben perfectamente en un mismo equipo, con dos navegadores o dos perfiles abiertos. Presentar el solapamiento como prueba de dos puestos de trabajo es exactamente el tipo de salto que conviene evitar ante un auditor: se defiende sin dificultad la simultaneidad de sesiones, y se defiende muy mal la simultaneidad de personas.
D · Recuperar identificadores de sesión del histórico
SELECT FROM_UNIXTIME(timecreated) AS momento,
userid,
ip,
other
FROM mdl_logstore_standard_log
WHERE eventname = '\\core\\event\\user_loggedout'
AND timecreated BETWEEN UNIX_TIMESTAMP('2026-03-02 00:00:00')
AND UNIX_TIMESTAMP('2026-03-02 23:59:59')
ORDER BY timecreated;
Aquí hay que corregir una creencia extendida. Se afirma con frecuencia que los eventos de autenticación guardan metadatos de sesión en el campo other. En la práctica, el evento de cierre de sesión sí incluye el identificador serializado; el de inicio de sesión guarda únicamente el nombre de usuario. La correlación por sid solo es posible, por tanto, para sesiones que fueron cerradas explícitamente, y no para las que expiraron por inactividad.
Escapado según el motor. El ejemplo está escrito para MySQL y MariaDB, donde la contrabarra es carácter de escape y hay que duplicarla. En PostgreSQL, con el comportamiento estándar de cadenas, se escriben contrabarras simples: '\core\event\user_loggedout'.
5. Correlación con el servidor web
Es la vía habitual para llegar al navegador y al sistema operativo, y tiene sus propias condiciones.
Si necesita diferenciar dispositivos y no solo identidades, los registros de Moodle no bastan: hay que acudir al log de accesos de Apache o Nginx, que puede conservar la cadena de agente de usuario de cada petición si su formato lo incluye. El procedimiento consiste en tomar la marca temporal de un evento concreto de la base de datos y localizar la petición correspondiente en el fichero de accesos.
- Que el formato de log incluya el agente. En Apache, el formato combined lo registra y el common no. En Nginx depende de que la directiva de formato contenga la variable correspondiente. Si el servidor está configurado con el formato reducido, ese dato sencillamente no se escribió nunca.
- Que los relojes estén alineados. Los eventos de Moodle se guardan como marca Unix y el log de accesos escribe la hora local del servidor con su desplazamiento horario. Sin sincronización y sin tener clara la zona, la correlación se desplaza y deja de ser prueba.
- Que el fichero siga existiendo. La rotación habitual conserva días o semanas, muy por debajo de los plazos que exige una auditoría de formación. Si va a apoyarse en esta fuente, ajuste la rotación antes, no cuando le reclamen.
- Que el agente siga discriminando. Los navegadores basados en Chromium aplican una política de reducción de la cadena de agente de usuario: congelan versiones y detalles de plataforma y trasladan el detalle a las Client Hints, que solo se envían si el servidor las solicita. Dos equipos corporativos con la misma imagen de sistema pueden presentar cadenas idénticas.
Y una corrección de alcance: el log del servidor web no registra la resolución de pantalla. Esa información no viaja en ninguna cabecera HTTP; solo se obtiene mediante código en el navegador. Lo que el agente aporta es sistema operativo, navegador y motor de renderizado, con las limitaciones ya descritas.
6. Matriz de trazabilidad
| Parámetro | Dónde se guarda | Persistencia | Discriminación |
|---|---|---|---|
| Cuenta autenticada | Columna userid del log |
Hasta la purga configurada | Absoluta entre cuentas |
| Rastro de eventos | Log estándar, un registro por acción | Hasta la purga configurada | Absoluta entre cuentas |
| Sesión activa | mdl_sessions: sid, firstip, lastip |
Volátil | Alta |
| Sesión cerrada | Campo other del evento de cierre |
Hasta la purga configurada | Alta, si hubo cierre explícito |
| Cadena User-Agent | Log del servidor web | Según rotación | Media y decreciente |
| IP pública | Columna ip del log |
Hasta la purga configurada | Nula bajo NAT |
| IP privada (LAN) | DHCP y cortafuegos de la empresa | Según política interna | Alta, si se conservan las concesiones |
| Dirección MAC | Solo infraestructura local | Según política interna | Alta; falsificable y aleatorizada en wifi |
Dos lecturas de esta tabla. La columna de persistencia es la que suele decidir un expediente: un dato con discriminación absoluta pero ya purgado no sirve de nada, y esa purga rara vez la decidió quien responde de la formación. Y toda la columna de discriminación se refiere a cuentas y dispositivos, no a personas.
7. Dos factores de configuración que condicionan la evidencia
Si la plataforma está detrás de un proxy inverso, un balanceador o una CDN, las columnas de IP pueden estar registrando la dirección del intermediario en lugar de la del cliente.
Moodle dispone de parámetros para interpretar las cabeceras reenviadas; si no están ajustados, todos los accesos aparecerán con la misma IP de infraestructura y el análisis por IP pierde todo sentido.
El ajuste vive en la administración del sitio, dentro de la configuración del almacén de registros estándar, y su valor de fábrica es no eliminar nunca. Conviene saberlo, porque contradice lo que muchos suponen.
El riesgo real es otro: como la tabla crece de forma explosiva y degrada el rendimiento y los respaldos, es habitual que en algún momento alguien —el proveedor de alojamiento, un integrador, un administrador anterior— la haya limitado a 180 o 365 días para resolver un problema operativo. Es una decisión de infraestructura tomada sin considerar el plazo de conservación exigible a la formación, y no deja rastro visible. Verifíquelo antes de necesitarlo: es el único factor de esta lista sin solución retroactiva.
8. Qué sostiene realmente una auditoría
La coincidencia de IP pública entre alumnos de una misma sede es el comportamiento esperado de cualquier red corporativa, de modo que por sí sola no dice nada sobre la realidad de la formación.
- El rastro de actividad individualizado. Historial cronológico por
userid: recursos consultados, tiempos, intentos de cuestionario, entregas y calificaciones. Es lo que demuestra aprendizaje real y no un acceso formal. - Los registros de finalización y calificación, que reflejan resultados distintos para personas distintas y son difíciles de fabricar de forma coherente.
- La concurrencia de sesiones acreditada mediante las consultas de solapamiento descritas más arriba, con el alcance que allí se precisa.
- El log del servidor web, si se conserva y si su formato incluye el agente, como fuente complementaria.
- La correlación con la red corporativa —DHCP y cortafuegos vinculando IP privada y dirección MAC— solo en disputas complejas. Es la vía más costosa y la que más implicaciones tiene en protección de datos.
En la práctica, lo que se entrega no son consultas SQL. Son los informes que la propia plataforma genera: el informe de actividad y de participación de cada curso, el libro de calificaciones y el registro de finalización, exportados en un formato estable y con la fecha de extracción visible. Las consultas de este artículo sirven para entender y para responder a una objeción concreta, no para sustituir a los informes normalizados que el auditor espera recibir.
Conviene decirlo con claridad, porque es la objeción que un auditor puede plantear y ante la que no sirve improvisar: ningún registro técnico demuestra quién estaba delante del teclado. Si dos personas comparten credenciales, los logs reflejarán dos rastros impecables sin que nada revele la sustitución.
Lo que la trazabilidad acredita es que existió actividad autenticada, individualizada, sostenida en el tiempo y coherente en sus resultados. Es exactamente el mismo alcance que tiene una firma en una hoja de asistencia presencial, y por eso se acepta. Presentarlo como prueba de identidad física, en cambio, es una promesa que los datos no respaldan y que se desmonta con una sola pregunta.
Una cautela final sobre el quinto punto de la lista. Los registros de conexión, la dirección IP, los identificadores de sesión y la correlación con equipos concretos son datos personales. Su tratamiento exige base jurídica, finalidad definida y plazo de conservación proporcionado. Recopilarlos «por si acaso» crea un riesgo nuevo mientras se intenta mitigar otro.
Notas: Si bonificas tu formación online quizá te interese consultar los requisitos técnicos que deciden si tu plataforma justifica o devuelve las bonificaciones …
9. Conclusión operativa
La arquitectura de Moodle independiza la identidad del usuario de la infraestructura de red: no necesita la dirección IP para saber qué cuenta hace qué, porque trabaja en la capa de aplicación sobre una sesión autenticada. La IP compartida es un dato de contexto, no un identificador, y su coincidencia no impide la trazabilidad individual.
La solidez de esa evidencia, en cambio, no es automática. Depende de que la retención cubra el periodo exigible, de que el proxy inverso esté bien configurado, de que el formato del log del servidor incluya lo que se pretende invocar, de que la argumentación se apoye en los campos que las tablas realmente contienen y de que no se prometa más alcance del que los datos tienen. Comprobarlo es cuestión de una hora, y es la hora mejor invertida de todo el proceso.
Este artículo tiene carácter técnico y divulgativo. No constituye asesoramiento jurídico ni una certificación de cumplimiento, y no sustituye la revisión de la configuración concreta de cada plataforma ni la consulta con el organismo competente en cada procedimiento de comprobación. Los nombres de tabla y de columna, los índices y las opciones de configuración descritos corresponden al almacén de registros estándar y al gestor de sesiones de Moodle, y pueden variar según la versión, los complementos instalados y las personalizaciones del entorno: verifique el comportamiento de su instalación antes de apoyar en él una evidencia.
Las consultas SQL incluidas son ejemplos ilustrativos redactados para MySQL o MariaDB y deben adaptarse al prefijo de tablas, al motor de base de datos y al volumen de cada instalación. Ejecútelas siempre sobre entornos de solo lectura o réplicas: una consulta sin acotar sobre la tabla de registros puede degradar gravemente el rendimiento de una plataforma en producción.
El tratamiento de registros de conexión, direcciones IP, identificadores de sesión y datos de dispositivo está sujeto a la normativa de protección de datos. Cualquier correlación con registros de red corporativa debe contar con base jurídica, información previa a las personas afectadas y un plazo de conservación proporcionado a la finalidad. Los identificadores de sesión son credenciales activas y no deben reproducirse en informes ni comunicaciones.
Moodle es una marca registrada de Moodle Pty Ltd. Este contenido no está afiliado ni respaldado por Moodle Pty Ltd.
Un comentario
Contenido relacionado: Auditoría Plataforma eLearning: requisitos Fundae … https://www.consultae.es/plataforma-elearning/