SSD Manager – Art. 28 Abs. 3 und Art. 32 DSGVO
1. Governance und Risikoorientierung
Mindestens halbjährliche sowie anlassbezogene Überprüfung.
Berechtigungs- und Restore-Prüfungen mindestens halbjährlich; erster Restore-Test erfolgreich durchgeführt.
Geheimnisse ausschließlich in geschützten Produktionsvariablen und lokalen, Git-ausgeschlossenen Recovery-Ablagen.
Vertraulichkeitsverpflichtung für Personen mit administrativem Zugriff.
2. Physische und lokale Sicherheit
Produktive Systeme in vertraglich gebundenen Rechenzentren der Dienstleister.
Lokale Administrationsgeräte mit Betriebssystemanmeldung, Gerätesperre, Festplattenverschlüsselung, Updates und Malware-Schutz.
Keine produktiven Daten auf privaten Wechselmedien; temporäre Restore-Dateien werden nach Prüfung gelöscht.
3. Authentifizierung und Zugang
Passwort-Hashing; keine Klartextpasswörter in der Datenbank.
Kurzlebige Zugriffstoken und widerrufbare, serverseitig gehashte Refresh-Sitzungen.
Persistente zufällige Installationskennung ersetzt veraltete Sitzungen derselben Installation.
Login-Rate-Limits und sichere, generische Fehlermeldungen.
Deaktivierung und Löschvormerkung widerrufen alle Sitzungen.
4. Rollen, Zugriff und Mandantentrennung
Serverseitige Schulgrenzen über school_id und rollenbezogene Autorisierung.
Rollen Schulsanitäter, Sani-Leitung, Lehreraufsicht und Sekretariat mit minimalen Rechten.
Kontolöschung nur durch Lehreraufsicht oder Sani-Leitung.
Dateizugriffe authentifiziert, uploader- und schulbezogen; 100-MB-Nutzerquote und maximal vier Anhänge a 8 MB je Nachricht.
Berechtigungen werden bei Rollenwechsel, Ausscheiden und Vertragsende entzogen.
5. Verschlüsselung und Übertragung
Produktive API ausschließlich über HTTPS/TLS.
Datenbank nicht öffentlich exponiert; API und MySQL im selben privaten Railway-Projekt und in derselben EU-Region.
Tägliche SQL-Sicherungen werden komprimiert und mit XChaCha20-Poly1305 authentifiziert verschlüsselt; All-Inkl erhält keinen Schlüssel.
FTPS-Übertragung mit Zertifikatsprüfung; dedizierter, auf /ssd-manager-backups/ beschränkter FTP-Nutzer.
6. Protokollierung und Datenminimierung
Auditierung administrativer und sicherheitsrelevanter Vorgänge.
Keine Roh-Exceptions, SQL-, Token-, Passwort- oder Antwortinhalte in Nutzerfehlermeldungen.
FCM-Payloads enthalten nur erforderliche technische Routinginformationen.
Keine Werbung, Marketinganalyse oder offene Registrierung.
Medizinische Falldokumentation ist organisatorisch und vertraglich ausgeschlossen.
7. Verfügbarkeit, Backup und Wiederherstellung
Railway API und MySQL in EU West (Amsterdam).
Separater 15-Minuten-Wartungsjob für Statusübergänge, Erinnerungen, verwaiste Uploads, Löschungen und Logrotation.
Tägliches Offsite-Backup um 03:35 Uhr Europe/Berlin; 30-Tage-Rotation.
Erster realer Backup-, Download-, Authentifizierungs-, Entschlüsselungs- und gzip-Test erfolgreich.
Zielwerte RPO/RTO jeweils 24 Stunden; Abweichungen und Wiederanlauf werden dokumentiert.
8. Incident Response und Überprüfung
Vorfall erkennen, eindämmen und Beweismittel zugriffsgeschützt sichern.
Betroffene Systeme, Daten, Schulen, Personen und Zeiträume bestimmen.
Schlüssel/Tokens rotieren und unberechtigte Sitzungen widerrufen.
Betroffene verantwortliche Schule unverzüglich mit verfügbaren Informationen informieren.
Ursache beheben, kontrolliert wiederherstellen und Wirksamkeit prüfen.
Entscheidungen, Meldungen und Verbesserungen dokumentieren.