# NEXARCH 2.0 – Sicherheitskonzept

Stand: 2026-08-26, alle 10 Punkte in Abschnitt 11 zwischen 2026-08-28 geklärt oder durch neue Tickets adressiert (Core OPS-06, Core IAM-15, DMS SRC-11, Mail SRC-11). Grundlage: `nexarch-state.json`, `SKALIERUNGSKONZEPT.md`, `STORAGE-KONZEPT.md`, `core-kanban/`, `dms-kanban/`, `mail-kanban/`, `archive-kanban/`, `workflow-kanban/`, `dms-kanban/known-issues-archivdms.md`, `dms-kanban/known-issues-archivmail.md` (Boards inzwischen aus dem Repo entfernt, Ticket-Historie liegt in der Gitea-PR-Historie).

Dieses Dokument führt keine neue Architektur ein. Es fasst die bereits in den sieben Boards getroffenen sicherheitsrelevanten Einzelentscheidungen zu einem Gesamtbild zusammen und prüft dabei — nach demselben Muster wie `STORAGE-KONZEPT.md` — auf Lücken und Widersprüche. Prüfraster: OWASP Top 10, angewendet auf den tatsächlichen NEXARCH-Techstack (Go, PostgreSQL, JWT, S3-kompatibler Storage, Manticore), nicht generisch abgehandelt.

## 1. Authentifizierung

| Baustein | Entscheidung | Ticket |
|---|---|---|
| Passwort-Hashing | bcrypt (bewusst nicht Argon2) | `nexarch-state.json` Techstack |
| Token | JWT, zustandslos, lokale Signaturverifikation via JWKS-ähnlichem Mechanismus mit `kid`-Rotation | Core `API-05` |
| Zweiter Faktor | TOTP (RFC 6238), Einrichtung, Wiederherstellungscodes, pro Tenant erzwingbar | Core `IAM-04` |
| Verzeichnisanbindung | LDAP-Abgleich | Core `IAM-05` |
| Föderation | SSO/OIDC | Core `IAM-06` |
| Brute-Force-Schutz | Account-Lockout / Rate-Limiting am Login | Core `IAM-07` |

Die Wahl bcrypt statt Argon2 ist im Entscheidungsverlauf nicht mit einer eigenen Begründung hinterlegt (`nexarch-state.json` Techstack-Feld nennt es nur als Faktum). Das ist keine Sicherheitslücke — bcrypt gilt weiterhin als solide, solange Kostenfaktor aktuell gehalten wird — aber eine unbegründete Abweichung vom heute üblichen Argon2id-Standard sollte im Core-Board mindestens als bewusste Entscheidung mit Kostenfaktor-Wert dokumentiert werden, nicht nur als Faktenzeile in der State-Datei.

**Korrektur gegenüber archivdms:** `known-issues-archivdms.md` Punkt 9 beschreibt einen In-Memory-Rate-Limiter ohne Shared State (`internal/auth/ratelimit.go`) — bei Mehrinstanz-Deployment pro Instanz getrennt und damit aushebelbar. `SKALIERUNGSKONZEPT.md` Abschnitt 1 hält fest, dass Core `IAM-07`/`API-03` Rate-Limiting mit **shared state statt in-process** umsetzt. Damit ist der konkrete archivdms-Fehler für den Login-Pfad explizit adressiert.

2FA-Aktivierungspflicht ist laut `IAM-04` pro Tenant konfigurierbar, nicht global erzwungen — das ist eine bewusste Flexibilitätsentscheidung (SaaS-Betrieb mit unterschiedlichen Kundenanforderungen), sollte aber im Betriebshandbuch als Empfehlung ("2FA-Pflicht für Admin-Rollen mindestens") festgehalten werden, sobald ein Betriebshandbuch existiert (siehe `fehlende_konzeptdokumente`).

## 2. Autorisierung / Zugriffskontrolle

RBAC ist vollständig in Core zentralisiert (`RBAC-01`..`RBAC-05`) — kein Modul implementiert eigene Rechteprüfung, das ist direkte Konsequenz der IAM-Konsolidierung (`nexarch-state.json` Entscheidungsverlauf "Konsolidierung IAM").

**Korrektur gegenüber archivmail:** `known-issues-archivmail.md` Punkt 7 beschreibt Tenant-Filterung als **Post-Filter statt in der Query** (`internal/api/ediscovery.go:90`) — fehleranfällig, weil jeder neue Codepfad das Filtern erneut korrekt implementieren muss. Die Notiz im selben Dokument ordnet das explizit auch DMS `IAM-03` ("Policy-Enforcement — zentral, nicht pro Handler") zu. Das Prinzip "Tenant-/Rechte-Scoping ausschließlich in der Query-/Repository-Schicht, nie als Post-Filter im Handler" ist damit als Korrektur benannt, aber es lohnt sich, es hier noch einmal projektweit festzuhalten: Diese Regel gilt für **jedes** Modul, das gegen die zentrale Core-RBAC-Prüfung arbeitet (DMS, Mail, Archive, Workflow, AI, Connect gleichermaßen), nicht nur für die ursprünglich betroffene eDiscovery-Funktion.

