Technisch-organisatorische Maßnahmen

1. Zutrittskontrolle (physischer Zugang zu DV-Anlagen)

Kein unbefugter Zutritt zu Servern, auf denen personenbezogene Daten verarbeitet werden.

• Es werden keine eigenen Server-Räume betrieben. Hosting der Anwendung erfolgt durch Vercel Inc. (EU-Region „fra1“ / Frankfurt am Main).
• Speicherung der Datenbank erfolgt durch Supabase Inc. auf AWS in Frankfurt (eu-central-1).
• Speicherung der Dokumente erfolgt durch Cloudflare, Inc. (R2-Speicher, EU-Jurisdiktion).
• Alle eingesetzten Subunternehmer sind nach ISO/IEC 27001 und/oder SOC 2 Type II zertifiziert; physische Zutrittskontrollen werden vertraglich gesichert.
• Arbeitsplätze des Auftragnehmers sind verschlüsselt (FileVault / BitLocker), gerätegebunden (MDM-fähig) und werden bei Verlust ferngelöscht.

2. Zugangskontrolle (logischer Systemzugang)

Verhinderung der Nutzung der Software durch Unbefugte.

• Anmeldung ausschließlich mit individueller E-Mail-Adresse und Passwort (keine Shared Accounts).
• Passwort-Hashing mit scrypt (speicherhartes Key-Derivation-Verfahren); Klartext-Passwörter werden zu keinem Zeitpunkt persistiert oder protokolliert.
• Passwort-Richtlinie: Mindestlänge 10 Zeichen, Höchstlänge 128 Zeichen, Buchstaben und Ziffern verpflichtend.
• Pflichtwechsel des Passworts bei initial vom Master-Administrator gesetzten Konten (mustChangePassword-Flag); die Rotation wird auch auf der Mobile-API erzwungen.
• Zwei-Faktor-Authentisierung (TOTP nach RFC 6238, 6-stellig, 30-Sekunden-Fenster, ±1-Step-Toleranz) für alle Nutzer aktivierbar; Mandant-weite 2FA-Pflicht durch den Mandant-Administrator konfigurierbar.
• Fail-closed 2FA-Step-up: eine neue Sitzung gilt bis zur erfolgreichen TOTP-Verifikation als nicht verifiziert — Fehler im Verifikations-Pfad sperren den Zugang, statt ihn zu umgehen.
• Anti-Replay für TOTP: ein einmal verwendetes Zeitfenster wird verbraucht und kann nicht erneut eingesetzt werden.
• TOTP-Geheimnisse werden in der Datenbank ausschließlich AES-256-GCM-verschlüsselt abgelegt; der Verschlüsselungsschlüssel liegt außerhalb der Datenbank in den Vercel-Environment-Variablen.
• Wiederherstellungs-Codes (10 Stück) werden bei der 2FA-Einrichtung einmalig im Klartext angezeigt, in der Datenbank ausschließlich als sha256-Hashes gespeichert und sind nach einmaliger Verwendung verbraucht (single-use, Anti-Replay).
• 5-Versuch-Lockout über 15 Minuten für die Zwei-Faktor-Verifikation (BSI-Mindeststandard MFA, Anti-Brute-Force).
• Schutz gegen Selbstaussperrung: die Deaktivierung des eigenen 2FA ist gesperrt, wenn die Mandant-Pflicht aktiv ist.
• Brute-Force-Schutz auf der Anmelde-Route (Rate Limiting je IP/Konto).
• Session-Management: signierte HTTP-only Cookies mit Secure-Flag und SameSite-Schutz; zusätzliche Origin-Prüfung über umgebungs-spezifische Trusted Origins (die Produktion akzeptiert ausschließlich die eigenen Domains).
• Sitzungen deaktivierter Nutzer-Konten werden serverseitig abgewiesen — eine Kontosperrung wirkt sofort, nicht erst beim nächsten Login.
• API-/Bearer-Tokens (Mobile-API, MCP-Zugänge) werden mit absoluter Ablaufzeit ausgestellt.
• Automatische Abmeldung bei Inaktivität (5 / 10 / 15 / 30 / 60 Minuten oder deaktiviert), Standardwert 10 Minuten, pro Nutzer konfigurierbar; Cross-Tab-Synchronisation via localStorage-Events.
• Keine öffentliche Selbstregistrierung — Konten werden ausschließlich per Einladung durch den Master- bzw. Mandant-Administrator angelegt.
• Automatische Sperrung von Konten ausscheidender Nutzer durch den Mandant-Administrator.

