Zum Hauptinhalt springen

Technische und organisatorische Maßnahmen

Entwurf

Diese Seite ist ein Entwurf, geschrieben anhand des Codes und der Server-Konfiguration am 14. Oktober 2026. Sie ist noch nicht anwaltlich geprüft und nicht unterschriftsreif. Sie beschreibt, was Clubkit heute tatsächlich tut; offene Punkte sind als offen markiert.

Anlage 1 zum AVV: wie Clubkit die Daten deines Vereins heute schützt, einschließlich der Punkte, die noch offen sind.

Anbieter: Mac Beagan – Web Development, Isartalstr. 16, 80469 München Plattform: Clubkit (clubkit.team)

1. Überblick: so ist Clubkit aufgebaut​

  • Ein virtueller Server bei der Hetzner Online GmbH in einem Rechenzentrum in Deutschland. Darauf laufen in Docker-Containern: die Datenbank (PostgreSQL 16), der Synchronisationsdienst (PowerSync, selbst betrieben), der API-Server, die öffentlichen Vereinswebsites und der Webserver Caddy.
  • Lokal zuerst („local-first"): Die App und die Web-Verwaltung halten eine Kopie der Daten, die die angemeldete Person sehen darf, auf dem Gerät. Welche Daten das sind, entscheidet allein der Server (siehe 4.).
  • Keine Analyse- oder Tracking-Werkzeuge, keine Werbung, keine Fehlerdienste von Drittanbietern in App, Web-Verwaltung oder Vereinswebsite.

2. Vertraulichkeit​

2.1 Zutrittskontrolle (Rechenzentrum)​

Physischer Zutritt liegt bei Hetzner (Zutrittskontrolle, Videoüberwachung, Personal vor Ort laut Hetzner). Der Anbieter selbst betreibt keine eigenen Serverräume.

2.2 Zugangskontrolle (Systeme)​

  • Nach außen offen sind nur die Ports 80 und 443 des Webservers. Die Datenbank hat keinen öffentlichen Port; sie ist nur innerhalb des Docker-Netzes erreichbar.
  • Verwaltungszugang zum Server hat nur der Inhaber, per SSH. (Offen: schriftlich festhalten, dass nur Schlüssel-Login erlaubt ist, und Firewall-Regeln dokumentieren.)
  • Zugangsdaten zu Diensten (Datenbank, E-Mail-Versand, DNS) liegen nur in einer Konfigurationsdatei auf dem Server, nicht im Quellcode.

Anmeldung von Nutzern:

  • Login mit E-Mail und Passwort. Passwörter werden nur als Hash gespeichert (scrypt, Standard von Better Auth).
  • Begrenzung von Anmeldeversuchen pro IP-Adresse: 30 pro Minute für Anmeldung und Registrierung, 10 pro Minute für „Passwort vergessen".
  • Nach einem Zurücksetzen des Passworts werden alle anderen Sitzungen beendet, und die Person bekommt eine Hinweis-E-Mail.
  • Sitzungen werden serverseitig gespeichert. Im Browser liegt das Sitzungs-Cookie nur für die jeweilige Adresse (nicht für die öffentlichen Vereinswebsites). In der App liegt das Sitzungstoken im geschützten Speicher des Betriebssystems (iOS-Schlüsselbund, Android Keystore).
  • Der Synchronisationsdienst akzeptiert nur kurzlebige Tokens (5 Minuten), die nur die Nutzerkennung enthalten. Rollen werden nie aus dem Token gelesen.
  • Offen: keine Zwei-Faktor-Anmeldung; E-Mail-Adressen werden bei der Registrierung nicht bestätigt.

2.3 Zugriffskontrolle (wer sieht was)​

Rollen im Verein: Inhaber, Admin, Trainer, Mitglied, Fan; dazu Erziehungsberechtigte (Verknüpfung mit dem Kind) und einzelne Sonderrechte, die die Vereinsverwaltung vergibt.

Lesen: Was auf ein Gerät gelangt, legt der Server in den Synchronisationsregeln fest, nicht die Oberfläche der App. Ein ausgeblendetes Feld ist also nicht „nur versteckt", es wird gar nicht übertragen. Im Einzelnen:

  • Mitglieder bekommen das Mitgliederverzeichnis nur mit wenigen Spalten (Name, Rolle, Mannschaft, Position u. ä.). Telefonnummern, Notfallkontakte, medizinische Hinweise, Nationalität und Beitragsdaten anderer Mitglieder erhalten sie nicht.
  • Profilfotos anderer Mitglieder erhalten Mitglieder nur, wenn die abgebildete Person der internen Nutzung zugestimmt hat.
  • Trainer erhalten Kontaktdaten, Notfallkontakte, medizinische Hinweise und Nationalität nur für die Mitglieder ihrer eigenen Mannschaften.
  • Trainer erhalten die Zu- und Absagen und die Anwesenheit aller Termine im Verein, auch der Termine anderer Mannschaften. Erfassen können sie die Anwesenheit bei Terminen der Mannschaften, die sie trainieren (bei einem Termin mit mehreren Mannschaften reicht eine davon), und bei Terminen für den ganzen Verein.
  • Termine nur für Eingeladene (und die Zu- und Absagen dazu) erreichen nur die Eingeladenen und die Vereinsverwaltung.
  • Fans erhalten nur öffentliche Spieldaten (Vereinsauftritt, Mannschaften, Spielplan, Ergebnisse) und ihre eigenen Kontodaten.
  • Erziehungsberechtigte erhalten die Daten ihrer eigenen Kinder.
  • Mitglieder, Erziehungsberechtigte und Fans erhalten Termine, Zu- und Absagen und Spiele nur aus den letzten 12 Monaten. Die Vereinsverwaltung und Trainer behalten den ganzen Verlauf.
  • E-Mails und Push-Benachrichtigungen, die der Server verschickt, folgen denselben Regeln: wer etwas nicht synchronisiert bekommt, bekommt es auch nicht per E-Mail oder Push.

Schreiben: Jede Änderung, die eine App oder die Web-Verwaltung macht, geht an einen einzigen Server-Endpunkt. Dort wird bei jeder Anfrage aus der Datenbank geprüft, ob die Person in diesem Verein aktiv ist und die nötige Rolle hat. Die Vereinskennung und den Zeitstempel setzt der Server selbst; was das Gerät mitschickt, wird nicht übernommen. Unzulässige Änderungen werden nicht ausgeführt und dem Gerät als abgelehnt gemeldet. Ergebnisse von Spielen berechnet nur der Server aus dem Ereignisprotokoll.

Prüfung: Die Synchronisationsregeln sind durch automatische Tests abgesichert, die für jede Rolle prüfen, welche Zeilen und Spalten ankommen. Nach jeder Änderung der Regeln wird dieser Test vor der Auslieferung und eine Stichprobe auf dem Produktivsystem durchgeführt.

2.4 Trennungskontrolle​

Alle Vereine liegen in einer gemeinsamen Datenbank. Jede vereinsbezogene Tabelle hat eine Vereinskennung; Lesen und Schreiben ist immer an die Mitgliedschaft der Person in genau diesem Verein gebunden (siehe 2.3). Die Vereinskennung eines Datensatzes setzt der Server, nie das Gerät.

2.5 Pseudonymisierung und Verschlüsselung​

  • Alle Verbindungen sind per TLS verschlüsselt (HTTPS, automatische Zertifikate). Das gilt für App, Web-Verwaltung, API, Synchronisation und Vereinswebsites.
  • Gelöschte Konten werden anonymisiert (Name durch einen Platzhalter ersetzt, persönliche Felder geleert), damit die Vereinsgeschichte ohne Personenbezug erhalten bleibt (Einzelheiten in Aufbewahrung und Löschung).
  • Offen: Die Datenbank und die hochgeladenen Bilder sind auf dem Server nicht zusätzlich verschlüsselt (keine Verschlüsselung auf Anwendungsebene). Datensicherungen sind nicht verschlüsselt.
  • Offen: Die Daten auf den Geräten (lokale Datenbank) werden von der App nicht zusätzlich verschlüsselt; es gilt die Geräteverschlüsselung des Betriebssystems. Beim Abmelden wird die lokale Datenbank gelöscht.

3. Integrität​

3.1 Weitergabekontrolle​

  • Übertragung nur über TLS.
  • E-Mails werden über Resend verschickt, je Empfänger eine eigene Nachricht (keine gemeinsamen Empfängerlisten).
  • Push-Benachrichtigungen gehen über den Push-Dienst von Expo an Apple bzw. Google. Sie enthalten den Text der Benachrichtigung (z. B. Titel eines Termins oder einer Mitteilung).
  • Auf der öffentlichen Vereinswebsite erscheinen Personen (z. B. im Kader) nur mit ihrer Einwilligung für die Website.
  • Hochgeladene Bilder bekommen zufällige Dateinamen (UUID); erlaubt sind nur JPG, PNG und WebP bis 5 MB. Offen: Die Bilddateien sind für jeden abrufbar, der die (nicht erratbare) Adresse kennt; es gibt keine Zugriffsprüfung beim Abruf. Ob Bild-Metadaten (z. B. Standort) entfernt werden, ist noch zu prüfen.

3.2 Eingabekontrolle​

  • Jede Zeile trägt einen vom Server gesetzten Änderungszeitpunkt.
  • Einwilligungen werden nur angehängt, nie überschrieben: jede Entscheidung mit Zeitpunkt und der Person, die sie getroffen hat.
  • Spielereignisse speichern, wer sie erfasst hat.
  • Offen: Es gibt kein allgemeines Änderungsprotokoll (wer hat wann welches Feld geändert).

4. Verfügbarkeit und Belastbarkeit​

  • Die Container starten nach einem Absturz oder Neustart automatisch neu.
  • Die Apps arbeiten auch ohne Verbindung weiter und gleichen Änderungen später ab.
  • Datensicherung heute: Ein Skript sichert die Datenbank (pg_dump) und die hochgeladenen Bilder und löscht Sicherungen nach 30 Tagen. Heute liegen die Sicherungen nur auf demselben Server; eine Sicherung an einem zweiten Ort (Offsite) ist noch nicht eingerichtet. Vor jeder Auslieferung mit Datenbankänderung wird eine Sicherung angelegt.
  • Offen: Offsite-Sicherung (verschlüsselt) einrichten; regelmäßige Sicherung per Zeitplan bestätigen; Wiederherstellung testen und dokumentieren.
  • Offen: Keine externe Verfügbarkeitsüberwachung (Uptime-Monitoring).

5. Verfahren zur regelmäßigen Überprüfung​

  • Automatische Tests (über 1.000) laufen vor jeder Auslieferung, darunter Tests der Zugriffsregeln je Rolle und End-to-End-Tests der Datenschutz-Regeln der Synchronisation.
  • Änderungen an den Synchronisationsregeln werden als eigene Auslieferung behandelt und danach pro Rolle stichprobenartig geprüft.
  • Neue Datenfelder folgen festen Regeln (nur Ergänzungen, unbekannte Werte werden abgelehnt, persönliche Daten nie in Tabellen, die vollständig an alle Mitglieder gehen).
  • Protokolle: Der API-Server protokolliert je Anfrage Methode, Pfad, Statuscode und Dauer, keine IP-Adressen. Der Webserver schreibt kein Zugriffsprotokoll. Offen: Aufbewahrungsdauer der Container-Protokolle festlegen.
  • Offen: Ablauf bei Datenschutzverletzungen schriftlich festhalten (wer meldet wem wann, siehe AVV Ziffer 10).

6. Auftragskontrolle​

  • Die Unterauftragsverarbeiter stehen in der Liste der Unterauftragsverarbeiter; mit jedem besteht ein Vertrag zur Auftragsverarbeitung bzw. gelten dessen Datenverarbeitungsbedingungen. (Offen: Abschluss bei jedem Dienst prüfen und ablegen.)
  • Der Anbieter verarbeitet Vereinsdaten nur für den Betrieb von Clubkit, nicht für eigene Zwecke.
  • Es gibt keine Zertifizierungen (z. B. ISO 27001) des Anbieters. Hetzner verfügt über eine eigene ISO-27001-Zertifizierung. (Offen: aktuellen Nachweis von Hetzner ablegen.)