msolarczek/certvia
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
37 Commits 2 Branches 0 Tags
27cbb286d03d9e140e679056ef692602299ff511
Commit Graph
11 Commits
Author SHA1 Message Date
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 e2b6dee788 Richtlinien Phase 2a: verwaltete Register-Tabellen + Anwender-Handbuch (§7b, §9.7) 
Vier neue, in die Bibliothek integrierte Dokumente (öffnen als interaktive Popups):

- Krypto-Register (VA-07): editierbare Tabelle der eingesetzten Verschlüsselung
  mit Ablaufüberwachung (läuft-ab/abgelaufen-Markierung), Baseline-Bezug
  (BL-CRY-…), voller CRUD (add/edit/delete).
- Risiko-Bewertungsmatrix (R03/VA-09): zentrale Pflegestelle mit FB-80-04-Defaults
  — 4×4-Heatmap (Schadensausmaß × EW), Risikoklassen + Akzeptanzinstanz
  (Niedrig≤3 / Mittel≤6 / Hoch≤9 / Kritisch≥12, editierbar), EW-Skala,
  7 Schadenskategorien. (Rückkopplung in die 5×5-Heatmap der Risikoanalyse folgt.)
- Klassifizierungs-Handhabungsmatrix (R02/VA-08): AA-80-20-Defaults, 4 Schutzklassen
  × 14 Aspekte mit eskalierenden Regeln; Zellen inline editierbar, Aspekt/Klasse
  hinzufügbar.
- Anwender-Handbuch (§9.7): kuratierte Themen (Passwörter/MFA, Zugriffsrechte,
  Klassifizierung, mobiles Arbeiten, E-Mail, Vorfälle) in verständlicher Sprache;
  Werte via {{VARIABLE}}-Templating → automatisch synchron zur Baseline; Deep-Links
  in die Quellabschnitte (z. B. R08 §4.1.2).

Zusätzlich: Richtlinien/Verfahren, die eine verwaltete Tabelle einbetten
(R09/VA-07, R03/VA-09, R02/VA-08), zeigen im Lesemodus einen „Vollständige Tabelle
öffnen"-Callout auf das jeweilige Register (§7b).

Datenmodell: CryptoEntry, ClassificationClass/HandlingAspect/HandlingRule,
RiskMatrixClass/RiskEwLevel/RiskDamageDimension, HandbookTopic (+ RLS).
Server-Actions mit RBAC (policy:write) + Audit-Log. Seed aus FB-80-04/AA-80-20.

Verifiziert im Browser: alle vier Register gerendert, Ablauf-/Farb-/Deep-Link-Logik,
Krypto-CRUD (add + delete) end-to-end.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-07 15:55:46 +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
msolarczekandClaude Opus 4.8 d994c94ebb IT-Service-Detail mit RACI-Matrix (VDA-ISA 6.1.3) 
- IT-Services als Assets (type IT_SERVICE) mit ITServiceProfile, Provider-Verknüpfung
- Detail-Cockpit: Stammdaten, verknüpfte Assets/Prozesse, Risiken
- RACI-/Shared-Responsibility-Matrix über den ISA-Control-Katalog
  (Control hinzufügen via datalist, Verantwortung per Klick durchschalten,
   PROVIDER/US/SHARED, Nachweis-Referenz, Löschen)
- Lieferanten/IT-Services als Pillen-Tabs (FilterTabs) auf /suppliers
- Server-Actions services.ts (create/update/delete/addRaci/cycleRaci/deleteRaci)
  mit Zod, RBAC (supplier:write) und Audit-Log
- ISA_CONTROLS-Vorschlagsliste (isa-controls.ts)
- Demo-IT-Service "Managed ERP-Hosting" mit 5 RACI-Zeilen im Seed
- de/en Übersetzungen (services, raciParty)

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-03 14:06:04 +02:00
MartinandClaude Opus 4.8 dc884062b2 Lieferantenmodul neu: Asset-basiert + Anforderungs-Engine (Phase 1) 
Referenz: docs/ISMS-Lieferantenmanagement-GEFIM.html

Architektur: Lieferanten (und IT-Services) sind jetzt Assets.
- AssetType += IT_SERVICE; SupplierProfile/ITServiceProfile als 1:1-
  Erweiterung eines Asset; alle Kind-Entitäten (Contract, Nda,
  SupplierEvidence, SupplierAssessment, ManagementDecision, Subcontractor,
  ServiceControlResponsibility, MaturityAssessment) hängen am Asset
  (keine parallele Datenhaltung). Migration + RLS; Demo neu geseedet.
