Technische und organisatorische Maßnahmen (TOMs)

1.1 Zutrittskontrolle

• Hosting im IONOS-Rechenzentrum Berlin mit zertifiziertem Sicherheitskonzept (ISO 27001).
• Physischer Zutritt zum Rechenzentrum ausschließlich für autorisiertes IONOS-Personal nach 24/7-Personenkontrolle.
• Server-Hardware ohne externe Wechselmedien-Schnittstellen.

Nachweise: IONOS Datacenter Security Whitepaper, Auftragsverarbeitungsvereinbarung MintFolder ↔ IONOS.

1.2 Zugangskontrolle

• Server-Zugang: ausschließlich über SSH mit Ed25519-Schlüsseln; Passwort-Login deaktiviert; Tailscale-VPN für administrativen Zugriff vorgeschaltet.
• Anwendungs-Login: Passwörter mit Argon2id gehasht (kein Klartext, keine umkehrbare Verschlüsselung); Sitzungs-Cookies mit den Flags HttpOnly, Secure und SameSite=Strict.
• Admin-Bereiche: verpflichtende Zwei-Faktor-Authentifizierung (TOTP) für sudo-Panel und Mobile-Admin-Login.
• Mobile-Tokens: SHA-256-gehasht vor der Speicherung; bei Token-Diebstahl unwiderruflich.
• Brute-Force-Schutz: Rate-Limiting auf alle Authentifizierungsendpunkte.

Nachweise: infra/systemd/smart-archiver-api.service, Modul argon2-cffi, gunicorn-Parameter --forwarded-allow-ips 127.0.0.1.

1.3 Zugriffskontrolle

• Berechtigungsmodell: rollenbasierte Zugriffsrechte je Mandant. Mandantenübergreifende Sichtbarkeit ist auch für Administratoren ohne expliziten Sudo-Modus nicht möglich.
• Datenbank-Trennung: jeder Datensatz trägt eine company_id bzw. user_id; jede Lese- und Schreiboperation wird gegen den Sitzungs-Eigentümer geprüft.
• Verschlüsselung ruhender Daten: personenbezogene Datenfelder mit Fernet (AES-128 im CBC-Modus, HMAC-SHA-256-authentifiziert) verschlüsselt; der Schlüssel wird ausschließlich von systemd via EnvironmentFile= geladen und niemals in Anwendungs-Logs geschrieben.
• Dateisystem: Sicherheitsdateien (credentials.json, OAuth-Tokens) mit chmod 600 und nicht im Git-Repository getrackt.

Nachweise: db/connection.py Fernet-Wrapper, db/_core.py Mandanten-Triggers, routes/invoice_routes.py Mandanten-Eigentumsprüfung pro Endpunkt.

1.4 Trennungskontrolle

• Strikte Datentrennung über Mandanten-IDs auf Datenbankebene.
• Separate Produktiv-, Staging- und Lokal-Umgebungen mit getrennten Datenbanken und getrennten Anmeldedaten.
• Backups jedes Mandanten lassen sich auf Wunsch isoliert exportieren (Datenträger-Format DATEV-EXTF / JSON / CSV).

Nachweise: getrennte systemd-Units smart-archiver-api (Port 8080) und smart-archiver-staging (Port 8081).

1.5 Pseudonymisierung

• Telegram-Bot-Tokens und API-Keys werden ausschließlich als verschlüsselte Werte in der n8n-Credential-Datenbank vorgehalten und zur Laufzeit entschlüsselt; Klartext-Werte erscheinen nicht im Anwendungs-Log.
• Audit-Log-Einträge enthalten Benutzer-IDs statt Klartext-Namen.

2.1 Weitergabekontrolle

• Sämtliche externen Verbindungen über TLS 1.2 oder höher mit Let's-Encrypt-Zertifikaten; HSTS aktiv (max-age=31536000; includeSubDomains).
• HTTPS-Erzwingung: alle HTTP-Anfragen werden auf HTTPS umgeleitet; nginx + Cloudflare als TLS-Terminierung.
• Secret-Verteilung: Anwendungs-Geheimnisse liegen in /etc/mintfolder/secrets.env (root:root, Modus 0600) und werden ausschließlich von systemd via EnvironmentFile= geladen.
• Webhook-Signaturen: ausgehende Webhooks werden mit HMAC-SHA-256 signiert; Stripe-Signaturen werden bei jedem eingehenden Webhook geprüft (Fail-Closed bei fehlendem Secret).

