nexarch/SICHERHEITSKONZEPT.md

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.