Anlage 2 — Technische und organisatorische Maßnahmen

Beschrieben ist der tatsächliche Stand, nicht ein Wunschbild. Was noch offen ist, steht in Abschnitt 8 und ist dem Verantwortlichen damit vor Vertragsschluss bekannt (§ 4.3 AVV).

1. Pseudonymisierung und Verschlüsselung

Übertragung: ausschließlich TLS. Der Reverse Proxy erzwingt HTTPS und erneuert die Zertifikate automatisch. Sicherheitsrelevante Antwortheader (u. a. X-Content-Type-Options, Referrer-Policy) sind gesetzt.
Sitzungen: kein Passwort im System. Der Sitzungsnachweis ist ein mit HMAC-SHA256 signiertes Token in einem HttpOnly-, Secure- und SameSite-Cookie, gültig sieben Tage, mit Neuableitung der Rolle aus der Datenbank alle 15 Minuten.
Integrationsgeheimnisse — Zugangsdaten zu Ticketsystem, Zahlungsanbieter und fremdem Mailrelay — werden mit AES-256-GCM verschlüsselt gespeichert (src/lib/crypto/aes.ts); ohne den Schlüssel aus der Umgebung sind die Datensätze wertlos.
Speicher: Sicherungskopien liegen serverseitig verschlüsselt im Objektspeicher; der Zugriff erfordert ein auf den Ablageort beschränktes Zugriffstoken.
Pseudonymisierung bei Löschung: Datensätze, die aus rechtlichen Gründen bestehen bleiben, erhalten für jedes identifizierende Feld denselben konstanten Ersatzwert. Ein aus Kennung oder Adresse abgeleiteter Wert würde die Person weiterhin auszeichnen und wäre nach Erwägungsgrund 26 weiterhin personenbezogen — genau das wird vermieden.
Unkenntlichmachung in Protokollen: Anmeldetoken, Codes, Geheimnisse und E-Mail-Parameter werden vor dem Versand an die Fehlerprotokollierung entfernt; die Reichweitenmessung ersetzt zusätzlich Badge-Codes in Adressen.

2. Vertraulichkeit

Zutritt. Kein eigenes Rechenzentrum. Die Server stehen bei der Hetzner Online GmbH in Deutschland, deren Rechenzentren nach ISO/IEC 27001 zertifiziert sind. Arbeitsgeräte sind vollverschlüsselt und automatisch bildschirmgesperrt.

Zugang. Serverzugang ausschließlich über SSH-Schlüssel; die Verwaltungsoberfläche (Coolify) und die Datenbankkonsole (Appwrite) sind mit eigenen Konten und Zwei-Faktor-Authentifizierung geschützt. Anwendungszugang nur über Einmal-Anmeldelink oder -code an die hinterlegte Adresse. Anmelde-, Registrierungs- und Bestellvorgänge sind mengenmäßig begrenzt (verteilte Zähler über Redis).

Zugriff. Vier Team-Rollen zuzüglich Sprecherrolle, hierarchisch nach unten wirkend. Jede Route prüft Berechtigung und Mandant zentral über eine gemeinsame Autorisierungsfunktion; die Prüfung liegt nicht in den einzelnen Handlern. Die Datenbank ist für Browser vollständig geschlossen — jeder Zugriff läuft über den Server mit einem serverseitigen Schlüssel.

Trennung. Jeder Datensatz trägt Organisations- und Arbeitsbereichskennung; jede Abfrage ist darauf eingeschränkt. Ein wiederkehrender Prüflauf (npm run audit:tenants) meldet Datensätze ohne oder mit falscher Zuordnung. Der Löschvorgang ist auf die Organisation begrenzt, damit eine Person, die bei zwei Veranstaltern auftritt, nicht beim falschen gelöscht wird.

3. Integrität

Weitergabe. Ausgehende Webhooks werden signiert, sodass der Empfänger die Herkunft prüfen kann; Zustellungen laufen in einen Wiederholungsmechanismus mit Obergrenze. Aufzeichnungen werden nicht über den Anwendungsserver ausgeliefert, sondern über kurzlebige, signierte Direktverweise auf den Objektspeicher. Datei-Uploads werden anhand ihrer Signaturbytes geprüft, nicht anhand der Dateiendung.

Eingabe. Jede Tabelle führt Erstell- und Änderungszeitpunkt samt verursachender Kennung. Einlasskontrollen bleiben auch nach einer Rücknahme als Protokolleintrag erhalten. Löschanträge werden mit Antragsteller, Zeitpunkt, Ausführung und Ergebnis protokolliert. Die Zustellung ausgehender Webhooks wird mit übermitteltem Inhalt protokolliert, damit später nachvollziehbar ist, was ein Empfänger erhalten hat.

4. Verfügbarkeit und Belastbarkeit

Datenbanksicherung täglich 03:00 UTC, Aufbewahrung der letzten drei Sicherungen lokal und der letzten 30 im Objektspeicher (~30 Tage).
Sicherung der hochgeladenen Dateien täglich 03:30 UTC, ebenfalls 30 Stände.
Die Wiederherstellung ist getestet, zuletzt am 31.08.2026; das Vorgehen samt Befehlen steht in ../backup-restore-runbook.md.
Zwischenspeicher (Redis) enthält personenbezogene Daten nur mit einer Verfallszeit von 60 Sekunden bis 5 Minuten; ein Verlust dieses Speichers bedeutet keinen Datenverlust.
Anwendungsprozesse laufen je Rechenkern getrennt hinter einer Zustandsprüfung; ein abgestürzter Prozess wird ersetzt.
Fehler laufen in eine eigene Fehlerprotokollierung mit Alarmierung.

