La fuite Canvas et la sécurité des données étudiantes

Plus tôt cette année, Canvas, l’un des plus grands systèmes de gestion de l’apprentissage au monde, a subi une fuite de données. Des noms, adresses e-mail, numéros d’étudiant et messages privés entre utilisateurs ont été exposés. La plateforme est exploitée par Instructure et utilisée par des milliers d’établissements et des millions d’étudiants. C’est exactement ce qui en fait une cible, et ce qui donne à cet incident une portée qui dépasse Canvas.

Si vous exploitez une plateforme d’apprentissage, ou si vous en construisez une, cela mérite quelques minutes de réflexion. Pas pour paniquer, mais parce que la leçon d’une fuite comme celle-ci n’est presque jamais celle que l’on imagine. Les entreprises qui en tirent la mauvaise leçon sont souvent celles qui la répètent.

La plupart des fuites ne sont pas sophistiquées. Ce sont des erreurs ordinaires à grande échelle.

On imagine volontiers les fuites de données comme l’œuvre de hackers brillants qui traversent plusieurs lignes de défense. Cela arrive parfois. Bien plus souvent, la cause est banale : un point d’accès API exposé qui n’aurait jamais dû être public, une permission mal configurée qui donne à un rôle accès à des données interdites, une base de données accessible depuis Internet, un jeton d’accès qui n’expire jamais.

Ce ne sont pas des problèmes exotiques. Ils apparaissent tôt dans la vie d’un produit, quand l’équipe est petite, avance vite et n’est pas encore attaquée. Le raccourci fonctionne. La fonctionnalité est livrée. Puis tout le monde passe à la suite.

Le problème, c’est que ces raccourcis ne sont pas nettoyés. Ils disparaissent sous les cent fonctionnalités suivantes. Le jour où votre plateforme devient assez grande pour intéresser un attaquant, chacun de ces raccourcis devient une porte d’entrée. Vous ne subissez pas une fuite parce que vous avez fait quelque chose d’exceptionnellement mal. Vous la subissez parce que vous avez fait quelque chose de banalement incorrect, puis que vous avez pris assez d’importance pour que cela compte.

Pourquoi les données étudiantes changent l’enjeu

Toutes les données ne se valent pas, et les données étudiantes se situent très haut sur l’échelle de sensibilité.

Dans bien des cas, vous détenez des informations sur des mineurs. Vous avez peut-être des numéros d’étudiant qui, dans certains systèmes, sont reliés aux dossiers académiques ou même à des identifiants gouvernementaux. Vous détenez des messages privés, des coordonnées et des données comportementales sur la manière dont les personnes apprennent. C’est précisément le type d’information qui cause un préjudice réel lorsqu’il fuit, et celui qui préoccupe le plus les régulateurs. Aux États-Unis, FERPA fixe les règles sur l’accès aux dossiers scolaires. Les conséquences d’une erreur ne sont pas théoriques.

L’ironie est que le secteur des technologies éducatives protège souvent ces données moins soigneusement que des secteurs qui détiennent des informations bien moins sensibles. La raison est une question de priorité. La plupart des plateformes d’apprentissage sont bâties dans une course aux fonctionnalités, à l’engagement et au contenu. La sécurité est invisible quand elle fonctionne ; elle perd donc chaque arbitrage face à ce que le client peut voir. Ce compromis semble acceptable jusqu’au moment où il cesse très publiquement de l’être.

Les questions à poser sur votre propre plateforme

Vous n’avez pas besoin d’un audit de sécurité pour commencer à raisonner correctement. Quelques questions honnêtes font remonter l’essentiel du risque.

Qui peut accéder à vos données étudiantes, et cet accès est-il journalisé ? Si un ingénieur, un agent de support ou un administrateur peut ouvrir un dossier d’étudiant, gardez-vous la trace de qui a consulté quoi et quand ? Sans journalisation, vous ne pouvez même pas détecter un problème, encore moins établir ce qui s’est passé ensuite.

Si un compte est compromis, les dégâts restent-ils limités à ce compte ? C’est la question du rayon d’explosion. Un mot de passe volé devrait exposer les données d’un seul utilisateur, pas toute la base. Si un compte support compromis peut lire les messages de chaque étudiant, vous n’avez pas un problème de compte : vous avez un problème d’architecture.

Quand quelqu’un a-t-il testé vos permissions pour la dernière fois, plutôt que de supposer qu’elles fonctionnent ? Les systèmes de permissions se dégradent en silence. Un rôle reçoit une capacité pour un cas ponctuel, personne ne la retire, et deux ans plus tard ce rôle voit des données qu’il n’aurait jamais dû voir. Supposer que vos permissions fonctionnent encore comme au lancement, c’est ouvrir la brèche.

Que devient la donnée dont vous n’avez plus besoin ? Anciens comptes, cours terminés, anciens étudiants. Les données que vous stockez encore sans les utiliser sont une responsabilité pure. Elles ne vous aident plus et peuvent toujours fuir.

La sécurité est une décision d’architecture, pas une fonctionnalité

La leçon essentielle d’une fuite comme celle-ci concerne le moment où l’on agit. La sécurité ne s’ajoute pas une fois qu’une entreprise est assez grande pour se l’offrir. À ce stade, les fondations dangereuses supportent déjà le produit, et les corriger impose de reconstruire des éléments centraux d’un système utilisé par de vraies personnes.

Les plateformes qui gèrent bien les données étudiantes ont pris cette décision tôt. Elles ont intégré les contrôles d’accès, la journalisation et des frontières de données cohérentes dans leurs fondations, quand c’était simple et peu coûteux, avant qu’il y ait quoi que ce soit à voler. Les autres sont celles qui écrivent ensuite des e-mails publics de divulgation de fuite.

Si vous construisez ou exploitez une plateforme d’apprentissage, vous n’avez pas à tout résoudre d’un coup. Mais vous devez cesser de traiter la sécurité comme un problème futur. C’est une décision que vous prenez aujourd’hui dans l’architecture, ou une facture que vous paierez publiquement demain.

Je conçois des plateformes e-learning sur mesure pour les équipes edtech et L&D, avec la sécurité et l’architecture des données intégrées dès le départ plutôt qu’ajoutées après coup. Si vous réfléchissez à la protection des données étudiantes sur votre plateforme, c’est exactement le type de problème que j’aide à résoudre.