3. Zugriffskontrolle (Berechtigungssteuerung)

Kein unbefugtes Lesen, Kopieren, Verändern oder Entfernen innerhalb der Anwendung.

• Mehrstufiges Rollenmodell (master_admin, admin, user, steuerberater [read-only], buchhaltung, verwaltung, techniker sowie die externen Portal-Rollen owner und mieter) mit feingranularen Permissions (z. B. property.read, beleg.review, journal.post); Back-Office- und Admin-Flächen sind zusätzlich durch Autorisierungs-Gates abgesichert.
• Externe Portal-Rollen (Eigentümer, Mieter) sehen ausschließlich die ihnen zugeordneten Objekte, Einheiten und Dokumente — keine Back-Office-Funktionen.
• Mandantenscharfe Datenisolation: jede Datenbank-Abfrage wird auf die tenant_id des angemeldeten Nutzers eingeschränkt; ein fail-closed Scope-Guard weist Abfragen ohne Mandanten-Filter zur Laufzeit ab (Abdeckung: alle 40 mandantenbezogenen Tabellen).
• Postgres Row-Level Security (RLS) ist auf allen Tabellen aktiviert (default-deny); die Tenant-Isolations-Policies als datenbankseitiger Backstop sind vorbereitet und Ende-zu-Ende verifiziert, die Aktivierung erfolgt nach Staging-Erprobung; ein Prüfskript sichert die Policy-Abdeckung aller Tabellen ab.
• Master-Administrator-Konten unterliegen verschärften Anforderungen (mandatorische 2FA, geringere Idle-Timeout-Standardwerte).
• Audit-Log aller geld-, daten- und sicherheitsrelevanten Vorgänge mit Vorher/Nachher-Werten, Nutzer-ID, IP-Adresse und Zeitstempel.
• Speicherung von Geheimnissen (API-Schlüssel, AES-Schlüssel, Tokens) ausschließlich in Vercel-Environment-Variablen — niemals im Quellcode oder Git-Repository.
• Datenschutzkonforme Vernichtung / Löschung über kaskadierende Foreign-Key-Löschungen sowie Soft-Delete-Marker, wo Aufbewahrungsfristen entgegenstehen.
• Demo-Daten laufen in gekennzeichneten, isolierten Demo-Mandanten mit eigenem Lebenszyklus — keine Vermischung mit Echtdaten.

4. Weitergabekontrolle (sicherer Transport)

Kein unbefugtes Lesen, Kopieren, Verändern oder Entfernen bei elektronischer Übertragung.

• Sämtlicher Datenverkehr zwischen Browser, Anwendung (Vercel), Datenbank (Supabase), Dokumentenspeicher (Cloudflare R2), KI-Provider (Anthropic) und E-Mail-Provider (Resend) erfolgt ausschließlich über TLS 1.2 oder höher.
• Cloudflare R2 verschlüsselt sämtliche Objekte at-rest mit AES-256.
• Supabase verschlüsselt die Datenbank at-rest mit AES-256 und stellt automatische SSL-Verbindungen bereit.
• Dokumenten-Downloads erfolgen über zeitlich befristete, signierte URLs (Presigned URLs, TTL maximal 5 Minuten).
• Content-Security-Policy mit per-Request-Nonce und Violation-Reporting; Betriebsmodus (Report-Only / Enforce) umgebungsgesteuert gemäß Härtungs-Plan.
• MIME-Whitelist für sämtliche Datei-Uploads einschließlich eingehender E-Mail-Anhänge; nur eine inline-sichere Teilmenge (PDF, Bilder, Klartext) wird im Browser dargestellt — aktive Inhalte (HTML/SVG) werden abgewiesen (Stored-XSS-Härtung).
• CSV-Exporte neutralisieren Formel-Injektion, damit Zellinhalte in nachgelagerten Tabellenkalkulationen nicht als Formeln ausgeführt werden.
• E-Mail-Versand (Resend) und E-Mail-Empfang (Postmark Inbound) ausschließlich über TLS-verschlüsselte SMTP-Verbindungen.
• Outbound-Mail an Dritte (Mahnwesen, NK-Abrechnungen, Mietvertrags-Versand) erfordert immer eine explizite Freigabe-Aktion eines Nutzers — kein automatischer Massenversand ohne menschliche Prüfung.

