Technische und organisatorische Maßnahmen (TOMs)

1.1 Zutrittskontrolle

• Hosting im IONOS-Rechenzentrum Frankfurt am Main 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.
• GoBD-orientierte Hash-Chain: jeder Audit-Eintrag enthält einen Hash des vorherigen Eintrags; Manipulationen werden vom gobd_health_check.py-Verfahren erkannt.
• 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.

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.

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 die Standardvertragsklauseln der EU-Kommission zugrunde gelegt.