Un profesor con permisos de administrador del sitio completo. Un alumno que, sin querer, puede ver calificaciones de otros compañeros. Un tutor con acceso a cursos que no le corresponden. Ninguno de estos casos suele ser mala intención, casi siempre es una configuración de roles heredada, copiada o nunca revisada desde que se creó la instalación.
En esta guía vas a ver cómo funciona el sistema de roles y permisos de Moodle, los errores de configuración más comunes, y cómo auditar tu instalación para detectar accesos que no deberían existir.
Cómo funciona el sistema de roles en Moodle
Moodle organiza los permisos en tres niveles que se combinan:
- Roles: conjuntos predefinidos de capacidades (Administrador, Gestor, Profesor, Profesor no editor, Estudiante, Invitado, entre otros roles personalizables).
- Capacidades: acciones específicas que un rol puede o no realizar (ver calificaciones, editar contenido, matricular usuarios, acceder a informes).
- Contexto: el nivel donde se aplica un rol, todo el sitio, una categoría de cursos, un curso concreto, o incluso un módulo o bloque específico.
Un mismo usuario puede tener roles distintos según el contexto: administrador a nivel de sitio, pero solo estudiante dentro de un curso concreto en el que se ha matriculado por interés personal, por ejemplo.
La jerarquía de contextos y cómo se hereda un rol
Aquí está la clave que casi nadie tiene clara, y de donde salen la mayoría de los accesos indebidos. Los contextos de Moodle están anidados, de más amplio a más específico:
Sistema (todo el sitio) > Categoría de cursos > Curso > Módulo de actividad (o bloque)
Un rol asignado en un contexto se hereda hacia abajo, hacia todos los contextos que cuelgan de él. Si asignas a alguien el rol de Profesor a nivel de una categoría, esa persona es profesor en cada curso que haya dentro de esa categoría, y en cada curso que se cree ahí en el futuro. La herencia no sube: un rol asignado en un curso concreto no da acceso a la categoría ni al resto del sitio.
El error clásico es asignar en el contexto equivocado, y casi siempre en el mismo sentido: dar el rol en un contexto más amplio del que hacía falta. El caso típico es asignar Profesor a nivel de sitio (en Administración del sitio > Usuarios > Asignar roles de sistema) cuando lo que se quería era hacer a alguien profesor de un curso. Resultado: esa persona pasa a ser profesor de todos los cursos de la plataforma, presentes y futuros, sin que aparezca en la lista de participantes de ningún curso individual, por eso no se detecta hasta que alguien revisa las asignaciones de sistema a mano.
La regla práctica: asigna siempre en el contexto más estrecho que resuelva el problema. Profesor de un curso se matricula en ese curso (Participantes > Matricular usuarios), no en los roles de sistema. Un rol a nivel de categoría solo tiene sentido cuando alguien gestiona de verdad toda esa rama.
Roles y capacidades: Permitir, Prevenir y Prohibir
Un rol no es más que una lista de capacidades (capabilities), y cada capacidad puede estar en uno de cuatro estados dentro del rol. Entender qué significa cada uno es lo que separa una configuración deliberada de una que “más o menos funciona”:
- No establecido / Heredar: el rol no dice nada sobre esa capacidad. El usuario la tendrá o no según lo que le den otros roles o el contexto superior. Es el estado por defecto de la mayoría de capacidades en un rol.
- Permitir: concede la capacidad. Un profesor tiene
mod/assign:gradeen Permitir, por eso puede calificar. - Prevenir: retira la capacidad en este rol, pero se puede volver a conceder más abajo con una anulación o con otro rol. Es un “no, salvo que algo más específico diga lo contrario”.
- Prohibir: retira la capacidad y no se puede anular en ningún contexto inferior ni con ningún otro rol. Es la única regla que gana siempre. Por eso Prohibir se usa con muchísima cautela: si prohíbes una capacidad en un rol asignado a nivel de sitio, no hay forma de devolvérsela a esa persona en un curso concreto salvo quitando el rol entero.
La diferencia entre Prevenir y Prohibir es la que más confunde. Prevenir es la opción normal para quitar algo; Prohibir es el candado definitivo que te deja sin margen de maniobra. Si alguna vez un usuario “no puede hacer X y no hay manera de arreglarlo por permisos”, casi siempre hay un Prohibir olvidado en un contexto superior.
Anulaciones de permisos: overrides a nivel de contexto
No hace falta crear un rol nuevo cada vez que quieres cambiar un permiso en un sitio concreto. Las anulaciones (overrides) permiten ajustar, dentro de un contexto, qué puede hacer un rol solo ahí, sin tocar la definición global del rol.
Se hacen desde el contexto en cuestión (por ejemplo, dentro de un curso, en Participantes > Permisos (o el menú de engranaje > Permisos)) eligiendo un rol y cambiando el estado de una capacidad concreta a Permitir o Prevenir para ese contexto y los que cuelgan de él. Ejemplo real: quieres que en un curso concreto los estudiantes no puedan iniciar mensajes privados entre ellos; anulas esa capacidad del rol Estudiante solo en ese curso, sin afectar al resto de la plataforma.
Las anulaciones son el bisturí; crear roles nuevos es el martillo. El problema es que también son la fuente número uno de “permisos que nadie recuerda haber tocado”: una anulación hecha hace dos años en una categoría sigue aplicándose a cada curso nuevo que se cree ahí dentro. Por eso, cuando algo no cuadra, conviene revisar los overrides del contexto y de todos sus contextos padre, no solo la definición del rol.
Los roles por defecto y su alcance típico
| Rol | Alcance típico |
|---|---|
| Administrador del sitio | Control total sobre toda la instalación, incluida configuración de servidor y usuarios |
| Gestor (Manager) | Gestión de cursos y usuarios dentro de una categoría, sin acceso a configuración global del servidor |
| Profesor | Edición completa de contenido, calificaciones y matriculación dentro de sus cursos asignados |
| Profesor no editor | Puede calificar y ver informes, pero no modificar el contenido del curso |
| Estudiante | Acceso a su propio progreso, contenido del curso y comunicación, sin visibilidad sobre otros participantes más allá de lo configurado |
| Invitado | Acceso muy limitado, normalmente solo lectura de contenido público |
Pero el alcance no lo define solo el rol: lo define el rol más el contexto donde lo asignas. Esta segunda tabla es la que de verdad conviene tener a mano cuando revisas quién tiene qué, porque cruza ambas cosas:
| Rol | Dónde se asigna normalmente | A qué da acceso |
|---|---|---|
| Administrador del sitio | Administración del sitio > Usuarios > Asignar roles de sistema | Todo: configuración de servidor, plugins, todos los usuarios y todos los cursos |
| Gestor | Categoría de cursos (o sistema, si gestiona todo) | Crear/editar cursos, matricular y gestionar usuarios dentro de su rama, sin tocar configuración global |
| Profesor | Un curso concreto (Participantes > Matricular usuarios) | Editar contenido, calificar, matricular y ver informes solo de ese curso |
| Profesor no editor | Un curso concreto | Calificar y ver informes de ese curso, sin modificar su contenido |
| Estudiante | Un curso concreto (matriculación) | Su propio progreso y el contenido del curso; sin visibilidad sobre otros participantes más allá de lo configurado |
| Rol personalizado de inspección | Curso o categoría, según el alcance de la revisión | Solo lectura de informes, registros y calificaciones; sin editar nada (ver más abajo) |
La lectura correcta de esta tabla es de derecha a izquierda: primero decides qué acceso necesita la persona, y de ahí sale en qué contexto asignar qué rol. Cuando se hace al revés, “le doy administrador y ya veremos”: es cuando aparecen los accesos indebidos.
Errores de configuración más comunes
Asignar rol de Administrador cuando bastaba con Gestor
Es habitual dar acceso de administrador completo a alguien que solo necesita gestionar cursos dentro de una categoría concreta, exponiendo innecesariamente configuración global del servidor a alguien que no la necesita ni debería tocar.
Permisos heredados de plantillas de curso sin revisar
Al duplicar un curso o crear uno nuevo a partir de una plantilla, los roles y permisos asignados a nivel de curso se copian tal cual, si la plantilla original tenía una configuración permisiva, ese error se propaga a cada curso nuevo creado a partir de ella.
Cuentas de usuarios inactivas con permisos elevados sin desactivar
Un profesor o administrador que ya no trabaja en el centro, pero cuya cuenta sigue activa con los mismos permisos, es un riesgo silencioso, especialmente si esa persona conserva acceso a información sensible o capacidad de modificar configuración.
Roles personalizados mal definidos
Crear un rol personalizado sin revisar exactamente qué capacidades incluye puede otorgar accesos no previstos por error, especialmente si se parte de duplicar un rol existente y solo se ajustan algunas capacidades sin revisar el conjunto completo.
Contexto incorrecto al asignar un rol
Asignar un rol a nivel de sitio completo cuando debería limitarse a una categoría o un curso concreto es de los errores más frecuentes y menos visibles, el usuario obtiene acceso a mucho más de lo que necesita, sin que nadie lo note hasta que se revisa explícitamente.
El alumno que ve de más
Un estudiante que puede ver las calificaciones de sus compañeros, descargar la lista de participantes con sus correos, o acceder a los registros de actividad casi nunca es un fallo del rol Estudiante por defecto, es una anulación mal puesta o un bloque configurado sin restricción. Suele salir de dar Permitir a una capacidad de vista (por ejemplo, ver el informe de calificaciones completo) en una anulación a nivel de curso o categoría que luego nadie retiró. Es el caso donde Comprobar permisos (más abajo) ahorra más tiempo: te dice exactamente de qué asignación viene el acceso.
El profesor con permisos de gestor
Pasa cuando se quiere que un profesor “también pueda crear cursos” o “gestionar matrículas de toda su área” y, en vez de darle el rol de Gestor en su categoría, se le sube a un rol más potente a nivel de sitio, o se le añaden capacidades de gestión al propio rol Profesor global. El profesor acaba con capacidad de tocar cursos que no son suyos. La solución casi siempre es un Gestor asignado en la categoría correcta, no un profesor con capacidades infladas.
Roles duplicados que se pisan
Un mismo usuario puede acumular varios roles en el mismo contexto, por ejemplo, matriculado como Estudiante y también asignado como Profesor no editor en el mismo curso. Los permisos se combinan, y ahí es donde la diferencia entre Prevenir y Prohibir se vuelve crítica: si un rol prohíbe algo, gana sobre cualquier otro que lo permita. Los roles duplicados hacen que el acceso real de una persona sea difícil de predecir a ojo, y son un motivo habitual de “juraría que esto no lo veía y ahora sí”.
Cómo auditar los roles de tu instalación
- Revisa la lista de usuarios con rol de Administrador del sitio (Site administration > Users > Assign system roles) y confirma que cada uno de ellos realmente necesita ese nivel de acceso.
- Revisa los roles asignados a nivel de categoría de curso, no solo a nivel de curso individual, ya que ahí se acumulan permisos amplios que afectan a varios cursos a la vez.
- Comprueba las cuentas inactivas (sin acceso reciente) que aún conservan roles con privilegios elevados.
- Revisa cualquier rol personalizado creado en la plataforma, confirmando exactamente qué capacidades incluye, no solo su nombre.
- Verifica el contexto de cada asignación de rol, asegurando que ningún usuario tiene un rol asignado a nivel de sitio cuando debería estar limitado a un curso o categoría concreta.
Crear un rol personalizado: el usuario de inspección de solo lectura
El caso donde un rol personalizado se justifica de sobra es el usuario de inspección: alguien que necesita entrar a mirar (un auditor, un responsable de calidad, o tú mismo comprobando un curso antes de una revisión) pero que no debe poder modificar nada. Darle rol de Profesor “para que vea” es exactamente el error de conceder de más: el profesor puede editar, calificar y borrar.
Se crea en Administración del sitio > Usuarios > Permisos > Definir roles > Añadir un nuevo rol. Tres decisiones importan:
- El arquetipo: parte del arquetipo que más se parezca (Estudiante suele ser buen punto de partida para solo-lectura, o ninguno si quieres empezar en blanco). El arquetipo define cómo se comporta el rol al restablecer permisos por defecto y cómo lo trata Moodle en ciertas funciones, no es solo cosmético.
- El contexto donde se puede asignar: en Tipos de contexto donde se puede asignar este rol marcas Curso y/o Categoría. Si no marcas ninguno, el rol existe pero no podrás asignárselo a nadie donde lo necesitas.
- Las capacidades: dejas en Permitir solo las de vista (ver informes, registros y calificaciones) y te aseguras de que las de edición, calificación y matriculación queden fuera. La idea es un rol que solo suma “mirar”.
Luego lo asignas en el curso o la categoría concretos que se van a inspeccionar, no a nivel de sitio, siguiendo la misma regla de contexto estrecho de siempre. Este es justo el tipo de acceso que conviene preparar antes de una revisión documental, lo tratamos con más detalle aplicado a formación bonificada en la guía del informe de seguimiento FUNDAE.
Comprobar permisos: la herramienta para depurar
Cuando no entiendes por qué un usuario puede (o no puede) hacer algo, no adivines: usa Comprobar permisos. Dentro del contexto (un curso, una categoría) en el menú de Permisos tienes la opción de Comprobar permisos, eliges al usuario y Moodle te lista todas las capacidades que tiene en ese contexto y de dónde salen. Es la forma más rápida de descubrir un Permitir heredado que no esperabas o un rol duplicado que se está pisando con otro. Cualquier auditoría seria de roles se apoya en esta herramienta más que en revisar definiciones de rol a ciegas. Encaja dentro del enfoque más amplio de seguridad en Moodle: los permisos son una superficie de riesgo tan real como una versión sin parchear.
Por qué esto importa especialmente en formación bonificada
Si gestionas formación bonificada FUNDAE, una configuración de roles descuidada puede además comprometer la trazabilidad exigida: un usuario con permisos excesivos podría, sin mala intención, modificar registros de calificación o completado que forman parte de la evidencia documental del curso, algo que una auditoría podría interpretar como manipulación de datos, independientemente de la intención real.
Preguntas frecuentes
¿Cuál es la diferencia entre el rol de Administrador y el de Gestor? El Administrador tiene control total sobre toda la instalación, incluida la configuración de servidor; el Gestor gestiona cursos y usuarios dentro de un alcance más limitado, normalmente una categoría, sin tocar configuración global.
¿Puedo tener roles distintos en distintos cursos? Sí, los roles se asignan por contexto, así que un mismo usuario puede ser profesor en un curso y solo estudiante en otro, según cómo se haya configurado cada asignación.
¿Cómo detecto si alguien tiene más permisos de los que debería? Revisando sistemáticamente las asignaciones de rol a nivel de sitio, categoría y curso, prestando especial atención a cuentas inactivas y a roles personalizados sin revisar en detalle.
¿Qué pasa si duplico un curso con permisos mal configurados? Los permisos se copian tal cual en el curso nuevo, propagando cualquier error de configuración original a cada copia posterior.
¿Debo revisar los roles con regularidad o solo al configurarlos por primera vez? Con regularidad. Cambios de personal, cuentas que quedan inactivas, y cursos nuevos creados a partir de plantillas antiguas hacen que la configuración de roles se desvíe con el tiempo si no se audita periódicamente.
¿Un rol personalizado es más arriesgado que uno de los roles por defecto? No necesariamente, pero requiere revisión explícita de cada capacidad incluida, ya que es fácil otorgar accesos no previstos si solo se ajustan algunas capacidades sobre un rol duplicado sin revisar el conjunto completo.
¿Los permisos de roles afectan a la trazabilidad de formación bonificada? Sí, un usuario con permisos excesivos podría modificar registros que forman parte de la evidencia documental exigida por FUNDAE, incluso sin intención de manipular nada.
¿Qué diferencia hay entre Prevenir y Prohibir una capacidad? Prevenir retira la capacidad en ese rol, pero se puede volver a conceder más abajo con una anulación u otro rol. Prohibir la retira de forma definitiva: no se puede anular en ningún contexto inferior ni con ningún otro rol. Por eso Prohibir se usa con mucha cautela; si alguien “no puede hacer algo y no hay manera de arreglarlo”, suele haber un Prohibir olvidado en un contexto superior.
¿Cómo doy acceso de solo lectura a un auditor sin que pueda editar nada? Crea un rol personalizado de inspección (en Definir roles), déjale en Permitir solo las capacidades de vista, marca Curso y Categoría como contextos donde se puede asignar, y asígnaselo únicamente en el curso o categoría que va a revisar. No uses el rol de Profesor “para que solo mire”: el profesor puede editar y calificar.
Un rol asignado a nivel de categoría, ¿afecta a los cursos que se creen después? Sí. La herencia de contextos aplica hacia abajo también en el tiempo: cualquier curso nuevo dentro de esa categoría hereda el rol y las anulaciones que haya en ella. Es una de las razones por las que una asignación amplia hecha una vez sigue teniendo efecto años después sin que nadie lo recuerde.
¿Cómo sé exactamente de dónde viene el acceso de un usuario a algo? Usa Comprobar permisos dentro del contexto (curso o categoría) desde el menú de Permisos: eliges al usuario y Moodle te muestra todas sus capacidades ahí y su origen. Es mucho más fiable que deducirlo revisando definiciones de rol por separado.
Conclusión
La mayoría de accesos indebidos en Moodle no vienen de un ataque externo, sino de una configuración de roles que nunca se revisó desde que se creó, permisos heredados de plantillas, cuentas inactivas con privilegios activos, o roles asignados en un contexto más amplio del necesario. Una auditoría periódica de roles es una de las medidas de seguridad más baratas de aplicar, y de las más olvidadas.
Si prefieres que alguien revise esto de forma sistemática, en Avantys lo incluimos como parte de la auditoría de seguridad de cada Moodle que gestionamos. Puedes pedirla gratis en Moodle Gestionado.
Artículos relacionados
- Mantenimiento y hosting Moodle: guía completa
- Checklist de hardening de Moodle
- Cómo proteger Moodle de ataques y vulnerabilidades
- RGPD y LOPD en plataformas Moodle
¿Y si tu Moodle lo lleváramos nosotros?
Actualizaciones, backups verificados, rendimiento y trazabilidad FUNDAE, gestionado de forma continua por una persona que responde. Auditoría gratuita de tu plataforma actual.