5. Eingabekontrolle (Nachvollziehbarkeit)

Feststellung, ob und von wem personenbezogene Daten in der Anwendung eingegeben, verändert oder entfernt worden sind (Art. 5 Abs. 2 DSGVO — Rechenschaftspflicht).

• Audit-Log der Anwendung erfasst jede schreibende Aktion (insert / update / delete) mit dem auslösenden Nutzer-Konto, Tenant-ID, IP-Adresse und Zeitstempel.
• Vorher- und Nachher-Werte werden für sicherheitsrelevante Tabellen (User, Session, Tenant, Mietvertrag, Beleg, MietzahlungSoll, BankTransaction, Journal) vollständig protokolliert.
• Sicherheits-Events (auth.2fa.*, auth.mandant.2fa_policy_changed, user.totp.locked) werden mit erweiterten Metadaten (Versuchszähler, Lockout-Bis-Wann) erfasst.
• Einträge im Audit-Log sind für Mandant-Administratoren in der Anwendung einsehbar (Menüpunkt System → Audit-Log).
• Aufbewahrungsdauer Audit-Log: buchungsrelevante Einträge 10 Jahre (§ 147 AO, datenbankseitig gegen frühere Löschung gesichert); übrige Einträge mindestens 12 Monate. Backups verlängern dies faktisch.

6. Verfügbarkeitskontrolle

Schutz gegen zufälligen oder mutwilligen Verlust personenbezogener Daten.

• Tägliche automatische Backups der Datenbank durch Supabase, einschließlich Point-in-Time Recovery (Wiederherstellung sekundengenau über die letzten 7 Tage).
• Cloudflare R2 speichert Dokumente mit eingebauter geo-verteilter Redundanz; die Anwendung behandelt Objekte write-once (keine Lösch- oder Überschreib-Pfade, Löschung nur als Soft-Delete auf Datenbankebene) — Schutz gegen versehentlichen und anwendungsseitigen Datenverlust.
• Täglich wird der vollständige Dokumentenbestand einseitig in ein unabhängiges WORM-Replikat kopiert (AWS S3 Frankfurt eu-central-1, Object Lock im Compliance-Modus, 10 Jahre Default-Retention); die Replikations-Zugangsdaten liegen auf einem von der Anwendung getrennten System. Erstes Voll-Replikat 07.07.2026, verifiziert (0 Abweichungen).
• Vercel betreibt die Anwendung mit automatischem Multi-Region-Failover.
• DDoS-Schutz und Bot-Mitigation durch Cloudflare.
• Quartalsweise Restore-Drills: Wiederherstellung der Datenbank in ein separates Drill-Projekt mit Schema- und Datenintegritätsprüfung; erster erfolgreicher Drill am 05.07.2026 im Betriebs-Runbook dokumentiert.
• Sentry-Monitoring für Anwendungs-Fehler; SLO-Alerts bei Anstieg der Fehlerrate.

7. Trennungskontrolle (Mandantentrennung)

Getrennte Verarbeitung von Daten, die zu unterschiedlichen Zwecken erhoben wurden.