**Tenant-Isolation — strukturell gelöst durch Modell C:** Multi-Tenancy läuft nach Modell C: eine physisch getrennte Datenbank je Mandant plus schlanke Registry (Core `TEN-01`/`TEN-06`/`TEN-07`, `nexarch-state.json` `multi_tenancy`, Begründung in `SKALIERUNGSKONZEPT.md` Abschnitt 4). Ein vergessener `tenant_id`-Filter kann damit keine fremden Daten mehr liefern, weil sie in der angesprochenen Datenbank nicht existieren; die Fehlerklasse aus `known-issues-archivdms.md` (Punkte 9/10, Tenant-Scoping-Fragilität) und `known-issues-archivmail.md` (#2/#7) ist strukturell beseitigt, nicht nur unwahrscheinlicher. Row-Level-Security ist bei physischer Trennung redundant und nicht vorgesehen. Die harte Regel aus dem vorigen Absatz (Rechte-Scoping zentral in der Repository-Schicht, nie als Post-Filter im Handler) bleibt bestehen, denn sie betrifft die Rechte *innerhalb* eines Mandanten (Ordner, Dokumente, Rollen), nicht die Mandantentrennung; `known-issues-archivdms.md` Punkt 2 fordert dafür eine Testpflicht als Merge-Gate, die bisher in keinem QA-Ticket als projektweite CI-Regel verankert ist (siehe Abschnitt 10). Verbleibendes Restrisiko liegt nicht mehr im Filter, sondern in der Zuordnung Mandant → Datenbank (Registry, Verbindungsinformation) und in mandantenübergreifenden Prozessspeichern (Caches, Pools): Kompensation sind der Pflicht-Tenant-Kontext bei jedem Modulaufruf (DMS `INT-16`), mandantengetrennte Cache-Schlüssel (Core `RBAC-10`) und der Mandant aus dem Token statt aus Anfrageparametern.

**Superadmin-Sonderfall:** `known-issues-archivdms.md` Punkt 4 beschreibt einen wiederholt vergessenen Superadmin-ohne-Tenant-Zustand (403 "tenant context required", mehrfach nachträglich gepatcht). Kein Core-Ticket in der gelesenen Auswahl adressiert das explizit als First-Class-Datenmodell-Zustand — siehe Offene Punkte (Abschnitt 11).

## 3. Injection-Schutz

Dynamische SQL-Klauseln/Tabellennamen via `fmt.Sprintf` bzw. String-Konkatenation waren ein wiederkehrendes Antipattern in beiden Altsystemen:

- archivdms: `known-issues-archivdms.md` Punkt 10 — dynamische Tabellennamen via `fmt.Sprintf` (`taxonomy.go`, `workflows.go`, `classification_templates_title.go`, `internal/index/manticore.go`), zur Tatzeit nur durch eine Whitelist-Funktion abgesichert, als "fragiles Muster" bewertet.
- archivmail: `known-issues-archivmail.md` Punkte 11/12 — dynamische SQL-Klauseln via Sprintf/Join (`internal/index/manticore.go:268,323`, `internal/storage/ocr.go:159`), gleiches Muster zweimal dupliziert.

Beide Fundstellen betreffen denselben Bereich: Suchindex-/Query-Aufbau gegen Manticore bzw. Postgres mit dynamischen Feldlisten. Die Korrektur ist in den entsprechenden Suchindex-Tickets verankert: DMS `SRC-01`, Mail `SRC-01` (Suchindex/Such-API-Grundlage der jeweiligen Module). Die verbindliche Regel aus beiden Known-Issues-Dokumenten lautet übereinstimmend: **Spalten-/Tabellennamen ausschließlich aus statischen Konstanten bzw. einem geschlossenen Enum/Switch-Typ, nie aus Nutzereingabe oder generischem String-Zusammenbau, auch nicht hinter einer Whitelist-Funktion.** Ein zentraler, getesteter Query-Builder mit Feld-Whitelist (`known-issues-archivmail.md` Punkt 12) ist der empfohlene Ansatz — ob dieser als gemeinsame Utility zwischen DMS `SRC-01` und Mail `SRC-01` geteilt wird oder je Modul separat entsteht, ist in keinem der beiden Tickets festgelegt (siehe Offene Punkte).

## 4. Sensible Daten / Verschlüsselung

| Baustein | Entscheidung | Ticket |
|---|---|---|
| Verschlüsselung at rest | AES-256-GCM, Envelope Encryption | DMS `FDN-09`, Mail `ARC-02` |
| Reihenfolge Hash/Verschlüsseln | SHA-256-Hash auf Klartext **vor** Verschlüsselung (sonst funktioniert Dublettenerkennung nie) | DMS `FDN-09`/`DOC-02`, Mail `ARC-02`/`ARC-03` |
| Secrets | ausschließlich über Umgebungsvariablen, nie im Code | durchgängige Ticket-Regel (Abschlussabschnitt jedes Tickets, u.a. explizit in `IAM-04`..`IAM-07`, `RBAC-01`..`RBAC-05`, `API-02`..`API-06`, `AUD-05`) |
| Audit-Log-Aufbewahrung | append-only (`AUD-02`), Retention über Archive-Engine statt eigener Löschlogik, Default 10 Jahre (GoBD-Buchungsbeleg-Frist) | Core `AUD-05`, Archive `RET-01`/`RET-02`/`RET-05` |

Die Hash-vor-Verschlüsseln-Reihenfolge ist ein gutes Beispiel für eine bereits im Projekt selbst aufgedeckte und behobene Lücke: laut Entscheidungsverlauf fehlte sie zunächst im Mail-Board (`ARC-02`/`ARC-03`), obwohl DMS (`FDN-09`) sie schon hatte, und wurde nachgezogen — dokumentiert in `nexarch-state.json` unter "Duplikatserkennung vor Weiterverarbeitung".

**Schlüsselverwaltung/-rotation — geklärt (2026-08-27):** Zweistufige Schlüsselhierarchie statt eines einzelnen globalen Master-Key. Core hält EINEN Master-Key (Root-KEK, über Umgebungsvariable/Secret-Provider, austauschbar gegen echten KMS-Dienst), der ausschließlich **Tenant-Schlüssel** (Tenant-KEK) verpackt — niemals Objekte direkt. Jeder Mandant erhält bei seiner Provisionierung (`TEN-01`) einen eigenen Tenant-KEK, verschlüsselt mit dem Master-Key in der Registry abgelegt. DMS (`FDN-09`) und Mail (`ARC-02`) beziehen für ihre pro-Objekt-DEKs ausschließlich den entschlüsselten Tenant-KEK ihres jeweiligen Mandanten (nie den Master-Key direkt), authentifiziert über das Service-Credential aus `API-02`. Rotation ist auf beiden Ebenen unabhängig möglich, ohne Objektdaten neu zu verschlüsseln: Master-Key-Rotation verpackt nur alle Tenant-KEKs neu (klein, schnell), Tenant-KEK-Rotation verpackt nur die DEKs dieses einen Mandanten neu und berührt keinen anderen Tenant. Umgesetzt in Core `API-10`.

**Begründung für die Tenant-Ebene:** Ein einzelner globaler Master-Key hätte einen gemeinsamen Blast-Radius für alle Mandanten geschaffen — ein kompromittierter Tenant-KEK (z. B. durch ein fehlerhaftes Modul-Log oder einen kompromittierten Service-Credential-Aufruf) betrifft mit der zweistufigen Hierarchie strukturell nur diesen EINEN Mandanten. Das ist die konsequente Fortsetzung der physischen Modell-C-Isolation (siehe TEN-01, Entscheidungsverlauf "Multi-Tenancy: Modell A -> Modell C") auch auf Schlüsselebene, statt einer Isolationslücke, die die sonstige Trennung wieder aufheben würde.

Die JWT-Schlüsselrotation (Core-Public-Key, `kid`-Rotation) ist dagegen bereits ausformuliert (`SKALIERUNGSKONZEPT.md` Abschnitt 11 letzter Punkt, Core `API-05`): muss ohne Ausfallzeit anderer Module möglich sein. Das ist ein anderer Schlüssel als der Storage-Verschlüsselungs-Master-Key und löst dessen Rotationsfrage nicht mit.

## 5. Eingabevalidierung / bekannte Angriffsvektoren aus den Altsystemen

| Altsystem-Fund | Fundstelle | NEXARCH-Korrektur |
|---|---|---|
| Header-Injection bei E-Mail-Versand (From/To/Subject per Stringkonkatenation ohne CRLF-Prüfung) | `known-issues-archivmail.md` #1, `internal/mailer/mailer.go:144-146` | Mail `ING-03` — `net/mail`-Writer bzw. harte CRLF-/Steuerzeichen-Prüfung |
| Ungebremstes Lesen von Anhängen (`io.ReadAll` ohne Größenlimit → Speicherbombe) | `known-issues-archivmail.md` #3, `pkg/mailparser/parser.go` | Mail `ING-04` (Ingestion) und DMS `DOC-01` (Upload-API) — `io.LimitReader` mit Max-Size, harte Ablehnung; explizit auch für DMS-Uploads übernommen, nicht nur Mail |
| XSS-Risiko bei Anhang-/Dokument-Vorschau über iframe-Rendering von Fremdinhalt | `known-issues-archivmail.md` #9, positiv gelöst via `PdfCanvasPreview.tsx` (Canvas statt iframe) | DMS `DOC-05` (PDF-Viewer) und Mail `UX-03` — Canvas-Rendering von Anfang an, kein iframe/HTML-Rendering von Fremdinhalt |
| Content-Type-Erkennung über Dateiendung statt Inhalt | `known-issues-archivmail.md` #8, `AttachmentPreviewDialog.tsx` | betrifft ebenfalls DOC-05 — serverseitige Magic-Bytes-Erkennung statt Dateiendung, im Ticket-Titel nicht explizit als Akzeptanzkriterium sichtbar (siehe Offene Punkte) |

Die Speicherbomben-Korrektur (`DOC-01`/`ING-04`) ist im Entscheidungsverlauf nicht als eigener Eintrag sichtbar, aber laut Known-Issues-Dokument bereits als "betrifft auch DMS" annotiert — das Konzept übernimmt diese Zuordnung, prüft aber nicht, ob `DOC-01` das Größenlimit tatsächlich als Akzeptanzkriterium enthält oder nur als Empfehlung im Known-Issues-Dokument steht. Diese Prüfung sollte bei nächster Gelegenheit nachgeholt werden.

## 6. Vertrauensstellung zwischen Modulen

NEXARCH ist modular mit sieben eigenständigen Boards — Vertrauen zwischen Modul und Core (und indirekt zwischen Modulen) ist eine eigene Angriffsfläche, die in einem Monolithen nicht existieren würde.

- **Modul vertraut Core:** asymmetrische JWT-Signatur, Core signiert mit privatem Schlüssel, Module verifizieren lokal mit öffentlichem Schlüssel über JWKS-ähnliche Verteilung mit `kid`-Rotation (Core `API-05`).
- **Core vertraut Modul:** Service-Credential je Modul-Instanz, ausgestellt bei Provisionierung (Core `API-02`, erweitert). Notwendig, weil einseitiges Vertrauen (nur Module prüfen Core-Signatur) nicht ausreicht — Core muss bei Nachlieferung/Registrierung wissen, welche Modul-Instanz tatsächlich anfragt, sonst könnte sich ein fremder Absender als Modul ausgeben (`nexarch-state.json` Entscheidungsverlauf "Vertrauensstellung Core↔Module").
- **Wiederanlauf nach Ausfall:** sofortiger Cache-Refresh per Health-Check-Trigger, gepufferte Audit-Events/Nutzungszähler werden über das Service-Credential authentifiziert nachgeliefert, Pufferqueue muss persistent sein (Core `API-06`).
- **Rückkanal-API-Berechtigungsprüfung:** Workflow `VOR-04` (Pull-Rückkanal, damit DMS/Mail Akte/Vermerke/Wiedervorlage im eigenen Kontext anzeigen können) ist explizit als "read-only, berechtigungsgeprüft" spezifiziert — das ist der einzige Rückkanal (Pull), der zusätzlich zum bereits bestehenden Push-Kanal (Workflow `ENG-02`) existiert und daher eine eigene Berechtigungsprüfung braucht, nicht nur das Push-seitige Modul-Vertrauen wiederverwenden darf.

Dieses wechselseitige Vertrauensmodell (asymmetrische Signatur + Service-Credential) ist die Antwort auf ein OWASP-Broken-Access-Control-Szenario, das speziell durch die Modul-Architektur entsteht und in einem monolithischen Altsystem (archivdms/archivmail) so nicht vorkam — beide Known-Issues-Dokumente enthalten dazu folgerichtig keinen Eintrag.

## 7. Ausfallsicherheit als Sicherheitsthema

Verfügbarkeit ist hier aufgeführt, weil ein unkontrollierter Core-Ausfall entweder zu Totalausfall der Plattform (worst case für Verfügbarkeit) oder — schlimmer — zu unkontrolliertem Fail-open bei Rechteprüfungen führen könnte, wenn nicht bewusst entschieden wird.

- **Fail-open vs. fail-closed** ist explizit pro Aktionsklasse festgelegt (Core `API-05`/`API-06`, ausformuliert in `SKALIERUNGSKONZEPT.md` Abschnitt 11): Lesevorgänge mit abgelaufenem Rechte-Cache eher fail-open (letzter bekannter Stand gilt weiter), sicherheitskritische Aktionen (Rechteänderung, Löschung, Freigabe) eher fail-closed (lieber verweigern als mit veralteten Rechten ausführen). Das ist eine bewusste, dokumentierte Abwägung — kein Automatismus in eine Richtung.
- **Core-Hochverfügbarkeit** selbst (`SKALIERUNGSKONZEPT.md` Abschnitt 10): Anwendungsschicht ist zustandslos, echter Single Point of Failure ist die Postgres-Instanz. Stufe 1 kein Live-Failover (Backup/Restore, Archive `BAK-03`), Stufe 2/3 Streaming-Replikation mit pg_auto_failover (LXC-tauglich) oder Patroni (Multi-Standort), Verbindungsindirektion via PgBouncer/HAProxy, Fencing gegen Split-Brain.
- Wichtiger Nebeneffekt, im Skalierungskonzept explizit benannt: der JWKS-Mechanismus aus `API-05` bleibt während eines kurzen Core-DB-Failover-Fensters funktionsfähig, weil Signaturprüfung keine Core-DB-Verbindung braucht — Core-DB-Failover und die Resilienz der anderen Module sind zwei getrennte, sich gegenseitig entlastende Probleme.

## 8. Sicherheitsrelevante Betriebsaspekte

- **Transportverschlüsselung E-Mail:** TLS/STARTTLS für IMAP/POP3/SMTP (Mail `ING-06`).
- **Kein direkter Storage-Zugriff:** Up-/Downloads laufen ausschließlich über zeitlich begrenzte signierte URLs, die das Backend ausstellt — Storage-Zugangsdaten erreichen nie den Browser (`STORAGE-KONZEPT.md` Abschnitt 5, DMS `FDN-03` Akzeptanzkriterium 2). Presigned-URL-Gültigkeit soll kurz und konfigurierbar gehalten werden (Minuten, nicht Stunden).
- **Zentrales Rate-Limiting:** Core `API-03` mit Shared State statt in-process — korrigiert denselben archivdms-Mehrinstanz-Bug wie in Abschnitt 1 beschrieben, hier aber als API-weite (nicht nur Login-spezifische) Infrastruktur, seit der API/Token/Rate-Limiting-Konsolidierung (`nexarch-state.json` Entscheidungsverlauf) alleinige Quelle für alle Module — DMS/Mail betreiben kein eigenes Rate-Limiting mehr.

## 9. Bewährte Muster, die bewusst übernommen werden

Nicht jeder Fund in den Altsystemen ist ein Fehler. Beide Known-Issues-Dokumente benennen positiv zu übernehmende Muster ausdrücklich:

- **Vier-Augen-Prinzip mit `FOR UPDATE`-Lock** bei Löschbestätigung (`known-issues-archivdms.md`, Abschnitt "Positiv zu übernehmende Muster") — im NEXARCH-Kontext die passende Entsprechung für Compliance-kritische Freigaben in Archive `CMP-06` (Vier-Augen-Prinzip), wo derselbe Lock-Mechanismus gegen doppelte/konkurrierende Freigabe schützen sollte.
- **Timing-safe Vergleich** bei sicherheitsrelevanten Entscheidungen — in archivdms bei Share-Link-Passwortvergleich eingesetzt (`known-issues-archivdms.md`, Positiv-Abschnitt). Gilt als generelles Prinzip für jeden Vergleich, der eine Zugriffsentscheidung trifft (Passwort, Token, Signatur, Wiederherstellungscode aus `IAM-04`), nicht nur für Share-Links — sollte als projektweite Coding-Konvention (analog zur Sprintf-Verbots-Regel aus Abschnitt 3) festgehalten werden, ist aber in keinem Ticket als Konvention formuliert, nur implizit durch das positive Altsystem-Beispiel nahegelegt.
- **Tenant-Filter in der Query, IDOR-Guards bei Shares** — ebenfalls aus archivdms als positiv übernommenes Muster gelistet; deckt sich mit der in Abschnitt 2 verlangten Regel (Scoping in der Repository-Schicht).

## 10. CI/Merge-Gates für sicherheitsrelevanten Code

`known-issues-archivdms.md` Punkt 2 fordert explizit Testpflicht für Auth/Tenant-Scoping/Retention als Merge-Gate; `known-issues-archivmail.md` Punkt 4 fordert dasselbe für Tenant-Scoping/Protokoll-State-Machines. Beide Forderungen sind in den Known-Issues-Dokumenten als Lehre formuliert, aber in keinem gelesenen QA-Ticket (Core `QA-01`..`QA-05`, DMS `QA-01`, Mail `QA-07`) als projektweite, verbindliche CI-Regel ("kein Merge auf sicherheitsrelevanten Code ohne Test") wiedergefunden. Das ist keine fehlende Einzelentscheidung, sondern eine fehlende Verallgemeinerung einer bereits zweimal unabhängig gemachten Erfahrung — siehe Offene Punkte.

## 11. Offene Punkte

Die folgenden Themen sind entweder in keinem Board bisher behandelt oder nur am Rand erwähnt, ohne dass ein Ticket sie abdeckt. Sie werden hier bewusst nur benannt, nicht mit erfundenen Tickets vorweggenommen — das entscheidet der Nutzer:

1. ~~Security-Header für das Next.js-Frontend~~ — **geklärt (2026-08-28)**: Core `API-08` "Security-Header-Baseline für alle Frontends" deckt CSP, HSTS, X-Frame-Options, Referrer-Policy, X-Content-Type-Options als gemeinsame, wiederverwendbare Middleware ab, die jedes Modul-Frontend einbindet statt eigener Definition.

2. ~~Dependency-/Supply-Chain-Sicherheit~~ — **geklärt (2026-08-28)**: neues Ticket Core `OPS-06` "Automatisiertes Schwachstellen-Scanning (Supply-Chain)" verankert `govulncheck` (Go-Module) und `npm audit`/Dependabot (Frontend-Pakete) als verbindlichen, blockierenden CI-Schritt über alle sieben Boards. Hängt im Core-Abschluss-Gate `QA-05`.

3. ~~Schlüsselverwaltung/-rotation für den Storage-Verschlüsselungs-Master-Key~~ — **geklärt (2026-08-27), siehe Abschnitt 4**: zweistufige Hierarchie Master-KEK → Tenant-KEK → Objekt-DEK, umgesetzt in Core `API-10`.

4. ~~Verschlüsselung in Transit zwischen Modulen~~ — **geklärt (2026-08-28)**: Core `API-09` "mTLS zwischen Modul-Instanzen (verteilte Installation)" deckt genau das ab — gegenseitige TLS-Authentifizierung zwischen allen sieben Modul-Instanzen für Stufe 2/3, optional für Stufe-1-Einzel-LXC. Hängt im Core-Abschluss-Gate `QA-04`. `PROXMOX-DEPLOYMENT.md` Abschnitt 3 referenziert es bereits korrekt als ab Stufe 2 verpflichtend.

5. ~~Penetrationstest-Verfahren vor Produktivbetrieb~~ — **geklärt (2026-08-28)**: Core `QA-06` "Externe Sicherheitsprüfung / Penetrationstest vor Produktivbetrieb" deckt genau das ab, projektweit über alle sieben Boards, als externe Ergänzung zu den internen Sicherheits-Prüfgates. `QA-06` ist selbst das letzte, allem nachgelagerte Gate (hängt von `QA-05`, `QA-07`, `QA-08` ab) — der Pentest läuft also erst, wenn alles andere bereits abgenommen ist.

6. ~~Incident-Response-Plan~~ — **geklärt (2026-08-28)**: Core `OPS-04` deckt genau das ab (Erkennung, Eskalation, DSGVO-72h-Meldefrist, Verweis auf Core `AUD-01`/`AUD-05` als Vorfall-Datenquelle) und ist im `code`-Repository bereits als tatsächliches Betriebsdokument umgesetzt (`docs/INCIDENT-RESPONSE-PLAN.md`). Offen bleibt nur die Schlüssel-Notfallrotation im Vorfallsfall — die behandelt `OPS-04` nicht explizit, sollte als Ergänzung im Dokument nachgezogen werden.

7. ~~Superadmin-ohne-Tenant als First-Class-Zustand~~ — **geklärt (2026-08-28)**: Core `IAM-01` Akzeptanzkriterium 2 lautet explizit "Superadmin-ohne-Tenant ist als First-Class-Zustand modelliert" — war bei der ersten Lektüre offenbar übersehen worden, ist aber bereits vorhanden.

8. ~~Verbindliche CI-Testpflicht für sicherheitsrelevanten Code als projektweite Regel~~ — **geklärt (2026-08-28)**: Akzeptanzkriterium "Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) als verbindliches Merge-Gate" in allen 6 übrigen `QA-01`-Tickets (DMS, Mail, Archive, Workflow, AI, Connect) nachgezogen, analog zu Core `QA-01`. Jetzt projektweit einheitlich.

9. ~~Timing-safe Vergleich als projektweite Coding-Konvention~~ — **geklärt (2026-08-28)**: neues Ticket Core `IAM-15` verankert die Regel projektweit (Passwort-Hash, Token, Signatur, 2FA-Wiederherstellungscode), nicht mehr nur implizit über das archivdms-Beispiel. Hängt im Core-Abschluss-Gate `QA-05`.

10. ~~Gemeinsamer Query-Builder für Injection-Schutz~~ — **geklärt (2026-08-28)**: Entscheidung getroffen — getrennte Implementierung je Board, keine gemeinsame Utility, konsistent mit der bereits getroffenen Entscheidung, Suche/OCR nicht zu zentralisieren (siehe `nexarch-state.json` → `bewusst_nicht_zentralisiert`). Neue Tickets DMS `SRC-11` und Mail `SRC-11` verankern dieselbe Whitelist-Regel unabhängig in beiden Boards, hängen in DMS `QA-06` bzw. Mail `QA-04`.

11. **bcrypt-Kostenfaktor nicht dokumentiert.** Die Wahl bcrypt statt Argon2 ist als Faktum in `nexarch-state.json` festgehalten, aber ohne Begründung und ohne festgelegten Kostenfaktor.

12. ~~Anomalie-Erkennung bei API-Token-Nutzung (Core `IAM-09`)~~ — **geklärt (2026-09-14)**: neues Ticket Core `IAM-20` "Anomalie-Erkennung bei API-Token-/Service-Account-Nutzung" ergänzt IP-/Rate-Anomalie-Erkennung als Hinweissignal (Audit-Event, keine automatische Sperre) zur reinen Scope-/Ablaufzeit-Prüfung aus `IAM-09`. Siehe Threat-Model-Finding #2 in Abschnitt 13.

## 13. Threat Model: NEXARCH Core (STRIDE)

Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Core-Kanban (Identity, Tenancy, Auth, RBAC, Lizenzierung/Feature-Flags, Audit, zentrale Konfiguration/Benachrichtigung, Core-API/Modulverwaltung, Monitoring), analysiert anhand der Ticket-Inhalte (TEN/IAM/RBAC/AUD/LIC/CFG/API/OPS), nicht anhand des tatsächlichen Codes. Alle Findings mit Schweregrad Kritisch/Hoch/Mittel sind inzwischen als Tickets in Welle 9 und 10 des Core-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea); Finding #2 (Niedrig-Mittel) ist offen, siehe Punkt 11 oben.

