Commit Graph
11 Commits
Author SHA1 Message Date
msolarczekandClaude Opus 4.8 db36c795bd Fundament Benutzer-/Rollenverwaltung: Schema, Passwort-Policy, Force-Change
Vorbereitung für die Benutzer- & Rollenverwaltung (Pakete A–C) ohne E-Mail-Flow.

- Schema: User.mustChangePassword (erzwungener Wechsel), User.mfaEnrolledAt +
  recoveryCodes (optionale Nutzer-MFA, Paket C); neues Singleton PlatformSetting
  mit mfaRequired (Default aus → MFA optional). Migration additiv + Grant/Seed.
- RBAC: neue Permission role:manage (Rollenverwaltung), dem Mandanten-Admin
  zugewiesen; für den bestehenden Demo-Mandanten nachgezogen (neue Tenants via
  provision/seed automatisch).
- Passwort-Policy: lib/password-policy.ts (client-safe Validierung/Beschreibung,
  Defaults + Ableitung aus TenantSettings.securityPolicy) und server/password.ts
  (Argon2id-Hash + policy-konformer Einmal-Passwort-Generator).
- Force-Change-Flow: /change-password (außerhalb der (app)-Shell) + Self-Service-
  Action changeOwnPassword (policy-geprüft, Audit). (app)-Layout erzwingt den
  Wechsel autoritativ aus der DB und sperrt deaktivierte Konten (Abmelden-Screen).

tsc + lint + build + Guard-Check grün.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-22 09:18:05 +02:00
msolarczekandClaude Opus 4.8 8e4040d1da Separater Superadmin-Store + eigener Login + MFA-Pflicht (Phase-1-Härtung Paket 2)
Plattform-Administratoren sind nicht länger isPlatformAdmin-Nutzer innerhalb eines
Mandanten, sondern ein getrennter Store mit eigener Auth-Domäne — Voraussetzung
für den sicheren Betrieb beim ersten echten Kunden.

Store & Migration
- Neues Modell PlatformAdmin (kein tenant_id): Argon2id-Hash, TOTP-Secret,
  Recovery-Codes (nur SHA-256-Hashes), Fehlversuchszähler + Sperre, lastLogin.
- AuditLog.tenant_id nullable → mandantenlose Plattform-Ereignisse (scope=platform).
- Datenmigration: bestehende isPlatformAdmin-Nutzer in den neuen Store übernommen
  (gleicher Hash → Login sofort möglich), Flag mandantenweit auf false gesetzt.

Getrennter Login + MFA
- Zweite NextAuth-Instanz (server/platform-auth.ts) mit eigenem Cookie und
  eigenem basePath /api/platform-auth; Session trägt bewusst KEINEN tenantId.
- TOTP-MFA (otplib): Enrollment beim ersten Login (/platform/enroll-mfa, QR +
  Klartext-Secret), danach bei jedem Login erzwungen; 10 einmalige Recovery-Codes.
- Härtung: Konto-Sperre nach 5 Fehlversuchen (15 min), Audit aller Anmeldungen,
  Fehlversuche und Sperren (scope=platform).

Autorisierung / Trennung
- Admin-Konsole nach (platform)/admin verschoben; (platform)/layout.tsx erzwingt
  Plattform-Session + aktivierte MFA. Mandanten-Session hat KEINEN Zugriff auf /admin.
- Mandanten-Shell zeigt keinen /admin-Link mehr; admin-Actions prüfen die
  Plattform-Session statt des abgelösten Flags.
- provision/seed setzen isPlatformAdmin nicht mehr; Seed legt den Demo-Plattform-
  Admin (admin@demo.example) im getrennten Store an.

Browser-verifiziert: Plattform-Login → erzwungenes MFA-Enrollment → Recovery-Codes →
/admin; Login ohne Code scheitert (?error=1); Mandanten-Session auf /admin wird auf
/platform/login umgeleitet. tsc + lint + build + Guard-Check grün.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-20 20:55:12 +02:00
msolarczekandClaude Opus 4.8 0e3ed82b21 Admin-Konsole & Mandantenverwaltung (Phase 1)
Plattform-Admin-Konsole (Superadmin) + Kunden-Einstellungsbereich:

- Datenmodell: TenantSettings (Quelle der ISMS-Template-Variablen), TenantModule
  (Feature-Toggles je Mandant), Tenant += short/sector, TenantStatus += ARCHIVED,
  AuditLog += scope (tenant|platform); RLS für die neuen Tenant-Tabellen.
- Wiederverwendbare Provisionierung (server/provision.ts): Rollen+Permissions,
  erster Admin-User, Einstellungen, alle Module, optional Richtlinienpaket-Seed +
  TISAX-Default; idempotent + Audit (§3.7). syncPolicyVariablesFromSettings mappt
  Stammdaten → ISMS-Variablen (ORG_NAME, ISMS_SCOPE, ROLE_* …).
- Admin-Konsole /admin (Guard isPlatformAdmin): Mandantenliste, „Neuer Kunde"
  (anlegen + provisionieren), Detailseite mit Modul-Toggles, Lebenszyklus
  (aktiv/gesperrt/archiviert), Nutzerliste. Aktionen im Plattform-Audit-Log.
- Kunden-Einstellungen /settings (Guard tenant:manage): Unternehmensdaten,
  verantwortliche Rollen, Branding/Regionales, TISAX-Level — Stammdaten speisen
  die ISMS-Variablen (eine Pflegestelle). Modul-Übersicht.
- Modul-Gating der Navigation (deaktivierte Module ausgeblendet); Login bereits
  für gesperrte/archivierte Mandanten blockiert (auth.authorize).
- Seed: Demo-Mandant mit Einstellungen, 12 aktiven Modulen; admin@demo.example
  = Superadmin.

Verifiziert: tsc/lint/build grün; Seed rollt Einstellungen/Module/Superadmin aus.
(Browser-Verifikation diese Sitzung nicht möglich — Preview-Tools getrennt.)

Offen (Phase 2): separater Superadmin-Store + eigener Login + MFA-Pflicht;
Impersonation (zeitlich begrenzt, protokolliert); Plan/Limits; Logo-Upload/
Objektspeicher; SMTP/Benachrichtigungen; per-Route-Modul-Enforcement (serverseitig);
Datenexport/Löschung/Retention (DSGVO); SSO.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-19 20:38:10 +02:00
msolarczekandClaude Opus 4.8 89b0e3a5a5 Richtlinien & Verfahren (Phase 1): Import, Rendering-Engine, Bibliothek, Coverage
Fundament des VDA-ISA-2027-Richtlinienmoduls (Spec §1–9):

- Datenmodell: PolicyDocument, PolicyRequirement, PolicyVariable (Variablen +
  Feature-Flags), PolicyBaselineParam, PolicyEvidence — inkl. RLS + Tenant-Guard
- Seed-Importer (import-policies.ts): liest die echten .md-Dateien (15 Richtlinien
  L00/R01–R14 + 11 Verfahren), mapping.json (120 Anforderungen/46 Controls),
  variables.schema.json (53 Variablen/Flags), Technische-Sicherheits-Baseline
  (31 BL-Parameter) und Nachweisregister; idempotent pro Mandant
- 6 im Vorlagenpaket beschädigte Variablen-Tokens (VA-08/09/10/12/13) repariert
  (dokumentiert im README des Übergabepakets)
