Architektur in Kürze: Sämtliche Verarbeitung der Inhaltsdaten erfolgt auf dedizierten Servern in Deutschland (IONOS, Standort Karlsruhe/Frankfurt). Die Anwendung ist self-hosted; eine Auslagerung der Datenbank oder des Object-Storage in eine Public Cloud findet nicht statt. Drittlandtransfers sind auf wenige eng eingegrenzte Subprocessor-Zwecke beschränkt (siehe Anhang 2).
Gliederung
- Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)
- Integrität (Art. 32 Abs. 1 lit. b DSGVO)
- Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b und c DSGVO)
- Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung (Art. 32 Abs. 1 lit. d DSGVO)
- Pseudonymisierung und Verschlüsselung (Art. 32 Abs. 1 lit. a DSGVO)
- Datenschutzfreundliche Voreinstellungen (Art. 25 DSGVO)
§ 1 Vertraulichkeit
1.1 Zutrittskontrolle (physisch)
- Server-Hosting in einem deutschen Rechenzentrum des Hosting-Anbieters IONOS. Die vom Hosting-Anbieter beworbene Tier-Klassifizierung sowie die Zertifizierungsnachweise (u. a. ISO 27001) sind den jeweils aktuellen Datenblättern des Anbieters unter www.ionos.de zu entnehmen.
- Physische Zutrittskontrolle, Videoüberwachung, Zugangssicherung und Brandschutz werden gemäß den Anbieter-Eigenangaben durch IONOS sichergestellt. Eigene Audit-Begehung durch den Auftragsverarbeiter findet nicht statt.
- Kein Zutritt unbefugter Personen zum Hostsystem durch den Auftragsverarbeiter selbst (kein on-prem Server beim Auftragsverarbeiter).
- AVV mit IONOS gem. Art. 28 DSGVO ist abgeschlossen und liegt beim Auftragsverarbeiter vor.
1.2 Zugangskontrolle (System)
- SSH-Zugang ausschließlich über Public-Key-Authentifizierung (Ed25519 / RSA ≥ 4096 Bit). Konkret in
sshd_config: PasswordAuthentication no, ChallengeResponseAuthentication no, PermitRootLogin prohibit-password, PubkeyAuthentication yes.
- SSH-Port abweichend vom Standard-Port (22).
- fail2ban aktiv: automatische IP-Sperre nach mehrfach fehlgeschlagenen Authentifizierungsversuchen (Default-Jail
sshd aktiv).
- firewalld als Host-Firewall: ausschließlich die Ports 80 (HTTP-Redirect → HTTPS), 443 (HTTPS) und der konfigurierte SSH-Port sind freigegeben.
- SELinux im enforcing-Modus auf Betriebssystem-Ebene (AlmaLinux 9).
- Anwendungs-Admin-Bereich (
/admin/) ist durch HTTP-Basic-Auth geschützt; Zugangsdaten sind auf den Inhaber beschränkt. Zusätzlich ist eine zweite Stufe TOTP-2FA (RFC 6238, 6 Stellen, 30s-Periode) implementiert (otplib + qrcode); Aktivierung über Konfigurations-Flag ADMIN_TOTP_ENABLED=true nebst AES-256-GCM-verschlüsseltem TOTP-Secret. 8 Recovery-Codes (SHA-256-gehashed, einmal-nutzbar) für Geräteverlust; Lockout nach 5 falschen Versuchen für 15 Min. Audit-Events: admin.totp.success, admin.totp.fail, admin.session.revoked.
- Webhook-Endpunkte (Mollie, Synthflow, Cal.com) durch zeitkonstanten Token-Vergleich abgesichert (
timingSafeEqual).
- Follow-up-Formulare nutzen einmalig vergebene URL-Tokens mit Ablaufdatum.
1.3 Zugriffskontrolle (Daten)
- Datenbankzugriff ausschließlich über die Anwendung; kein direkter Datenbankzugriff aus dem öffentlichen Netz.
- PostgreSQL bindet ausschließlich an
127.0.0.1; Verbindung über lokale Unix-Socket / Loopback.
- Object-Storage (MinIO) ebenfalls lokal; S3-API nur intern erreichbar.
- Trennung von DB-Benutzern: ein Owner-User ausschließlich für Migrationen (DDL); ein Anwendungs-User mit eingeschränkten Rechten (SELECT/INSERT/UPDATE auf definierten Tabellen, kein DROP/TRUNCATE/DDL) für den Regelbetrieb der Anwendung.
- Audit-Trail: Sicherheitsrelevante Aktionen (Buchungs-Erstellung, Status-Änderungen, Mail-Versand, manuelle Eingriffe, Admin-Logins) werden in einer Tabelle
audit_events mit Zeitstempel und Auslöser revisionssicher gespeichert. Manipulationssicherheit auf zwei Ebenen: (a) PostgreSQL-Rules blockieren UPDATE und DELETE auf der Tabelle (DO INSTEAD NOTHING); (b) jeder Eintrag enthält eine Hash-Chain (row_hash = SHA-256(prev_hash || id || created_at || event_type || actor || detail)), sodass nachträgliche Eingriffe über die Verifikations-View v_audit_chain_check nachweisbar werden.
1.4 Trennungskontrolle
- Logische Trennung der Datensätze über Buchungs-IDs (UUID v4); jede Buchung ist eindeutig referenziert.
- Trennung Test-/Entwicklungs-Umgebung von Produktion; keine Echtdaten in Entwicklungs-Umgebungen.
- Trennung von Stammdaten, Inhaltsdaten und Rechnungsdaten in separaten Tabellen mit unterschiedlichen Aufbewahrungsfristen (siehe AVV § 12).
§ 2 Integrität
2.1 Weitergabekontrolle (Verschlüsselung in der Übertragung)
- Sämtliche externe Kommunikation ausschließlich über TLS 1.2 oder TLS 1.3. Die nginx-Konfiguration orientiert sich am Intermediate-Profil des Mozilla SSL Configuration Generator (Stand 04/2026); der Wechsel auf Modern-Profil (TLS 1.3 only) ist als Roadmap-Item vorgesehen, sobald keine TLS 1.2-Clients mehr unterstützt werden müssen.
- HTTP-Strict-Transport-Security (HSTS) mit
max-age=31536000; includeSubDomains.
- Let's-Encrypt-Zertifikate mit automatischer Erneuerung.
- Kein HTTP-Fallback; HTTP-Anfragen werden auf HTTPS umgeleitet.
- Header zur Härtung:
X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (geolocation/microphone/camera disabled).
- Rate-Limiting auf Webserver-Ebene (nginx) und in der Anwendung (Fastify) gegen Missbrauch.
2.2 Eingabekontrolle
- Schema-basierte Validierung aller eingehenden Daten (Zod-Schemata).
- Body-Limit (≤ 5 MB Standard, ≤ 20 MB für Follow-up-Uploads); Schutz gegen DoS durch übergroße Anfragen.
- Content-Security-Policy auf HTML-Seiten zur Eindämmung von XSS-Angriffen.
- SQL-Injection-Schutz durch Parameter-bound Queries (postgres-js Template-Strings).
- Eingabe-Sanitisierung in HTML-Ausgaben (Escape-Funktionen).
§ 3 Verfügbarkeit und Belastbarkeit
3.1 Verfügbarkeitskontrolle
- Prozess-Manager (pm2) mit automatischem Neustart bei Fehlern; Health-Endpoints (
/health, /health/ready).
- Hosting-Anbieter mit redundanter Strom-/Netz-Anbindung gemäß Anbieter-SLA.
- USV / Notstromsystem im Rechenzentrum durch den Hoster gemäß Anbieter-Eigenangaben.
- Cron-basierte Retention-Jobs zur Bereinigung abgelaufener Daten – auch Verfügbarkeits-relevant (Speicherüberlauf-Prävention).
3.2 Datensicherung
- Tägliche Backups der PostgreSQL-Datenbank (logische Dumps), Aufbewahrung 14 Tage rollierend.
- Snapshot-Backups bei größeren Deploys mit SHA-256-Manifest zur Integritätsprüfung.
- Backup-Verschlüsselung: PostgreSQL-Dumps werden vor Speicherung mit
age (X25519, AES-256-GCM) verschlüsselt. Der Public-Key des Recipients liegt auf dem Server; der zugehörige Identity-Key (Private-Key) wird ausschließlich offline beim Inhaber aufbewahrt und gelangt nicht auf den Produktiv-Server. Skript: /usr/local/bin/annie-backup-encrypted.sh (täglich via systemd-Timer); Retention 14 Tage rollierend.
- Eine zusätzliche Off-Site-Replikation der Backups auf einem dritten externen Cloud-Speicher findet bewusst nicht statt, um die Subprocessor-Kette schlank und nachvollziehbar zu halten. Schutz gegen Verlust des Primär-Hosts erfolgt durch Hosting in einem Tier-III-zertifizierten Rechenzentrum mit eigener redundanter Strom-/Netz-Anbindung sowie durch periodische lokale Snapshot-Kopien auf einem unabhängigen Datenträger im Rahmen der vom Inhaber durchgeführten Wartungsfenster.
- Backup-Tests werden monatlich automatisiert ausgeführt (systemd-Timer
annie-backup-restore-test.timer, OnCalendar=*-*-01 03:00:00); Skript stellt die letzte Sicherung in eine Wegwerfdatenbank ein und verifiziert Tabellen-Existenz; Ergebnis in /var/log/annie-restore-test.log. Vierteljährlich zusätzlich manueller Volltest.
3.3 Wiederherstellbarkeit
- Ziel-RTO (Recovery-Time-Objective): 24 Stunden für vollständigen System-Wiederaufbau im Regelbetrieb (werktags innerhalb üblicher Geschäftszeiten). Hierbei handelt es sich um eine Zielvorgabe, nicht um eine SLA-Garantie.
- Ziel-RPO (Recovery-Point-Objective): 24 Stunden (letztes vollständiges Backup) bzw. genauer bei aktivem WAL-Archiving. Hierbei handelt es sich um eine Zielvorgabe, nicht um eine SLA-Garantie.
- Dokumentierte Deploy-Prozedur, die einen Wiederaufbau aus dem Quellcode in nachvollziehbaren Schritten erlaubt.
§ 4 Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung
- Zentrale Konfigurations-Verwaltung des nginx-Servers; Konfig-Änderungen sind versioniert und dokumentiert.
- Server-Logging in
/var/log/nginx/ (Access + Error) und Anwendungs-Logs über pino (strukturiertes JSON-Logging).
- Sicherheits-Monitoring: regelmäßige Prüfung der fail2ban-Logs, der Anwendungs-Audit-Logs und der Zugriffsverläufe.
- Patch-Management:
dnf-basierte Sicherheits-Updates über dnf-automatic für sicherheitsrelevante Updates wöchentlich; sicherheitskritische Patches mit CVE-Bezug werden zeitnah eingespielt (Zielvorgabe, keine SLA-Garantie).
- Dependency-Management: Node.js-Pakete mit pnpm/lockfile-pinning; regelmäßiger Abgleich mit Schwachstellen-Datenbanken (npm audit / GitHub Advisories).
- DSFA-Unterstützung: Die Pflicht zur Durchführung einer Datenschutz-Folgenabschätzung trifft den Auftraggeber als Verantwortlichen (Art. 35 DSGVO). Der Auftragsverarbeiter stellt zur Erfüllung dieser AG-Pflicht auf Anforderung eine strukturierte Inputs-Vorlage bereit (Verarbeitungs-Beschreibung, Risikobewertung der KI-Komponente, Subprocessor-Kette mit Drittlandbezug, eingesetzte TOM, Restrisiko-Bewertung). Eine eigene DSFA für die 365tec-interne Verarbeitung wird, soweit nach Art. 35 Abs. 1 erforderlich, vom Auftragsverarbeiter geführt.
- Auftragskontrolle: Subprocessor-Liste (Anhang 2) wird bei jeder Änderung den Auftraggebern mit 30 Tagen Vorlauf in Textform mitgeteilt (siehe AVV § 8 Abs. 2).
- Mitarbeiter-Sensibilisierung: Da der Auftragsverarbeiter als Einzelunternehmer geführt wird, beschränkt sich die Sensibilisierung auf den Inhaber. Bei künftiger Erweiterung auf Mitarbeiter wird eine Verpflichtungserklärung auf Vertraulichkeit (Art. 28 Abs. 3 lit. b DSGVO; bei C1-Branchen zusätzlich § 203 Abs. 4 StGB) eingeholt.
- AI Literacy (EU AI Act Art. 4): Der Inhaber des Auftragsverarbeiters bildet sich laufend zu KI-Anwendungen, deren Risiken und der zugrundeliegenden Modelle weiter; die Schulungen werden formlos dokumentiert. Auftraggeber werden auf ihre eigene AI-Literacy-Pflicht hingewiesen.
§ 5 Pseudonymisierung und Verschlüsselung
5.1 Pseudonymisierung
- Buchungen werden ausschließlich über UUID-Identifikatoren referenziert; keine sequenziellen, ratbaren IDs.
- Audio-Dateien werden im Object-Storage unter einem UUID-basierten Schlüssel abgelegt; Klar-Dateinamen mit personenbezogenem Inhalt werden vermieden.
- In der Buchungsbestätigung wird die Buchungs-ID kommuniziert, sie ersetzt namentliche Identifikatoren in technischen Logs.
- Hinweis zur PII-Maskierung vor Drittland-Übermittlung: Strukturierte PII-Maskierung (PHONE / EMAIL / IBAN / TAX_ID / DOB) via Regex ist implementiert und nutzt eine eigene Mapping-Tabelle
pii_mappings (booking-scoped, ON-DELETE-CASCADE; Token-Format TYPE_NNN). Eine NER-basierte Erweiterung für Eigennamen/Organisationen/Orte (PERSON/ORG/LOC) ist als internes Roadmap-Item dokumentiert (ohne fixe Zeitleiste); ein Hook im Service ist vorbereitet. Bis NER produktiv ist, wirken Datenminimierung und das Pre-Call-Fact-Sheet als kompensatorische Maßnahmen.
5.2 Verschlüsselung
- Transport: TLS 1.2/1.3 für alle externen Verbindungen (Anwendung <-> Browser, Anwendung <-> Mollie/Synthflow/Anthropic-API).
- Datenbank-Verbindungen: über localhost / Unix-Socket – kein Drittland-Routing.
- Object-Storage (MinIO): Server-Side-Encryption (SSE-S3, AES-256) auf Bucket-Ebene aktiviert.
- Backup-Verschlüsselung: Datenbank-Dumps und Snapshot-Backups werden mit GPG / age (AES-256) verschlüsselt (siehe § 3.2).
- Festplatten-Verschlüsselung at rest: Eine eigenaktive Verschlüsselung der OS-Festplatten (dm-crypt/LUKS) ist nicht aktiviert. Begründung: Bei einem unbeaufsichtigten Reboot wäre manuelles Eingreifen zum Entsperren erforderlich, was die Wiederanlaufzeit erheblich verlängert. Schutz erfolgt durch (a) physische Zutrittskontrolle des Hosters gemäß dessen AVV, (b) vertraglich zugesicherte Wipe-Verfahren bei Disk-Tausch durch den Hoster, (c) anwendungsseitige Verschlüsselung sensibler Speicherbereiche (MinIO-SSE, Backup-GPG/age). Die Risikoabwägung wird im Rahmen der eigenen Verarbeitungs-Risikobewertung dokumentiert.
- Secrets: Anwendungs-Secrets (Tokens, API-Keys) liegen ausschließlich in
.env-Dateien mit Datei-Berechtigungen 0600; sie werden nicht im Repository committet und nicht in Logs ausgegeben.
- Cookie-Signierung: Admin-Session-Cookies werden mit einem zufälligen, mindestens 256-Bit-langen Geheimnis signiert.
§ 6 Datenschutzfreundliche Voreinstellungen (Privacy by Default)
- Aufzeichnung der Telefongespräche erfolgt nur nach ausdrücklichem akustischen Hinweis am Gesprächsanfang und mit Einwilligung des Anrufers (Transparenzpflicht EU AI Act Art. 50).
- Sprachaufzeichnungen werden nach 30 Tagen automatisiert gelöscht; nur das Transkript verbleibt bis Tag 90 (siehe AVV § 12).
- Im Telefoninterview vermeidet die KI-Assistenz aktiv die Erfassung von Berufsgeheimnis-Daten (Mandanten-/Patientennamen, konkrete Falldetails) durch entsprechende Gesprächsführung und Stopp-Hinweise. Wichtig: Die anwendungsseitige Stopp-/Lösch-Funktion entfernt entsprechende Audio-Segmente bei 365tec; eine vollständige Löschung bei US-Subprocessoren (Twilio, Synthflow) erfolgt im Rahmen der dort geltenden Retention-Policy.
- Cookies auf der Bestell-Seite: technisch notwendige Cookies; keine Tracking-Cookies, kein Cross-Site-Tracking.
- Keine Verwendung von Inhaltsdaten für KI-Modell-Training durch den Auftragsverarbeiter selbst. Zur Verwendungs-Praxis der Subprocessoren (Anthropic, Synthflow, Twilio) siehe Anhang 2 mit jeweils anbieter-spezifischer Aussage.
Stand und Aktualisierung
Diese TOM-Beschreibung wird mindestens jährlich überprüft und bei wesentlichen Änderungen der eingesetzten Technik oder Organisation aktualisiert. Eine aktuelle Fassung wird auf https://365tec.de/legal/avv-tom.html bereitgestellt.