• Mandantenfähige Architektur ab Tag 1: jede Tabelle der Datenbank trägt eine tenant_id, jede Abfrage wird auf die tenant_id des Sitzungsbenutzers eingeschränkt; der Scope-Guard arbeitet fail-closed (Abfragen ohne Mandanten-Filter werden abgewiesen).
• Dokumentenspeicher Cloudflare R2 verwendet pro Mandant einen eigenen Schlüsselpfad-Präfix (<tenant_id>/...).
• Postgres Row-Level Security (RLS) ist auf allen Tabellen aktiviert (default-deny); die Tenant-Isolations-Policies sind vorbereitet, Ende-zu-Ende verifiziert und werden nach Staging-Erprobung als zusätzliche Datenbank-seitige Absicherung aktiviert.
• Eingehende Beleg-E-Mails werden über mandantenspezifische Subdomains (belege@<tenant>.immobilien-butler.com) eindeutig zugeordnet.
• Strikte logische Trennung von Test-, Staging- und Produktivumgebung — kein Datenabgleich zwischen Umgebungen.

8. Auftragskontrolle

Keine Auftragsdatenverarbeitung im Sinne von Art. 28 DSGVO ohne entsprechende Weisung des Auftraggebers.

• Mit allen in Anlage 2 zur AVV genannten Subunternehmern bestehen schriftliche Auftragsverarbeitungsverträge gemäß Art. 28 DSGVO.
• Bei Subunternehmern mit Sitz außerhalb der EU/EWR (insbesondere Anthropic für KI-gestützte Belegerkennung) erfolgt der Datentransfer auf Grundlage der EU-Standardvertragsklauseln (Durchführungsbeschluss 2021/914) sowie ergänzender technischer Maßnahmen (Zero Data Retention, kein Modelltraining mit Mandanten-Daten).
• Dokumentation aller Subunternehmer-Verträge; jährliche Überprüfung der Sicherheits-Zertifizierungen (ISO 27001, SOC 2).
• Aktualisierungen der Subunternehmer-Liste werden den Auftraggebern rechtzeitig vor dem Wirksamwerden mitgeteilt; ein Widerspruchsrecht aus berechtigtem Grund besteht.

Phishing-Resistenz von TOTP

TOTP ist nicht inhärent phishing-resistent (im Gegensatz zu Passkeys). Kompensation: kurze Session-Timeouts, IP- und User-Agent-Erfassung im Audit-Log, geplante Einführung von WebAuthn/Passkeys.

Verlust des zweiten Faktors durch den Nutzer

10 Backup-Codes als Recovery-Pfad. Bei Verlust sowohl des Geräts als auch der Backup-Codes: manueller Reset durch den Mandant-Administrator nach Identitätsprüfung; Vorgang im Audit-Log dokumentiert.

Insider-Risiko durch DB-Zugriff

TOTP-Secrets sind bei reinem DB-Zugriff nicht nutzbar — der AES-Schlüssel liegt außerhalb der DB. Backup-Codes sind sha256-gehasht und nicht reversibel. Passwort-Hashes (scrypt) sind ebenfalls nicht reversibel.

Datenbankseitige RLS-Erzwingung noch nicht aktiv

Die Mandantentrennung wird derzeit anwendungsseitig erzwungen (fail-closed Scope-Guard über alle 40 mandantenbezogenen Tabellen). Die RLS-Isolations-Policies als Datenbank-Backstop sind vorbereitet und Ende-zu-Ende verifiziert (05.07.2026); Aktivierung erfolgt nach Staging-Erprobung gemäß Härtungs-Plan.

Drittlandtransfer USA (Anthropic für KI-Belegerkennung)

EU-Standardvertragsklauseln (SCC 2021/914), Zero Data Retention beim Provider, vertraglicher Verzicht auf Modelltraining mit Mandanten-Daten. Mandant kann KI-Belegerkennung deaktivieren — Ausweichpfad ist die manuelle Beleg-Erfassung.

Session-Hijacking bei kompromittiertem Endgerät

HTTP-only + Secure Cookies mit SameSite-Schutz, Origin-Prüfung, TLS 1.2+ überall, automatische Idle-Abmeldung (Standard 10 Min), sofortige serverseitige Abweisung gesperrter Konten, IP-Erfassung im Audit-Log zur Anomalie-Erkennung.