La filtración de Canvas y la seguridad de datos de estudiantes

A principios de este año, Canvas, uno de los sistemas de gestión del aprendizaje más grandes del mundo, sufrió una filtración de datos. Se expusieron nombres, direcciones de correo, números de estudiante y mensajes privados entre usuarios. La plataforma la opera Instructure y la usan miles de centros y millones de estudiantes. Eso es justamente lo que la convierte en objetivo y lo que hace que el incidente importe más allá de Canvas.

Si gestionas una plataforma de aprendizaje, o estás construyendo una, conviene detenerse un momento en esto. No para entrar en pánico, sino porque la lección de una filtración así casi nunca es la que la gente supone. Las empresas que extraen la lección equivocada suelen ser las que la repiten.

La mayoría de las filtraciones no son sofisticadas. Son errores básicos a escala.

Existe el mito de que las filtraciones son obra de hackers brillantes que atraviesan capas de defensa. A veces es así. Con mucha más frecuencia, la causa es mundana: un endpoint de API expuesto que nunca debió ser público, un permiso mal configurado que deja a un rol ver datos que no le corresponden, una base de datos accesible desde Internet o un token de acceso que jamás caduca.

No son problemas exóticos. Aparecen al principio de la vida de un producto, cuando el equipo es pequeño, avanza deprisa y todavía nadie lo ataca. El atajo funciona. Se publica la funcionalidad. Todo el mundo sigue adelante.

El problema es que esos atajos no se limpian. Quedan enterrados bajo las siguientes cien funcionalidades. El día en que tu plataforma crece lo suficiente como para merecer un ataque, cada atajo inicial se convierte en una puerta. No sufres una filtración porque hiciste algo extraordinariamente mal. La sufres porque hiciste algo normalmente mal y luego creciste lo suficiente para que importara.

Por qué los datos de estudiantes elevan tanto el riesgo

No todos los datos son iguales, y los de estudiantes están cerca de la parte más sensible de la escala.

En muchos casos guardas información de menores. Puede que tengas números de estudiante que, en algunos sistemas, enlazan con expedientes académicos o incluso identificadores gubernamentales. Tienes mensajes privados, datos de contacto y señales de comportamiento sobre cómo aprende la gente. Es justo el tipo de información que causa un daño real cuando se filtra y el que más preocupa a los reguladores. En Estados Unidos, FERPA establece quién puede ver los expedientes educativos de un estudiante. Las consecuencias de equivocarse no son teóricas.

La ironía es que el sector de tecnología educativa a menudo protege estos datos con menos cuidado que industrias que guardan información mucho menos sensible. La causa es el enfoque. La mayoría de las plataformas de aprendizaje se construyen en una carrera por funcionalidades, participación y contenido. La seguridad es invisible cuando funciona, así que pierde cada discusión de prioridades frente a lo que el cliente sí puede ver. Esa concesión parece razonable hasta el momento, muy público, en que deja de serlo.

Las preguntas que merece la pena hacerse sobre tu plataforma

No necesitas una auditoría de seguridad para empezar a pensar con claridad. Unas pocas preguntas honestas sacan a la luz la mayor parte del riesgo real.

¿Quién puede acceder a los datos de estudiantes y queda registrado ese acceso? Si un ingeniero, una persona de soporte o un administrador puede abrir expedientes, ¿queda constancia de quién vio qué y cuándo? Acceso sin registros significa que ni siquiera puedes detectar el problema, mucho menos demostrar qué ocurrió después.

Si se compromete una cuenta, el daño se limita a esa cuenta? Esta es la pregunta del radio de impacto. Una contraseña robada debería exponer los datos de una sola persona, no toda la base. Si un acceso de soporte comprometido puede leer los mensajes de cada estudiante, no tienes un problema de cuenta: tienes un problema de arquitectura.

¿Cuándo fue la última vez que alguien probó los permisos en vez de asumir que funcionan? Los sistemas de permisos se degradan en silencio. Un rol recibe una capacidad por una excepción, nadie la retira y dos años después ese rol puede ver cosas que nunca debió ver. Suponer que los permisos siguen igual que el día del lanzamiento es como se abre la brecha.

¿Qué ocurre con los datos que ya no necesitas? Cuentas antiguas, cursos terminados, antiguos estudiantes. Los datos que aún guardas pero ya no usas son responsabilidad pura. No pueden ayudarte y todavía pueden filtrarse.

La seguridad es una decisión de arquitectura, no una funcionalidad

La lección más importante de una filtración así tiene que ver con el momento. La seguridad no es algo que añades cuando ya eres lo bastante grande para pagarla. Para entonces, las bases inseguras ya soportan peso y corregirlas exige reconstruir partes centrales de un sistema que presta servicio a usuarios reales.

Las plataformas que tratan bien los datos de estudiantes tomaron la decisión pronto. Incluyeron controles de acceso, registros y límites sensatos de datos en los cimientos, cuando era barato y sencillo, antes de que hubiera nada que robar. Las que no lo hicieron son las que después redactan correos públicos anunciando la filtración.

Si construyes o gestionas una plataforma de aprendizaje, no tienes que resolverlo todo de golpe. Pero sí tienes que dejar de tratar la seguridad como un problema futuro. Es una decisión que tomas hoy en la arquitectura o una factura que pagarás públicamente mañana.

Construyo plataformas de e-learning a medida para equipos edtech y L&D, con seguridad y arquitectura de datos integradas desde el principio, no añadidas después. Si estás pensando cómo proteger los datos de estudiantes en tu plataforma, ese es exactamente el tipo de problema que ayudo a resolver.