### Systemüberblick

```
Client/Browser --HTTPS--> Modul-Frontend (Next.js) --> Core-API (Go/net/http)
                                                          |
                                          JWT-Middleware (IAM-02) --tenant claim--
                                                          |
                                    Connection-Router (TEN-06) --lookup--> Registry-DB
                                                          |
                                          Tenant-DB (Modell C, 1 pro Mandant)
                                                          |
                        Modul-zu-Modul (DMS/Mail/Archive/Workflow/AI/Connect) via Service-Credential (API-02) [+ optional mTLS API-09]
                                                          |
                                    Master-KEK (API-10) --wraps--> Tenant-KEK --wraps--> Objekt-DEK (in DMS/Mail)
```

Trust-Boundaries: (1) Internet/Client → Modul-Frontend, (2) Frontend/externe Aufrufer → Core-API, (3) Core-API → Registry-DB, (4) Core-API → Tenant-DB, (5) Core ↔ andere Module (Service-Credentials), (6) Core → LDAP/OIDC-Provider (extern), (7) Master-KEK-Speicherort (KMS/Secret-Provider) → Registry.

### Findings

| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|---|--------|------------|-----------|--------------|--------|
| 1 | Spoofing | IAM-02 Login/JWT | Kein Widerrufsmechanismus — gestohlenes JWT bleibt bis Ablauf gültig, kein Logout-Invalidierung serverseitig | Hoch | `IAM-17` |
| 2 | Spoofing | IAM-09 API-Token/Service-Accounts | Token-Diebstahl bei Leak — keine Anomalie-Erkennung bei Nutzung aus fremdem Kontext | Mittel | `IAM-20` |
| 3 | Tampering | TEN-07 Migrations-Orchestrierung | Migrationsdatei ohne Integritätsprüfung würde 1:N gegen alle Tenant-DBs laufen | Mittel | `TEN-10` |
| 4 | Tampering | API-10 Master-Key-Verwaltung | Master-KEK-Kompromittierung hebelt zweistufige Hierarchie komplett aus — kein Rotationszwang/Alarming | Kritisch | `API-13` |
| 5 | Repudiation | AUD-01 Audit-Log | „Append-only" nur konventionell, nicht technisch durchgesetzt (DB-Admin-Zugriff könnte ändern/löschen) | Mittel | `AUD-07` |
| 6 | Information Disclosure | API-08 Security-Header-Baseline | Gut abgedeckt (CSP/HSTS/X-Frame etc. zentral) | Niedrig | abgedeckt |
| 7 | Information Disclosure | TEN-01 Control-Plane-Registry | Höchstwertiges Einzelziel (Verbindungsinfo zu allen Tenant-DBs + Superadmin-Konten) — kein eigenes Härtungs-Ticket | Kritisch | `TEN-09` |
| 8 | Information Disclosure | IAM-05 LDAP/AD-Anbindung | LDAP-Bind-Credentials je Tenant — Speicherform (Klartext vs. verschlüsselt) nicht spezifiziert | Mittel | `IAM-19` |
| 9 | Denial of Service | TEN-06 Connection-Pooling | Ungedeckeltes LRU-Pooling ohne Rate-Limit auf Tenant-Wechsel — Pool-Thrashing-Risiko | Mittel | `TEN-11` |
| 10 | Denial of Service | LIC-02 Feature-Flag-Service | Kein definiertes Fail-Open/Fail-Closed-Verhalten bei Registry-Ausfall oder Cache-Invalidierungssturm | Mittel | `LIC-06` |
| 11 | Elevation of Privilege | RBAC-01 Rollenmodell | Keine Prüfung gegen zirkuläre/fehlerhafte Rollenvererbung Tenant-Admin → Superadmin | Hoch | `RBAC-08` |
| 12 | Elevation of Privilege | API-09 mTLS Modul-zu-Modul | Für Stufe-1 optional — Aktivierung beim Wechsel auf Stufe 2 könnte vergessen werden | Mittel | `OPS-07` |
| 13 | Elevation of Privilege | IAM-06 SSO/OIDC | Claim-Validierung (Issuer/Audience/Signatur) nicht spezifiziert — Risiko automatischer Superadmin-Ableitung aus externem Claim | Hoch | `IAM-18` |

