Anlage 2 zum AVV Cento: Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

Auftragsverarbeiter: Vanturis UG (haftungsbeschränkt), Hintergasse 12, 55237 Flonheim

Version: 0.1 (Entwurf). Änderungshistorie am Ende.

0. Schutzbedarf und Architekturüberblick

Schutzbedarf: hoch für Vertraulichkeit und Integrität (Bankdaten, Steuerdaten, Daten nach Art. 9 DSGVO, Buchführungsdaten mit GoBD-Anforderungen an Unveränderbarkeit), normal bis hoch für Verfügbarkeit (Fristen bei Steueranmeldungen).

Architektur in Kurzform:

• Anwendung als Container auf dedizierten bzw. Cloud-Servern der Hetzner Online GmbH in Deutschland (Nürnberg/Falkenstein), orchestriert über Coolify, Reverse Proxy Traefik.
• Datenbank PostgreSQL mit Row-Level Security (RLS) je Mandant.
• Dateiablage (Belege) im Objektspeicher, serverseitig vor dem Schreiben verschlüsselt.
• Schlüsseldienst OpenBao (Transit-Engine) als eigener Dienst.
• Backups in Hetzner Object Storage an einem zweiten Standort mit Object Lock.
• Administrativer Zugang ausschließlich über Zero-Trust-Tunnel (Pangolin/WireGuard), keine offenen SSH-Ports im Internet.
• Selbst gehostete Hilfsdienste: Stalwart (Mail), GlitchTip (Fehler), ClamAV (Virenprüfung). Support-Tickets laufen im eigenen Support-Modul von Cento, Produktanalyse nur serverseitig und aggregiert.

1. Vertraulichkeit: Zutrittskontrolle

Ziel: Unbefugte erhalten keinen physischen Zutritt zu Datenverarbeitungsanlagen. [INF.2 Rechenzentrum, OPS.2.2 Cloud-Nutzung]

2. Vertraulichkeit: Zugangskontrolle

Ziel: Datenverarbeitungssysteme können nicht von Unbefugten genutzt werden. [ORP.4 Identitäts- und Berechtigungsmanagement, SYS.1.1 Allgemeiner Server]

Kunden und deren Nutzer

• Pflicht zur Zwei-Faktor-Authentifizierung für alle Nutzer. Ein Passkey (WebAuthn/FIDO2) mit Nutzerverifikation (userVerification: required) zählt allein als starke Anmeldung und wird beim Onboarding als Standard angeboten. Bei Anmeldung per Passwort oder Social Login ist zusätzlich ein Passkey oder eine TOTP-App erforderlich. SMS ist nicht zulässig.
• Passkey-only-Login möglich. Passwörter, sofern genutzt: Mindestlänge 12 Zeichen, Prüfung gegen Listen kompromittierter Passwörter (k-Anonymity-Abfrage oder lokale Liste), Hash mit Argon2id.
• Schutz gegen Brute Force: Ratenbegrenzung je Konto und IP, schrittweise Verzögerung, Benachrichtigung bei Anmeldung von neuem Gerät.
• Bot-Schutz bei der Registrierung: datenschutzfreundliches Proof-of-Work-Verfahren, selbst gehostet (z. B. ALTCHA). [PRÜFEN]
• Sitzungen: sichere, HttpOnly-, SameSite-Cookies; Inaktivitäts-Timeout 30 Minuten, absolute Sitzungsdauer 12 Stunden; Abmeldung aller Sitzungen durch Nutzer möglich.
• Wiederherstellungscodes einmalig nutzbar; Zurücksetzen der 2FA nur nach Identitätsprüfung und mit Benachrichtigung aller Administratoren des Mandanten.

Personal von Vanturis

• Administrativer Zugang zu Servern nur über Zero-Trust-Tunnel (Pangolin/WireGuard) mit personenbezogenen Konten; SSH ausschließlich mit Hardware-gebundenen Schlüsseln (FIDO2/ed25519-sk), Passwort-Login deaktiviert.
• Zwei-Faktor-Authentifizierung für alle Verwaltungsoberflächen (Coolify, Hetzner-Konsole, AWS, Stripe, Git-Hosting, Cento-Backoffice, GlitchTip, Passwortmanager).
• Root-Konten von Hetzner und AWS nur für Notfälle, Zugangsdaten im Tresor (Vier-Augen-Prinzip [PRÜFEN]).
• Geräte des Personals: vollständige Datenträgerverschlüsselung, automatische Updates, Bildschirmsperre, Endpoint-Schutz.
• Passwortmanager mit Ende-zu-Ende-Verschlüsselung für Zugangsdaten.