5. Verfahren zur Überprüfung und Bewertung

Alle Änderungen laufen über Versionskontrolle und Review vor der Übernahme in den Hauptzweig.
Automatisierte Tests laufen bei jeder Änderung. Ein Test erzwingt, dass jede neue Tabelle mit personenbezogenen Daten im Löschverfahren bewertet ist — eine vergessene Tabelle lässt den Test scheitern, statt eine Löschung stillschweigend unvollständig zu machen.
Abhängigkeiten werden auf bekannte Schwachstellen geprüft (npm audit, zuletzt ohne Befund).
Vollständige Sicherheitsprüfung des Codes zuletzt am 01.09.2026 (../security-audit-2026-09-01.md), Wiederholung mindestens jährlich sowie bei wesentlichen Änderungen.

6. Auftragskontrolle

Unterauftragsverarbeiter werden vor Beauftragung geprüft, vertraglich nach Art. 28 Abs. 4 DSGVO verpflichtet und in Anlage 3 offengelegt. Weisungen des Verantwortlichen werden in Textform entgegengenommen und dokumentiert.

7. Unterstützung der Betroffenenrechte im Produkt

Diese Funktionen sind Teil der Maßnahmen, weil sie die Rechte der Betroffenen technisch durchsetzbar machen:

Löschantrag aus der App heraus, mit Warteschlange und Monatsfrist im Veranstalterbereich.
Auskunftsexport über alle Tabellen hinweg, mit ausdrücklicher Begrenzung dort, wo Rechte Dritter berührt sind — aus einem Gespräch wird der eigene Anteil ausgegeben, nicht das Protokoll der Gegenseite (Art. 15 Abs. 4).
Die Löschung zeigt vor der Ausführung an, welche Tabelle gelöscht, anonymisiert oder gesperrt wird und was aus rechtlichen Gründen bleibt.
Der Vorgang ist wiederholbar, ohne Schaden anzurichten — nötig, weil eine Wiederherstellung aus der Sicherung gelöschte Personen zurückbringt.

8. Bekannte Restrisiken und Behebungsplan

Aus der Prüfung vom 01.09.2026, Stand 04.09.2026. Sie sind hier offengelegt, weil der Verantwortliche sie für seine eigene Risikobewertung kennen muss.

Nr.	Befund	Wirkung	Status	Behebung bis
C1	Weiterleitungsziel nach der Anmeldung filtert Steuerzeichen nicht	Phishing mit echtem Anmeldelink	offen	30.09.2026
C2	Gestaltungsvorgaben des Veranstalters werden ungeprüft als Stilangaben ausgegeben	Skripteinschleusung durch einen Veranstalter, auch auf der Anmeldeseite	offen	30.09.2026
C3	Anmeldetoken mit 24 Bit Zufall, Prüfroute ohne Mengenbegrenzung	Erraten eines fremden Anmeldelinks	offen	30.09.2026
C4	Standardwert für die Zahl vertrauenswürdiger Proxys ist 0	Mengenbegrenzungen fallen in einen gemeinsamen Topf, Aussperren aller Nutzer möglich	offen, Produktionswert unbestätigt	30.09.2026
H1	Streamschlüssel wird an alle Ticketinhaber ausgeliefert	Fremdes Video im Livestream	offen	31.10.2026
H2	Profil in der Organisation gilt als Teilnahme an allen ihren Veranstaltungen	Teilnehmerverzeichnis fremder Veranstaltungen lesbar	offen	31.10.2026
H3	Mitgliederliste eines ausstellenden Unternehmens liefert vollständige Profile samt Adresse	Sammeln von Kontaktdaten	offen	31.10.2026
H4	Dateiablagen erlauben Schreib- und Löschrechte für jedes angemeldete Konto der Datenbankplattform	Löschen oder Einstellen fremder Dateien	offen	31.10.2026

Behobene Fehlkonfiguration. Bis zum 01.09.2026 waren 39 Tabellen der Datenbank mit Lese- und Schreibrechten für „any” konfiguriert. Nach Angabe des Betreibers betraf das die Staging-Instanz, die keine echten Nutzerdaten enthält; eine Verletzung des Schutzes personenbezogener Daten nach Art. 4 Z 12 DSGVO lag damit nicht vor, und es bestand keine Melde- oder Benachrichtigungspflicht nach Art. 33 und 34. Die Rechte sind gesperrt (npm run lock-permissions). Für die Produktivinstanz ist dokumentiert, dass sie zum selben Zeitpunkt eingeschränkt war.

Zugriff auf Sicherungen. Eine Wiederherstellung kann jede Person auslösen, die Serverzugang oder Zugang zur Verwaltungsoberfläche hat. Derzeit ist das eine Person. Bei Erweiterung des Kreises ist ein Vier-Augen-Prinzip einzuführen.