### Bereits abgedeckt (ohne Nachbesserung nötig)

- **Tenant-Isolation strukturell** (Modell C, physisch getrennte DB) — macht klassisches "vergessener tenant_id-Filter"-Leck strukturell unmöglich (siehe `nexarch-state.json`). Kein Finding dafür.
- **Security-Header-Baseline** (`API-08`) zentral statt pro Modul.
- **Envelope-Encryption-Konzept** (`API-10`) zweistufig — richtiger Ansatz, Finding #4 betraf nur Betrieb/Rotation, nicht das Modell selbst.
- **Audit-Log als eigenständiges Modell** (`AUD-01`), DSGVO-Meldeprozess vorhanden (`OPS-04`, 72h-Frist).
- **bcrypt statt schwächerem Hashing**, Trennung Auth/Autorisierung (Casbin-Prinzip).

## 14. Threat Model: NEXARCH DMS (STRIDE)

Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: DMS-Kanban (Dokumentenkern/Upload/Storage/Verschlüsselung, Suche & OCR, Metadaten, Versionierung, Integration/API, Hot-Folder/Scanner, UX), analysiert anhand der Ticket-Inhalte, nicht anhand des tatsächlichen Codes. Identity/Auth/RBAC/Tenancy sind nach Core ausgelagert und dort bereits in Abschnitt 13 analysiert — hier nicht erneut. Alle Findings sind als Tickets in Welle 12 (Hoch/Mittel) bzw. Welle 13 (Finding #9, `DOC-18`, ergänzt 2026-09-14) des DMS-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea).

### Systemüberblick

```
Client --> DMS-Frontend --> DMS-API (auf Core-API-Grundgerüst, INT-01)
                               |
              Upload (DOC-01) --checksum DOC-02--> Storage-Adapter (FDN-03, S3/lokal)
                               |                         |
                     Envelope-Encryption (FDN-09, DEK<-Tenant-KEK aus Core API-10)
                               |
              Async-Worker (FDN-04: OCR/Konvertierung/Index) --> Manticore-Index (SRC-01)
                               |
        Externe Eingänge: Hot-Folder (INT-08), Netzwerkscanner (INT-06), CMIS (INT-09)
                               |
        Externe Ausgänge: Archive (INT-11 Retention), AI (INT-12), Workflow (INT-13)
```

Trust-Boundaries: (1) Client→API, (2) API→Storage, (3) API→Async-Worker-Queue, (4) Dateisystem-Hot-Folder (lokal, kein API-Auth)→DMS, (5) DMS↔Archive/AI/Workflow (Modul-Registrierung), (6) CMIS-Schnittstelle→Drittwerkzeuge.

### Findings

| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|---|--------|------------|-----------|--------------|--------|
| 1 | Tampering | DOC-01 Upload | Kein Malware-Scan vor Ablage (nur MIME/Größe geprüft) | Mittel | `DOC-17` |
| 2 | Tampering | INT-08 Hot-Folder | Dateisystem-Import ohne Auth-Kontext, keine explizite Tenant-Zuordnung des Verzeichnisses | Hoch | `INT-14` |
| 3 | Tampering | INT-06 Netzwerkscanner-Ordner | Gleiches Muster wie INT-08 | Hoch | `INT-14` |
| 4 | Information Disclosure | FDN-03 Storage-Adapter | Signierte URLs ohne festgelegten Scope/kurze TTL | Mittel | `FDN-10` |
| 5 | Information Disclosure | DOC-05 Inline-Betrachter | "Ohne Download-Zwang" ist UI-Ziel, keine technische Zugriffskontrolle — Hinweis, kein eigenständiges Risiko | Niedrig | Hinweis |
| 6 | Information Disclosure | INT-09 CMIS-Schnittstelle | Keine festgelegte Auth-/Tenant-Scoping-Parität zur REST-API | Hoch | `INT-15` |
| 7 | Repudiation | VER-05 Unveränderliches Protokoll | "Unveränderlich" nur konventionell, nicht technisch durchgesetzt (Analogie Core-Finding #5) | Mittel | `VER-08` |
| 8 | Denial of Service | FDN-04 Async-Worker | Keine Ressourcenlimits je Job (Zeit/Speicher/Seitenzahl) | Mittel | `FDN-11` |
| 9 | Denial of Service | DOC-08 Archiv-Bündelung | Kein Limit für Gesamtgröße/Anzahl je Bündelungs-Anfrage | Niedrig | `DOC-18` |
| 10 | Elevation of Privilege | INT-11/12/13 Modul-Registrierung | Rückkanäle (z. B. Workflow VOR-04) könnten Service-Credential-Kontext statt Nutzer-Tenant-Kontext verwenden | Hoch | `INT-16` |
| 11 | Elevation of Privilege | DOC-02 Duplikat-Prüfung | Falls Hash-Abgleich global statt tenant-scoped implementiert wird: Seitenkanal-Leck über Duplikat-Treffer | Niedrig | Hinweis, Implementierungsdetail bei Umsetzung von DOC-02 explizit tenant-scoped halten |

### Bereits abgedeckt

- **Envelope-Encryption pro Objekt** (`FDN-09`) korrekt an Core-Schlüsselhierarchie (`API-10`) gekoppelt, keine eigene Master-Key-Logik im DMS.
- **Tenant-Isolation strukturell** über Core Modell C — gilt auch hier.
- **Duplikat-Erkennung/Checksum** (`DOC-02`) als bewusste Nutzerentscheidung statt automatischem Verwerfen.
- **known-issues-archivdms.md** bereits als Vermeidungs-Checkliste im Board berücksichtigt (Rechte-Bug Ersteller-Sichtbarkeit, Superadmin-Sonderfall, Sprintf-in-SQL) — deshalb hier nicht erneut als Findings gelistet.

## 15. Threat Model: NEXARCH Mail (STRIDE)

Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Mail-Kanban (Ingestion & Protokoll-Server IMAP/POP3/SMTP, Postfach-Import, Archivierung, Suche & OCR, Integration/API), analysiert anhand der Ticket-Inhalte, nicht anhand des tatsächlichen Codes. Identity/Auth/RBAC/Tenancy sind nach Core ausgelagert (Abschnitt 13). Code-Wiederverwendung aus archivmail ist hier – anders als bei DMS – ausdrücklich erlaubt, daher liegt ein Schwerpunkt auf bekannten Altsystem-Bugs aus `known-issues-archivmail.md`. Alle Findings sind als Tickets in Welle 8 des Mail-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea).

### Systemüberblick

```
Externe Mailserver --IMAP/POP3/SMTP--> Ingestion-Server (ING-01..03, TLS/STARTTLS ING-06)
                                              |
                          Import-Scheduler (IMP-01) --Anhänge--> Virenscan (IMP-06)
                                              |
                          Archivierung (ARC-01, Objekt-Storage je Tenant-Bucket ARC-06)
                                              |
                    Envelope-Encryption (ARC-02, DEK<-Tenant-KEK aus Core API-10)
                                              |
                    Indexierung/OCR (SRC-02/SRC-07) --> Manticore-Index
                                              |
        Ausgehend: Mailer (ING-03) für Benachrichtigungen --> Core-Dispatcher (CFG-02)
                                              |
        Externe Ausgänge: Archive (INT-08 Retention), AI (INT-09), Workflow (INT-10)
```

Trust-Boundaries: (1) Externer Mailserver→Ingestion-Server, (2) Ingestion→Import-Pipeline, (3) Import→Objekt-Storage, (4) Mail-API→Client, (5) Mail↔Archive/AI/Workflow (Modul-Registrierung), (6) Mailer→externe Empfänger (ausgehend).

### Findings

| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|---|--------|------------|-----------|--------------|--------|
| 1 | Tampering | ING-03 Mailer (ausgehend) | Header-Injection bei Stringkonkatenation von From/To/Subject — konkreter, bereits im archivmail-Altsystem aufgetretener Bug (known-issues Punkt 1) | Hoch | `ING-11` |
| 2 | Elevation of Privilege | INT-08/09/10 Modul-Registrierung | Rückkanäle könnten Service-Credential-Kontext statt Nutzer-Tenant-Kontext verwenden (analog DMS-Finding) | Hoch | `INT-11` |
| 3 | Information Disclosure | INT-01/ARC-01 Anhang-Download | Signierte URLs ohne festgelegten Scope/kurze TTL (analog DMS-Finding) | Mittel | `INT-12` |
| 4 | Denial of Service | SRC-02/SRC-07 Indexierung/OCR | Keine Ressourcenlimits je Job (Zeit/Speicher/Seitenzahl), analog DMS-Finding | Mittel | `SRC-12` |
| 5 | Denial of Service | ING-09 Rate-Limiting | Bereits abgedeckt — SMTP-Annahme und Login-Versuche rate-limitiert | Niedrig | abgedeckt |
| 6 | Tampering | IMP-02/IMP-06 Anhang-Verarbeitung | Bereits abgedeckt — Virenscan mit Quarantäne vorgesehen (IMP-06), Größenlimit als Lehre aus archivmail (known-issues Punkt 3) im Board verankert | Niedrig | abgedeckt |
| 7 | Information Disclosure | ARC-06 Objekt-Storage | Bereits abgedeckt — physische Mandantentrennung je Bucket/Pfad-Root statt Präfix-Konvention | Niedrig | abgedeckt |

### Bereits abgedeckt

- **Virenscan mit Quarantäne** (`IMP-06`) bereits im Board vorgesehen, nicht erst nachträglich als Finding nötig (anders als beim DMS-Board, wo dies fehlte).
- **Physische Mandantentrennung im Objekt-Storage** (`ARC-06`) korrigiert das archivmail-Muster einer gemeinsamen Ablage mit Pfad-Präfix.
- **Rate-Limiting auf Protokollebene** (`ING-09`) für SMTP-Annahme/Login bereits vorgesehen.
- **TLS/STARTTLS verpflichtend** (`ING-06`) für alle drei Protokollserver.
- **Signatur-Prüfung bei Archivierung mit Zeitstempel** (`ARC-10`) für S/MIME/PGP-signierte Mails nach BSI TR-03125.

## 16. Threat Model: NEXARCH Archive (STRIDE)

Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Archive-Kanban (Retention & WORM, Compliance & eDiscovery, Backup & Wiederherstellung, Kennzahlen) — die zentrale, alleinige Quelle für Aufbewahrung/WORM/Compliance/Backup für DMS und Mail. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 7 des Archive-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea).

