msolarczekandClaude Opus 5
c8e6f30a27
Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
8.9 KiB
8.9 KiB
Sicherheit & Administration — Konzept & Empfehlung (PO)
Grundlage: STAND-dev-branch.md (Ist-Stand dev). Ziel: die genannten Punkte umsetzen und — weil Certvia selbst ein ISMS-Produkt ist — ein Sicherheitsniveau erreichen, das man dem Kunden vorlebt („eat your own dog food"). Status-Legende: ✅ vorhanden · 🟡 teilweise · 🟥 neu.
1. Eure Punkte im Ist-Abgleich (wichtig: nicht doppelt bauen)
| Anforderung | Status heute | Was fehlt / zu tun |
|---|---|---|
| E-Mail-Versand (Onboarding, Reset, Ticket-/Fristen-Benachrichtigungen) | 🟥 offen | „Paket 4" bewusst zurückgestellt; Aktivierung ist bereits gekapselt. Kompletter SMTP-/Mail-Layer + Templates neu. |
| Passwort-Reset | 🟥 offen | Hängt am Mail-Versand; aktuell nur Initial-/Einmal-Passwort. Self-Service-Reset via signiertem, kurzlebigem Token neu. |
| Passwort ändern (selbst) | 🟡 teilweise | Force-Change (/change-password) + Passwort-Policy (Argon2id) vorhanden. Freiwillige Änderung im Profil ergänzen (mit Alt-Passwort-Bestätigung). |
| 2FA / MFA | 🟡 teilweise | TOTP optional (Plattform-Admins und Mandanten-Nutzer) + Recovery-Codes vorhanden; Policy-Flag mfaRequired da. Fehlt: Enrollment-Erzwingung beim Login (Gate), optional WebAuthn/Passkeys. |
| Weiterer übergreifender Admin im Adminportal | 🟡 teilweise | Getrennter PlatformAdmin-Store + eigener Login (/platform/login) + MFA existiert. Fehlt: CRUD-UI im Adminportal, um weitere Plattform-Admins anzulegen/zu verwalten (Rollen, Sperren, Reset, MFA-Pflicht). |
Kernbotschaft: 2FA und der getrennte Superadmin-Store sind im Kern schon da — hier geht es um Erzwingung bzw. Verwaltungs-UI, nicht um Neubau. Der echte Neubau ist der Mail-Layer (und alles, was daran hängt: Reset, Einladung, Benachrichtigungen).
2. Bausteine für die genannten Punkte
2.1 E-Mail-Infrastruktur (Fundament — schaltet Reset/Einladung/Benachrichtigung frei) 🟥
- Transaktionaler Mail-Provider (SMTP oder API): z. B. Postmark/SendGrid/Mailgun/Amazon SES oder eigener SMTP. Auswahl = offene Entscheidung (§5).
- Domänen-Authentifizierung: SPF, DKIM, DMARC einrichten (sonst Spam/Spoofing). Dediziert Absender-Domain (z. B.
no-reply@certvia.de). - Template-Engine (gebrandet, Certvia): Layout-Basis + Bausteine für Einladung, Passwort-Reset, Passwort-geändert-Bestätigung, MFA-Änderung, Ticket-/Freigabe-/Fristen-Benachrichtigung.
- Queue + Retry (BullMQ/Redis ist im Stack) für zuverlässigen, asynchronen Versand; Fehler-/Bounce-Handling; Rate-Limit.
- Benachrichtigungsregeln je Nutzer/Ereignis (opt-in/opt-out, Sprache de/en), respektiert Mandanten-Isolation.
2.2 Passwort-Reset (Self-Service) 🟥
- Single-Use-Token, kurzlebig (z. B. 30–60 Min), serverseitig gehasht gespeichert (nicht im Klartext), an E-Mail gebunden.
- Enumeration-Schutz: „Falls ein Konto existiert, wurde eine E-Mail gesendet." (immer gleiche Antwort), Rate-Limit pro IP/Konto.
- Nach Reset: alle Sessions invalidieren, Bestätigungs-Mail „Passwort geändert", Audit-Log-Eintrag. Deaktivierte/geblockte Konten: kein Reset.
2.3 Passwort selbst ändern 🟡
- Profilseite „Passwort ändern": Alt-Passwort-Bestätigung, Policy-Prüfung (bestehende
password-policy.ts), danach andere Sessions abmelden (aktuelle behalten), Bestätigungs-Mail + Audit.
2.4 2FA scharfschalten & härten 🟡→
- MFA-Enrollment-Gate: bei
securityPolicy.mfaRequired(tenant-weit) oder für Plattform-Admins Enrollment beim Login erzwingen (analog Force-Change-Gate). - Recovery-Codes: Anzeige/Regenerierung, Verbrauch protokolliert (vorhanden — Flow abrunden).
- Optional/Ausbau: WebAuthn/Passkeys (phishing-resistent) als 2. Faktor; Re-Auth (Step-up) für sensible Aktionen (MFA deaktivieren, Admin anlegen, Export).
- TOTP-Secret at rest verschlüsselt speichern (falls noch Klartext) + Rate-Limit auf Code-Eingabe.
2.5 Weiterer übergreifender Plattform-Admin 🟡→
- Plattform-Admin-Verwaltung im Adminportal (
/platform/...): Liste, anlegen (Initial-Passwort/Einladung), Rollen/Rechte (z. B. „Voll-Admin" vs. „Support/Read-only"), sperren/reaktivieren, Passwort-Reset, MFA-Pflicht für alle Plattform-Admins. - Vier-Augen für kritische Plattform-Aktionen (mind. 2 Admins, kein Self-Lockout — der Lockout-Schutz existiert bereits für Tenant-Rollen, hier fürs Plattform-Level ergänzen).
- Vollständiges Audit jeder Plattform-Admin-Aktion (
scope=platform, ist im Log-Modell vorgesehen).
3. Weitere sinnvolle Sicherheitsmaßnahmen (Empfehlung, priorisiert)
P0 — sollte mit diesem Block kommen (hoher Nutzen, moderat):
- HTTP-Security-Header: CSP, HSTS,
X-Frame-Options/frame-ancestors,X-Content-Type-Options,Referrer-Policy,Permissions-Policy. (Zentraler Middleware-Layer.) - Rate-Limiting/Brute-Force an Login, Reset, MFA, API — ergänzt den vorhandenen Konto-Lockout (IP- und kontobezogen).
- Session-Härtung: kurze Idle-/Absolute-Timeouts, Session-Invalidierung bei Passwort-Reset/Deaktivierung/MFA-Änderung, „aktive Sitzungen" anzeigen + einzeln abmelden.
- Sichere Token-/Secret-Behandlung: alle Tokens single-use + gehasht; Secrets nur aus Env/Secret-Store, nie im Repo; Secret-Scanning in CI.
- Audit-/Security-Event-Log erweitern: Logins (Erfolg/Fehlschlag), Rechteänderungen, MFA-Änderungen, Exporte, Admin-Aktionen; append-only/manipulationssicher; Aufbewahrung definiert.
- Passwort-Breach-Check beim Setzen (HaveIBeenPwned k-Anonymity) zusätzlich zur Policy.
P1 — kurz danach (Betrieb/Compliance):
- Tenant-Isolationstests automatisiert (RLS-Regression) — Kernrisiko bei Multi-Tenant.
- Verschlüsselung at rest (DB + Backups), TLS/HSTS überall, Key-Rotation; TOTP-/sensible Felder verschlüsselt.
- Backups + regelmäßige Restore-Tests (dogfooding: das fordert ihr selbst als Control ein), DR-Konzept, RTO/RPO.
- Dependency-/Container-Scanning (SCA), SAST,
npm audit/Renovate; Patch-SLA. - DSGVO-Funktionen (Admin Phase 2): mandantenvollständiger Export, Löschkonzept/Retention, AVV/DPA-Bausteine, TOMs dokumentiert.
- Impersonation (Admin Phase 2) nur zeitlich begrenzt, protokolliert, mit „Support-Sitzung aktiv"-Banner (Support-Zugriff sicher machen).
- E-Mail-Change-Verifizierung (Double-Opt-in bei Adressänderung) + Benachrichtigung an alte Adresse.
P2 — mittelfristig / Reifegrad:
- WebAuthn/Passkeys, SSO (OIDC/SAML) für Enterprise-Kunden (steht im Backlog).
- Datei-Upload-Sicherheit (sobald Storage kommt): AV-Scan, MIME/Größen-Limits, kein HTML-Serving, signierte URLs.
- WAF/Reverse-Proxy + DDoS-Schutz vor der App; least-privilege DB-User; Netzsegmentierung.
- Responsible-Disclosure:
security.txt, Kontaktpfad, ggf. Bug-Bounty. - Externer Pen-Test vor „Go-Live/Skalierung"; Ergebnisse als Maßnahmen ins eigene ISMS.
- Incident-Response-Prozess für Certvia selbst (passt zum NIS2-/Vorfälle-Modul, das ihr ohnehin baut).
4. Vorschlag: Priorisierte Roadmap (integriert eure Punkte + P0)
| Reihe | Paket | Inhalt |
|---|---|---|
| 1 | Mail-Fundament | Provider + SPF/DKIM/DMARC, Queue/Retry, Certvia-Templates, Benachrichtigungsregeln |
| 2 | Auth-Self-Service | Passwort-Reset (Token), Passwort selbst ändern, E-Mail-Change-Verifizierung, Session-Invalidierung |
| 3 | MFA scharf | Enrollment-Gate erzwingen, Recovery-Codes-Flow, TOTP-Secret verschlüsselt, Step-up für sensible Aktionen |
| 4 | Plattform-Admin-Verwaltung | Weitere Superadmins anlegen/verwalten, Rollen, Vier-Augen, Plattform-Audit |
| 5 | Härtung P0 | Security-Header, Rate-Limiting, Audit-Erweiterung, Breach-Check, Secret-Scanning |
| 6+ | P1/P2 | RLS-Tests, at-rest-Verschlüsselung, Backups/Restore, DSGVO, Impersonation, WebAuthn/SSO, Pen-Test |
Pakete 1–4 sind stark verzahnt (alles hängt am Mail-Fundament); 5 läuft quer und sollte mit 1–4 kommen, nicht danach.
5. Offene Entscheidungen (bevor wir Tasks schneiden)
- Mail-Provider: API-Dienst (Postmark/SendGrid/SES …) oder eigener SMTP? (beeinflusst Zustellbarkeit, DSGVO-Ort, Aufwand)
- 2FA-Ausbau: reicht TOTP scharfschalten, oder direkt WebAuthn/Passkeys mitnehmen?
- Plattform-Admin-Rollen: nur „Voll-Admin", oder abgestufte Rollen (Support/Read-only)?
- DSGVO-Umfang jetzt (Export/Löschung/Retention) oder in eigener Runde?
- Team-Setup: 1, 2 oder 3 Entwickler parallel — dann schneide ich analog zum Wizard vertikale Lanes.
6. Nächster Schritt
Auf dieser Basis schneide ich — wie beim Wizard — Entwickler-Aufgabenpakete (mit Branch-Konvention unter dev, Akzeptanzkriterien, DoD). Sag mir die Antworten zu §5 (v. a. Mail-Provider und Team-Größe), dann lege ich los. Reihenfolge-Empfehlung: Mail-Fundament zuerst, weil Reset/Einladung/Benachrichtigung daran hängen.