Seguridad de la plataforma

1. Encriptacion en transito

Todo el trafico entre el navegador del usuario y los servidores de la plataforma se realiza sobre HTTPS con TLS 1.3 (o TLS 1.2 como fallback para navegadores antiguos). No servimos contenido ni aceptamos formularios por HTTP sin redireccion a HTTPS. Los certificados son gestionados y renovados automaticamente por nuestra infraestructura de hosting, que aplica cifrados modernos (AES-GCM) y reenvia el header Strict-Transport-Security a los clientes.

2. Encriptacion de datos almacenados

Los datos persistidos se almacenan en infraestructura administrada con encriptacion a nivel de disco habilitada por defecto:

• Base de datos PostgreSQL (Neon): los volumenes que contienen la base de datos estan encriptados en reposo con AES-256. Las conexiones desde la aplicacion requieren TLS.
• Almacenamiento de archivos (S3-compatible): los objetos subidos por usuarios (tareas, imagenes, repositorio) se encriptan en reposo del lado del proveedor. El acceso se controla mediante URLs firmadas temporales, no enlaces publicos.

3. Autenticacion y contrasenas

Las credenciales de usuario se manejan con practicas estandar del ecosistema:

• Hashing de contrasenas con bcrypt, con factor de coste 12 para toda contrasena que elige una persona o que fija un administrador. Las contrasenas temporales que genera al azar la importacion masiva usan coste 5: son cadenas aleatorias de 12 caracteres (unos 69 bits), que ningun ataque de diccionario acorta, y deben cambiarse en el primer inicio de sesion, cuando la nueva se guarda con coste 12. Nunca almacenamos ni tenemos forma de recuperar una contrasena en texto plano; un reseteo genera siempre una nueva.
• Sesiones por JWT firmado. El token incluye solo el identificador del usuario, su rol, su organizacion y una huella corta e irreversible de su contrasena: cuando la contrasena cambia se cierran todas sus sesiones abiertas, salvo la sesion desde la que la propia persona la cambio. Se firma con una clave secreta no expuesta al cliente. La cookie es HttpOnly, Secure y SameSite=Lax.
• Cambio de contrasena obligatorio al primer inicio para cuentas creadas por el administrador, para que la contrasena temporal no persista.
• No se permite compartir credenciales ni se toleran cuentas compartidas; ver tambien la seccion "Uso aceptable" de los Terminos de Servicio.

Autenticacion de dos factores (2FA) e inicio de sesion unico (SSO/SAML) no estan disponibles en la version actual. Estamos evaluando su inclusion en funcion de la demanda de instituciones contratantes; contactanos si es un requisito de tu institucion.

4. Aislamiento multi-tenant

Gnosis es una plataforma multi-institucion. Cada organizacion opera en un espacio logicamente aislado dentro de la misma base de datos, pero:

• Toda entidad de negocio (cursos, clases, modulos, usuarios, matriculas, archivos) pertenece a una organizacion identificada por organizacionId.
• Las consultas desde APIs y paginas exigen organizacionId en cada filtro, verificado a partir de la sesion del usuario y no de parametros del cliente. No es posible pedir los datos de otra organizacion por cambiar un ID en la URL.
• Los roles ADMIN y PROFESOR tienen siempre scope de su organizacion. El rol SUPERADMIN (interno de la plataforma) no aparece en el dashboard de ninguna institucion.
• Los profesores solo ven estudiantes y datos de las clases que tienen asignadas, no de toda la organizacion. La excepcion, que estamos corrigiendo, es la mensajeria interna: quien participa en una conversacion tiene acceso a todos sus mensajes y al nombre y el correo de quienes los enviaron o recibieron (y a si ya los leyeron), aunque sean de otras clases; y su respuesta llega a quien envio el ultimo mensaje y a todos los que lo recibieron, sin comprobar si puede escribirles.

5. Autorizacion por rol

Las operaciones sensibles requieren un rol explicito:

• Crear o editar cursos, clases, estudiantes y miembros del equipo es exclusivo de ADMIN (a nivel de UI y de endpoint).
• Los PROFESORES gestionan contenido (modulos, evaluaciones, calificaciones) dentro de sus clases asignadas.
• Las evaluaciones cuentan con proteccion anti-fraude opcional (bloqueo de copiar/pegar, marca de agua con el nombre del estudiante, deteccion de cambio de ventana).

6. Respaldos y continuidad

La base de datos realiza respaldos automaticos de acuerdo al plan de infraestructura contratado, incluyendo retencion por un plazo que permite restaurar a un punto anterior en caso de incidentes. El almacenamiento de archivos replica objetos conforme a las garantias de durabilidad del proveedor. En situaciones de mantenimiento programado notificamos con antelacion razonable por los canales de la plataforma.

7. Monitoreo y observabilidad

La plataforma esta instrumentada para detectar incidentes antes de que lleguen a ser reportados por usuarios:

• Disponibilidad: un monitor externo chequea cada pocos minutos el endpoint publico /api/health, que verifica tambien la conectividad con la base de datos y devuelve 503 si hay un problema. Las caidas disparan alerta inmediata.
• Errores de aplicacion: las excepciones no capturadas (servidor y cliente) se registran en un servicio externo de monitoreo con agrupacion por huella y notificacion al equipo tecnico. No se envian datos personales (IP, cookies, headers sensibles) y el contenido textual de las paginas se enmascara en los registros de sesion.
• Actualizaciones sin downtime: los despliegues se realizan de forma atomica; una version nueva recibe trafico solo cuando pasa el build y las migraciones, y la anterior se sigue sirviendo hasta ese momento.

8. Gestion de vulnerabilidades y reporte

Las dependencias de terceros se actualizan con regularidad mediante revisiones de seguridad automaticas. Si descubres una vulnerabilidad o un comportamiento inesperado, preferimos recibir el reporte por correo de forma privada antes de que sea publicado:

9. Alcance y limites honestos

Para evitar expectativas erroneas, Gnosis LMS no cuenta actualmente con:

• Certificaciones formales del tipo SOC 2 o ISO 27001.
• Autenticacion de dos factores (2FA) ni SSO/SAML empresarial.
• Registro detallado de auditoria exportable (auditoria basica de eventos criticos si existe, pero no un log continuo estilo SIEM).
• Cifrado de datos del lado del cliente (end-to-end).

Si alguno de estos puntos es requisito para tu institucion, escribenos: priorizamos features segun la demanda real de las instituciones cliente.