### Systemüberblick

```
DMS/Mail --Registrierung (RET-05)--> Archive Retention-Engine (RET-01..03)
                                              |
                          WORM-Speicherpfad (RET-04) --> Objekt-Storage
                                              |
                     Löschworkflow mit Vier-Augen-Prinzip (CMP-06) / DSGVO-Löschantrag (CMP-07)
                                              |
                          Compliance/eDiscovery-Export (CMP-01..03) --> Audit (Core AUD-01, CMP-04)
                                              |
                     Backup: DB (BAK-01), Objekt-Storage (BAK-02) --> Restore-Test (BAK-06)
```

Trust-Boundaries: (1) DMS/Mail→Archive (Registrierung, Service-Credentials), (2) Archive→Objekt-Storage (WORM), (3) Archive→Core-Audit-Log, (4) Backup-Ziel (extern/separates Speichersystem), (5) Restore-Testumgebung.

### Findings

| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|---|--------|------------|-----------|--------------|--------|
| 1 | Tampering | RET-04 WORM-Speicherpfad | "Kein Überschreiben" ggf. nur anwendungsseitig, nicht als Storage-Garantie (Object Lock) durchgesetzt | Hoch | `RET-11` |
| 2 | Spoofing | RET-05 Registrierungsschnittstelle | Tenant-Kontext bei Registrierung durch DMS/Mail wird ggf. ungeprüft übernommen | Hoch | `RET-12` |
| 3 | Information Disclosure | BAK-01/BAK-02 Backup | Kein festgelegter Verschlüsselungsschutz für Backup-Snapshots — schwächeres Abbild derselben Daten als das Live-System | Mittel | `BAK-09` |
| 4 | Information Disclosure | BAK-06 Restore-Testumgebung | Enthält echte wiederhergestellte Mandantendaten, Schutzniveau nicht festgelegt | Mittel | `BAK-10` |
| 5 | Repudiation | RET-03/CMP-06 Löschworkflow | Bereits abgedeckt — Vier-Augen-Prinzip und Protokolleintrag vorgesehen, Legal Hold hat Vorrang | Niedrig | abgedeckt |
| 6 | Tampering | CMP-03 eDiscovery-Export | Bereits abgedeckt — prüfsummengesicherter Export vorgesehen | Niedrig | abgedeckt |

