From 2ec0230f571016a53cc8fb6df568990e606676aa Mon Sep 17 00:00:00 2001 From: Martin Date: Thu, 23 Jul 2026 17:25:45 +0200 Subject: [PATCH] =?UTF-8?q?Doku:=20Konsolidierte=20=C3=9Cbergabe=20des=20d?= =?UTF-8?q?ev-Stands=20(PM=20+=20neue=20Entwickler)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Neues Dokument docs/STAND-dev-branch.md fasst alle Entwicklungstätigkeiten auf dev zusammen: Produktionshärtung (Pakete 1-3), Benutzer-/Rollenverwaltung (A/B/C), Freigabe-Workflow + Aufgaben-Modul, Richtlinien-Governance und GAP-Report (WP1-4, E2). Enthält fachlichen Status für PM, technische Landkarte (neue Modelle, 6 Migrationen, Auth-Architektur, Modul-Guards, Fallstricke), Commit-Übersicht und nächste Schritte. HANDOVER-DEV.md und HANDOVER-PM.md verweisen prominent darauf. Co-Authored-By: Claude Opus 4.8 --- docs/HANDOVER-DEV.md | 2 + docs/HANDOVER-PM.md | 2 + docs/STAND-dev-branch.md | 150 +++++++++++++++++++++++++++++++++++++++ 3 files changed, 154 insertions(+) create mode 100644 docs/STAND-dev-branch.md diff --git a/docs/HANDOVER-DEV.md b/docs/HANDOVER-DEV.md index bcf4fe3..f07a5df 100644 --- a/docs/HANDOVER-DEV.md +++ b/docs/HANDOVER-DEV.md @@ -1,5 +1,7 @@ # Entwickler-Übergabe — ISMS-Tool +> 📌 **Aktueller Gesamtstand des `dev`-Branches (alle Entwicklungstätigkeiten, PM + Dev):** siehe **`docs/STAND-dev-branch.md`**. + > Stand: 2026-07-22 · Branch `dev` (Produktionshärtung + Benutzerverwaltung) · Basis `main` > Zweck: Kontext, Setup und Konventionen, damit ein neuer Entwickler direkt weiterarbeiten kann. > Fachlicher Status (fertig/offen) siehe **`docs/HANDOVER-PM.md`**. Neue Härtungs-/Verwaltungspakete: §10. diff --git a/docs/HANDOVER-PM.md b/docs/HANDOVER-PM.md index 94bb770..57e9bab 100644 --- a/docs/HANDOVER-PM.md +++ b/docs/HANDOVER-PM.md @@ -1,5 +1,7 @@ # Projektübergabe — ISMS-Tool (Stand für Projektmanagement) +> 📌 **Konsolidierter Gesamtstand aller Entwicklungstätigkeiten auf `dev` (PM + Dev):** siehe **`docs/STAND-dev-branch.md`**. + > Stand: 2026-07-22 · Branch `dev` (Produktionshärtung + Benutzerverwaltung; noch nicht nach `main` gemerged) > Zweck: Statusüberblick für die Weiterplanung — was ist umgesetzt, was ist offen (mit Priorität & grobem Aufwand). diff --git a/docs/STAND-dev-branch.md b/docs/STAND-dev-branch.md new file mode 100644 index 0000000..48071eb --- /dev/null +++ b/docs/STAND-dev-branch.md @@ -0,0 +1,150 @@ +# Entwicklungsstand `dev` — Konsolidierte Übergabe (PM + neue Entwickler) + +> Stand: 2026-07-23 · Branch **`dev`** (19 Commits vor `main`, gepusht auf Gitea) · Basis-Doku: `docs/HANDOVER-DEV.md`, `docs/HANDOVER-PM.md`, `docs/SPEC.md` +> Zweck: Ein Dokument, das den kompletten Stand der Weiterentwicklung auf `dev` zusammenfasst — fachlich (für PM) und technisch (für einen neuen Entwickler). `dev` ist noch **nicht** nach `main` gemergt. + +--- + +## 1. Executive Summary + +Auf `main` lag das Fundament (Auth/RBAC/Mandanten-Isolation, Assets/BIA, Risiko, Maßnahmen, Abhängigkeiten, Lieferanten, Richtlinien Phase 1/2a, Admin-Konsole Phase 1). Der Branch **`dev`** ergänzt vier große Blöcke — alle mit `tsc`+`lint`+`build`, Modul-Guard-Check und (wo relevant) Browser-Verifikation abgeschlossen: + +1. **Produktionshärtung Phase 1** — API-seitige Modul-Durchsetzung, getrennter Superadmin-Store mit eigenem Login + MFA, nicht-destruktiver Richtlinien-Re-Import. +2. **Benutzer- & Rollenverwaltung** (ohne E-Mail-Flow) — Plattform-Admin verwaltet Nutzer je Mandant; Mandanten-Admin verwaltet Nutzer **und** Rollen intern; Force-Change-Passwort, Passwort-Policy, optionale MFA je Nutzer; Popup-UI wie bei Assets. +3. **Freigabe-Workflow + Aufgaben-Modul** — Richtlinien-Freigabe an eine konkrete Person, Bearbeitung im neuen Modul „Aufgaben", Dashboard-Kachel; plus zentralisierte Richtlinien-Governance (zentrale Variablen, Schutzbedarf, Coverage-Filter nach Assessment-Level). +4. **GAP-Report-Umsetzung (Richtlinien-Vorlagenpaket)** — WP1–WP4 + E2: sechs neue Verfahrensanweisungen (ISB-Volltexte), Inline-VA-Verlinkung, Rendering-Fix, generisches editierbares Register-Datenmodell. + +**Migrationen (6 neu, laufen beim Deploy automatisch über den Init-Container):** +`platform_admins` · `policy_lifecycle_archived` · `user_mgmt_and_platform_settings` · `tasks` · `strip_tool_variable_articles` · `managed_registers` + +--- + +## 2. Für das Projektmanagement — fachlicher Status + +### ✅ Neu fertig auf `dev` + +| Thema | Nutzen | Status | +|-------|--------|--------| +| **API-seitige Modul-Durchsetzung** | Deaktiviertes Modul sperrt jetzt auch Schreibzugriffe serverseitig (nicht nur Navigation); automatischer Vollständigkeitscheck als Build-Gate | ✅ | +| **Getrennter Superadmin-Login** | Betreiber-Zugang unter `/platform/login` mit eigenem Store, ohne Mandantenkontext; Kundenfachdaten für Superadmin gesperrt | ✅ | +| **MFA (optional)** | TOTP für Plattform-Admins **und** Mandanten-Nutzer freiwillig; Policy-Flag „MFA-Pflicht" kann Erzwingung wiederherstellen; Recovery-Codes | ✅ | +| **Benutzerverwaltung (Superadmin)** | Superadmin legt je Kunde Nutzer an (Initial-/Einmal-Passwort), weist Rollen zu, deaktiviert/reaktiviert, setzt Passwörter zurück | ✅ | +| **Benutzer- & Rollenverwaltung (Kunde)** | Mandanten-Admin verwaltet **intern** Nutzer und Rollen (eigene Rollen + granulare Rechte, Standardrollen klonbar); strikt mandantengetrennt; Lockout-Schutz | ✅ | +| **Nutzer-Onboarding ohne E-Mail** | Start mit Initialpasswort + erzwungenem Wechsel beim ersten Login; E-Mail-Einladung (Paket 4) später nahtlos ergänzbar | ✅ | +| **Popup-Bedienung** | Anlegen/Bearbeiten von Nutzern über Popups wie bei Assets; Tabelle nur Anzeige | ✅ | +| **Zuständigkeiten geklärt** | Superadmin steuert Kern-Einstellungen (Module, TISAX-Tiefe); Mandanten-Admin nur seinen Bereich (Stammdaten, Nutzer/Rollen) | ✅ | +| **Richtlinien-Governance zentral** | Zentrale Variablen (Unternehmensname, Rollen, Schutzbedarf) nur in Einstellungen pflegbar; Coverage-Matrix zeigt nur Controls des aktiven Assessment-Levels (AL2 ohne „sehr hoch") | ✅ | +| **Freigabe-Workflow + Aufgaben** | Einreicher wählt Freigeber → Aufgabe; Freigeben/Ablehnen (mit Kommentar) im Modul „Aufgaben" (Vier-Augen); Dashboard-Kachel für offene Freigaben | ✅ | +| **Nicht-destruktiver Re-Import** | Richtlinien-Paket-Updates erhalten Status/Freigabe/Overrides/Variablenwerte; entfernte Einträge werden deaktiviert statt gelöscht; Änderungsreport | ✅ | +| **GAP-Report Richtlinien** | 6 neue Verfahrensanweisungen (VA-14..19), alle zuständigen VAs inline verlinkt, Rendering-Fehler behoben, verwaltete Register editierbar | ✅ | + +### 🟥 Bewusst zurückgestellt / offen + +| Thema | Anmerkung | +|-------|-----------| +| **Paket 4 — SMTP + E-Mail-Einladungs-/Reset-Flow** | Auf Kundenwunsch später; Aktivierung läuft vorerst über Initial-/Einmal-Passwort, gekapselt für spätere Token-Aktivierung | +| **Tenant-weite MFA-Pflicht scharfschalten** | Flag `securityPolicy.mfaRequired` vorhanden + von „MFA deaktivieren" respektiert; Enrollment-Erzwingung beim Login noch nicht verdrahtet (analog Force-Change-Gate) | +| **Admin Phase 2** | Impersonation, Plan/Limits, Logo-Upload, DSGVO-Export/Retention | +| **NIS2-Modul** | nie begonnen (großes Framework, Incident-Reporting mit Fristen-Timern) | +| **Richtlinien-Versionierung/Diff, DOCX/PDF-Export** | offen | +| **ISB-Freigabe der neuen GAP-Texte** | fachlicher Prozessschritt (kein Code): neue/geänderte VA-/Richtlinien-Texte durch den ISB freigeben | +| **Platzhalter-Module** | SoA & Controls, Vorfälle, Nachweise, Management-Review, KI-Chat | + +--- + +## 3. Für neue Entwickler — technische Landkarte + +> Setup, Stack, Konventionen und Fallstricke unverändert in **`docs/HANDOVER-DEV.md`** (§1–§9). Hier nur, was `dev` ergänzt. + +### 3.1 Neue Datenmodelle (Prisma) + +| Modell | Zweck | Mandantengebunden? | +|--------|-------|--------------------| +| `PlatformAdmin` | Getrennter Superadmin-Store (kein `tenant_id`), Argon2id, TOTP-Secret, Recovery-Codes, Lockout | nein (plattformweit) | +| `PlatformSetting` (Singleton) | Plattform-Policy, u. a. `mfaRequired` | nein | +| `Task` / `TaskComment` | Generisches Aufgaben-/Freigabe-Modell (erster Typ `policy_approval`), Kommentar-Historie | ja | +| `ManagedRegister` / `RegisterRow` | Generisches editierbares Register (code, columns JSON, Cross-Links supplier/asset) | ja | +| `User.*` neu | `mustChangePassword`, `mfaEnrolledAt`, `recoveryCodes` | ja | +| `PolicyDocument.archivedAt`, `PolicyRequirement.archivedAt` | Lifecycle für nicht-destruktiven Re-Import (deaktivieren statt löschen) | ja | +| `AuditLog.tenantId` nullable | Plattform-Ereignisse ohne Mandantenbezug (`scope=platform`) | — | + +Alle neuen tenant-gebundenen Modelle sind in **`TENANT_MODELS`** (`src/server/db.ts`) und haben **RLS-Policies** (in den jeweiligen Migrationen). + +### 3.2 Auth-Architektur (wichtig!) + +- **Zwei getrennte NextAuth-Instanzen:** Mandanten-Login (`src/server/auth.ts`, `/login`) und **Plattform-Login** (`src/server/platform-auth.ts`, eigener Cookie + basePath `/api/platform-auth`, `/platform/login`). Plattform-Session trägt **keinen** `tenantId`. +- **Superadmin-Bereich** liegt unter `src/app/(platform)/…` (Layout erzwingt Plattform-Session + ggf. MFA); Mandanten-App unter `src/app/(app)/…`. +- **MFA-Helfer** `src/server/mfa.ts` (otplib TOTP + Recovery-Codes) — von Plattform- und Nutzer-MFA gemeinsam genutzt. +- **Force-Change:** `(app)`-Layout prüft Kontostatus/`mustChangePassword` autoritativ aus der DB → `/change-password` bzw. Abmelde-Screen bei deaktivierten Konten. +- **Passwort-Policy:** `src/lib/password-policy.ts` (reine Validierung, client-safe) + `src/server/password.ts` (Argon2id + Generator); Quelle `TenantSettings.securityPolicy.password`. + +### 3.3 Modul-Durchsetzung (§3.4) — Konvention für neue Actions + +- Jede mutierende Server-Action eines **gegateten Moduls** läuft über `moduleGuard("")` (`src/server/action-guard.ts`): Session → `assertModuleEnabled` → RBAC. +- **Vollständigkeitscheck** `scripts/check-module-guards.ts` (als `prebuild` verdrahtet): jede Datei in `src/server/actions/` muss dort eingetragen sein (Modul-Key oder `EXEMPT`), sonst **failt der Build**. → Neue Action-Datei? Dort eintragen. +- Neues Modul **`tasks`** in `src/lib/modules.ts` (für Bestands-Tenants per Default aktiv, da fehlende `TenantModule`-Zeile = aktiv). + +### 3.4 Wo liegt was (neu) + +- **Superadmin/Plattform:** `src/app/(platform)/admin/**`, `/platform/{login,enroll-mfa,profile}`, `src/server/actions/{admin,platform,platform-users}.ts`. +- **Benutzer-/Rollenverwaltung (Kunde):** `src/app/(app)/settings/users/`, `src/server/actions/{tenant-users,account}.ts`, Komponenten `user-table.tsx`/`user-forms.tsx`/`role-manager.tsx`. +- **Aufgaben/Freigabe:** `src/app/(app)/tasks/`, `src/server/actions/tasks.ts` (+ `submitForApproval` in `policies.ts`); Dashboard-Kachel in `dashboard/page.tsx`. +- **Register:** `src/components/generic-register.tsx`, `src/server/actions/register.ts`, Definitionen in `prisma/import-managed.ts` (`GENERIC_REGISTERS`). +- **Richtlinien-Import (nicht-destruktiv):** `prisma/import-policies.ts` (Diff/Upsert, `{ dryRun }`, Änderungsreport, `archivedAt`). +- **Vorlagenpaket (Source of Truth):** `seed/isms-vorlagenpaket-v2/` — 28→**34 Dokumente** (VA-14..19 neu), `mapping.json`, `variables.schema.json`, Baseline, Nachweisregister, **`_verify.py`** (Rendering-/Anker-Check; nach Änderungen `python3 _verify.py` → **OK**). + +### 3.5 Konventionen / Fallstricke (Ergänzungen) + +- **Dev-Server & Server-Actions:** Änderungen an Server-Actions greifen im Turbopack-Dev manchmal erst nach **Neustart** des Dev-Servers. +- **Migrations-Flow Prisma 7** wie gehabt (`migrate diff --from-config-datasource … --to-schema … --script`, dann RLS-DO-Block manuell anhängen, `migrate deploy`). Data-Migrationen (z. B. `strip_tool_variable_articles`) sind reine SQL-`UPDATE`-Migrationen. +- **Zentrale Variablen** (Organisation/Rollen/Schutzbedarf-Flags, `src/lib/policy-variables.ts`) sind im Richtlinien-Editor gesperrt und werden serverseitig geblockt — nur in `/settings` pflegbar. +- **Rendering (Variante B):** Tool-Variablen-Defaults ohne führenden Artikel (`TOOL_TICKET`=„Ticketsystem" etc.); der Fließtext setzt Artikel/Deklination. Bestandswerte werden per Migration migriert. +- **Register vs. Managed-Register-Docs:** die verwalteten Register (CRYPTO/RISKMATRIX/CLASSIFICATION/HANDBUCH) sind spezifische Modelle; die neuen `REG-*` nutzen das **generische** `ManagedRegister`-Modell. `importPolicies` archiviert nur den Paket-Namensraum (L00/R*/VA-*/BASELINE/NACHWEIS) — Register bleiben unberührt. + +### 3.6 Demo-Logins (Passwort `Demo1234!`) + +- Mandanten-Login `/login`: `admin@demo.example` (Mandanten-Admin + ISB), **`bea.approver@demo.example`** (ISB, zweiter Freigeber für den Vier-Augen-Workflow), `auditor@…`, `owner@…`, `user@…`. +- Plattform-Login `/platform/login`: `admin@demo.example` (getrennte Session; MFA optional, Enrollment beim ersten Login nur wenn Policy es verlangt). + +--- + +## 4. Commit-Übersicht (`main..dev`, neueste zuerst) + +``` +95d4479 GAP WP3.1: IMPL-Texte mit verwalteten Registern verdrahtet +bd56a47 GAP WP3.0: Generisches, editierbares Register-Datenmodell + Editor +b9784e5 GAP E2: ISA 3.1.3-Stub entfernt (3.1.2 deprecated) +b7d5df4 GAP WP2.2 (Rendering Variante B) + WP4 (Feinschliff) +36c2903 GAP WP1: Neue VAs 14–19 + Register + Baseline + Eltern-Wiring +522508a GAP WP2.1: Inline-VA-Verweise + Verify-Fix (F17) +742277f Doku: Benutzer-Popups, Aufgaben-Modul, Richtlinien-Governance, Demo-Approver +1d8f563 Freigabe-Workflow + Aufgaben-Modul + Dashboard-Kachel +73c9813 Benutzerverwaltung als Popup (Einstellungen + Admin) +959d816 Richtlinien-Fixes: zentrale Variablen, Schutzbedarf zentral, Coverage nach Level +d38b265 Benutzer bearbeiten (Name/E-Mail) + Kern-Einstellungen nur Superadmin +303dcd0 Doku: Produktionshärtung + Benutzer-/Rollenverwaltung +d0821e2 Paket B — Mandanten-Admin: Benutzer- & Rollenverwaltung +3db820e Paket C — MFA optional (Superadmin + Tenant) +908b098 Paket A — Plattform-Admin: Benutzerverwaltung je Mandant +db36c79 Fundament Benutzer-/Rollenverwaltung: Schema, Passwort-Policy, Force-Change +e07dcd9 Nicht-destruktiver Richtlinien-Re-Import (Härtung Paket 3) +8e4040d Separater Superadmin-Store + eigener Login + MFA (Härtung Paket 2) +8348764 API-seitige Modul-Durchsetzung (§3.4, Härtung Paket 1) +``` + +--- + +## 5. Deployment & Verifikation + +- **Coolify-Deploy:** `dev` deployen; die 6 neuen Migrationen laufen automatisch im Init-Container (`prisma migrate deploy`), Bootstrap-Seed legt Demo-Daten + Demo-Approver an. +- **Lokale Verifikation:** `npx tsc --noEmit` → `npm run lint` → `npm run build` (führt `prebuild`-Guard-Check aus); für das Vorlagenpaket `python3 seed/isms-vorlagenpaket-v2/_verify.py` (**OK** = rückstandsfrei, Mapping sauber). +- **Merge `dev` → `main`:** liegt beim PM/Lead (Gitea-PR: `…/msolarczek/ISMS-Tool/pulls/new/dev`). + +--- + +## 6. Empfohlene nächste Schritte + +1. **ISB-Freigabe** der neuen/angepassten Richtlinien- und VA-Texte (fachlich). +2. **Paket 4** — SMTP + E-Mail-Einladungs-/Aktivierungs-/Reset-Flow (Aktivierung ist bereits gekapselt). +3. **Tenant-weite MFA-Pflicht** scharfschalten (Enrollment-Gate). +4. **Admin Phase 2** (Impersonation, Plan/Limits) oder **NIS2-Modul** — je nach Vertriebs-/Compliance-Priorität.