Rechtsgrundlage
Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung
Art. 32 DSGVO verpflichtet den Verantwortlichen und den Auftragsverarbeiter, geeignete technische und organisatorische Maßnahmen zu treffen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten. Die nachfolgenden Maßnahmen berücksichtigen den Stellenwert personenbezogener Daten im schulischen Kontext insbesondere von Minderjährigen.
Konkrete Umsetzung
1. Physische Sicherheit (Zutrittskontrolle)
1.1 Server-Standort
Die Server, auf denen die EduSlot-Anwendung betrieben wird, befinden sich in einem professionellen Rechenzentrum des Hosting-Providers (z. B. Hetzner Online GmbH) in Deutschland. Das Rechenzentrum erfüllt die Anforderungen an physikalische Sicherheit nach ISO 27001.
1.2 Kein physischer Zugriff durch den Anbieter
Der Anbieter (Maurizio Morelli) hat keinen physischen Zugang zu den Server-Infrastrukturen. Der Zugriff auf die Hardware erfolgt ausschließlich durch das Rechenzentrum-Personal des Hosters.
1.3 Virtueller Fernzugriff
Die Server sind ausschließlich virtuell erreichbar via SSH (Secure Shell) oder Web-basiertem Admin-Panel. Jeglicher Fernzugriff erfolgt verschlüsselt über kryptografisch gesicherte Verbindungen.
2. System-Sicherheit (Zugangskontrolle)
2.1 SSH-Schlüsselbasierter Zugang
Der SSH-Zugang auf die Serverebene ist ausschließlich über kryptografische SSH-Schlüssel möglich. Ein Passwort-Login über SSH ist deaktiviert. Private Schlüssel werden lokal und verschlüsselt aufbewahrt.
2.2 Firewall
Auf allen Servern ist eine Firewall aktiv (UFW / iptables), die nur notwendige Ports öffnet (HTTPS 443, SSH 22). Alle anderen Ports sind standardmäßig gesperrt. Unautorisierte Zugriffsversuche werden protokolliert.
2.3 Zwei-Faktor-Authentifizierung
Wo technisch möglich, wird eine Zwei-Faktor-Authentifizierung (2FA) für den administrativen Zugang eingesetzt, um die Identität des Nutzers zusätzlich zu verifizieren.
2.4 Separate Admin-Accounts
Für den Systemzugang existieren dedizierte Administration-Accounts, die von den Anwendungs-Accounts (EduSlot-Login) vollständig getrennt sind. Passwörter für Systemzugänge entsprechen den gängigen Sicherheitsstandards (Mindestlänge, Komplexität, regelmäßiger Wechsel).
3. Zugriffskontrolle (Berechtigungsmanagement)
3.1 Rollenbasierte Zugriffssteuerung
Innerhalb der EduSlot-Anwendung greift ein rollenbasiertes Berechtigungssystem (RBAC) bzw. Rollenmodell mit Trennung von Administrator-, Lehrkraft- und Benutzerrechten (Schüler). Folgende Rollen sind definiert:
- Admin: Vollzugriff auf Verwaltungsfunktionen, Raum- und Nutzerverwaltung
- Lehrer: Anlegen und Verwalten eigener Buchungen, Einsicht in eigene Daten
- Schüler: Nur Lesezugriff auf für sie freigegebene Informationen
- Kiosk: Anonymer Statusbildschirm ohne Login, kein Zugriff auf personenbezogene Daten
3.2 Passwort-Hashing
Lokale Nutzerpasswörter werden niemals im Klartext gespeichert. Es kommt ein modernes Hash-Verfahren zum Einsatz (bcrypt über Werkzeug / Python), das sowohl Salting als auch iterative Key-Stretching umfasst.
3.3 Brute-Force-Schutz
Das System erfasst fehlgeschlagene Anmeldeversuche in einer atomaren
Datenbank-Operation (failed_login_attempts). Nach Überschreiten
einer definierten Anzahl wird das Konto temporär gesperrt
(Rate-Limiting). Dies schützt vor automatisierten Passwort-Angriffen.
3.4 Session-Management
Die Anwendung verwendet serverseitige Sessions (Flask-Session). Das
Session-Cookie ist mit HttpOnly und Secure
gesetzt. Nach Ablauf der Sitzung oder beim Logout wird das Cookie
ungültig.
3.5 IServ-OAuth (Single Sign-On)
Als optionale Single-Sign-On-Lösung wird die IServ-Integration über OAuth 2.0 angeboten. Dabei speichert EduSlot kein IServ-Passwort. Übermittelt werden lediglich Benutzername, E-Mail-Adresse und Rolle nach erfolgreicher Authentifizierung.
3.6 Privacy by Design
In bestimmten Rollen werden keine Klarnamen gespeichert. Schülernamen werden vor der Speicherung automatisch pseudonymisiert (z. B. "Max M."), um die Datensparsamkeit technisch zu erzwingen.
4. Trennungsgebot (Multi-Tenancy)
4.1 Strict Multi-Tenancy
Jede Schule hat eine eigenständige Datenbank-Instanz oder eigene Tabellen-/Namespace-Strukturen. Es erfolgt keine gemeinsame Nutzung von Datenbankschemas zwischen verschiedenen Schulen.
4.2 Keine Datenvermischung
Daten verschiedener Schulen werden physisch und logisch strikt voneinander getrennt gespeichert. Ein Zugriff auf Daten einer anderen Schule ist durch die Architektur technisch ausgeschlossen.
4.3 Containerisierung
Wo zutreffend, erfolgt die Ausführung der Anwendungen in separaten Docker-Containern pro Schule, um Prozessisolation und zusätzliche Sicherheitsebenen zu gewährleisten.
5. Pseudonymisierung und Verschlüsselung
5.1 Pseudonymisierung in der Anwendung
Klarnamen von Schülern werden vor dem Speichern in der Datenbank
pseudonymisiert (abbreviate_name_filter,
name_source in models.py). Diese Pseudonymisierung
ist irreversibel und erfolgt serverseitig, bevor die Daten die Datenbank
erreichen.
5.2 Verschlüsselte Datenbankverbindung
Die Verbindung zur PostgreSQL-Datenbank wird über SSL/TLS verschlüsselt hergestellt. Daten werden während der Übertragung zwischen Anwendung und Datenbank kryptografisch geschützt.
5.3 HTTPS/TLS für Webverbindungen
Alle Webverbindungen zu EduSlot laufen ausschließlich über HTTPS. Dabei wird TLS 1.2 oder höher für sämtliche Datenübertragungen erzwungen. TLS-Zertifikate werden über Let's Encrypt bezogen und regelmäßig neu ausgestellt. Der nginx-Reverse-Proxy leitet unverschlüsselte HTTP-Anfragen automatisch auf HTTPS um.
5.4 Keine unverschlüsselte Übertragung
Eine unverschlüsselte Übertragung personenbezogener Daten zwischen Client und Server sowie zwischen Server und Datenbank ist technisch nicht möglich, da ausschließlich verschlüsselte Protokolle erlaubt sind.
6. Vertraulichkeit (Geheimhaltung)
6.1 Vertraulichkeitserklärungen
Soweit Mitarbeiter oder Unterauftragsnehmer Zugang zu personenbezogenen Daten erhalten, werden diese zur Vertraulichkeit verpflichtet. Eine schriftliche Geheimhaltungserklärung ist erforderlich.
6.2 Berechtigungsprinzip
Ein Zugriff auf Kundendaten erfolgt ausschließlich bei Vorliegen eines berechtigten Interesses (z. B. Support-Ticket, Fehlerbehebung) und nur in dem dafür erforderlichen Umfang. Der Zugriff wird protokolliert.
6.3 Zugriffsprotokolle und Log-Management
System- und Zugriffsprotokolle (Logs) werden automatisch geschrieben. Sie enthalten keine Passwörter oder Session-Secrets. Die Logs werden regelmäßig auf Anomalien geprüft und nach einer definierten Aufbewahrungsfrist datenschutzkonform gelöscht.
7. Integrität (Datenintegrität)
7.1 Automatisierte Backups
Die Datenbank wird in regelmäßigen Abständen automatisch gesichert. Die Backups werden auf separaten Speichermedien oder redundanten Systemen vorgehalten und im Bedarfsfall zur Wiederherstellung eingesetzt.
7.2 Versionskontrolle
Der gesamte Quellcode wird über ein Versionskontrollsystem (Git) verwaltet. Änderungen sind nachvollziehbar, rückverfolgbar und bei Bedarf revertierbar. Jede Änderung ist einem Autor und einem Zeitstempel zugeordnet.
7.3 Kein direkter Datenbankzugriff
Endnutzer haben keinen direkten Zugriff auf die Datenbank. Alle Datenbankoperationen laufen ausschließlich über die Anwendungsschicht, die eingehende Daten validiert und parametrisierte Abfragen verwendet, um SQL-Injection auszuschließen.
8. Verfügbarkeit und Belastbarkeit
8.1 Regelmäßige Backups
Datenbank-Backups werden mindestens täglich erstellt. Die Backup-Häufigkeit ist an die jeweilige Verfügbarkeitsvereinbarung mit dem Kunden angepasst (z. B. stündlich bei Business-Tarif).
8.2 System-Monitoring
Das System wird kontinuierlich überwacht (z. B. Logs, externe Monitoring-Tools). Bei Erreichen von Schwellenwerten (CPU, RAM, Festplatte, Error-Rate) werden automatisch Warnmeldungen ausgelöst.
8.3 Redundanz
Der Hosting-Provider stellt redundante Infrastruktur bereit (z. B. RAID im VPS). So wird gewährleistet, dass ein Hardware-Ausfall nicht zum Datenverlust oder zum Totalausfall führt.
8.4 Wiederherstellungsverfahren
Ein dokumentierter Disaster-Recovery-Plan beschreibt die Schritte zur Wiederherstellung nach einem Systemausfall oder Datenverlust. Ziel ist die Rückführung auf den letzten konsistenten Zustand anhand der verfügbaren Backups.
9. Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung
9.1 Sicherheitsaktualisierungen
Das Betriebssystem der Server wird regelmäßig gewartet
(apt update / automatische Sicherheitspatches).
Kritische Sicherheitsupdates werden unverzüglich eingespielt.
9.2 Überprüfung der Zugriffsrechte
In regelmäßigen Intervallen (z. B. vierteljährlich) erfolgt eine Überprüfung der vergebenen Zugriffsrechte. Veraltete, überflüssige oder falsch vergebene Berechtigungen werden korrigiert oder entzogen (Prinzip der geringsten Rechte).
9.3 Log-Analyse
Die System- und Zugriffsprotokolle werden auf Anomalien geprüft (z. B. ungewöhnliche Login-Zeiten, erhöhte Fehlversuche, unerwartete Zugriffsmuster). Festgestellte Auffälligkeiten werden dokumentiert und bei Bedarf eskaliert.
9.4 Incident-Response-Verfahren
Bei Sicherheitsvorfällen (z. B. unautorisierte Zugriffe, Datenschutz- verletzungen) greift ein vordefiniertes Incident-Response-Verfahren:
- Identifikation und Eindämmung des Vorfalls
- Dokumentation der betroffenen Daten und Systeme
- Beseitigung der Sicherheitslücke
- Benachrichtigung der betroffenen Stellen (sofern notwendig und gemäß Art. 33/34 DSGVO)
- Lessons-Learned und Anpassung der Maßnahmen
10. Datenverarbeitung bei Unterauftragsnehmern
10.1 Hosting-Provider als Auftragsverarbeiter
Der Hosting-Provider (z. B. Hetzner Online GmbH) fungiert als Unterauftragsnehmer im Sinne des Art. 28 DSGVO. Die Datenverarbeitung erfolgt ausschließlich auf Grundlage eines abgeschlossenen Auftragsverarbeitungsvertrags (AVV).
10.2 Weisungsgebundenheit
Der Unterauftragsnehmer handelt ausschließlich nach Weisung des Verantwortlichen. Eine eigenmächtige Nutzung oder Weitergabe der Daten durch den Hoster ist vertraglich ausgeschlossen.
10.3 Keine weiteren Drittanbieter
Es werden keine weiteren Drittanbieter oder Sub-Sub-Prozessoren ohne vorherige Zustimmung des Kunden eingebunden. Sollte eine Änderung des Hosting-Providers oder der Infrastruktur erforderlich werden, wird der Kunde vorab informiert.
Zusammenfassung
Die vorstehenden technisch-organisatorischen Maßnahmen stellen sicher, dass die Verarbeitung personenbezogener Daten innerhalb von EduSlot ein dem jeweiligen Risiko angemessenes Schutzniveau erreicht. Die Maßnahmen werden laufend an technische Entwicklungen und geänderte gesetzliche Anforderungen angepasst.
Stand: Juni 2026