### Bereits abgedeckt

- **Vier-Augen-Prinzip bei Löschung** (`CMP-06`) — positives Muster aus archivdms übernommen.
- **Legal Hold hat Vorrang vor Fristablauf** (`RET-03`) — verhindert versehentliche Löschung bei laufendem Rechtsverfahren.
- **DSGVO-Löschantrag mit Aufbewahrungs-Vorrangprüfung** (`CMP-07`) korrekt gegen `RET-03` abgegrenzt, keine zweite Lösch-Implementierung.
- **Prüfsummengesicherter eDiscovery-Export** (`CMP-03`).
- **Eigene, von Dokument-Retention unabhängige Backup-Prune-Policy** (`BAK-07`) — Backups laufen nicht unbegrenzt oder zu früh ab.

## 17. Threat Model: NEXARCH Workflow (STRIDE)

Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Workflow-Kanban (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang) — alleinige Quelle für Genehmigungsprozesse, Aufgaben/Fristen und Routing für DMS und Mail. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 8 des Workflow-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea).

### Systemüberblick

```
DMS/Mail --Push-Registrierung (ENG-02)--> Workflow-Engine (ENG-01, Zustandsautomat)
                                              |
                     Genehmigungen (APR-01..04) / Aufgaben & Fristen (TSK-01..05)
                                              |
                     Instanzschritt-Protokoll (ENG-04, unveränderlich)
                                              |
                     Akte & Vorgang (VOR-01..03) <--Pull-Rückkanal (VOR-04)-- DMS/Mail
                                              |
                     Regelbasiertes Routing (RTE-01..04) --optional-- KI-Vorschlag (AI WFS-02, RTE-05)
```

