Kann ein Schulserver wirklich BSI-konform sein? Eine Marktanalyse.

„BSI-konform” ist einer der am häufigsten verwendeten und am seltensten belegten Begriffe in Ausschreibungen für Schulsoftware. Hersteller werben damit, Einkäufer nicken, und am Ende fragt niemand nach: Konform womit genau?

Dieser Artikel ist keine juristische Einschätzung. Es ist ein Versuch, die Frage ehrlich zu beantworten — was BSI-Konformität für Schulserver bedeutet, wie der Markt damit umgeht, und was Schulträger bei der Beschaffung wirklich prüfen sollten.

Was das BSI-Grundschutz-Kompendium verlangt

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) veröffentlicht das IT-Grundschutz-Kompendium — ein Regelwerk, das IT-Sicherheitsanforderungen für Behörden und öffentliche Einrichtungen beschreibt. Es ist kein Gesetz, aber für viele Bundesbehörden und zunehmend auch für kommunale Einrichtungen faktisch verbindlich.

Für Schulen relevant sind insbesondere:

SYS.1.1 – Allgemeiner Server: Anforderungen an Serverbetrieb, Härtung, Patch-Management
SYS.2.1 – Allgemeiner Client: Endgerätesicherheit, Zugriffsschutz
OPS.1.1.3 – Patch- und Änderungsmanagement: Prozesse für Updates und Sicherheitskorrekturen
APP.2.1 – Allgemeiner Verzeichnisdienst: Anforderungen an LDAP-Server (direkt relevant für UCS@school)
CON.1 – Kryptokonzept: Verschlüsselung in Ruhe und in der Übertragung
ISMS.1 – Sicherheitsmanagement: Prozessuale Anforderungen an die gesamte IT-Organisation

Das Kompendium unterscheidet zwischen Basis-, Standard- und erhöhten Schutzanforderungen. Für Schulen mit personenbezogenen Daten von Minderjährigen gelten in der Regel mindestens Standardanforderungen — in einigen Bundesländern explizit erhöhte Anforderungen für Sonderpädagogik und Schulpsychologie.

Was „BSI-konform” auf dem Markt bedeutet

Wenn ein Hersteller sein Produkt als „BSI-konform” bewirbt, kann das vielerlei bedeuten:

Szenario A: Zertifizierung nach ISO 27001 auf Basis von IT-Grundschutz
Das ist die strengste Variante — eine externe Prüfung durch akkreditierte Auditoren, Dokumentation aller Sicherheitsmaßnahmen, regelmäßige Rezertifizierung. Kostet fünfstellige Beträge und mehrere Monate Arbeit. Wenige Schulanbieter haben das.

Szenario B: Selbstauskunft auf Basis einer Grundschutz-Analyse
Der Anbieter hat intern geprüft, welche Grundschutz-Bausteine für sein Produkt relevant sind, und dokumentiert die Umsetzung. Keine externe Prüfung. Solide, wenn sorgfältig gemacht — aber unkontrollierbar.

Szenario C: Marketing
Das Produkt erfüllt einzelne Anforderungen aus dem Kompendium (zum Beispiel TLS-Verschlüsselung) und bewirbt dies als „BSI-konform”. Formal nicht falsch, aber inhaltlich bedeutungslos.

In einer nicht-repräsentativen Durchsicht von Produktwebseiten und Ausschreibungsunterlagen, die uns im Laufe des Jahres 2025 zugegangen sind, war Szenario C bei weitem am häufigsten.

Was Schulserver tatsächlich leisten müssen

Abseits des Buzzword-Bingos gibt es eine handhabbare Checkliste, die Schulträger bei der Prüfung anlegen können:

Härtung und Patch-Management

Wird das Betriebssystem regelmäßig mit Sicherheitsupdates versorgt?
Gibt es einen definierten Patch-Rhythmus (mindestens monatlich für kritische Updates)?
Sind nicht benötigte Dienste deaktiviert?
Ist der Fernzugriff auf das System restriktiv konfiguriert (VPN, Schlüsselbasierte SSH, kein Root-Login)?