3. Vertraulichkeit: Zugriffskontrolle

Ziel: Berechtigte haben nur Zugriff auf die Daten, die ihrer Berechtigung unterliegen. [ORP.4, APP.4.3 Relationale Datenbanken, CON.1 Kryptokonzept]

Rollen in Cento (RBAC)

• Bereich „Private Steuerdaten (Einkommensteuer)" ist ein gesondertes Recht, standardmäßig nur für den Inhaber.
• Berechtigungsänderungen werden im Audit-Log erfasst.

Datenbank

• PostgreSQL Row-Level Security: Jede Tabelle mit Mandantendaten trägt eine Mandanten-ID; Policies erzwingen, dass eine Sitzung nur Zeilen des gesetzten Mandanten sieht. Die Anwendung verbindet sich mit einer Rolle ohne BYPASSRLS. Migrationen laufen unter einer gesonderten Rolle.
• Automatisierte Tests prüfen für jede Tabelle, dass RLS aktiv ist und mandantenfremde Zugriffe scheitern (CI-Pflichttest).
• Keine direkten Datenbankzugriffe durch Personal im Regelbetrieb. Notfallzugriff nur über protokollierten Break-Glass-Prozess mit Begründung und nachträglicher Benachrichtigung des Kunden bei Zugriff auf Inhalte.

Support-Zugriff

• Personal sieht Mandanteninhalte nur nach zeitlich befristeter Freigabe je Mandant (Standard 72 Stunden, widerruflich). Freigeben dürfen nur dazu berechtigte Mitglieder, standardmäßig der Inhaber des Mandanten; der Nachweis der Freigabe bleibt auch nach Löschung des Mandanten erhalten. Zugriff erfolgt ausschließlich über eine Backoffice-Sitzung mit eigener Kennung und eigener Datenbankrolle, keine Anmeldung als Kundennutzer (keine Impersonation); jede Aktion wird im Audit-Log des Mandanten als Support-Aktion gekennzeichnet.
• Ohne Freigabe nur bei Störung, vom Kunden beauftragter Wiederherstellung, gesetzlicher Pflicht oder Break-Glass; immer protokolliert, der Kunde wird benachrichtigt.
• Für Einkommensteuer-Daten und Art. 9-Felder ist eine gesonderte Freigabe erforderlich.

Verschlüsselung und Schlüsselverwaltung [CON.1]

• Datenträgerverschlüsselung (LUKS2, AES-256-XTS) für alle Server-Volumes mit Kundendaten. [PRÜFEN] bei Cloud-Volumes
• Envelope-Encryption für Bank-Secrets (Qonto-Tokens, Tokens des Kontoinformationsdienstes), TOTP-Secrets, Art. 9-Felder und Belegdateien:
• Daten werden mit einem Datenschlüssel (DEK, AES-256-GCM) verschlüsselt.
• DEKs sind je Mandant und Datenkategorie getrennt, für Art. 9-Daten je Person, und mit einem Schlüsselverschlüsselungsschlüssel (KEK) verschlüsselt.
• Der KEK liegt nicht in der Datenbank und nicht in Konfigurationsdateien, sondern im getrennten Schlüsseldienst OpenBao (Transit-Engine), und wird nicht ins Backup der Datenbank aufgenommen; Unseal-Schlüssel nach Shamir aufgeteilt (Vier-Augen-Prinzip), KEK-Sicherung getrennt und offline. [PRÜFEN]
• Rotation des KEK mindestens jährlich und anlassbezogen; Neuverschlüsselung der DEKs ohne Neuverschlüsselung der Nutzdaten.
• Löschung eines Mandanten vernichtet dessen DEKs (kryptografische Löschung, auch wirksam für Backups).
• FinTS-PIN: wird nie gespeichert; Eingabe je Abruf.
• Hetzner Object Storage bietet keine standardmäßige Verschlüsselung ruhender Daten. Belegdateien werden daher von Cento serverseitig vor dem Schreiben in den Objektspeicher verschlüsselt (AES-256-GCM; Reihenfolge: Virenprüfung, SHA-256 über den Klartext, Verschlüsselung), nicht im Browser. Backups werden vor dem Upload verschlüsselt (z. B. mit restic/age).