Trust-Boundaries: (1) DMS/Mail→Workflow (Push-Registrierung, Service-Credentials), (2) DMS/Mail←Workflow (Pull-Rückkanal VOR-04), (3) Workflow→Core-Benachrichtigungs-Dispatcher, (4) Workflow→AI (optionaler KI-Vorschlag).

### Findings

| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|---|--------|------------|-----------|--------------|--------|
| 1 | Information Disclosure / Elevation of Privilege | VOR-04 Rückkanal-API | Kein festgelegter Tenant-Kontext-Abgleich bei Pull-Anfrage von DMS/Mail — Bypass der Mandantentrennung über den Rückkanal möglich | Hoch | `VOR-06` |
| 2 | Spoofing | ENG-02 Registrierungsschnittstelle | Tenant-Kontext bei Push-Registrierung durch DMS/Mail wird ggf. ungeprüft übernommen (analog Archive-Finding) | Mittel | `ENG-06` |
| 3 | Repudiation | ENG-04 Instanzschritt-Protokoll | "Unveränderlich" nur konventionell, nicht technisch durchgesetzt (Analogie Core-Finding #5/DMS `VER-08`) | Mittel | `ENG-07` |
| 4 | Elevation of Privilege | APR-02 Vier-Augen-Freigabe | Bereits abgedeckt — generisches, modulunabhängiges Vier-Augen-Muster vorgesehen | Niedrig | abgedeckt |
| 5 | Elevation of Privilege | RTE-05 KI-Vorschlag im Routing | Bereits abgedeckt — KI liefert nur Vorschlag, regelbasierte Engine bleibt maßgebliche Entscheidungsinstanz | Niedrig | abgedeckt |

### Bereits abgedeckt

- **Vier-Augen-Prinzip für Freigaben** (`APR-02`) generisch und modulunabhängig konfigurierbar.
- **KI bleibt Vorschlag, nie Entscheidung** (`RTE-05`) — verhindert stille Rechte-/Entscheidungsverlagerung an ein optionales KI-Modul.
- **Vermerke unveränderlich nach Speichern** (`VOR-02`, Ergänzung statt Bearbeitung) — passendes Muster für Nachvollziehbarkeit, unabhängig vom technischen Append-only-Finding zu `ENG-04`.

## 18. Threat Model: NEXARCH AI (STRIDE)

Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: AI-Kanban (KI-Engine & Modell-Anbindung, Klassifizierung, Extraktion, Zusammenfassung, semantische Suche & Chat, Workflow-Vorschläge, Datenschutz & Governance) — alleinige Quelle für KI-Funktionen für DMS und Mail, optional aktivierbar über Core `LIC-02`. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 10 des AI-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea).

