Die Canvas-Datenpanne und die Sicherheit von Schülerdaten

Anfang dieses Jahres erlitt Canvas, eines der größten Lernmanagementsysteme der Welt, eine Datenpanne. Namen, E-Mail-Adressen, Studierendennummern und private Nachrichten zwischen Nutzenden wurden offengelegt. Die Plattform wird von Instructure betrieben und von Tausenden Schulen sowie Millionen Lernenden genutzt. Genau das macht sie zum Ziel und erklärt, warum der Vorfall über Canvas hinaus Bedeutung hat.

Wenn Sie eine Lernplattform betreiben oder bauen, lohnt es sich, kurz innezuhalten. Nicht um in Panik zu geraten, sondern weil die Lehre aus einer solchen Datenpanne fast nie die ist, die Menschen vermuten. Unternehmen, die daraus die falsche Lehre ziehen, wiederholen sie oft.

Die meisten Datenpannen sind nicht raffiniert. Es sind einfache Fehler in großem Maßstab.

Es gibt den Mythos, Datenpannen seien das Werk genialer Hacker, die mehrere Schutzschichten durchbrechen. Gelegentlich stimmt das. Viel häufiger ist die Ursache banal: ein offener API-Endpunkt, der nie öffentlich sein sollte, eine falsch konfigurierte Berechtigung, durch die eine Rolle Daten sieht, die ihr nicht zustehen, eine Datenbank, die aus dem offenen Internet erreichbar ist, oder ein Zugangstoken ohne Ablaufdatum.

Das sind keine exotischen Probleme. Sie entstehen früh im Produktleben, wenn ein Team klein ist, schnell arbeitet und noch niemand angreift. Die Abkürzung funktioniert. Das Feature geht live. Alle machen weiter.

Nur werden diese Abkürzungen nicht aufgeräumt. Sie verschwinden unter den nächsten hundert Features. Sobald Ihre Plattform groß genug wird, um einen Angriff zu lohnen, wird jede frühe Abkürzung zu einer Tür. Sie werden nicht kompromittiert, weil Sie außergewöhnlich falsch gehandelt haben. Sie werden es, weil Sie etwas gewöhnlich Falsches getan haben und dann groß genug wurden, dass es zählt.

Warum Schülerdaten den Einsatz erhöhen

Nicht alle Daten sind gleich, und Schülerdaten stehen weit oben auf der Sensibilitätsskala.

Oft verwalten Sie Informationen über Minderjährige. Vielleicht besitzen Sie Studierendennummern, die in manchen Systemen mit akademischen Akten oder sogar staatlichen Kennungen verbunden sind. Sie haben private Nachrichten, Kontaktdaten und Verhaltensdaten darüber, wie Menschen lernen. Genau solche Informationen verursachen echten Schaden, wenn sie auslaufen, und interessieren Regulierungsbehörden besonders. In den USA regelt FERPA, wer Bildungsakten einsehen darf. Die Folgen eines Fehlers sind nicht theoretisch.

Ironischerweise schützt die Bildungstechnologiebranche diese Daten oft weniger sorgfältig als Branchen mit viel weniger sensiblen Informationen. Der Grund liegt im Fokus. Lernplattformen werden meist im Wettlauf um Funktionen, Engagement und Inhalte gebaut. Sicherheit ist unsichtbar, wenn sie funktioniert, und verliert daher jede Priorisierungsdebatte gegen das, was Kundinnen und Kunden sehen können. Dieser Kompromiss wirkt vernünftig, bis er es sehr öffentlich nicht mehr ist.

Fragen, die Sie Ihrer eigenen Plattform stellen sollten

Für klares Denken brauchen Sie noch kein Sicherheitsaudit. Einige ehrliche Fragen legen den größten Teil des Risikos frei.

Wer kann auf Schülerdaten zugreifen, und wird dieser Zugriff protokolliert? Wenn Entwickler, Support oder Admins Akten öffnen können, gibt es dann eine Aufzeichnung darüber, wer was wann angesehen hat? Zugriff ohne Protokollierung bedeutet, dass Sie ein Problem nicht einmal erkennen, geschweige denn später belegen können, was passiert ist.

Wenn ein Konto kompromittiert wird, endet der Schaden bei diesem Konto? Das ist die Frage nach dem Schadensradius. Ein gestohlenes Passwort sollte die Daten einer Person offenlegen, nicht die ganze Datenbank. Wenn ein kompromittierter Support-Login die Nachrichten aller Lernenden lesen kann, haben Sie kein Kontoproblem, sondern ein Architekturproblem.

Wann hat zuletzt jemand Ihre Berechtigungen getestet, statt anzunehmen, dass sie funktionieren? Berechtigungssysteme altern leise. Eine Rolle erhält für einen Sonderfall eine neue Fähigkeit, niemand nimmt sie wieder weg, und zwei Jahre später sieht diese Rolle Dinge, die sie nie sehen sollte. Die Annahme, dass Berechtigungen noch wie beim Start funktionieren, öffnet die Lücke.

Was geschieht mit Daten, die Sie nicht mehr brauchen? Alte Konten, abgeschlossene Kurse, ehemalige Lernende. Daten, die Sie noch speichern, aber nicht mehr nutzen, sind reine Belastung. Sie helfen Ihnen nicht und können trotzdem auslaufen.

Sicherheit ist eine Architekturentscheidung, kein Feature

Die wichtigste Erkenntnis jeder solchen Datenpanne betrifft den Zeitpunkt. Sicherheit lässt sich nicht einfach anbauen, sobald ein Unternehmen groß genug ist, sie sich leisten zu können. Dann tragen unsichere Fundamente bereits das Produkt; ihre Korrektur bedeutet, Kernteile eines Systems mit echten Nutzenden neu zu bauen.

Plattformen, die Schülerdaten gut schützen, haben sich früh entschieden. Sie haben Zugriffskontrollen, Protokollierung und sinnvolle Datengrenzen ins Fundament eingebaut, als es günstig und einfach war und noch nichts Wertvolles zu stehlen gab. Die anderen schreiben später Offenlegungs-E-Mails.

Wenn Sie eine Lernplattform bauen oder betreiben, müssen Sie nicht alles zugleich lösen. Sie müssen aber aufhören, Sicherheit als Zukunftsproblem zu behandeln. Es ist eine Entscheidung, die Sie heute in der Architektur treffen, oder eine Rechnung, die Sie morgen öffentlich bezahlen.

Ich entwickle maßgeschneiderte E-Learning-Plattformen für Edtech- und L&D-Teams, mit Sicherheit und Datenarchitektur von Anfang an statt späteren Patches. Wenn Sie den Schutz von Schülerdaten auf Ihrer Plattform durchdenken, helfe ich genau bei dieser Art von Problem.