- Rendering-Engine (policy-render.ts, Handlebars + marked): verschachtelte
  {{#if FLAG}}, {{VARIABLE}}, {{LINK:…}}-Deeplinks, Hidden-Anker + BL-Referenzen
  im Lesemodus entfernt (Wert bleibt), zentral verwaltete Abschnitte unterdrückt,
  wiederholtes „Umsetzung bei <Org>" reduziert (§7a); lenienter Fallback +
  Residue-Check über alle Flag-Kombinationen (analog _verify.py)
- UI: Bibliothek mit Typ-Chips/KPIs, Lesemodus-Popup (einklappbare Info-Tabelle,
  Control-Chips, Richtlinie↔Verfahren-Verlinkung), Coverage-Matrix
  (Control → Richtlinie → MUSS/SOLL → Verfahren → Anforderungs-IDs)
- Nav-Punkt „Richtlinien" aktiviert; de/en-Übersetzungen

Verifiziert: Import 28 Dokumente/120 Anforderungen; Rendering rückstandsfrei
über alle Flag-Kombinationen; Bibliothek, Lesemodus (R08 nested flags), Coverage
im Browser.

Später (Phase 2+): Bearbeiten/Freigabe-Workflow mit Versionierung, verwaltete
Tabellen (Krypto-/Risiko-/Klassifizierungsregister), Anwender-Handbuch,
DOCX/PDF-Export, Word-Upload, KI-Wizard, zentrale Baseline-/Variablen-Einstellseite.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-07 13:35:59 +02:00
MartinandClaude Opus 4.8 32ab91efbf Iteration Teil D: Lieferantenmanagement (VDA-ISA 2027 Kap. 6 + NIS2)
Datenmodell (Prisma, RLS): Supplier + SupplierAsset, SupplierAssessment,
Contract, Nda, SupplierEvidence, ServiceResponsibility, Subcontractor,
ManagementDecision, SupplierControl (globaler Katalog) +
SupplierControlMaturity.

- VDA-ISA-2027-Kap.-6-Mini-Katalog (Controls 6.1.1–6.1.3) mit Zielbild,
  Muss/Soll, Anforderungen für hoch/sehr hoch, Simplified Group
  Assessment, Ziel-Reifegrad 3 und Cross-Referenzen (ISO/NIST/BSI); im
  Seed befüllt
- Lieferantenverzeichnis mit KPIs (gesamt, NIS2-relevant, ablaufend,
  Reviews fällig), Kritikalität, NIS2-Flag, Review-Fristen
- Detail-Popup: Stammdaten (Sektor/Leistung/Datenkategorien/CIA),
  betroffene Assets, VDA-ISA-Reifegrade je Control (Ziel 3, farbige
  Balken), Nachweise (Angemessenheit + Ablauf), Assessments, Verträge
  (AV/DPA, Flow-down, Fristen), NDAs (Fristen), Shared-Responsibility-
  Matrix, Subunternehmer, Managemententscheidungen
- Bearbeiten-Popup: Stammdaten (ein Speichern), Reifegrad je Control,
  Add/Delete für alle Kind-Entitäten, Löschen im ⋯-Menü
- Regel 6.1.1: fehlt geprüfter Audit-/TISAX-Nachweis → Warnung, dass
  eine dokumentierte risikobasierte Managemententscheidung nötig ist
- Server-Actions mit Zod/RBAC/Audit-Log; Seed mit Demo-Lieferant
  (TISAX-Label, AV/DPA, NDA, Assessment, RACI, Reifegrade)
- Menüpunkt „Lieferanten" aktiv; Lieferant ↔ Asset verknüpft (Graph)

Verifiziert: Register/Detail/Bearbeiten dunkel & vollständig, Reifegrad-
Save (6.1.2→4 mit Audit), Managemententscheidungs-Logik.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-03 10:23:02 +02:00
MartinandClaude Opus 4.8 d9685b65b9 Iteration Teil B: Modul „Abhängigkeiten & kritische Pfade"
Referenz: docs/ISMS-Abhaengigkeitskarte-GEFIM.html

- Graph-Ableitung serverseitig (dependency-graph.ts) aus Process,
  ProcessAsset(role), Asset, AssetRelation — keine redundante Haltung.
  Kritikalität je Knoten (BIA / max C·I·A), kritische Kanten (beide
  Endknoten ≥ Schwellwert), kritischer Pfad (DFS), SPOF-Erkennung
  (transitiv abhängige kritische Prozesse ≥ N)
- React-Flow-Canvas (Topology-Look, dunkle Leinwand + Punktraster):
  Custom-Nodes mit Typ-Icon, Kritikalität, Status-Punkt, SPOF-Badge;
  smoothstep-Kanten mit Labels; kritische Kanten rot + Glow
- dagre-Auto-Layout (links Prozesse → rechts Assets); Toolbar mit Suche
  (Fokus/Zentrieren), Toggle „Kritische Pfade", Fit, PNG-Export;
  Knoten-Klick hebt zusammenhängenden Pfad hervor, Rest abgedunkelt
- Analyse-Panel: kritische Prozesse/Kanten, SPOF-Liste, kritischster
  Pfad, Legende
- Eigener Menüpunkt „Abhängigkeiten"; Absprung aus Asset-/Prozess-Detail
- Theme-Tokens für React Flow (Controls, kritische-Kanten-Glow)

Verifiziert: 10 Knoten/9 Kanten korrekt aus Demo-Daten, SPOF (Cloud-
Hoster, Kundendatenbank), kritischster Pfad, Toggle & Such-Fokus.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-03 09:53:49 +02:00
MartinandClaude Opus 4.8 7afd7f6acf Iteration Teil A: Dark-Theme (zentrale Token-Umstellung)
Referenz: docs/ISMS-Abhaengigkeitskarte-GEFIM.html

- Zentrale Theme-Definition in globals.css auf das dunkle GEFIM-Muster:
  Flächen (--bg-0/1, --panel, --elevated), Text (--txt/--muted),
  Marke (aufgehelltes Violett #7d6fd6), Status (--ok/warn/risk/info),
  Verläufe (--grad-primary/--grad-critical), Glow-Ambiente auf dem Body,
  Fokus-Ring, Punktraster-Utility
- Alle shadcn-Tokens (background/card/popover/primary/muted/border/
  sidebar …) auf Dunkelwerte gemappt; neue semantische Flächen-Tokens
  (panel/elevated/surface-soft/band/band-text/band-brd) ergänzt
- Hardcodierte Hex projektweit auf Tokens umgestellt: Panel-/Band-
  Flächen, Status-Pillen (Alpha-Tints), Tags, Trend-/Prioritätsfarben,
  Kanban, Login-Fehler, Topbar, Filter-Tabs
- GEFIM-Logo als weißes Negativ auf Dunkel (Sidebar + Login)
- Ampel-Segmentbalken/Score-Skala bleiben als semantische Statusfarben

Dark ist Default; Light-Mode später über dieselben Token-Namen möglich.
Verifiziert: Dashboard, Risiko-Detail, Asset-Bearbeiten dunkel & lesbar.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-03 08:55:35 +02:00
MartinandClaude Fable 5 668e587881 Iteration 4 (Maßnahmen) + Risikoanalyse nachgeschärft
Risikoanalyse:
- Risiko direkt aus dem Asset-Popup erstellbar ("+ Risiko erstellen"
  → Anlege-Popup mit vorverknüpftem Asset)
- Brutto-/Rest-Risiko detailliert: Eintrittswahrscheinlichkeit und
  Schaden als beschriftete Werte (X × Y = Score-Pille)
- Rest-Risiko wird NICHT mehr manuell erfasst, sondern automatisch aus
  den verknüpften Maßnahmen berechnet (Minderung je Dimension, Summe,
  Untergrenze 1; src/server/risk-calc.ts); Neuberechnung bei jeder
  Änderung an Bewertung oder Maßnahmen-Verknüpfungen
- Risikoregister unterhalb der Heatmap in voller Breite

Maßnahmen-Modul (SPEC §4.4):
- Measure/RiskMeasure-Schema mit RLS, laufende Nummer (M-001),
  Status/Priorität/Owner/Fälligkeit
- Kanban-Board mit Drag-and-Drop (dnd-kit): Karten zwischen Offen /
  In Umsetzung / Erledigt verschieben aktualisiert den Status per
  Server-Action inkl. Audit-Log; überfällige Karten rot markiert
- Maßnahmen-Popups (Detail read-only / Bearbeiten / Anlegen) nach
  App-Muster; Detail zeigt verknüpfte Risiken mit Minderung
- Im Risiko-Bearbeiten: bestehende Maßnahme verknüpfen ODER neue
  Maßnahme direkt anlegen & verknüpfen (jeweils mit Minderung
  Wahrscheinlichkeit/Schaden); "Notwendige Maßnahmen" im Risiko-Detail
  jetzt echt
- Seed: 4 Beispiel-Maßnahmen, Rest-Risiken daraus berechnet

Verifiziert im Browser: DnD-Statuswechsel (beide Richtungen, Audit-
Einträge), Rest-Risiko-Berechnung (R-001: 4×5=20 → 2×4=8), Risiko-
Anlage aus dem Asset inkl. automatischer Verknüpfung.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 16:07:59 +02:00
MartinandClaude Fable 5 df634e356d Iteration 3: Risikoanalyse + Menü-Trennung + Prozesskategorie
- Risiko-Modul (SPEC §4.2): Risk/RiskAsset-Schema mit RLS, laufende
  Nummer je Mandant (R-001), Brutto-/Rest-Bewertung (5×5), Behandlung,
  Status, Owner- und Prozess-Bezug, n:m betroffene Assets
- /risks im Mockup-Layout: 5×5-Heatmap (Farb-Bänder + R-Chips, Legende,
  Achsen) und Risikoregister mit Score-Pillen, Behandlungs-Tags, Status
- Risiko-Popups nach App-Muster: Read-only-Detail (Bewertungs-Band
  Brutto vs. Rest, betroffene Assets, Maßnahmen-Platzhalter für
  Iteration 4), Bearbeiten im Popup (Bewertung, Assets verknüpfen,
  Löschen), Anlegen; Server-Actions mit Zod, RBAC und Audit-Log
- Menü aufgetrennt: eigene Punkte "Asset-Inventar", "Business Impact
  Analyse" und "Risikoanalyse" (Modul-Tabs entfernt)
- Prozesskategorie (Kernprozess/Managementprozess/Unterstützender
  Prozess): Schema-Feld, Formulare, Listen-Spalte, Popup-Tag
- Asset-Detail-Popup optisch ans Prozess-Popup angeglichen (Stammdaten-
  Karte mit violettem Rand, Abhängigkeiten-Tabelle, Risiken-Band)
- "Zugeordnete Risiken" jetzt echt: im Asset-Popup (verknüpfte Risiken)
  und im Prozess-Popup (direkt + über Assets aggregiert); Dashboard-KPI
  "Offene Risiken" mit echten Zahlen; Seed mit 4 Beispiel-Risiken

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 15:43:25 +02:00
MartinandClaude Fable 5 0befcc6a2c GUI ans Mockup-Design angepasst (GEFIM-Branding)
- GEFIM-Farbwelt aus dem Mockup als shadcn-Theme: Violett #5d52a3 als
  Primärfarbe, Magenta/Hellblau-Akzente, Ink-Text, #f5f6fa-Hintergrund,
  Verlaufs-Utilities (bg-grad, bg-grad-soft), Karten-Schatten
- Fonts Poppins (Überschriften/Buttons) + Open Sans (Text), self-hosted
  über next/font — kein Google-CDN-Aufruf zur Laufzeit (DSGVO)
- Sidebar mit extrahiertem GEFIM-Logo (public/gefim-logo.png), aktive
  Navigation in Violett wie im Prototyp
- Sticky Topbar mit globaler Suche (leitet vorerst auf die Asset-Suche),
  Nutzer-Info und Verlaufs-Avatar mit Initialen; Logout in die Topbar
- Primär-Buttons mit Verlaufshintergrund, Level-Badges als Pillen in
  Mockup-Farben, Login-Seite im GEFIM-Look
- Dashboard im Mockup-Stil: KPI-Karten (Assets, Prozesse, kritische
  Prozesse, Risiken-Platzhalter) und Letzte-Aktivitäten-Feed aus dem
  echten Audit-Log

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 13:51:11 +02:00
MartinandClaude Fable 5 392bb246cf Iteration 2: Assets & BIA als gemeinsames Modul
- App-Shell mit Seitennavigation (alle 12 Module, kommende ausgegraut),
  shadcn/ui-Setup (Base-UI-Variante) mit hellem Theme
- Asset-Inventar: filterbare Liste (Suche/Typ/Status), Anlegen/Bearbeiten/
  Löschen, Detailansicht mit Schutzbedarf (C/I/A 1–4), Abhängigkeiten
  (beide Richtungen, hinzufügen/entfernen), zugeordneten Prozessen mit
  Primär-/Sekundär-Rolle und Platzhalter für zugeordnete Risiken
- Prozesse & BIA: Liste mit Kritikalität/RTO/MTD, Prozess-Detail mit
  Asset-Zuordnung nach Rolle (primär/sekundär), BIA-Formular
  (RTO/RPO/MTD, Schadenshöhe je Schutzziel, Kritikalität nach Max-Prinzip)
- Server-Actions mit Zod-Validierung, requirePermission und Audit-Log
  für jede schreibende Aktion; Tenant-Guard um upsert-Injektion erweitert
- Prisma: Asset, AssetRelation, Process, ProcessAsset, BiaEntry
  inkl. RLS-Policies; Seed mit Beispiel-Assets, Prozessen und BIA
- Im Browser verifiziert: CRUD, Relationen, BIA-Speichern, Audit-Einträge

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 12:35:19 +02:00