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>
msolarczekandClaude Opus 4.8
0e3ed82b21