Hilfestellung zur DSFA
Nach Artikel 35 der Europäischen Datenschutz-Grundverordnung (DSGVO) sind Sie als Schule (Verantwortlicher) verpflichtet, eine Datenschutz-Folgenabschätzung (DSFA) durchzuführen, wenn die Form der Datenverarbeitung voraussichtlich ein hohes Risiko für die persönlichen Rechte natürlicher Personen zur Folge hat.
1. Erforderlichkeit der DSFA bei Schulhamsta
Ob der Einsatz von Schulhamsta an Ihrer Schule eine DSFA erfordert, hängt davon ab, welche Formulare und Datenfelder Sie in der App administrieren. Besonders bei der digitalen Erfassung von Schulanmeldungen (inkl. Gesundheitsinformationen etc.) ist nach den Blacklists der Landesdatenschutzbeauftragten eine DSFA oft zwingend.
Dieses Dokument liefert Ihnen daher wesentliche technische Textbausteine (Muster-Risikoanalyse) zu Schulhamstas Softwarearchitektur, um Sie bei der Erstellung Ihrer eigenen Folgenabschätzung massiv zu entlasten.
2. Systemische Gegenmaßnahmen ("Privacy by Design")
Zur strukturellen Risikominimierung ist Schulhamsta als moderne Multi-Tenant-Architektur aufgebaut:
- Tenant-Isolation (Mandantenfähigkeit): Jede Schule erhält in der Datenbank eigene, strikt abgekapselte Bereiche (Tenants). Softwareseitige "Scopes" in Laravel garantieren, dass Datensätze (z.B. Anträge einer Schule) unter keinen Umständen von Nutzern einer anderen Schule angefragt werden können.
- Verschlüsselung im Transport & Ruhezustand: HTTP-Kommunikation ist TLS-gesichert; Dateien, die Eltern im Antragsverfahren hochladen, liegen isoliert im Ionos S3 Storage und werden datenbankspezifisch nach erfolgreichem Login tokenisiert verlinkt (Short-Lived URLs).
3. Muster-Risikoanalyse für Schulhamsta-Komponenten
| Bedrohungsszenario | Potenzielle Schwere | Ergriffene Gegenmaßnahmen in Schulhamsta |
|---|---|---|
| Kompromittierte Passwörter / Phishing Unbefugte entwenden die Zugangsdaten der Lehrkraft. | Mittel | Erzwingung sicherer Passwörter sowie kryptografisches Hashing (z.B. Bcrypt) in der Datenbank. Passwörter können bei Kompromittierung weder vom Support noch von Administratoren im Klartext ausgelesen werden. Optional: 2-Faktor-Authentifizierung. |
| Unberechtigte Zugriffsausweitung Nutzer erhalten Zugang zu Formularen über ihre Rolle hinaus. | Hoch | Striktes Role-Based Access Control (RBAC) auf Middleware- und Methoden-Ebene in Laravel. Eine einfache URL-Manipulation (`/applications/1024`) für fremde Anträge wird mit Error 403 / 404 sicher geblockt, da dem Zugriff stets ein Owner-Verify für Mandant und Personengruppe vorausgeht. |
| Datenverlust durch Hardware-Ausfall Ionos Serverausfall zerstört Speichermedien. | Gering bis Mittel | Einsatz hochverfügbarer Cluster. Die Ionos DB bietet Disaster Recovery durch fortlaufende, geografisch redundante Backups (PITR - Point in Time Recovery) sowie S3-Replikationsstrukturen. |
| Schwachstellen in App-Bibliotheken (Exploits) Hack-Angriffe via SQL-Injection oder XSS auf Frontend. | Hoch | Der Vue.js-Renderer schützt nativ vor Cross-Site-Scripting (DOM-Sanitization). Laravel's ORM (Eloquent) nutzt Prepared Statements und schließt SQL-Injections systemisch aus. Libraries (npm/composer) werden automatisiert überwacht. |
Ergebnis der Bewertung: Die getroffenen und evaluierten Maßnahmen von Schulhamsta reduzieren das Restrisiko beim Betrieb der Lösung auf ein für Schulen vertretbares, geringes Maß (Stand der Technik gem. Art. 32 DSGVO).