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 in Deutschland. Der Betreiber des Rechenzentrums sichert physische Schutzmaßnahmen zu (Zugangskontrollen, Videoüberwachung, redundante Strom- und Netzanbindung); der eingesetzte Dienstleister wird im Rahmen des Auftragsverarbeitungsvertrags benannt.
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
Vorgabe für Version 4: Privilegierte interaktive Zugriffe auf Hosting, Control Center, Backup-Verwaltung und Fernwartung werden mit MFA abgesichert. Die Umsetzung ist vor Vertragsverwendung nachzuweisen. Diese Vorgabe ist kein Nachweis einer bereits überall aktivierten MFA. Maschinenzugänge werden durch gesonderte, begrenzte Schlüssel geschützt.
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
Im Buchungsmodul werden Schülernamen vor der Speicherung automatisch gekürzt (z. B. "Max M."). Fachmodule wie Laufzettel können bei aktivierter Nutzung zweckgebunden weitere personenbezogene Angaben verarbeiten; dafür gelten Rollenrechte und konfigurierbare Aufbewahrungsfristen.
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
Die Mandantentrennung erfolgt durch getrennte Instanzen und mandantenbezogene Berechtigungen. Ihre konkrete Umsetzung und Wirksamkeit sind je Betriebsmodell zu prüfen. Ein absoluter Ausschluss jeglichen unberechtigten Zugriffs wird nicht zugesagt.
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
Das Buchungsmodul kürzt Schülernamen serverseitig vor der Speicherung
(abbreviate_name_filter). Wo der konkrete schulische Zweck
eine eindeutige Zuordnung erfordert, können andere Module – insbesondere
Laufzettel – vollständige Namen und fachliche Angaben verarbeiten.
5.2 Verschlüsselte Datenbankverbindung
Anwendung und PostgreSQL laufen im Docker-Betrieb in einem nicht öffentlich
erreichbaren, isolierten Netzwerk. Bei einer externen Datenbank muss die
Schule TLS in der DATABASE_URL und am Datenbankserver erzwingen.
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
Öffentliche Produktivzugriffe werden über HTTPS bereitgestellt. Interne Verbindungen sind durch Container-/Host-Netze abgeschottet; externe Datenbank- und Mailserver müssen zusätzlich mit verifiziertem TLS konfiguriert werden.
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. Die Anwendung vermeidet Passwörter, Tokens, E-Mail-Adressen und fachliche Inhalte in ihren Logs. Rotation, Aufbewahrungsdauer und regelmäßige Prüfung der Host-/Proxy-Logs sind durch den Betreiber festzulegen.
7. Integrität (Datenintegrität)
7.1 Automatisierte Backups
Der Agent erstellt regelmäßige Datenbanksicherungen. Neue Deployments verlangen verschlüsselte Backups mit einem separaten Fernet-Schlüssel. Offsite-Kopie, Schlüsselverwahrung und geprüfte Wiederherstellung bleiben Bestandteil des Betriebskonzepts der Schule.
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 das Risiko von SQL-Injection zu reduzieren.
8. Verfügbarkeit und Belastbarkeit
8.1 Regelmäßige Backups
Datenbank-Backups werden regelmäßig und mindestens vor jedem Deployment-Update erstellt; ergänzend werden verschlüsselte Vollbackups angefertigt. Häufigkeit, Aufbewahrung und Aufbewahrungsort richten sich nach der jeweiligen Betriebsvereinbarung mit dem Kunden.
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
Für Ausfallsicherheit sorgen die vom Rechenzentrumsbetreiber bereitgestellten Redundanzen (Strom, Netzanlage) sowie die Backup- und Wiederherstellungskonzepte nach Abschnitt 7 und 8.1. Ein einzelner Hardware-Ausfall führt nicht zum Verlust der letzten Datensicherung.
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 Abständen, mindestens einmal jä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 für das Hosting eingesetzte Rechenzentrums-Dienstleister (Serverstandort Deutschland) fungiert als Unterauftragsverarbeiter im Sinne des Art. 28 Abs. 4 DSGVO. Die Datenverarbeitung erfolgt ausschließlich auf Grundlage eines abgeschlossenen Auftragsverarbeitungsvertrags.
10.2 Weisungsgebundenheit
Der Unterauftragsverarbeiter handelt ausschließlich auf Weisung des Auftragsverarbeiters, der seinerseits an die Weisungen des Verantwortlichen gebunden ist. Eine eigenmächtige Nutzung oder Weitergabe der Daten durch den Dienstleister ist vertraglich ausgeschlossen.
10.3 Keine weiteren Drittanbieter
Die tatsächlich eingesetzten Dienstleister und Verarbeitungsorte werden in der Betriebsanlage dokumentiert. Änderungen unterliegen dem Informations- und Widerspruchsverfahren des AVV. Nicht bestätigte Standorte oder Dienstleister dürfen nicht als feststehend behandelt werden.
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: 14. September 2026 – Version 4 (Entwurf)
Betriebsmodelle, sensible Daten und Fristen
Beim Self-Hosting trägt die Schule die Verantwortung für ihre Infrastruktur. Beauftragte Anbieterzugriffe, Agent-Übertragungen und Backups sind separat in der Betriebsanlage zu erfassen. Managed Hosting umfasst nur die vereinbarten Betriebsleistungen.
Bei Daten nach Art. 9 DSGVO sind Zweckbindung, Datenminimierung, eng begrenzte Berechtigungen, geschützte Speicherung und kurze zweckbezogene Löschfristen besonders zu berücksichtigen. Die Schule legt die rechtmäßige Verarbeitung fest.
Die versionierte Betriebsanlage konkretisiert Empfänger, Datenflüsse und Löschfristen. Unbestätigte Fristen und Sicherheitsbehauptungen in dieser Bestandsbeschreibung dürfen nicht als nachgewiesene Zusagen übernommen werden.