CoachDesk · Fassung beta-2026-11-14

Technische und organisatorische Maßnahmen (TOM) nach Art. 32 DSGVO

Verantwortlich für dieses Blatt: Bernhard Millauer · Stand: Entwurf vom 2026-11-13 · Fassung 0.2

1. Vertraulichkeit (Art. 32 Abs. 1 lit. b)

1.1 Zutritt (Rechenzentrum)

• Server bei Hetzner Online GmbH, Rechenzentrum Helsinki (Finnland, EU). Zutrittskontrolle, Videoüberwachung, Brandschutz nach den TOM von Hetzner (jährlich durch TÜV Rheinland / i-sec geprüft).
• Der Betreiber hat keinen physischen Zutritt; Verwaltung nur über verschlüsselte Fernzugänge.

1.2 Zugang (Systeme)

• Server-Zugang nur per SSH mit Schlüssel; Verwaltung der Dienste über Coolify.
• Vorgeschalteter Schutz vor Angriffen (Cloudflare-Proxy: Abwehr von Überlastungsangriffen, Filterung).
• Anmeldung an der Anwendung mit Passwort (mind. 8 Zeichen), gespeichert als PBKDF2-HMAC-SHA256-Hash (200 000 Iterationen, zufälliges Salt), Vergleich in konstanter Zeit.
• Zwei-Faktor-Anmeldung (TOTP nach RFC 6238) mit Schutz gegen Wiederverwendung und 8 Wiederherstellungscodes (nur als Hash gespeichert). Wer sie nicht eingerichtet hat, wird bei jedem Aufruf der Anwendung zur Einrichtung aufgefordert; aufschieben lässt sich das nur um jeweils 2 Tage.
• Begrenzung von Fehlversuchen: 5 je IP und Benutzername in 10 Minuten (auch beim zweiten Faktor); PIN: 5 Versuche in 5 Minuten.
• Sitzungs-Token zufällig (256 Bit), serverseitig gespeichert, 30 Tage gültig; Cookie HttpOnly, SameSite=Lax, Secure.
• Bildschirmsperre mit PIN und automatische Sperre nach Inaktivität (Standard 15 Minuten).
• E-Mail-Bestätigung vor der ersten Anmeldung; Passwort-Zurücksetzen per Link (1 Stunde gültig), das alle Sitzungen beendet; Registrierung nur mit Einladungscode; Begrenzung je IP und E-Mail; Antworten, die nicht verraten, ob ein Konto existiert.

1.3 Zugriff (Berechtigungen)

• Rollen in der Anwendung (Administrator, Benutzer). Vertrauliche Inhalte (Protokolle, Nächste Schritte, KI-Zusammenfassungen, E-Mail-Texte, vertrauliche Berichte) sieht nur die zuständige Berater:in; Administratoren erhalten dadurch keinen zusätzlichen Lesezugriff; gesperrte Inhalte werden nicht an den Browser gesendet.
• Das Öffnen vertraulicher Inhalte wird protokolliert.
• Anonymisierungsmodus für Bildschirmfreigaben (verbirgt Namen, Kontaktdaten, Texte).
• Betreiber-Konsole ohne Zugriff auf Mandanteninhalte (getestet); jede Betreiber-Aktion im Plattform-Protokoll.

1.4 Trennung (Mandanten)

• Jeder Mandant hat eine eigene Datenbankdatei und einen eigenen Dokumentenordner. Die Zuordnung erfolgt bei der Anmeldung; Anfragen eines Mandanten öffnen nur dessen Datenbank. Zentrale Plattform-Datenbank nur für Konten, Einladungen, Feedback.
• Die bestehende AJOUR-Instanz läuft als getrennter Dienst mit eigenem Speicher; keine gemeinsamen Daten.

1.5 Verschlüsselung und Pseudonymisierung