- Lieferanten erscheinen im Asset-Inventar (Filter „Lieferant"/„IT-Service"),
  tragen C/I/A, nutzbar in Graph/BIA/Risiko.

Anforderungs-Engine (Herzstück, src/lib/supplier.ts):
- Schutzbedarf aus max C/I/A der verknüpften Assets → Stufe normal/hoch/
  sehr hoch; schaltet Anforderungen gestuft scharf (must/should/high/veryhigh)
- Flache Anforderungsliste (nach Themen gruppiert) mit Status-Ableitung aus
  den hinterlegten Objekten, Referenz + Herkunfts-Control (6.1.1–6.1.3)
- Gate-Logik: sehr hoch ohne Audit/Label → Kompensation (Management-
  entscheidung UND verknüpftes Risiko); „Risiko anlegen" erzeugt echten Risk
- Konformität (Konform/Teilweise/Lücken/Handlung nötig) + berechneter
  Reifegrad; ISB-Freigabe (Abweichung nur mit Begründung → Audit-Log)
- Cockpit-Detail mit Schutzbedarf-Banner + Live-Simulation der Stufe

Verifiziert: Register mit abgeleiteter Stufe/Reifegrad/Konformität,
Cockpit-Simulation (Tiers werden inaktiv), Gate bei sehr hoch ohne Audit,
„Risiko anlegen" erzeugt R-005 im Risikomodul.

Offen (Phase 2): Fragebogen-Builder, Self-Service-Portal, IT-Service-
Detail mit RACI-Matrix, Klick im Asset-Inventar öffnet Cockpit,
Scheduler-Automatisierung.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
 2026-07-03 11:57:17 +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 Fable 5 dfe27de51f Risiko-Minderung dezimal + editierbar, Bedrohungs-/Schwachstellen-Kataloge 
- Minderung je Maßnahmen-Verknüpfung jetzt dezimal (0,00–4,00 statt
  ganzer Punkte): mehrere Maßnahmen summieren sich, bis eine Dimension
  einen vollen Punkt sinkt; Rest-Risiko entsprechend dezimal (z. B.
  2,5 × 4 = 10), gerundet auf 2 Nachkommastellen, lokalisierte Anzeige
- Minderung bereits verknüpfter Maßnahmen direkt im Risiko-Bearbeiten
  editierbar (Eingabefelder je Verknüpfung + Speichern-Button);
  Komma-Eingaben werden akzeptiert
- Globale Kataloge Bedrohungen/Schwachstellen (je 15 Einträge, Seed):
  Eingabefelder schlagen per datalist Katalogwerte vor, Freitext bleibt
  weiterhin möglich (SPEC §5 Threat/Vulnerability)
- Schema: reduction*/residual* auf Float, Threat-/Vulnerability-Modelle

Verifiziert: −1 + −0,5 Minderung → Rest 2,5 × 4 = 10 · Erhöht (DB +
Anzeige), Neuberechnung auch beim Entfernen einer Verknüpfung.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
 2026-07-02 16:55:27 +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 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
MartinandClaude Fable 5 880afed391 Iteration 1: Auth (lokale Accounts), RBAC, RLS-Policies, i18n 
- Auth.js v5 mit Credentials-Provider: Argon2id-Verifikation, JWT-Session
  mit Mandanten-Kontext, Rollen und Permissions; Login-/Logout-Flow (deutsch)
- RBAC-Katalog (28 Permissions, 5 Rollen-Blueprints) mit serverseitigem
  requirePermission; Seed legt Demo-Mandant und 4 Demo-Nutzer an
- Route-Gate über Next-16-proxy.ts (UX-Ebene), autoritative Prüfung
  serverseitig via requireSession/requirePermission
- Prisma-Migrationen: init + Row-Level-Security-Policies (zweite
  Verteidigungslinie, Scharfschaltung in Härtungs-Iteration dokumentiert)
- i18n-Gerüst mit next-intl (de aktiv, en vorbereitet), Audit-Log-Helper
- Login/Logout end-to-end im Browser verifiziert; Build/Lint/Typecheck grün

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