Datensicherheit

Stand: 16. Mai 2026

Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen (TOM gemäß Art. 32 DSGVO), mit denen personenbezogene Daten in SeizeIO geschützt werden. Es ergänzt die Datenschutzerklärung.

1. Übertragung

• Die gesamte Kommunikation zwischen App und Backend erfolgt ausschließlich verschlüsselt über HTTPS (TLS 1.2+) bzw. WSS für WebSocket-Verbindungen.
• HTTP Strict Transport Security (HSTS) ist serverseitig aktiviert, damit Browser nur verschlüsselte Verbindungen aufbauen.
• Sicherheits-Header (X-Content-Type-Options, X-Frame-Options, Referrer-Policy) werden bei jeder Antwort gesetzt.

2. Authentifizierung

• Identitätsmanagement erfolgt über einen dedizierten Keycloak-Server (OpenID Connect / OAuth 2.0).
• Passwörter werden ausschließlich als Hash (bcrypt, verwaltet durch Keycloak) gespeichert. Klartext-Passwörter verlassen das Endgerät nie.
• Zugriffstoken (JWT) sind kurzlebig; ein Refresh-Token-Flow ermöglicht eine nahtlose Erneuerung ohne wiederholte Passwortabfrage.
• Auf dem Endgerät werden Tokens im Secure Storage des Betriebs- systems abgelegt (Android Keystore / iOS Keychain).

3. Autorisierung und Zugriff

• Sämtliche API-Endpunkte verlangen ein gültiges Zugriffstoken, ausgenommen davon sind ausschließlich öffentliche Informationsseiten (z. B. diese Seite).
• Datenzugriffe sind nutzerbezogen abgesichert: Nutzer:innen können ausschließlich ihre eigenen Konto- und Bewegungsdaten verändern.
• Spielbezogene Daten (Routen, Eroberungen) werden nur innerhalb der jeweiligen Runde mit anderen Teilnehmenden geteilt.

4. Speicherung

• Die Datenbank wird verschlüsselt auf gemanagter Infrastruktur (Railway) betrieben; Snapshots werden ebenfalls verschlüsselt abgelegt.
• Standortpunkte werden nach Verarbeitung in aggregierter Form (Pfade, Territorien) gehalten. Roh-GPS-Punkte werden nur so lange wie für die Spiellogik nötig vorgehalten.
• Server-Logs enthalten keine GPS-Koordinaten und werden nach maximal 30 Tagen automatisch gelöscht.

5. Eingabevalidierung und Schutz vor Missbrauch

• Rate-Limiting auf authentifizierten Endpunkten verhindert Brute-Force- und Scraping-Angriffe.
• Plausibilitätsprüfung der eingehenden GPS-Daten verhindert das Einreichen unrealistischer Bewegungen (Geschwindigkeitsgrenzen je Bewegungsmodus, geografische Sprungerkennung).
• Eingabedaten werden serverseitig über typisierte Schemas (Pydantic) validiert; SQL-Anfragen erfolgen ausschließlich parametrisiert (SQLAlchemy ORM).

6. Endgerät

• Die App fragt Standortberechtigungen nur an, wenn sie tatsächlich benötigt werden, und zeigt vor jeder System-Abfrage einen eigenen Hinweis (Prominent Disclosure).
• Beim Hintergrund-Tracking ist auf Android eine dauerhaft sichtbare System-Benachrichtigung Pflicht; sie kann nicht ausgeblendet werden. Auf iOS weist ein System-Standort-Hinweis in der Statusleiste auf die aktive Ortung hin.
• Bei Verlust der Internetverbindung werden GPS-Punkte lokal gepuffert und automatisch übertragen, sobald wieder Verbindung besteht.

7. Betrieb

• Backend und Keycloak laufen auf Railway in isolierten Containern; Zugang ausschließlich über Schlüsselauthentifizierung.
• Geheimnisse (API-Schlüssel, DB-Credentials) werden ausschließlich über die Secret-Verwaltung der Plattform bereitgestellt und niemals im Quellcode gespeichert.
• Abhängigkeiten werden regelmäßig auf bekannte Sicherheitslücken geprüft.

8. Meldung von Sicherheitslücken

Sicherheitsrelevante Funde meldest du bitte vertraulich an ajohe.ajohe@gmail.com. Wir bemühen uns um eine zeitnahe Rückmeldung und behandeln verantwortungsvoll gemeldete Schwachstellen mit angemessener Diskretion.

9. Änderungen

Dieses Dokument wird bei wesentlichen Änderungen der eingesetzten Sicherheitsmaßnahmen aktualisiert. Die jeweils aktuelle Version ist unter dieser URL abrufbar.