• Transport: HTTPS (TLS) für alle Verbindungen zwischen Browser, Cloudflare und Server.
• Datenbank, Dokumente samt allen Vorschauen, Papierkorb, E-Mail-Anhänge in Warteschlange, eingegangene E-Mails, Feedback-Bildschirmfotos und Sicherungen jedes Mandanten verschlüsselt gespeichert: Datenbanken mit SQLCipher (AES-256, Seiten-HMAC), Dateien mit AES-256-GCM, je Datei ein eigener Schlüssel. Jeder Mandant hat einen eigenen Schlüssel; die Mandantenschlüssel (und der Schlüssel der Plattform-Datenbank) sind mit zwei Hauptschlüsseln verschlüsselt, die nicht auf dem Daten-Volume liegen: Hauptschlüssel A als Geheimnis der Server-Konfiguration, Notfallschlüssel B als Schlüsselpaar, dessen privater Teil nur offline im Safe des Betreibers liegt (der Server kennt nur den öffentlichen Teil und kann damit nichts entschlüsseln). Ohne passenden Schlüssel A startet die Anwendung nicht. Ein Rohabzug des Volumes enthält nachweislich keine lesbaren Klientendaten (Prüfung im Umstellungsbericht und im Probelauf).
• Verlust von Schlüssel A: Wiederherstellung allein mit Notfallschlüssel B (neuer Schlüssel A, Daten unverändert), erprobt. Verlust von A und B bedeutet Verlust aller Daten.
• Klartext entsteht nur im Arbeitsspeicher bzw. für Umwandlungen (LibreOffice, Vorschauen) in einem flüchtigen Speicherbereich (tmpfs, 512 MB), der sofort geleert wird; nie auf dem Daten-Volume.
• Zugangsdaten zusätzlich verschlüsselt (innerhalb der verschlüsselten Datenbank): Passwörter von E-Mail-Konten, Zwei-Faktor-Geheimnisse, KI-API-Schlüssel; werden nie an den Browser ausgeliefert. Sitzungs-Tokens nur als Hash gespeichert.
• Lokale Entwürfe im Browser mit AES-GCM verschlüsselt (Schlüssel je Benutzer vom Server abgeleitet, nur im Arbeitsspeicher).
• Inhalte mit dem Schlüssel der Beraterin (Einzelkonten ohne Team): Protokolle, Notizen, Nachrichten, KI-Ergebnisse, Anmerkungen, Aufgaben, Preise, Zahlungen und Dokumente sind zusätzlich mit einem Schlüssel verschlüsselt, der aus ihrem Passwort entsteht (Argon2id) bzw. mit ihrem Notfall-Kit geöffnet wird. Weder Administrator:innen noch der Betreiber noch die Hauptschlüssel A/B öffnen ihn; ein Passwort-Reset gibt keinen Zugang zu alten Inhalten. Damit ein Server-Neustart nicht erneut nach dem Passwort fragt, liegt für eine laufende Anmeldung (höchstens 30 Tage, endet mit Abmelden oder Passwort-Reset) eine Kopie in der Datenbank, verschlüsselt mit einem Zufallsgeheimnis, das nur der Browser der Beraterin hat (Cookie, nicht per Skript lesbar); der Server speichert und protokolliert es nie, Mandanten- und Hauptschlüssel öffnen die Kopie nicht. Geöffnet ist der Schlüssel nur während der Server eine Anfrage von ihr bearbeitet (im Arbeitsspeicher, danach verworfen). KI-Aufträge erhalten nur den jeweils nötigen Text (Auftragsumschlag), nie den Schlüssel.
• [Grenze] Namen, Kontaktdaten und Termine sind nur mit dem Mandantenschlüssel verschlüsselt (für Erinnerungen und E-Mails ohne Anmeldung nötig). Wer den laufenden Server kontrolliert oder den Code ändert, kann Schlüssel angemeldeter Nutzer:innen erreichen. E-Mails an Klient:innen laufen unverschlüsselt über Mailgun; Cloudflare sieht den Datenverkehr.
• KI-Vorschläge für Suchprofile und Angebote: vor der Übermittlung werden Namen, E-Mail-Adressen, Telefonnummern, Sozialversicherungsnummern, IBAN, Geburtsdaten und Adressen aus dem Text entfernt.
• [Grenze] KI-Zusammenfassungen von Protokollen: der Protokolltext geht so, wie er geschrieben wurde, an den von der Nutzerin gewählten Anbieter (Namen darin werden nicht automatisch entfernt); darauf weist der Antrag hin.
• Kalender-Links zeigen standardmäßig nur „Klient #Nummer“; Tokens werden nur als Hash gespeichert.

2. Integrität (Art. 32 Abs. 1 lit. b)

2.1 Weitergabe

