Zum Inhalt springen
CastTool
Menü

Technische und organisatorische Maßnahmen

Entwurf, keine geprüfte Rechtsangabe: Dieser Text ist noch nicht anwaltlich geprüft, und die Firma des Betreibers steht noch nicht fest. Offene Angaben sind markiert.

Fassung: draft-2026-11-02

Stand

Diese Anlage zum AVV beschreibt die Maßnahmen, die im Code von CastTool umgesetzt sind. Geprüft sind sie bisher mit automatischen Tests in einer lokalen Umgebung. Prüfung auf einer Testumgebung, externer Penetrationstest, Lasttest und Wiederherstellungsprobe stehen vor dem Start noch aus. Organisatorische Maßnahmen sind noch nicht beschrieben und markiert.

Trennung der Kunden

  • Alle Kunden teilen eine Datenbank. Jede Zeile gehört genau einem Kunden, und die Datenbank selbst lässt nur Zeilen dieses Kunden zu (Row Level Security, auch für den Eigentümer der Tabellen erzwungen).
  • Die Anwendung arbeitet mit eigenen Datenbankrollen ohne Recht, diese Regeln zu umgehen. Hätte ihre Rolle das Recht, startet sie nicht.
  • Für jede Tabelle prüft ein automatischer Test mit zwei Kunden, dass keiner die Daten des anderen sieht. Er verhindert jede Änderung, die das bricht.
  • Dateien liegen je Kunde unter eigenem Pfad.

Zugang und Berechtigungen

  • Konten entstehen nur über die Registrierung mit bestätigter E-Mail-Adresse oder eine Einladung. Einladungen gelten 7 Tage und einmal, in der Datenbank steht nur ihr Hash.
  • Passwörter haben mindestens 12 Zeichen und liegen nur als Hash vor. Ein zweiter Faktor ist möglich, für Mitarbeiter der Plattform Pflicht.
  • Rollen je Kunde: Owner, Admin, Model und Kunde. Ein Model sieht nur sich selbst, ein Kunde nur seine eigenen Listen und Anfragen.
  • Die Sitzung gilt nur auf app.casttool.net und erreicht die Websites der Kunden nie. Jede ändernde Anfrage prüft ihre Herkunft.
  • Die Plattform greift auf ein Konto nur über eine eigene Funktion zu: mit zweitem Faktor, höchstens eine Stunde, mit sichtbarem Hinweis. Eingriffe der Plattform werden mit Person und Ziel protokolliert.
  • Für jede Schnittstelle ist festgelegt, wer sie aufrufen darf. Ein automatischer Test ruft jede mit der Sitzung eines fremden Kunden auf.

Dateien

  • Originale, Dokumente und Rechnungen liegen in einem privaten Speicher. Öffentlich ist nur, was der Kunde freigegeben hat, und davon nur eine bearbeitete Fassung.
  • Uploads landen zuerst in einer Quarantäne. Geprüft wird der Inhalt der Datei, nicht ihre Endung. SVG wird abgelehnt.
  • Bei Bildern und Videos werden Metadaten wie GPS entfernt, bevor etwas öffentlich wird.
  • Dokumente gibt es nur als kurz gültigen Link zum Herunterladen, bei Minderjährigen kürzer als bei Erwachsenen.

Übertragung

  • Alle Verbindungen laufen verschlüsselt über HTTPS, zwischen Cloudflare und dem Server mit geprüftem Zertifikat, mindestens TLS 1.2.
  • Jede Oberfläche hat eigene Sicherheitsheader und eine eigene Content Security Policy.
  • Links in E-Mails, die etwas auslösen, sind signiert, laufen ab und wirken erst nach einer Bestätigung auf der Seite.

Schutz öffentlicher Formulare

  • Jede öffentliche Aktion hat eine Grenze je IP-Adresse und, wo sinnvoll, je E-Mail-Adresse. Gespeichert wird dafür nur ein Schlüssel, aus dem sich die Adresse nicht zurückrechnen lässt.
  • Formulare prüfen auf dem Server, ob ein Mensch sie abgeschickt hat (Cloudflare Turnstile).
  • Mails an Adressen aus öffentlichen Formularen enthalten keinen Text aus dem Formular, damit niemand darüber Fremden schreiben kann.

Nachvollziehbarkeit

  • Einwilligungen von Models und Freigaben der Eltern stehen mit Fassung des Texts und Zeitpunkt in einem Protokoll, das nur wächst.
  • Jede Fassung der Rechtstexte bleibt im Archiv.
  • Jede ausgehende Mail steht im Protokoll, auch jeder Fehlversuch.

Verfügbarkeit und Wiederherstellung

  • Laut Betriebsdokumentation wird die Datenbank täglich gesichert, die Dateien mit restic, Ziel ist eine Hetzner Storage Box.
  • Eine Wiederherstellung der Dateien wurde am 2026-10-19 erfolgreich geprobt.
  • Bis zu 24 Stunden Datenverlust sind möglich. Eine Wiederherstellung auf jeden Zeitpunkt ist geplant und noch nicht umgesetzt.
  • offen: Standort und Verschlüsselung der Sicherungen, Aufbewahrung, Probe der Datenbank

Regelmäßige Prüfung

  • Jede Änderung am Code durchläuft automatische Tests, darunter die Trennung der Kunden, die Berechtigungen jeder Schnittstelle und eine Suche nach Geheimnissen im Code.
  • Vor dem Start ist ein externer Penetrationstest geplant. offen: Anbieter, Zeitpunkt, Wiederholung

Organisatorische Maßnahmen

offen: Verpflichtung auf Vertraulichkeit, wer Zugriff auf Server und Datenbank hat, Umgang mit Zugangsdaten, Vorgehen bei Sicherheitsvorfällen, Schutz der Räume und Rechenzentren