1. Governance
Risikoorientierte Überprüfung mindestens halbjährlich und bei wesentlichen Änderungen oder Vorfällen.
Vertraulichkeitsverpflichtung und Minimalzugriff für Personen mit Produktions-, Administrations- oder Supportzugriff.
Secrets ausschließlich in geschützten Produktionsvariablen und nicht öffentlichen, Git-ausgeschlossenen Recovery-Ablagen.
Berechtigungsprüfung mindestens vierteljährlich; Restore-Prüfung mindestens halbjährlich.
2. Physische und lokale Sicherheit
Produktive Infrastruktur in vertraglich gebundenen Rechenzentren der Dienstleister.
Administrative Endgeräte mit Betriebssystemanmeldung, automatischer Sperre, Festplattenverschlüsselung, zeitnahen Updates und Schadsoftware-Schutz.
Keine reguläre Speicherung produktiver Schuldaten auf privaten Wechselmedien; temporäre Restore-Dateien werden nach Prüfung sicher gelöscht.
3. Authentifizierung und Sitzungen
Passwörter mit Argon2id, sofern verfügbar, andernfalls bcrypt; keine Klartextpasswörter.
Kurzlebige signierte Zugriffstoken und widerrufbare, serverseitig ausschließlich gehashte Refresh-Sitzungen.
Zufällige Installationskennung ohne Hardwareableitung; Ersetzen veralteter Sitzungen derselben App-Installation.
Serverseitige Login-Rate-Limits, generische Nutzerfehlermeldungen und sofortiger Sitzungswiderruf bei Deaktivierung/Löschvormerkung.
Mehrfaktor-Authentifizierung für zentrale Betreiber-/Providerkonten, soweit vom Dienst unterstützt.
4. Rollen und Mandantentrennung
Serverseitige Schulgrenzen über school_id bei jedem schulbezogenen Zugriff.
Rollen Schulsanitäter, Sani-Leitung, Lehreraufsicht und Sekretariat mit serverseitig erzwungenen Rechten.
Moderationswarteschlange und -entscheidung ausschließlich für Lehreraufsicht.
Dateiabruf nur authentifiziert und schulbezogen; maximal vier Anhänge à 8 MB je Nachricht und 100 MB Uploadquote je Nutzer.
Berechtigungen bei Rollenwechsel, Ausscheiden und Vertragsende unverzüglich entziehen.
5. Verschlüsselung und Sicherung
Produktive API ausschließlich über HTTPS/TLS; Datenbank nicht öffentlich exponiert.
API und MySQL in derselben privaten Railway-Projektumgebung und EU-Region.
Täglicher transaktionskonsistenter SQL-Dump, gzip-Kompression und authentifizierte XChaCha20-Poly1305-Verschlüsselung.
FTPS mit Zertifikatsprüfung; dedizierter, auf das Backup-Verzeichnis beschränkter ALL-INKL-Zugang; Schlüssel nicht bei ALL-INKL.
30-Tage-Rotation; Wiederherstellung nur in kontrollierter Umgebung und erneute Anwendung wirksamer Löschungen vor Produktivfreigabe.
6. Protokollierung und Datenminimierung
Administrative und sicherheitsrelevante Vorgänge werden schulbezogen auditiert.
Keine Passwörter, Token, privaten Schlüssel, SQL-Abfragen, Roh-Exceptions oder vollständigen API-Antworten in Nutzerfehlermeldungen.
Kurzfristige Ausfälle erfassen keinen Grund; Push-Mitteilung hierzu ist neutral und ohne Krankheitsinformation.
Normale Ankündigungs-Pushes können Absender und kurze Vorschau enthalten; keine Anhänge werden in Push-Payloads übertragen.
Keine Werbung, Marketinganalyse, offene Registrierung, Patientendokumentation oder Leistungsbewertung.
7. Verfügbarkeit und Wartung
Produktive API und MySQL in Railway EU West (Amsterdam); externe Zustell- und Supportzugriffe gesondert bewertet.
Wartungsjob alle 15 Minuten für Statusübergänge, Erinnerungen, verwaiste Uploads, Löschungen und Logrotation.
Tägliches Offsite-Backup; technisches Ziel RPO und RTO jeweils 24 Stunden, ohne gesondertes SLA kein garantierter Wert.
Backup-Download, Authentifizierung, Entschlüsselung und gzip-Prüfung wurden real getestet; vollständige Restore-Tests mindestens halbjährlich.
8. Entwicklung und Änderung
Quellcodeverwaltung ohne Produktivdaten oder Secrets; Abhängigkeits- und Sicherheitstests bei relevanten Änderungen.
Serverseitige Autorisierungstests, Schulgrenzentests und dokumentierte Deploymentprüfung.
Getrennte Entwicklungs-/Testdaten; keine echten Schülerdaten in Screenshots, Seeds oder automatisierten Tests.
9. Vorfälle und Kontinuität
Vorfall erfassen, eindämmen, unberechtigte Sitzungen widerrufen und Beweismittel zugriffsgeschützt sichern.
Betroffene Systeme, Schulen, Datenarten, Personen, Zeitraum und mögliche Offenlegung bestimmen.
Verantwortliche Stelle unverzüglich mit verfügbaren Angaben informieren und fortlaufend unterstützen.
Ursache beheben, kontrolliert wiederherstellen, Wirksamkeit prüfen und Verbesserungen dokumentieren.