craftvia/docs/PROMPT-lane-haertung.md

Kickoff-Prompt — Lane Sicherheitshärtung (certvia)

Diesem Prompt einem Entwickler/Claude-Code-Agenten geben. Bootstrapt in certvia + diese Lane.

Du übernimmst die Lane „Sicherheitshärtung" am Produkt „certvia" (ISMS-Tool, Multi-Tenant
Next.js-16 / Prisma-7 / Postgres+RLS / Auth.js-v5). Repo: ~/Projects/ISMS-Tool, Branch `dev`.

WICHTIG: certvia ist strikt getrennt von jedem anderen Produkt (insb. „visitvia"). Nichts vermischen.

BRANCH/CHECKOUT:
   Arbeits-Branch: `lane-haertung` (KEIN `feature/`-Prefix — origin-Namespace-Konflikt).
   git fetch origin && git checkout dev && git checkout -b lane-haertung.
   Remotes: origin = https://git.certvia.de/msolarczek/certvia.git · local-gitea (intern).

1) PFLICHTLEKTÜRE:
   - docs/HANDOVER-DEV.md, docs/SPEC.md, docs/STAND-dev-branch.md
   - docs/KONZEPT-haertung.md          ← dein Fahrplan
   - docs/KONZEPT-backup-restore.md §9 ← das gemeinsame Verschlüsselungs-Primitiv

2) AUFTRAG (Phasen aus dem Konzept §7):
   (1) PEPPER (App) — JETZT, solange test/dev-DBs frisch/leer sind.
   (2) Host-Encryption (LUKS/Volume) + verschlüsselte Backups (Ops, mit Backup-Lane).
   (3) Secrets-Register formalisieren.
   (4) DB-TLS (sslmode) + Vault/KMS = Phase 2.

3) VERBINDLICHE REGELN:
   - PEPPER: über Argon2-`secret` bei hash() UND jeder verify()-Stelle. Env `PASSWORD_PEPPER`
     (32-Byte hex). Nach Option C ist der verify-Pfad zentral (Login gegen Identity) → wenn nötig
     einen verifyPassword(hash,pw)-Wrapper einführen, damit Pepper EINE Stelle ist.
   - ⚠ Pepper ist NICHT rotierbar ohne Passwort-Reset für alle (wie MFA_ENC_KEY) → bewusst
     JETZT setzen, leere DBs nutzen. Restore-Kohärenz: Pepper ist Umgebungs-Secret, nicht im Artefakt.
   - Argon2-PARAMETER sind ERLEDIGT (src/server/password.ts, ARGON2_OPTIONS) — nicht anfassen,
     nur den `secret` ergänzen.
   - Host-Encryption/Backup-Verschlüsselung sind OPS-Runbook (kein App-Code) → in
     docs/DEPLOY-PROD-CONTABO.md als Go-Live-Punkte ergänzen; §9-Mechanismus (AES-256 client-seitig,
     Keys pro Umgebung) verwenden.
   - Secrets-Register: AUTH_SECRET · MFA_ENC_KEY · PASSWORD_PEPPER · pgBackRest-Key · age-Keypair;
     je Umgebung getrennt, nie im Artefakt-Bucket, Offline-Kopie versiegelt.

4) ARBEITSWEISE:
   - Gate vor JEDEM Merge: tsc · lint · build · ALLE scripts/test-*.ts. Der Pepper braucht einen Test
     (hash+verify mit gesetztem Pepper; verify schlägt fehl bei falschem/fehlendem Pepper).
   - DevOps: lane-haertung → git merge --no-ff nach dev → Gate grün → Push auf BEIDE Remotes →
     STAND pflegen.

5) KOORDINATION: §9-Verschlüsselung gemeinsam mit Lane Backup (Mechanismus/Keys entschieden — einmal
   abstimmen). Pepper-Rollout NUR auf Umgebungen mit leerer/frischer DB (sonst Passwort-Reset nötig).

6) NICHT TUN: keine Auth-Logik-Änderung außer dem Pepper; keine Rotation eines gesetzten Peppers/
   MFA_ENC_KEY ohne expliziten Reset-Plan; Argon2-Parameter unverändert lassen.

Erste Schritte: (a) Pflichtlektüre + Fragen, (b) Pepper-PR-Plan (Env, verify-Wrapper, Test) +
Bestätigung „Pepper jetzt setzen, DBs leer" einholen, (c) umsetzen. Warte nach (a)/(b).