4. Weitergabekontrolle (Integrität und Vertraulichkeit bei Übertragung)

Ziel: Daten können bei Übertragung oder Transport nicht unbefugt gelesen, kopiert, verändert oder entfernt werden. [NET.1.1, CON.1, APP.3.1 Webanwendungen]

• TLS 1.2 und 1.3 nach BSI TR-02102-2, nur Cipher Suites mit Forward Secrecy; HSTS mit Preload; TLS 1.0/1.1 deaktiviert. Zertifikate über ACME mit automatischer Erneuerung.
• Interne Verbindungen zwischen Diensten auf getrennten Hosts verschlüsselt (WireGuard bzw. TLS); Datenbank nicht aus dem Internet erreichbar.
• Verbindungen zu Unterauftragsverarbeitern (AWS Bedrock, Stripe) und Bank-Schnittstellen nur über TLS mit Zertifikatsprüfung.
• E-Mail-Versand: TLS erzwungen, wo der Empfänger es unterstützt (MTA-STS, DANE wo möglich); SPF, DKIM, DMARC. Benachrichtigungen enthalten keine Inhalte aus der Buchhaltung, nur einen Link in die Anwendung.
• Push-Benachrichtigungen (Apple APNs, Google FCM, Web Push): kein Inhalt, nur generischer Hinweis („Neue Aktivität in Cento") bzw. Ende-zu-Ende-verschlüsselte Nutzlast bei Web Push.
• Exporte als Download über authentifizierte, kurzlebige signierte Links (Gültigkeit 15 Minuten); keine Versendung von Exporten per E-Mail.
• Datenträger: keine Weitergabe physischer Datenträger. Austausch und Vernichtung defekter Festplatten durch das Rechenzentrum nach dessen zertifiziertem Verfahren; Daten darauf sind durch Datenträgerverschlüsselung geschützt.

5. Eingabekontrolle (Nachvollziehbarkeit)

Ziel: Es ist nachträglich feststellbar, wer welche Daten wann eingegeben, verändert oder entfernt hat. [OPS.1.1.5 Protokollierung, DER.1 Detektion]

• Audit-Log mit Hash-Kette je Mandant:
• Jeder Eintrag enthält Zeitstempel, handelnde Kennung (Nutzer, Support, System, API), Aktion, betroffenes Objekt, vorher/nachher (bei Buchungen), Quelle (IP gekürzt, Gerät).
• Jeder Eintrag enthält den SHA-256-Hash des vorherigen Eintrags; damit ist jede nachträgliche Änderung oder Löschung erkennbar.
• Kettenanker (aktueller Hash) wird täglich außerhalb der Datenbank gesichert, in einem eigenen Speicherbereich mit Object Lock im Compliance-Modus (nur Hashes und IDs, keine Inhalte). [PRÜFEN] Option: externer Zeitstempel nach RFC 3161.
• Täglich automatische Prüfung der Kette; Abweichungen lösen einen Sicherheitsalarm aus.
• Der Kunde kann das Audit-Log einsehen und exportieren.
• GoBD-Unveränderbarkeit: festgeschriebene Buchungen werden nicht geändert, sondern nur storniert; Belege werden nach Festschreibung nicht überschrieben (Versionierung). [GoBD Rz. 58 ff.]
• Administrative Aktionen des Personals (Deployments, Konfigurationsänderungen, Datenbankzugriffe) werden zentral protokolliert und 90 Tage aufbewahrt.
• Protokolldaten werden datensparsam geführt: keine Inhalte von Belegen, Passwörter, Tokens oder Art. 9-Daten in technischen Logs; automatische Filterung sensibler Felder in Fehlerberichten (GlitchTip before_send, Feld-Blacklist).

6. Auftragskontrolle

Ziel: Daten werden nur entsprechend den Weisungen des Kunden verarbeitet.

• Schriftlicher AVV mit jedem Kunden; Weisungen über Ticketsystem dokumentiert.
• Unterauftragsverarbeiter nur nach Prüfung von Sitz, Datenstandort, TOMs, Zertifizierungen und Übermittlungsgarantien; Dokumentation je Anbieter.
• Funktionen mit zusätzlichen Empfängern (KI, Bankverbindung) sind standardmäßig deaktiviert bzw. erfordern eine aktive Handlung des Kunden (Privacy by Default, Art. 25 Abs. 2 DSGVO).
• KI-Verarbeitung (AWS Bedrock):
• nur EU-Regionen bzw. EU-Inferenzprofile; globale Inferenzprofile sind technisch ausgeschlossen (IAM-Policy/SCP auf zugelassene Regionen) [PRÜFEN],
• Datenaufbewahrungsmodus „keine Aufbewahrung" konfiguriert, soweit für das Modell verfügbar; nur Modelle, die diesen Modus erlauben [PRÜFEN],
• keine Aufzeichnung von Prompts und Antworten im Invocation-Logging,
• Übermittlung nur der für die Aufgabe nötigen Daten (z. B. Belegtext ohne Bankverbindung, wo möglich),
• standardmäßig aus; Hauptschalter je Organisation (Aktivierung durch den Inhaber), zusätzlich je Mandant abschaltbar, Status im Audit-Log.

7. Verfügbarkeit und Belastbarkeit

Ziel: Daten sind gegen zufällige Zerstörung oder Verlust geschützt, Systeme sind belastbar und nach Vorfällen rasch wiederherstellbar. [CON.3 Datensicherungskonzept, DER.4 Notfallmanagement, OPS.1.1.3 Patch- und Änderungsmanagement]

Backups

• Datenbank: kontinuierliche WAL-Archivierung (Point-in-Time-Recovery) plus tägliches Voll-Backup.
• Belegdateien: tägliche Sicherung.
• Ziel: Hetzner Object Storage an einem anderen Standort als das Produktivsystem (z. B. Produktiv Nürnberg, Backup Falkenstein; beide Deutschland). [PRÜFEN] Standortwahl; Helsinki (Finnland, EU) nur als Ausweichoption.
• Verschlüsselung vor dem Upload (AES-256), Schlüssel getrennt vom Backup-Speicher.
• Object Lock (WORM) im Compliance-Modus mit Aufbewahrung 35 Tage, Versionierung aktiviert; Lifecycle-Regel löscht abgelaufene Versionen automatisch. Die Zugangsdaten des Backup-Systems erlauben nur Schreiben, kein Löschen. [PRÜFEN] Unterstützte Lock-Modi bei Hetzner verifizieren.
• Primärspeicher der Belege: Object Lock im Governance-Modus bis zum Ende der Aufbewahrungsfrist; aufheben kann ihn nur der Lösch-Job mit eigener Berechtigung. Bei Löschung eines Mandanten werden zuerst die DEKs vernichtet, dann Datensätze und Speicherpräfixe gelöscht. [PRÜFEN]
• Löschkonzept für Backups: siehe AVV § 12 Abs. 3 (eingeschränkte Verarbeitung, Tombstones bei Restore, kryptografische Löschung).

Wiederherstellung

• Restore-Test: monatlich automatisiert (Einspielen des letzten Backups in eine isolierte Umgebung, Integritätsprüfung, Prüfung der Audit-Hash-Kette), quartalsweise vollständiger, dokumentierter Wiederherstellungstest des Gesamtsystems mit Zeitmessung.
• Zielwerte: RPO ≤ 15 Minuten (Datenbank), ≤ 24 Stunden (Dateien); RTO ≤ 8 Stunden. [PRÜFEN]
• Wiederanlaufplan (Runbook) für Totalausfall eines Standorts.

Betrieb

• Überwachung von Verfügbarkeit, Ressourcen und Zertifikaten mit Alarmierung.
• Sicherheitsupdates für Betriebssystem und Container-Images: kritische innerhalb von 72 Stunden, sonstige innerhalb von 30 Tagen. Automatischer Abhängigkeits- und Container-Scan (z. B. Trivy, Dependabot/Renovate).
• Schutz vor Überlast: Ratenbegrenzung, Upload-Größenlimits, DDoS-Grundschutz des Rechenzentrums.
• Virenprüfung aller hochgeladenen Dateien (ClamAV, selbst gehostet); infizierte Dateien werden in Quarantäne genommen. Dateien werden nicht an externe Scan-Dienste gesendet.
• Redundante Stromversorgung, Klimatisierung, Brandschutz: durch das Rechenzentrum.

8. Trennungskontrolle

Ziel: Zu unterschiedlichen Zwecken oder für unterschiedliche Kunden erhobene Daten werden getrennt verarbeitet. [APP.4.3, SYS.1.6 Containerisierung]

• Logische Mandantentrennung durch RLS (Ziff. 3) und mandantenbezogene Schlüssel.
• Belegdateien in mandantenbezogenen Präfixen mit eigenen Schlüsseln; Zugriff nur über die Anwendung, nicht über öffentliche URLs.
• Getrennte Umgebungen für Entwicklung, Test und Produktion. Keine echten Kundendaten in Entwicklung oder Test; Testdaten werden synthetisch erzeugt. Ausnahme nur zur Fehleranalyse mit Freigabe des Kunden und in isolierter Umgebung mit Löschung nach Abschluss.
• Isolierte Container je Dienst; selbst gehostete Hilfsdienste (GlitchTip) in getrennten Netzen ohne Zugriff auf die Produktivdatenbank. Das Support-Modul ist Teil von Cento und unterliegt denselben Rechten, RLS-Regeln und Protokollen wie die übrige Anwendung.
• Daten, für die Vanturis Verantwortlicher ist (Abrechnung, Vertriebs-CRM), werden getrennt von Mandantendaten gehalten.
• Audit-Log des Mandanten gehört zu den Daten des Kunden und wird mit dem Mandanten exportiert und gelöscht.

9. Pseudonymisierung und Datenminimierung

• Produktanalyse nur serverseitig und aggregiert: kein Analyse-Skript im Browser oder in der App (auch nicht auf der Website), keine Inhalte, keine Klarnamen, keine Nutzerkennungen in den Auswertungen, keine A/B-Tests mit Kennung, kein Cross-Site-Tracking. Ereignisse nur zu Funktionsnutzung. [PRÜFEN]
• Fehlerberichte: Nutzer nur über pseudonyme ID; Request-Bodies und Formulardaten werden nicht übermittelt.
• Webserver-Logs: IP-Adressen nach 7 Tagen gekürzt, Löschung nach 30 Tagen.
• KI-Verarbeitung: Entfernung bzw. Maskierung von IBAN und Steuer-ID vor Übermittlung, soweit die Aufgabe dies zulässt. [PRÜFEN]
• Support-Screenshots: Hinweis an den Nutzer vor Upload; Cento bietet Schwärzungsfunktion [PRÜFEN]; Löschung der Anhänge nach 90 Tagen.
• Push-Tokens werden bei Abmeldung des Geräts gelöscht.

10. Organisatorische Maßnahmen

Personal [ORP.2 Personal, ORP.3 Sensibilisierung]

• Verpflichtung auf Vertraulichkeit und Datenschutz vor Aufnahme der Tätigkeit, schriftlich bzw. in Textform; bei Bedarf Belehrung nach § 203 StGB.
• Datenschutz- und Sicherheitsschulung bei Einstellung und jährlich; Nachweis dokumentiert.
• Verpflichtung von freien Mitarbeitern und Dienstleistern entsprechend.
• Geregelter Austritt: Entzug aller Zugänge am letzten Arbeitstag, Rotation geteilter Geheimnisse.

Richtlinien und Dokumentation [ISMS.1]

• Informationssicherheitsleitlinie, Berechtigungskonzept, Kryptokonzept, Datensicherungskonzept, Löschkonzept (nach DIN 66398 orientiert), Notfallhandbuch.
• Verzeichnis der Verarbeitungstätigkeiten als Auftragsverarbeiter (Art. 30 Abs. 2 DSGVO).
• Jährliche Überprüfung dieser TOMs und anlassbezogene Aktualisierung.

Sichere Entwicklung [CON.8 Software-Entwicklung, APP.3.1]

• Code-Review für jede Änderung (Vier-Augen-Prinzip [PRÜFEN] bei zwei Entwicklern umsetzbar), geschützter Hauptzweig.
• Statische Codeanalyse und Secret-Scanning in der CI.
• Orientierung an OWASP ASVS Level 2 für die Webanwendung.
• Signierte Container-Images bzw. reproduzierbare Builds aus der CI; keine manuellen Deployments auf Produktivsysteme.

Penetrationstest

• Externer Penetrationstest vor dem öffentlichen Start und danach jährlich sowie nach wesentlichen Architekturänderungen; Schwerpunkt Mandantentrennung, Authentifizierung, Datei-Upload, Bank-Schnittstellen.
• Behebung: kritische Befunde innerhalb von 7 Tagen, hohe innerhalb von 30 Tagen.
• Responsible-Disclosure-Richtlinie mit security.txt.

11. Verfahren bei Sicherheitsvorfällen [DER.2.1 Behandlung von Sicherheitsvorfällen]

1. Erkennen: Alarme aus Monitoring, Audit-Kettenprüfung, GlitchTip, Hinweise von Kunden, Dienstleistern oder Sicherheitsforschern; zentrale Meldeadresse [PLATZHALTER security@vanturis.de].
2. Bewerten (innerhalb von 4 Stunden nach Eingang): Einstufung nach Schwere; Prüfung, ob personenbezogene Daten von Kunden betroffen sind.
3. Eindämmen: z. B. Sperren von Konten und Schlüsseln, Rotation von Secrets, Isolierung betroffener Systeme, Beweissicherung (Logs, Snapshots).
4. Melden: an betroffene Kunden innerhalb von 24 Stunden nach Kenntnis (AVV § 11), Nachmeldungen mindestens alle 24 Stunden. Betrifft ein Vorfall eigene Daten von Vanturis (als Verantwortlicher), Meldung an die Aufsichtsbehörde binnen 72 Stunden (Art. 33 DSGVO).
5. Beheben und wiederherstellen: ggf. aus Backup mit Object Lock.
6. Nachbereiten: Ursachenanalyse, Abschlussbericht an betroffene Kunden, Anpassung der TOMs.
7. Dokumentieren: alle Vorfälle in einem Vorfallregister, auch ohne Meldepflicht.

Erreichbarkeit: Rufbereitschaft der Geschäftsführung [PRÜFEN] Vertretungsregelung bei Urlaub/Krankheit, da zwei Personen.

12. Zusätzliche Maßnahmen gegen Drittlandzugriffe

Für Unterauftragsverarbeiter mit Konzernbezug in Drittländern (AWS, Stripe):

• Datenstandort nur EU (AWS: EU-Regionen, EU-Inferenzprofil).
• Transportverschlüsselung; keine dauerhafte Speicherung von Kundeninhalten beim KI-Anbieter (Zero-Retention-Konfiguration).
• Datenminimierung vor Übermittlung (Ziff. 9).
• Stripe erhält nur Daten des Kunden als Vertragspartner von Vanturis, keine Buchhaltungsinhalte.
• Dokumentierte Risikobewertung (Transfer Impact Assessment) je Anbieter; Überprüfung bei Änderungen der Rechtslage (z. B. Entscheidung des EuGH in der Rechtssache C-703/25 P).

13. Zusätzliche Maßnahmen für besondere Kategorien (Art. 9 DSGVO) und Steuerdaten

• Gesonderte Verschlüsselung der Einkommensteuer-Felder (Religionszugehörigkeit, Gesundheitsangaben, Familienangaben) mit eigenem DEK je Person.
• Gesondertes Zugriffsrecht (Ziff. 3), standardmäßig nur Inhaber.
• Keine Übermittlung dieser Felder an KI-Dienste; keine Aufnahme in Logs, Fehlerberichte oder Analyse.
• Gesonderte Freigabe für Support-Zugriff.
• Erfassung des Kirchensteuermerkmals nur als für die Steuerberechnung erforderlicher Code (z. B. „ev", „rk", „--"), keine Freitextfelder.
• Übermittlung an die Finanzverwaltung ausschließlich über die amtliche Schnittstelle (ERiC) auf Auslösung durch den Kunden. [PRÜFEN] ob ELSTER-Anbindung Teil des Funktionsumfangs ist.

Änderungshistorie