Technisch-organisatorische Maßnahmen

Anlage 1 zum AVV: Maßnahmen nach Art. 32 DSGVO, Stand 20.07.2026

Diese TOMs beschreiben die tatsächlich implementierte Architektur und werden bei Architektur-Änderungen fortgeschrieben.

1. Verschlüsselung & Pseudonymisierung (Art. 32 Abs. 1 lit. a)

  • Clientseitige Ende-zu-Ende-Verschlüsselung: Drop-Inhalte werden im Browser des Nutzers mit AES-256-GCM (WebCrypto-API) verschlüsselt, bevor sie übertragen werden. Der Schlüssel wird im URL-Fragment transportiert, das Browser prinzipbedingt nie an Server senden. Der Anbieter speichert ausschließlich Ciphertext.
  • Optionale Passphrase: wird clientseitig per HKDF-SHA256 in den Schlüssel gemischt; verlässt den Browser nie.
  • Zugriffstoken: serverseitig ausschließlich als SHA-256-Hash gespeichert; ein Datenbank-Abzug allein ermöglicht keinen Drop-Zugriff (Zwei-Token-Design).
  • IP-Pseudonymisierung: IP-Adressen werden im Audit-Protokoll ausschließlich als SHA-256-Hash gespeichert.
  • Transportverschlüsselung: TLS 1.2+ mit HSTS für sämtliche Verbindungen.

2. Vertraulichkeit & Zugriffskontrolle (lit. b)

  • Zutrittskontrolle: Betrieb ausschließlich in ISO-27001-zertifizierten Rechenzentren (Hetzner, Deutschland); kein eigener physischer Serverzugang erforderlich.
  • Zugangskontrolle: Administrativer Zugriff nur über SSH-Public-Key-Verfahren und Konten mit Multi-Faktor-Authentifizierung; keine Passwort-Logins.
  • Zugriffskontrolle: Least-Privilege-Prinzip; produktive Datenbankzugriffe nur durch die Applikation. Architektur-Eigenschaft: Auch privilegierte Administratoren können Drop-Inhalte nicht entschlüsseln (kein Schlüsselmaterial serverseitig vorhanden).
  • Keine Fremd-Skripte auf Drop-Seiten (Ausschluss von Fragment-Exfiltration durch Dritt-Code); keine Werbe-Tracker.
  • Protokollierungs-Verzicht: Keine Access-Logs mit URLs auf Drop-Pfaden; Invoke-Payloads der Chat-Integrationen werden nicht geloggt.

3. Integrität (lit. b)

  • Authentifizierte Verschlüsselung: AES-GCM erkennt jede Manipulation des Ciphertexts; manipulierte Drops sind nicht entschlüsselbar.
  • Atomare Lese-Transaktionen: Burn-after-read wird datenbankseitig atomar durchgesetzt; ein Einmal-Drop kann auch bei parallelen Zugriffen nur genau einmal gelesen werden.
  • Audit-Protokoll (Team-Plan): Ereignisse erstellt/gelesen/verbrannt/abgelaufen mit Zeitstempel: ausschließlich Metadaten, nie Inhalte.
  • Eingabevalidierung & Rate-Limiting auf allen öffentlichen Endpunkten; signaturgeprüfte Webhooks (Stripe, Slack, Microsoft).

4. Verfügbarkeit & Belastbarkeit (lit. b/c)

  • Zustandslose Applikationsschicht, horizontal skalierbar; Infrastruktur als Code reproduzierbar.
  • Tägliche Datenbank-Backups (enthalten ausschließlich Ciphertext und Metadaten) in EU-Objektspeicher (Hetzner, Falkenstein) mit 30 Tagen Aufbewahrung, zusätzlich kontinuierliche Transaktionsprotokoll-Sicherung; Wiederherstellung bei Einrichtung Ende-zu-Ende getestet, weitere Tests mindestens jährlich.
  • Monitoring der Verfügbarkeit und Fehlerraten über die Kubernetes-Plattform (Health-Checks, automatischer Neustart fehlerhafter Instanzen, rollierende Deployments ohne Ausfall).

5. Löschkonzept

  • Selbstlöschung per Design: Drops werden beim Erreichen des Lese-Limits sofort und beim Ablauf spätestens nach 60 Sekunden endgültig gelöscht (harte DELETEs, kein Soft-Delete, kein Papierkorb).
  • Verbrannte, abgelaufene und nie existente Drops sind in der API-Antwort ununterscheidbar (kein Existenz-Orakel).
  • Restbestände in Backups verfallen mit der Backup-Rotation nach max. 30 Tagen.
  • Account- und Audit-Daten werden nach Vertragsende gemäß Ziffer 10 des AVV gelöscht.

6. Auftragskontrolle & Organisation (Art. 32 Abs. 1 lit. d, Art. 28)

  • Subprozessoren nur innerhalb EU/EWR für Kerndienst-Daten; Verträge nach Art. 28 Abs. 4 DSGVO; aktuelle Liste im Trust Center.
  • Definierte Verantwortlichkeiten für Datenschutz und Sicherheit; dokumentierter Incident-Response-Prozess mit 48-Stunden-Meldezusage.
  • Quelloffene Client-Verschlüsselung: externe Überprüfbarkeit als organisatorische Maßnahme.
  • Änderungsmanagement über Versionskontrolle, Code-Review und automatisierte Tests (u.a. Krypto-Roundtrip- und Nebenläufigkeitstests der Burn-Semantik).
  • Überprüfung und Fortschreibung dieser Maßnahmen mindestens jährlich sowie anlassbezogen.