Nachweise: routes/n8n_webhooks.py, stripe_billing.py Signaturprüfung, nginx-Konfiguration /etc/nginx/sites-enabled/*.

2.2 Eingabekontrolle

• Audit-Log auf Datenbankebene: sämtliche Einträge in action_ledger und credit_ledger sind unveränderlich; SQLite-Trigger verhindern UPDATE und DELETE. Aktueller Stand: 97 aktive Trigger über das Schema (Schema-Version 747, 145 Tabellen; davon 95 Integritäts-/Append-only- und 2 FTS-Trigger).
• GoBD-orientierte Hash-Chain: jeder Audit-Eintrag enthält einen Hash des vorherigen Eintrags; Manipulationen werden vom gobd_health_check.py-Verfahren erkannt.
• DATEV-Festschreibung (§ 146 Abs. 4 AO): mit DATEV exportierte B2B-Nutzungsprotokolle werden über b2b_usage_logs.datev_locked festgeschrieben; fünf SQLite-Trigger verhindern nachträgliche Änderung oder Entsperrung bereits exportierter Datensätze. Sprint 5
• CSRF-Schutz: alle zustandsändernden Operationen erfordern einen pro Sitzung erzeugten Token.
• Eingabevalidierung: jedes API-Schema wird per Pydantic geprüft; Datenbank-Zugriffe ausschließlich über parametrisierte Statements.

Nachweise: db/_core.py GoBD-Trigger-Block, scripts/gobd_health_check.py Integritätsprüfung, db/companies.py Festschreibung b2b_usage_logs.datev_locked.

2.3 E-Rechnungs-Validierung und revisionssichere Exporte

• Eingehende E-Rechnungen: ZUGFeRD/Factur-X- und XRechnung-Belege werden gegen die EN-16931-Schematron-Regeln (über die factur-x-Bibliothek) geprüft; das Ergebnis wird an jedem Beleg vermerkt (e_rechnung_validation_status / e_rechnung_validation_errors). Eingehende Belege werden unabhängig vom Prüfergebnis stets im Originalformat archiviert (Vollständigkeit gemäß § 147 AO — kein Verwerfen). Sprint 6 · #966
• Ausgehende E-Rechnungen: ausgehende XRechnung-Belege (CII-Syntax) werden vor dem Finalisieren per Schematron (Saxon/saxonche) gegen EN 16931 geprüft; bei einem Schematron-Verstoß wird das Finalisieren mit HTTP 422 abgelehnt. Eine XSD-Validierung wird wegen der Element-Reihenfolge im CII-Format bewusst nicht eingesetzt. Sprint 6 · #966
• XRechnung-CIUS-/BR-DE-Validierung (KoSIT): ausgehende XRechnungen werden beim Finalisieren zusätzlich gegen die KoSIT-XRechnung-3.0-Schematron (BR-DE-Regeln, Leitweg-ID; via saxonche) geprüft; das Ergebnis wird am Beleg vermerkt (brde_validation_status / brde_validation_errors, nach Finalisierung unveränderbar). Die Prüfung läuft derzeit warnend (warn-first) und ist noch keine harte Sperre — die blockierende EN-16931-Schematron-Prüfung (HTTP 422) bleibt maßgeblich. R2 · #1072
• GDPdU-/Z3-Export (Audicon-Beschreibungsstandard): Datenüberlassung für die Betriebsprüfung als Datenträger-Paket aus index.xml, gdpdu-01-08-2002.dtd und journal.csv. Sprint 6 · #967

Nachweise: services/e_rechnung.py (eingehende EN-16931-Schematron-Prüfung), services/invoice_generator.py (ausgehende XRechnung-Schematron-Prüfung, HTTP 422), services/export/gdpdu.py (GDPdU/Z3-Export).

3.1 Verfügbarkeitskontrolle

• Service-Überwachung alle 5 Minuten: automatischer Health-Check der Anwendung, der Datenbank und der nginx-Erreichbarkeit; Alarmierung per Telegram bei drei aufeinanderfolgenden Fehlern.
• Audit-Pakete alle 3 Stunden: 14-Punkte-Produktionsaudit (CPU, RAM, Disk, Backups, SSL, DB-Integrität, Endpunkt-Antworten) per Telegram.
• DDoS-Schutz: vorgelagertes Cloudflare-Edge mit Rate-Limit-Regeln auf 443; Origin-Firewall (ufw) lässt nur die offiziellen Cloudflare-IPv4-Bereiche zu.
• Reverse-Proxy-Hardening: nginx mit X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy ohne Kamera/Mikrofon/Geolokation, Cross-Origin-Opener-Policy same-origin, Cross-Origin-Resource-Policy same-site.

Nachweise: scripts/health_check.sh, scripts/telegram_audit.sh, cron-jobs/alerts/service_health.sh.

3.2 Belastbarkeit

• Anwendungs-Server mit automatischem Neustart bei Absturz (Restart=always in systemd).
• DB-Operationen über Connection-Pool mit Schutz vor Verbindungslecks.
• KI-Pipeline mit Fallback-Kette (Regex → Gemini Flash → Claude → OpenAI gpt-4o → Ollama lokal); Ausfall einer einzelnen Komponente verursacht keinen Service-Ausfall.
• Drittlandtransfer Google Gemini: die Klassifizierung erfolgt über den Google-AI-Studio-Endpunkt in den USA. Der Transfer wird auf den EU-U.S. Data Privacy Framework (Durchführungsbeschluss (EU) 2023/1795) sowie ergänzend auf die EU-Standardvertragsklauseln (Beschluss 2021/914) gestützt. Ein Art.-9-Gatekeeper (187 Schlüsselwörter in 7 Kategorien) soll die Übermittlung besonderer Kategorien unterbinden; gewöhnliche personenbezogene Daten werden auf dem Standard-Pfad nicht automatisch redigiert (einzelne OCR-Text-Fallback-Pfade nutzen lokale PII-Redaktion).

4.1 Backup-Strategie

• Primärbackup (Restic): stündlich, AES-256-clientseitig verschlüsselt, Übertragung an Hetzner Storage Box in Falkenstein/EU. Frische-Schwelle 90 Minuten; Ausfall wird per Telegram-Heartbeat erkannt.
• Sekundärbackup (rclone): täglich, AES-256-CBC-verschlüsselt, Übertragung an Google-Drive-Speicher. Aufbewahrung lokal 10 Stück, Cloud 30 Tage.
• Recovery Point Objective (RPO): maximal 1 Stunde Datenverlust.
• Recovery Time Objective (RTO): maximal 4 Stunden bis zur vollständigen Wiederherstellung.

Nachweise: scripts/restic_heartbeat.sh, backup.sh, disaster-recovery.sh, ADR-010 (Dual Backup Strategy).

4.2 Wiederherstellungs-Tests

• Wöchentliche Restore-Drills (Sonntag 03:00 Europe/Berlin): vollständige DB-Wiederherstellung in einer temporären Umgebung mit anschließender Schema- und Integritätsprüfung.
• Vollständiger Disaster-Recovery-Lauf disaster-recovery.sh umfasst sieben Phasen, dauert in der Regel ~15 Minuten auf einem frischen Ubuntu-24.04-VPS.

Nachweise: scripts/test_restore_drill.sh (PASS/FAIL Exit-Code).

5.1 Datenschutzmanagement

• Verfahrensverzeichnis (Verzeichnis von Verarbeitungstätigkeiten) wird intern fortlaufend aktualisiert und auf Anfrage Aufsichtsbehörden vorgelegt.
• Risiko-Register dokumentiert offene technische und organisatorische Risiken (z. B. APP-002 für CSP-Hardening Q3 2026).
• Monatliche Sichtprüfung der Aufsichtsbehörden-Mitteilungen und der DSGVO-relevanten Rechtsprechung.

5.2 Incident-Response-Management

• Festgelegter Incident-Commander-Prozess mit Severity-Klassifikation (SEV1 bis SEV4) und definierten Eskalationsschwellen.
• Zentrales Incident-Log und blameless Post-Mortems nach jedem SEV1- oder SEV2-Vorfall.
• Tägliche Sentry- und UptimeRobot-Auswertung (sofern für die jeweilige Komponente aktiv).

Nachweise: docs/POST_MORTEMS.md, docs/OPS/sentry-setup.md, docs/OPS/uptimerobot-setup.md.

5.3 Datenschutzfreundliche Voreinstellungen

• Sämtliche Belegfunktionen verarbeiten standardmäßig ausschließlich die Daten, die der Anwender aktiv hochlädt; keine Vorab-Bezugnahme auf externe Datenquellen.
• KI-Klassifizierung läuft ohne Benutzer-bezogenes Profiling; jedes Dokument wird isoliert klassifiziert.
• Cookies werden nur nach ausdrücklicher Einwilligung gesetzt (TDDDG-konform).

5.4 Sicherheits-Tests

• Continuous Integration prüft mit pip-audit sämtliche Python-Abhängigkeiten gegen bekannte CVEs.
• Statische Code-Analyse via ruff; jeder Pull Request muss CI-grün sein, bevor er gemergt werden kann.
• Vulnerability Disclosure Policy unter /.well-known/security.txt mit Zusage einer Bestätigung innerhalb von 48 Stunden.

Nachweise: .github/workflows/ci.yml, static/.well-known/security.txt.

6.1 Verarbeitung nach Weisung

• Sämtliche Verarbeitungen erfolgen ausschließlich auf Grundlage des Hauptvertrags und der zugehörigen Auftragsverarbeitungsvereinbarung.
• Mündliche Weisungen werden nachträglich in Textform bestätigt.
• Mitarbeitende sind zur Verschwiegenheit verpflichtet.

6.2 Unterauftragsverarbeiter-Steuerung

• Aktuelle Liste der Unterauftragsverarbeiter siehe Abschnitt 6 der AVV.
• Änderungen an der Liste werden 30 Tage vor Inkrafttreten angekündigt; Auftraggeber hat ein Widerspruchsrecht innerhalb dieser Frist.
• Bei Übermittlungen außerhalb des EWR werden — soweit kein Angemessenheitsbeschluss greift — die EU-Standardvertragsklauseln (Beschluss 2021/914) zugrunde gelegt. Für Transfers in die USA wird, sofern der Empfänger zertifiziert ist, zusätzlich der EU-U.S. Data Privacy Framework (Durchführungsbeschluss (EU) 2023/1795) herangezogen (z. B. Google Gemini).