### Systemüberblick

```
DMS/Mail --Registrierung (GOV-01)--> AI-Governance
                                              |
                     KI-Engine (ENG-01..06) --> Ollama (Standard) / externer Cloud-Adapter (ENG-03, optional)
                                              |
              Inferenz-Warteschlange (ENG-05) --> Klassifizierung/Extraktion/Zusammenfassung/SEM-Chat
                                              |
                     Prompt-Injection-Härtung (GOV-06) / Audit-Protokollierung (GOV-05 -> Core AUD-01)
                                              |
                     Workflow-Vorschläge (WFS-01..03) --> Workflow-Board (nur Vorschlag, keine Entscheidung)
```

Trust-Boundaries: (1) DMS/Mail→AI (Registrierung, Service-Credentials), (2) AI→Ollama/externer Provider (ENG-03, ggf. Datenabfluss außerhalb der eigenen Infrastruktur), (3) Dokument-/Mailinhalt→Prompt (Prompt-Injection-Fläche), (4) AI→Core-Audit-Log, (5) AI→Workflow (Vorschlags-Rückkanal).

### Findings

| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|---|--------|------------|-----------|--------------|--------|
| 1 | Spoofing | GOV-01 Registrierungsschnittstelle | Tenant-Kontext bei Registrierung durch DMS/Mail wird ggf. ungeprüft übernommen (analog Archive-/Workflow-Finding) | Mittel | `GOV-07` |
| 2 | Denial of Service | ENG-05 Inferenz-Warteschlange | Keine Ressourcenlimits je Anfrage (Kontextlänge/Verarbeitungszeit) | Mittel | `ENG-07` |
| 3 | Tampering | GOV-06 Prompt-Injection-Härtung | Bereits abgedeckt — strikte Trennung Systemanweisung/Nutzerinhalt, Schema-Validierung, Instruktions-Muster-Erkennung explizit vorgesehen | Niedrig | abgedeckt |
| 4 | Repudiation | GOV-05 KI-Entscheidungsprotokoll | Bereits abgedeckt — Protokollierung über Core-Audit-Schnittstelle statt eigenem Log | Niedrig | abgedeckt |
| 5 | Elevation of Privilege | WFS-02/03 Workflow-Vorschläge | Bereits abgedeckt — KI liefert nur Vorschlag, regelbasierte Workflow-Engine bleibt maßgebliche Entscheidungsinstanz (siehe Abschnitt 17) | Niedrig | abgedeckt |
| 6 | Information Disclosure | ENG-03 externer Cloud-Adapter | Optionaler Datenabfluss an externen Anbieter — durch `GOV-03` (Steuerung lokal/extern je Tenant, Trainingsausschluss) technisch adressiert; DSGVO-Auftragsverarbeitungsvertrag mit externem Anbieter ist Vertragsthema, siehe `SAAS-BETRIEBSMODELL.md` Abschnitt 5a | Niedrig | organisatorisch geklärt (2026-09-14), kein Ticket |

### Bereits abgedeckt

- **Prompt-Injection-Härtung** (`GOV-06`) — ungewöhnlich vollständig für ein Planungsdokument: Trennung Systemanweisung/Inhalt, Schema-Validierung, Muster-Erkennung.
- **KI-Entscheidungen vollständig auditierbar** (`GOV-05`) über die zentrale Core-Audit-Schnittstelle statt eigenem Log.
- **Feingranulare Tenant-Steuerung** (`GOV-02`/`GOV-03`) für einzelne KI-Funktionen und lokal-vs-extern, mit explizitem Trainingsausschluss auf Kundendaten.
- **Verbrauchsobergrenzen je Tenant** (`GOV-04`) gekoppelt an Core-Lizenzsteuerung — verhindert bereits einen Teil der Ressourcenerschöpfungs-Angriffsfläche auf Tenant-Ebene (ergänzt durch `ENG-07` auf Einzelanfrage-Ebene).
- **Grounding mit Belegpflicht** (`SEM-04`/`SEM-05`) — keine Chat-Antwort ohne nachvollziehbare Quellenangabe.

## 19. Threat Model: NEXARCH Connect (STRIDE)

Erstellt mit dem `security-threat-model`-Skill am 2026-09-12. Scope: Connect-Kanban (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität) — baut vollständig auf Core auf, keine eigene API-Infrastruktur. Identity/Auth/RBAC/Tenancy nach Core ausgelagert (Abschnitt 13). Alle Findings sind als Tickets in Welle 7 des Connect-Boards umgesetzt (Board inzwischen aus dem Repo entfernt, Historie in Gitea). Letztes der sieben Boards, das mit diesem Skill durchlaufen wurde — Abschnitte 13–19 decken jetzt alle NEXARCH-Boards ab.

### Systemüberblick

```
Connector-Engine (ENG-01) --Plugin-Registrierung--> ERP/CRM (ERP-01..04), DATEV (DAT-01..03),
                                                      M365 (M365-01..03), Andere-DMS (DMS2-01..03)
                    |
      Zugangsdaten-Verwaltung (ENG-02) --verschlüsselt--> je Connector-Instanz
                    |
      Sync-Jobs (ENG-03) --Fehlerbehandlung/Retry (ENG-05)--> Drittsystem
                    |
      Alle Connector-Aktionen --> Core-Audit-Log (ENG-06)
```

Trust-Boundaries: (1) NEXARCH↔Drittsystem (OAuth/API-Key, ausgehend), (2) Connector-Engine→Zugangsdaten-Speicher, (3) Sync-Job→Drittsystem (Netzwerk, außerhalb eigener Kontrolle), (4) Connect→Core-Audit-Log.

### Findings

| # | STRIDE | Komponente | Bedrohung | Schweregrad | Ticket |
|---|--------|------------|-----------|--------------|--------|
| 1 | Information Disclosure | ENG-02 Zugangsdaten-Verwaltung | Verschlüsselung ohne festgelegte Anbindung an die zentrale Tenant-KEK-Hierarchie — Risiko eines zweiten, separat zu härtenden Verschlüsselungspfads | Mittel | `ENG-07` |
| 2 | Denial of Service | ENG-03/ENG-05 Sync-Jobs | Keine Obergrenzen für Laufzeit/Datenmenge je Sync-Lauf, Retry-Abbruchgrenze nicht technisch erzwungen | Mittel | `ENG-08` |
| 3 | Repudiation | ENG-06 Audit-Kopplung | Bereits abgedeckt — alle Connector-Aktionen an Core-Audit-Log gekoppelt | Niedrig | abgedeckt |
| 4 | Information Disclosure | DMS2-03 externe Backup-Ziele | Bereits abgedeckt — „verschlüsselter Export“ explizit vorgesehen | Niedrig | abgedeckt |

### Bereits abgedeckt

- **Alle Connector-Aktionen im Core-Audit-Log** (`ENG-06`) — Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert.
- **Verschlüsselter Export zu externen Backup-Zielen** (`DMS2-03`).
- **Keine eigene API-/Rate-Limiting-/Webhook-Infrastruktur** — vollständig auf Core aufgebaut, reduziert die Angriffsfläche gegenüber einer zweiten, parallelen Implementierung.
- **LDAP/SSO bleibt Core-Sache** — Connect dupliziert keine Identitäts-Infrastruktur.