Souveränität & Betrieb
Cyberangriffe auf Hochschulen
Weniger Angriffsfläche, mehr Ausfallsicherheit
Kilian Peschel
Datenabfluss an der LMU München, Ausfälle beim Hochschulservicezentrum Baden-Württemberg, Angriffe auf die Universitäten Halle und Leipzig: Der Herbst 2026 zeigt, wie unterschiedlich die Folgen von Cyberangriffen sein können. Zwei Architekturentscheidungen verdienen besondere Aufmerksamkeit: die unabhängige Erreichbarkeit der Hochschulwebsite und die kontrollierte Anbindung zentraler Campus-Management-Systeme.
Wenn Hochschulen Ziel eines Cyberangriffs werden, geht es längst nicht nur um verschlüsselte Dateien oder gestohlene Daten. Ganze Verwaltungsprozesse können zum Stillstand kommen. Bewerbungen lassen sich nicht bearbeiten, Prüfungsinformationen nicht abrufen, Beschäftigte nicht erreichen. Und ausgerechnet die Website, über die eine Hochschule in dieser Situation informieren müsste, ist möglicherweise ebenfalls nicht verfügbar.
Die Sicherheitsvorfälle der vergangenen Wochen machen deutlich, wie abhängig Hochschulen von ihrer digitalen Infrastruktur geworden sind. Sie werfen aber auch eine grundsätzliche Frage auf: Wie lassen sich Systeme so gestalten, dass ein erfolgreicher Angriff möglichst wenig Schaden anrichtet?
Zwei Entscheidungen spielen dabei eine wichtige Rolle. Die erste betrifft den Betrieb der öffentlichen Website. Die zweite betrifft die Verbindungen zwischen Campus-Management, Website und weiteren digitalen Anwendungen.
Vier Angriffe, eine Sicherheitslücke, unterschiedliche Folgen
Am 16. September 2026 stellte die Ludwig-Maximilians-Universität München einen unbefugten Zugriff auf ein IT-System mit Stamm- und Immatrikulationsdaten fest. Nach den Ende September veröffentlichten Untersuchungsergebnissen waren rund 600.000 Datensätze aktueller und ehemaliger Studierender betroffen. Je nach Zeitraum und Einzelfall gehörten dazu auch Bankverbindungen und weitere personenbezogene Informationen.
Am 7. Oktober traf ein Cyberangriff das Hochschulservicezentrum Baden-Württemberg (HSZ-BW) in Reutlingen. Das Zentrum stellt IT-Dienste für zahlreiche Hochschulen des Landes bereit. Nach Bekanntwerden des Angriffs wurden die Systeme vorsorglich vom Netz genommen. Die Folgen reichten weit über das Servicezentrum hinaus: Noten-, Bewerbungs- und Stundenplansysteme fielen aus, Zeugnisse konnten nicht ausgestellt, Lehrbeauftragte zunächst nicht bezahlt werden. Nach der forensischen Untersuchung wurde ein Datenabfluss von etwa einem Gigabyte gemeldet. Die weitreichenden Betriebsunterbrechungen zeigen, dass sich der Schaden eines Angriffs nicht allein an der Menge abgeflossener Daten bemisst.
Am 14. Oktober wurde an der Martin-Luther-Universität Halle-Wittenberg ein Angriff festgestellt, bei dem Unbefugte nach Angaben der Universität möglicherweise Zugriff auf Daten aus rund 51.000 Studienbewerbungen erlangten. Betroffen waren unter anderem Namen, Adressen, Geburtsdaten und Angaben zum Bewerbungsverfahren. Auch ein Zugriff auf hochgeladene Bewerbungsdokumente war möglich.
Am 21. Oktober kam ein Vorfall anderer Art hinzu: die Veröffentlichung kritischer Sicherheitslücken in PHP, bekannt unter dem Namen PHP2Shell. Angreifer konnten auf ungepatchten Webservern ohne Anmeldung Schadcode ausführen. Zahlreiche Hochschulen nahmen ihre Webauftritte vorsorglich vom Netz, darunter die Universität Freiburg mit Lernplattform und Webmail, die Hochschule Bielefeld und die Universität Paderborn. Die Ruhr-Universität Bochum war drei Tage später von außen noch nicht erreichbar.
Am 28. Oktober nahm die Universität Leipzig nach einem Angriff ihre IT-Dienste vorsorglich vom Netz. Website, E-Mail und zahlreiche digitale Anwendungen standen zunächst nicht zur Verfügung. Um dennoch informieren zu können, richtete die Universität eine Ersatzwebsite unter ihrer bekannten Internetadresse ein.
Die Vorfälle haben unterschiedliche Ursachen und Auswirkungen. Ein Zusammenhang zwischen ihnen ist nicht bekannt. Auch lässt sich aus den veröffentlichten Informationen nicht ableiten, dass bestimmte Hosting- oder Schnittstellenarchitekturen die jeweiligen Angriffe verhindert hätten.
Sie verdeutlichen aber zwei Risiken: Zentral betriebene Dienste können zahlreiche Einrichtungen gleichzeitig beeinträchtigen. Und jede zusätzliche Verbindung zu einem System mit sensiblen Daten muss als potenzieller Angriffsweg betrachtet werden.
Lehre 1: Die Website muss auch im Krisenfall erreichbar bleiben
Eine Hochschulwebsite ist mehr als ein Informations- und Marketingkanal. Im Krisenfall wird sie zur zentralen Anlaufstelle für Studierende, Beschäftigte, Bewerberinnen und Bewerber, Medien und Öffentlichkeit. Gerade dann kann sie jedoch selbst betroffen sein. Läuft die Website in derselben Infrastruktur wie andere Hochschuldienste, kann eine vorsorgliche Netztrennung auch den öffentlichen Webauftritt lahmlegen. Wie häufig das geschieht, zeigten die vielen abgeschalteten Hochschulseiten nach PHP2Shell.
Der Fall Leipzig zeigt zugleich, wie wichtig ein Ersatzkanal ist. Die Universität konnte trotz der Abschaltung ihrer regulären Systeme eine Notfallwebsite unter ihrer bekannten Domain bereitstellen.
Eine Möglichkeit, solche Abhängigkeiten zu reduzieren, ist der vom Campusnetz getrennte Betrieb der öffentlichen Website bei einem spezialisierten Hostingdienstleister. Fällt das Hochschulrechenzentrum aus oder muss es isoliert werden, bleibt der Webauftritt erreichbar, vorausgesetzt, er hängt nicht über andere Wege an der ausgefallenen Infrastruktur. DNS, Administration, Authentifizierung, Datenbanken und angebundene Dienste müssen deshalb mitgedacht werden. Eine extern betriebene Website, die für jede Anfrage Daten aus dem abgeschalteten Campusnetz benötigt, steht im Ernstfall ebenfalls still.
Entscheidend ist deshalb weniger die Frage, ob ein Server innerhalb oder außerhalb der Hochschule steht, sondern ob der öffentliche Informationskanal unabhängig betrieben und im Notfall weitergenutzt werden kann.
Sicherheitsbetrieb ist mehr als Hosting
Die PHP2Shell-Schwachstellen haben gezeigt, wie wenig Zeit zwischen der Veröffentlichung einer kritischen Sicherheitslücke und möglichen Angriffen bleiben kann. Unterstützte Softwareversionen, kontinuierliches Schwachstellenmanagement und schnelle Sicherheitsupdates sind deshalb keine optionalen Betriebsleistungen.
Ein spezialisierter Hostingdienstleister kann hier Vorteile bieten, etwa durch standardisierte Betriebsumgebungen, zentrale Überwachung, eingespielte Updateprozesse und Bereitschaftsdienste. Ob intern oder extern betrieben sollten bei der Bewertung eines Hostingkonzepts konkrete Leistungen im Mittelpunkt stehen:
Sicherheitsorganisation: nachvollziehbare Prozesse und geeignete Nachweise, beispielsweise eine ISO-27001-Zertifizierung mit passendem Geltungsbereich.
Patchmanagement: verbindliche Reaktionszeiten für kritische Sicherheitslücken und klare Zuständigkeiten für CMS, PHP, Erweiterungen und Betriebssystem.
Systemtrennung: getrennte Berechtigungen, Administrationszugänge und Betriebsumgebungen.
Wiederherstellbarkeit: unabhängige Backups, definierte Wiederherstellungszeiten und regelmäßig getestete Wiederanlaufverfahren.
Angriffsschutz: geeignete Maßnahmen gegen DDoS-Angriffe, Webangriffe und unberechtigte Zugriffe.
Krisenkommunikation: eine vorbereitete, unabhängig erreichbare Notfallwebsite, die auch ohne das reguläre Content-Management-System betrieben werden kann.
Gerade der letzte Punkt wird leicht unterschätzt. Eine statische Notfallseite benötigt keine komplexe Anwendungslogik und kann unabhängig von einem betroffenen PHP-basierten CMS ausgeliefert werden. Damit bleibt zumindest die Kommunikation handlungsfähig, auch wenn andere Systeme zunächst abgeschaltet werden müssen.
Lehre 2: Nicht jede Anwendung braucht Zugriff auf das Campus-Management
Die Vorfälle an der LMU München und der Universität Halle zeigen, wie gravierend der Zugriff auf personenbezogene Daten sein kann. Campus-Management-Systeme verwalten besonders schützenswerte Informationen über Studieninteressierte und Studierende. Neben Bewerbungs- und Immatrikulationsdaten gehören dazu je nach System und Berechtigung auch Prüfungsinformationen und weitere personenbezogene Angaben.
Gleichzeitig wächst die Zahl digitaler Anwendungen, die Informationen aus diesen Systemen benötigen: Hochschulwebsites, Studiengangsfinder, Campus-Apps, Veranstaltungskalender oder Personenverzeichnisse.
Das Problem entsteht, wenn jede Anwendung eine eigene direkte Verbindung zum Campus-Management erhält. Dann müssen zahlreiche Schnittstellen, Zugangsdaten und Berechtigungen abgesichert und dauerhaft gepflegt werden. Mit jeder zusätzlichen Integration steigen die Anforderungen an Dokumentation, Überwachung und Rechteverwaltung.
Ein grundlegendes Sicherheitsprinzip lautet deshalb: Anwendungen sollen nur auf diejenigen Daten zugreifen können, die sie für ihre Aufgabe tatsächlich benötigen. Für eine öffentlich zugängliche Studiengangssuche sind beispielsweise Studiengangsbezeichnungen, Abschlüsse, Studienorte und Bewerbungsfristen erforderlich, nicht aber individuelle Bewerbungen oder Prüfungsleistungen.
Integrationsschichten können Zugriffe begrenzen
Eine Möglichkeit zur technischen Umsetzung ist eine Middleware beziehungsweise eine zentral gesteuerte Integrationsschicht. Sie verbindet das Campus-Management mit den Anwendungen, bereitet Daten auf und stellt definierte Informationen über eigene Schnittstellen bereit. Drittanwendungen müssen dadurch nicht direkt auf das ursprüngliche Verwaltungssystem zugreifen.
Eine solche Architektur bietet mehrere Vorteile: Zugriffsrechte werden zentral verwaltet, Datenfreigaben lassen sich nachvollziehbar gestalten und einzelne Anwendungen erhalten nur die Informationen, für die sie vorgesehen sind.
Der HIO-Publisher wurde speziell für die Anbindung von HISinOne an Hochschulwebsites und weitere digitale Anwendungen entwickelt. Die Middleware liest Daten über definierte HISinOne-Schnittstellen aus, bereitet sie auf und stellt sie nach konfigurierbarer Filterung bereit. So können beispielsweise Studiengangs-, Personen- und Forschungsinformationen auf Websites oder in Hochschul-Apps genutzt werden, ohne dass jede Anwendung einen eigenen direkten Zugang zu HISinOne benötigt. An der Universität Hohenheim werden über den HIO-Publisher unter anderem Personenprofile, Forschungsprojekte und Publikationen in TYPO3 bereitgestellt. Die Jade Hochschule nutzt die Middleware, um Kontakt- und Forschungsinformationen aus HISinOne automatisch in ihren Webauftritt zu übernehmen.
Wie sehr die Anforderungen vom Zweck einer Integrationsschicht abhängen, zeigt ein Vergleich mit CampusConnect. Die Open-Source-Initiative verbindet Campus-Management-Systeme mit Lernplattformen wie ILIAS und Moodle, unter anderem über einen HISinOne-Proxy. Anders als bei einer öffentlichen Website müssen hier auch Einschreibungen, Kurszuordnungen und Nutzerdaten übertragen werden. Je mehr personenbezogene Daten eine Integrationsschicht transportiert, desto höher sind die Anforderungen an ihre eigene Absicherung.
Sicherheit entsteht deshalb nicht allein durch den Einsatz einer Middleware, sondern durch eingeschränkte Zugriffsrechte, kontrollierte Datenfreigaben und die konsequente Absicherung der Integrationskomponenten selbst. Andernfalls entsteht lediglich ein neuer zentraler Angriffspunkt. Richtig umgesetzt verhindert eine solche Architektur aber, dass jede neue Websitefunktion oder Anwendung eine weitere direkte Verbindung zu zentralen Verwaltungssystemen benötigt.
Was passiert, wenn das Campus-Management ausfällt?
Neben der Vertraulichkeit spielt die Verfügbarkeit der Daten eine wichtige Rolle. Werden Informationen bei jedem Seitenaufruf unmittelbar aus dem Campus-Management abgerufen, kann ein Ausfall des Quellsystems auch die Websitefunktion beeinträchtigen.
Eine entkoppelte Datenbereitstellung schafft hier zusätzliche Sicherheit. Werden freigegebene Daten regelmäßig synchronisiert und in einer getrennten Umgebung vorgehalten, können beispielsweise Studiengangsinformationen, Personenverzeichnisse oder Forschungsprofile weiterhin angezeigt werden, auch wenn das Campus-Management vorübergehend nicht erreichbar ist. Der HIO-Publisher nutzt ein solches Synchronisationsmodell, bei dem Daten aus HISinOne abgerufen und über eine eigenständige Schnittstelle bereitgestellt werden. Voraussetzung ist, dass die jeweilige Anwendung die Daten tatsächlich ohne erneuten Zugriff auf das Quellsystem nutzen kann.
Dabei muss zwischen öffentlichen Informationen und transaktionalen Verwaltungsfunktionen unterschieden werden. Eine Studiengangsbeschreibung kann mit dem letzten synchronisierten Datenstand weiter angezeigt werden. Eine Prüfungsanmeldung oder die Änderung persönlicher Stammdaten benötigt dagegen in der Regel das verfügbare und autoritative Verwaltungssystem. Entkopplung verhindert so nicht jeden Ausfall aber dass der Ausfall eines zentralen Systems unnötig weitere Informationsangebote mitreißt.
Fünf Fragen, die Hochschulen jetzt stellen sollten
Die jüngsten Vorfälle sind ein Anlass, bestehende IT-Architekturen und Betriebsprozesse zu überprüfen. Dafür braucht es zunächst keine vollständige Neuplanung, sondern belastbare Antworten auf einige grundlegende Fragen.
1. Wie schnell können wir kritische Sicherheitslücken schließen? Sind alle öffentlich erreichbaren Systeme, PHP-Versionen und CMS-Installationen bekannt? Wer entscheidet über Sofortmaßnahmen, wer installiert Updates und wer prüft anschließend, ob eine Kompromittierung stattgefunden hat? 2. Bleiben wir im Krisenfall erreichbar? Kann die Hochschule Informationen veröffentlichen, wenn das eigene Rechenzentrum abgeschaltet werden muss? Gibt es eine unabhängig betriebene Notfallwebsite mit vorbereiteten Zugängen, Ansprechpartnern und Veröffentlichungsprozessen? 3. Welche Anwendungen greifen auf unsere Campus-Management-Systeme zu? Existiert ein vollständiges Verzeichnis der Schnittstellen, ihrer technischen Berechtigungen und der verantwortlichen Stellen? Werden nicht mehr benötigte Verbindungen regelmäßig entfernt? 4. Welche Daten geben wir tatsächlich weiter? Ist nachvollziehbar, welche Informationen aus HISinOne oder anderen Verwaltungssystemen an Websites, Apps und Drittanbieter übertragen werden? Werden Freigaben ausdrücklich definiert und technisch durchgesetzt? 5. Wie gut sind wir auf längere Ausfälle vorbereitet? Sind Backups unabhängig erreichbar? Wurden Wiederanlaufverfahren getestet? Können öffentliche Informationsangebote auch mit zuletzt synchronisierten Daten weiterarbeiten? |
Die Antworten zeigen, wo technische Risiken bestehen – und wo organisatorische Entscheidungen die Ausfallsicherheit verbessern können.
Weniger Angriffsfläche ist eine Architekturentscheidung
Kein Hostingmodell, keine Firewall und keine Middleware kann Cyberangriffe vollständig verhindern. Hochschulen können aber beeinflussen, wie weit sich ein erfolgreicher Angriff auswirkt. Dafür müssen sie Systeme voneinander trennen, Berechtigungen begrenzen, Abhängigkeiten reduzieren und den Wiederanlauf vorbereiten.
Eine unabhängig betriebene Website sichert im Krisenfall die Kommunikation. Eine kontrollierte Integrationsschicht verhindert, dass immer mehr digitale Anwendungen direkte Zugriffe auf zentrale Verwaltungssysteme benötigen. Regelmäßig synchronisierte, freigegebene Daten halten wichtige Informationsangebote verfügbar, wenn das Quellsystem vorübergehend ausfällt. Diese Maßnahmen entstehen nicht erst während eines Sicherheitsvorfalls. Sie müssen bei der Konzeption digitaler Dienste, beim Betrieb von Hochschulwebsites und bei der Einführung neuer Schnittstellen berücksichtigt werden.
Die entscheidende Frage ist deshalb nicht nur, wie Hochschulen Angriffe verhindern. Sondern auch, wie sie ihre digitale Infrastruktur so gestalten, dass ein einzelner Vorfall nicht unnötig viele Systeme, Prozesse und Kommunikationswege gleichzeitig lahmlegt.
Quellen
Weitere Quellen
Herausforderung erkannt?
Dieser Artikel skizziert das Problem. Lassen Sie uns über die Lösung für Ihre Hochschule sprechen.