• [zum Start] E-Mails an Klient:innen und Plattform-E-Mails über Mailgun (EU-Region) mit TLS; Absenderdomain coachdesk.at mit SPF, DKIM und DMARC. Vorschau vor dem Senden und 10 Sekunden Widerrufsmöglichkeit .
• KI-Übermittlung nur nach ausdrücklicher Zustimmung je Endpunkt und Modell; nur an HTTPS-Endpunkte mit geprüftem Zertifikat, ohne Weiterleitungen, nur an öffentliche Adressen (Schutz gegen SSRF).
• KI-Funktionen standardmäßig aus; Freischaltung nur auf begründeten Antrag durch den Betreiber.
• Datei-Uploads: Typprüfung nach Inhalt, keine HTML/SVG, max. 25 MB, Schutz gegen Zip-Bomben; Vorschauen in einer Sandbox (Content-Security-Policy) ausgeliefert.
• Sicherheits-Header: Content-Security-Policy (nur Skripte vom eigenen Server, keine fremden Quellen), Schutz gegen Einbetten in fremde Seiten (X-Frame-Options, frame-ancestors), HSTS, Referrer-Policy, Permissions-Policy.
• Schutz gegen Cross-Site-Request-Forgery: Cookie SameSite=Lax und Prüfung der Herkunft (Origin) jeder ändernden Anfrage; Anfragen aus fremder Herkunft werden abgelehnt.

2.2 Eingabekontrolle

• Änderungsprotokoll: jede ändernde Aktion mit Zeitpunkt, Benutzer, Objekt und Feldänderungen; nur anhängend, Zusammenfassungen ohne Klientennamen; aufbewahrt, solange das Konto besteht.

3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b, c)

• SQLite im WAL-Modus; automatische Sicherung der Datenbank vor jeder Migration, jedem Import und jedem Löschen einer Akte.
• [zum Start] Tägliche Sicherung je Mandant (Datenbank und Dokumente), verschlüsselt, auf eine Hetzner Storage Box in Helsinki, getrennt vom Anwendungsserver; Aufbewahrung 30 Tage.
• [zum Start] Erreichbarkeitsprüfung über Cloudflare mit Alarm an den Betreiber.
• Registrierung nur mit Einladungscode, Einladungen je Konto begrenzt (5 je Woche).
• [zum Start] Speicherkontingent je Mandant.
• Gelöschte Dokumente liegen bis zum Leeren in einem Papierkorb.

4. Wiederherstellung (Art. 32 Abs. 1 lit. c)

• Wiederherstellung aus Datenbank-Sicherungen; Probelauf mit einer Kopie der Daten vor jeder Auslieferung.
• Wiederherstellung ohne Hauptschlüssel A, nur mit Notfallschlüssel B: erprobt (automatischer Test und an einer Kopie der AJOUR-Daten).
• [zum Start] Dokumentierte Wiederherstellungsprobe eines Mandanten aus der verschlüsselten Off-Site-Sicherung.

5. Überprüfung und Bewertung (Art. 32 Abs. 1 lit. d)

• Automatische Tests und Probelauf (scripts/smoke_rehearsal.py) vor jeder Auslieferung; Schema-Änderungen nur über versionierte Migrationen.
• Dieses Blatt wird bei jeder wesentlichen Änderung, mindestens jährlich, überprüft.

6. Organisatorisch

• Ein Systemadministrator (Betreiber), zur Verschwiegenheit verpflichtet (§ 6 DSG).
• Ablauf bei Datenschutzverletzungen: Erkennen → Eindämmen → Meldung an betroffene Auftraggeber:innen spätestens 24 Stunden nach Kenntnis → Dokumentation.
• Löschkonzept: Konto-Löschung mit 14 Tagen Frist, danach Mandant samt Schlüssel vollständig gelöscht; Sicherungen laufen nach 30 Tagen aus; Server-Protokolle 14 Tage; Feedback längstens 30 Tage.
• Keine Tracker, keine Analysewerkzeuge, keine Inhalte von Drittservern in der Anwendung.

7. Offene Punkte zum Start

1. Passwortregel nur Mindestlänge 8 Zeichen.
2. Vertretung des Betreibers. Ein Administrator; Hauptschlüssel B liegt im Safe des Betreibers, eine Vertretung bei Ausfall (Zugang zu Schlüssel und Systemen) ist nicht geregelt.