Verschlüsselung

Sind alle Verbindungen TLS 1.2+ verschlüsselt?
Werden Festplatten verschlüsselt (LUKS oder ähnlich)?
Werden Backups verschlüsselt übertragen und gespeichert?

Zugriffskontrolle

Gibt es ein rollenbasiertes Zugriffsmodell?
Werden Zugriffsrechte bei Ausscheiden von Personen zeitnah entzogen?
Werden privilegierte Zugriffe protokolliert?

Logging und Monitoring

Werden sicherheitsrelevante Ereignisse geloggt?
Werden Logs zentral gespeichert und vor Manipulation geschützt?
Gibt es Alerting bei auffälligen Zugriffsmustern?

Notfallmanagement

Gibt es ein dokumentiertes Backup-Konzept mit definierten RPO/RTO-Werten?
Wird das Backup regelmäßig auf Wiederherstellbarkeit getestet?
Gibt es einen Notfallplan für den Ausfall zentraler Dienste?

Wie Open-Source-Systeme im Vergleich abschneiden

Für diese Checkliste ist die Lizenzform — proprietär oder Open Source — weniger entscheidend als die Architektur und der Betrieb. Schlecht konfiguriertes Open Source ist nicht sicherer als schlecht konfiguriertes proprietäres Software. Umgekehrt gilt das genauso.

Was Open-Source-Systeme strukturell im Vorteil macht:

Transparenz: Der Quellcode ist öffentlich. Sicherheitsforscher können ihn prüfen, Schwachstellen melden und Fixes nachverfolgen. Bei proprietärer Software ist das nicht möglich — was bedeutet, dass Schwachstellen potenziell länger unentdeckt bleiben.

CVE-Reaktionszeit: Öffentlich bekannte Schwachstellen (CVE) werden in Open-Source-Projekten im Durchschnitt schneller behoben als in proprietären Produkten, die interne Freigabeprozesse durchlaufen müssen.

Keine Backdoors durch Compliance: US-amerikanische Unternehmen unterliegen dem FISA Court und dem CLOUD Act. Es gibt keine gesetzliche Möglichkeit für sie, bestätigen zu können, dass ihre Produkte keine behördlich angeordneten Backdoors enthalten. Das ist keine Spekulation — es ist ein strukturelles Problem.

Was Schulträger bei Ausschreibungen fordern sollten

Anstatt „BSI-konform” als Anforderung zu nennen, sind folgende konkreten Formulierungen hilfreicher:

„Der Anbieter legt eine aktuelle Grundschutz-Analyse (Schutzbedarfsfeststellung) vor.”
„Das Produkt verfügt über eine dokumentierte CVE-Response-Policy mit definierten SLAs.”
„Der Quellcode ist öffentlich zugänglich (Open Source), oder es liegt ein escrow-gesicherter Quellcode-Zugang vor.”
„Alle personenbezogenen Daten werden ausschließlich auf Servern in der EU verarbeitet und gespeichert.”
„Der Anbieter ist nicht dem US CLOUD Act oder äquivalenten Gesetzen unterstellt.”

Diese Anforderungen sind prüfbar. „BSI-konform” ist es nicht.

Fazit

BSI-Konformität ist ein sinnvolles Ziel für Schulserver — aber kein Label, dem man blind vertrauen sollte. Die ehrliche Frage lautet nicht „Ist das BSI-konform?”, sondern: „Kann mir der Anbieter zeigen, wie er die relevanten Anforderungen umsetzt?”

Wer diese Frage stellt, wird schnell merken, welche Anbieter es ernst meinen — und welche das Label nur im Marketing verwenden.

Für Open-Source-Systeme wie UCS@school gilt: Die Antwort auf diese Frage ist öffentlich. Jede Zeile Code, jede CVE-Meldung, jeder Fix. Das ist kein Versprechen — es ist ein Beweis.