craftvia/docs/_certvia-archiv/DEPLOY-PROD-CONTABO.md

# Deployment: Produktivserver (Contabo-VPS via Coolify)

> Zielumgebung: öffentlicher Contabo-VPS, eigene Coolify-Instanz, Git (Gitea) auf
> demselben VPS, Domain **app.certvia.de** mit echtem Let's-Encrypt-TLS.
> Ergänzt `docs/DEPLOY-COOLIFY.md` (Testserver). Deploy-Datei: `docker-compose.coolify.yml`.

## Unterschiede zum Testserver

| Aspekt | Test (intern) | Produktiv (Contabo) |
|--------|---------------|---------------------|
| Erreichbarkeit | intern, HTTP, sslip.io | öffentlich, **HTTPS**, `app.certvia.de` |
| Git-Quelle | internes Gitea | **Gitea auf dem VPS** (Release-Push) |
| Erst-Admin | Demo-Seed (`RUN_DEMO_SEED=true`) | **Bootstrap-Admin** (`BOOTSTRAP_ADMIN=true`), **kein** Demo-Seed |
| Secrets | Testwerte | **frische, starke** Secrets |
| Backups | optional | **Pflicht** (pg_dump + Restore-Test) |
| Branch | `dev` | `main` |

---

## Phase 1 — VPS-Grundlage

1. **Contabo-VPS** bereitstellen — **≥ 8 GB RAM** empfohlen (Next-Build ~1 GB + Stack). Bei weniger RAM zwingend Swap:
   ```bash
   fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile
   echo '/swapfile none swap sw 0 0' >> /etc/fstab
   free -h
   ```
2. **Grundhärtung**: System aktualisieren, SSH-Key-Login (Passwort-Login aus), unattended-upgrades.
3. **Firewall** (ufw): nur benötigte Ports offen — `80`, `443`, SSH, sowie der Gitea-SSH-Port (s. Phase 2).
4. **Coolify installieren** (offizielles Installskript) — eigene, unabhängige Instanz.

## Phase 2 — Gitea auf dem VPS

5. Gitea als **Coolify-Ressource** (One-Click/Compose) aufsetzen, eigene Subdomain (z. B. `git.certvia.de`), TLS via Coolify.
6. Repo `ISMS-Tool` in diesem Gitea anlegen.
7. Lokal ein **zweites Remote** hinzufügen und beim Release `main` dorthin pushen:
   ```bash
   git remote add prod https://git.certvia.de/<org>/ISMS-Tool.git
   git push prod main
   ```
   (Das ist der bewusste „Release-Push" — Prod deployt nur, was hier landet.)

## Phase 3 — DNS & Domain

8. Bei eurem DNS für `certvia.de` einen **A-Record** `app.certvia.de` → Contabo-IP anlegen (ebenso `git.certvia.de`).
9. Coolify vergibt/prüft danach automatisch das Let's-Encrypt-Zertifikat (VPS ist öffentlich erreichbar).

## Phase 4 — App-Ressource (Prod) in Coolify

10. **＋ New Resource** → Git-Quelle = das **VPS-Gitea** (Deploy-Key), Repo `ISMS-Tool`, **Branch `main`**.
11. **Build Pack: Docker Compose**, **Compose Location: `docker-compose.coolify.yml`**.
12. **Domain** beim Service `app` = `https://app.certvia.de:3000` (Port 3000), Schema **https**.
13. **Environment-Variablen** aus `.env.prod.example` setzen (Runtime-Variablen). Kritisch:
    - Alle Secrets **frisch** (`AUTH_SECRET` neu: `openssl rand -base64 32`; neue DB-/MinIO-Passwörter).
    - `AUTH_URL=https://app.certvia.de` (exakt die App-Domain).
    - `RUN_DEMO_SEED=false` (bzw. weglassen).
    - **Bootstrap** (erster Deploy): `BOOTSTRAP_ADMIN=true` + `BOOTSTRAP_ADMIN_EMAIL/PASSWORD/NAME` + `BOOTSTRAP_TENANT_NAME/SLUG`.
14. **Persistent Storage** prüfen — v. a. `pgdata` (sonst Datenverlust bei Redeploy).

## Phase 5 — Erster Deploy & Bootstrap

15. **Deploy**. Ablauf: `postgres` (healthy) → `migrate` (migriert **und** legt via `BOOTSTRAP_ADMIN=true` den Erst-Admin an) → `app`.
16. In den **`migrate`-Logs** prüfen: `>> Bootstrap-Admin läuft…` → `✔ Bootstrap fertig: Mandant … + Plattform-Admin … angelegt.`
17. **Login** unter `https://app.certvia.de` mit den `BOOTSTRAP_ADMIN_*`-Zugangsdaten → **Passwort sofort ändern**.
18. Optional danach `BOOTSTRAP_ADMIN` auf `false` (das Skript ist idempotent, es schadet aber nicht, es an zu lassen).

## Phase 6 — Backups & Betrieb (vor „echtem" Go-Live)

19. **Postgres-Backups**: regelmäßiger `pg_dump` (oder Coolify-DB-Backup nach S3) + **Restore-Test** dokumentieren. `pgdata` ist das kritische Volume.
20. **MinIO-Backup**, sobald Datei-/Logo-Upload aktiv ist.
21. **Monitoring/Alerting**: App-Healthcheck ist im Compose vorhanden; zusätzlich Uptime-Check auf `https://app.certvia.de` und Log-Aggregation einrichten.
22. **Updates**: Betriebssystem/Coolify/Images regelmäßig aktualisieren.

## Phase 7 — Auto-Deploy (optional)

23. Gitea-Webhook (VPS-Gitea → Coolify) mit **Branch-Filter `main`**. Da Gitea und Coolify auf demselben Host sind, ggf. `GITEA__webhook__ALLOWED_HOST_LIST` weit genug setzen (vgl. Testserver-Erfahrung).

---

## Release-Fluss (Zusammenfassung)

```
Feature-Branch → dev            # Entwicklung, Auto-Deploy Testserver
dev → main                      # Release-Merge (nach Test-Freigabe)
git push prod main              # Release-Push ins VPS-Gitea → Prod-Deploy
```

## Row Level Security scharfschalten (F-04)

Postgres RLS ist als zweite Verteidigungslinie definiert (Policy `tenant_isolation`
je Mandanten-Tabelle) und mit der Migration `rls_enforce` unter
`FORCE ROW LEVEL SECURITY` + `WITH CHECK` scharf gestellt. Sie wird **env-gesteuert**
aktiviert (`RLS_ENFORCED`), Default ist **aus** (Owner-Betrieb wie bisher).

**Wie es funktioniert:** Bei `RLS_ENFORCED=true` verbindet sich der App-Prozess als
eingeschränkte Rolle `isms_app` (NOBYPASSRLS) über `RLS_DATABASE_URL` und setzt
`app.tenant_id` transaktionslokal pro Operation. Für diese Rolle greifen die
Policies. Migrationen, Seed/Bootstrap und der mandantenübergreifende Login-Lookup
laufen weiter über die **Owner-`DATABASE_URL`**.

**Scharfschalten (einmalig):**

1. App-Rolle mit LOGIN + starkem Passwort versehen (nur einmal, kein Secret ins Repo):
   ```bash
   docker exec -it <postgres-container> psql -U isms -d isms \
     -c "ALTER ROLE isms_app WITH LOGIN PASSWORD '<STARKES_PASSWORT>';"
   ```
2. In Coolify die Env-Variablen setzen:
   - `RLS_ENFORCED=true`
   - `RLS_DATABASE_URL=postgresql://isms_app:<STARKES_PASSWORT>@postgres:5432/isms?schema=public`
3. App-Service neu deployen. Fehlt `RLS_DATABASE_URL` bei aktivem Flag, bricht die
   App bewusst beim Start ab (fail secure).

> **Warnung — Owner-Rolle muss BYPASSRLS/Superuser sein.** Die in `DATABASE_URL`
> genutzte Owner-/Migrate-Rolle (`isms`) MUSS `BYPASSRLS` bzw. Superuser sein,
> sonst sähe der Login (mandantenübergreifend) **keine** Nutzer und Migrationen
> könnten fehlschlagen. FORCE ist für diese Rolle unschädlich, weil BYPASSRLS die
> RLS auch unter FORCE umgeht.
>
> **Warnung — ohne Kontext = null Zeilen.** `RLS_ENFORCED=true` NIE ohne korrektes
> `RLS_DATABASE_URL` setzen: eine RLS-Rolle ohne gesetzten `app.tenant_id` sieht
> gar keine Zeilen. Das Setzen des Kontexts übernimmt `dbForTenant` automatisch.

Nachweis der Korrektheit lokal: `npx tsx scripts/test-rls-enforcement.ts`.

## Host-Encryption at-rest — Daten-Volume (`pgdata` + MinIO)

> Umsetzung der Härtung §2 (`docs/KONZEPT-haertung.md`). **Ops-Runbook, kein App-Code.**
> Schützt gegen **physischen Plattendiebstahl / VPS-Decommission** — die Volumes liegen
> sonst im Klartext auf der Contabo-Platte (`pgvector`-Community-Postgres hat **kein TDE**).
> **Kein** Schutz gegen Live-Kompromittierung des laufenden Servers (dafür greifen
> App-Feld-Encryption, RLS, Zugriffskontrollen) — im Betrieb ist das Volume im RAM entschlüsselt.

**Prinzip:** Ein **LUKS/dm-crypt**-Container (dm-crypt/`cryptsetup`) bzw. ein
**provider-verschlüsseltes Block-Volume** trägt das gesamte Daten-Volume. Coolifys
Persistent-Storage (`pgdata`, MinIO-Daten, ggf. Redis-AOF) wird auf dieses
verschlüsselte Volume gelegt — damit sind `pgdata` **und** MinIO in einem Rutsch gedeckt.

**Einrichtung (einmalig, vor dem ersten Deploy mit echten Daten):**

1. Separates Block-Volume/Partition bereitstellen (z. B. `/dev/sdb`) — **nicht** das Root-FS.
2. LUKS-Container anlegen und öffnen:
   ```bash
   cryptsetup luksFormat --type luks2 /dev/sdb          # Passphrase vergeben (s. u.)
   cryptsetup open /dev/sdb cryptdata                    # -> /dev/mapper/cryptdata
   mkfs.ext4 /dev/mapper/cryptdata
   mkdir -p /srv/cryptdata && mount /dev/mapper/cryptdata /srv/cryptdata
   ```
3. Coolifys Datenwurzel (bzw. die betroffenen Named-Volumes/Bind-Mounts für `pgdata`
   und MinIO) auf `/srv/cryptdata/...` legen und die Compose-`volumes` dorthin zeigen lassen.
4. **Passphrase / Key-File** ausschließlich im **Org-Passwortmanager** hinterlegen
   (Eintrag im `docs/SECRETS-REGISTER.md` führen) + versiegelte Offline-Kopie. **Nie** ins Repo,
   nie ins Backup-Bucket.

**Boot-Unlock (dokumentierte Entscheidung nötig — Betreiber wählt):**

- **A) Manuelles Unlock (empfohlen für Einzel-VPS, höchster Schutz):** Nach jedem Reboot
  meldet sich ein Operator per SSH an und führt `cryptsetup open` + `mount` (bzw. ein
  `systemd`-Gate vor den Docker-/Coolify-Start) aus. Kein Key auf der Platte → Diebstahl
  der Platte nützt nichts. Nachteil: **kein unbeaufsichtigter Reboot** (Downtime bis Unlock).
- **B) Key-File auf getrenntem Medium / Netz-Unlock:** `crypttab`-Key-File auf einem separaten,
  nicht mit der Platte gestohlenen Träger, oder **dracut/clevis + Tang** (Network-Bound Disk
  Encryption) für auto-unlock, solange der Tang-Server erreichbar ist. Komfortabler,
  aber der Angreifer, der Platte **und** Key/Tang-Zugang hat, gewinnt.

> **Betreiber-Entscheidung dokumentieren:** A oder B, wer die Passphrase hält, und wie der
> Reboot-Ablauf aussieht (Runbook-Schritt „Nach Reboot: Volume entsperren, dann Coolify starten").
> Ohne Unlock startet Postgres/MinIO nicht — das ist beabsichtigt (fail-secure).

## Verschlüsselte Backups — pgBackRest / age / restic

> Umsetzung der Härtung §3 + Backup-Konzept §9 (`docs/KONZEPT-backup-restore.md`).
> **Entscheidung:** **client-seitige AES-256-Verschlüsselung mit einem Schlüssel pro Umgebung**
> — das Artefakt ist verschlüsselt, **bevor** es S3/MinIO erreicht (at-rest + in-transit +
> zero-knowledge vom Speicher). **Nicht** allein auf Storage-SSE verlassen (SSE gern zusätzlich).
> Konsistent zur bestehenden App-Verschlüsselung (TOTP AES-256-GCM, Backup-Export AES-256-GCM).

**Schichten (je Umgebung getrennte Schlüssel):**

| Schutzobjekt | Werkzeug | Schlüssel |
|---|---|---|
| Cluster-Backup (Postgres, WAL/Base) | **pgBackRest** `repo-cipher-type=aes-256-cbc` + `repo-cipher-pass` → S3/MinIO | pgBackRest-Repo-Key je Umgebung |
| Per-Tenant-Export + DSGVO-Pakete | **`age`** (X25519, encrypt-then-upload) | `age`-Keypair je Umgebung |
| MinIO-Dateien (Uploads/Logos) | **restic** (eingebaute AES-256-Verschlüsselung) | restic-Repo-Passwort je Umgebung |

**pgBackRest (Beispiel `pgbackrest.conf`, Repo auf MinIO/S3):**
```ini
[global]
repo1-type=s3
repo1-s3-endpoint=<minio-oder-s3-endpoint>
repo1-s3-bucket=certvia-pgbackrest-prod          # eigener Bucket, NICHT der App-Bucket
repo1-s3-key=<zugang>          # nur Backup-Zugang, getrennt vom App-MinIO-User
repo1-s3-key-secret=<zugang-secret>
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=<PGBACKREST_REPO_KEY>          # aus Passwortmanager, NIE im Bucket
repo1-retention-full=4                            # Retention: s. u.
[certvia]
pg1-path=/srv/cryptdata/pgdata
```

**age (Per-Tenant-/DSGVO-Artefakte):**
```bash
age-keygen -o /root/age-prod.key                  # Private Key -> Passwortmanager + offline
# Public Recipient (age1...) als Env/Config für die Backup-Jobs:
age -r age1<recipient-prod> -o export.tenant.age export.tenant.tar
```

**restic (MinIO-Objektdaten):**
```bash
export RESTIC_REPOSITORY=s3:<endpoint>/certvia-restic-prod
export RESTIC_PASSWORD=<RESTIC_REPO_KEY>          # aus Passwortmanager
restic backup /srv/cryptdata/minio
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
```

**Verdrahtung in Coolify / Betrieb:**

- **Scheduling:** Coolify-**Scheduled Task / Cron** je Job (pgBackRest full+incr, `age`-Export,
  restic) — Zugangsdaten als Coolify-Env-Secrets, **nicht** im Compose committen.
- **Retention je Schicht dokumentieren** (DR-WAL/Base, Per-Tenant-Snapshots, DSGVO-Exporte)
  und dem **DSB** vorlegen — Löschfristen ergeben sich aus der DSGVO-Aufbewahrung.
- **Getrennte Buckets/Zugänge:** Backup-Repos liegen in **eigenen** Buckets mit **eigenem**
  Zugang, nie im App-MinIO-Bucket und nie zusammen mit den Schlüsseln.
- **Restore-Test regelmäßig + dokumentiert** (der Prod-Runbook fordert das bereits für `pgdata`,
  Phase 6): mindestens quartalsweise eine Wiederherstellung in eine Wegwerf-Umgebung, Ergebnis
  protokollieren. Ein ungetestetes Backup gilt als kein Backup.

**Bezug zur App-Backup-Engine:** Der in `dev` integrierte App-Export/Restore verschlüsselt
Artefakte bereits **client-seitig mit AES-256-GCM** über `BACKUP_ENC_KEY` (Fallback `AUTH_SECRET`),
**ein Key pro Umgebung** (Backup-Konzept §9). Umgebungs-Secrets (Pepper/`MFA_ENC_KEY`/`BACKUP_ENC_KEY`)
liegen **nicht** im Artefakt; der Restore setzt Owner=Superuser voraus (`session_replication_role`).
pgBackRest/`age`/restic sind die **Ops-Ebene darunter** (Cluster/Host/Objektspeicher) —
dieselbe Grundregel „ein Schlüssel pro Umgebung, getrennt vom Artefakt" gilt durchgängig.

## Schicht A — Cluster-Disaster-Recovery mit PITR (Go-Live-Runbook)

> Umsetzung Backup-Konzept §2 (`docs/KONZEPT-backup-restore.md`). **Ops-Runbook, kein App-Code.**
> Schicht A deckt den **gesamten** Cluster ab — auch die **globalen** Tabellen (`Identity`/
> Credentials, Kataloge, `PlatformAdmin`), die die mandanten-scoped App-Engine (Schicht B)
> bewusst NICHT anfasst. Zweck: Totalausfall / Ransomware / menschlicher Massenfehler →
> „DB auf Zeitpunkt T" (Point-in-Time-Recovery).

**Bausteine:** **pgBackRest** (empfohlen) oder **wal-g** — periodisches **Voll-/Inkrement-Backup**
plus kontinuierliches **WAL-Archiving** nach S3/MinIO, verschlüsselt (`repo-cipher`). Erst das
WAL-Archiv macht PITR möglich (Replay bis zu einem Zeitpunkt zwischen zwei Base-Backups).

### A.1 Repo-Config (Ergänzung zu `pgbackrest.conf` oben)

```ini
[global]
# ... (repo1-* wie im Abschnitt „Verschlüsselte Backups" oben) ...
repo1-retention-full=4                 # 4 Voll-Backups vorhalten (s. Retention-Tabelle)
repo1-retention-archive=8              # WAL für so viele Full-Sets behalten (PITR-Fenster)
repo1-retention-archive-type=full
start-fast=y
archive-async=y                        # asynchrones Archiving (Durchsatz/latenztolerant)
spool-path=/var/spool/pgbackrest

[certvia]
pg1-path=/srv/cryptdata/pgdata
```

### A.2 WAL-Archiving in Postgres aktivieren (`postgresql.conf`)

```ini
archive_mode = on
archive_command = 'pgbackrest --stanza=certvia archive-push %p'
wal_level = replica
max_wal_senders = 3
```

```bash
# Stanza einmalig anlegen + prüfen, dann erstes Voll-Backup:
pgbackrest --stanza=certvia stanza-create
pgbackrest --stanza=certvia check
pgbackrest --stanza=certvia --type=full backup
# Zeitplan (Coolify Scheduled Task / cron):
#   full     wöchentlich   pgbackrest --stanza=certvia --type=full backup
#   diff/inc täglich       pgbackrest --stanza=certvia --type=incr backup
```

### A.3 Restore / PITR-Prozedur (dokumentierter Ablauf)

> **Achtung:** Cluster-weit — ersetzt den GESAMTEN Datenbestand aller Mandanten. Für einen
> **einzelnen** Kunden ist der **Portal-Restore** (Schicht B, `/admin/[id]?restore=1`) das
> richtige Werkzeug, nicht PITR.

```bash
# 1. App + Postgres stoppen (kein Schreibzugriff während des Restore).
docker compose stop app && systemctl stop postgresql   # bzw. Coolify-Dienst anhalten

# 2a. Vollständiger Restore auf den neuesten konsistenten Stand:
pgbackrest --stanza=certvia --delta restore

# 2b. ODER Point-in-Time-Recovery auf einen Zeitpunkt T:
pgbackrest --stanza=certvia --delta \
  --type=time --target="2026-08-11 14:30:00+02" \
  --target-action=promote restore

# 3. Postgres starten — spielt WAL bis zum Target und promotet dann.
systemctl start postgresql
#   Recovery-Fortschritt in den Postgres-Logs verfolgen (…"recovery stopping before"…).

# 4. Kohärenz prüfen (s. Restore-Kohärenz unten): Secrets der Zielumgebung müssen
#    zu den Daten passen (Pepper/MFA_ENC_KEY), sonst Login/MFA planmäßig zurücksetzen.
# 5. App wieder starten, Smoke-Test (Login, ein Mandant, ein Upload).
```

- **Quartalsweiser Restore-Test PFLICHT:** PITR in eine **Wegwerf-Umgebung** wiederherstellen,
  Ergebnis protokollieren (der Go-Live fordert das ohnehin für `pgdata`). Ungetestetes Backup = kein Backup.
- **Retention/PITR-Fenster** dem DSB vorlegen (s. Retention-Tabelle unten).

## MinIO-Objekt-Backup mit restic (vollwertig, Go-Live-Runbook)

> Ersetzt das frühere „Best-Effort-Key-Kopieren" durch ein **vollwertiges, versioniertes,
> verschlüsseltes** Objekt-Backup. MinIO hält Uploads/Logos **und** die App-Backup-Artefakte
> (`<tenantId>/backups/…`) sowie die DSGVO-Pakete (`<tenantId>/dsgvo-exports/…`); ein
> DB-Backup allein genügt nicht (Backup-Konzept §1/§3).

```bash
export RESTIC_REPOSITORY=s3:<endpoint>/certvia-restic-prod   # eigener Bucket, eigener Zugang
export RESTIC_PASSWORD=<RESTIC_REPO_KEY>                      # aus Passwortmanager, NIE ins Repo/Bucket
export AWS_ACCESS_KEY_ID=<restic-zugang> AWS_SECRET_ACCESS_KEY=<restic-secret>

restic snapshots || restic init                              # einmalig initialisieren
# Zeitplan (Coolify Scheduled Task / cron), täglich:
restic backup /srv/cryptdata/minio --tag minio --host certvia-prod
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune
restic check --read-data-subset=5%                           # Integrität stichprobenweise prüfen

# Restore (ganzes Repo oder gezielt ein Prefix):
restic restore latest --target /srv/cryptdata/minio
restic restore latest --target /tmp/recover --include '/srv/cryptdata/minio/<tenantId>/uploads'
```

- **Getrennte Buckets/Zugänge:** restic-Repo **nicht** im App-MinIO-Bucket, Schlüssel **nie**
  zusammen mit den Artefakten.
- **Konsistenz:** MinIO-Snapshot und DB-Backup laufen zeitnah; die App-Restore-Engine (Schicht B)
  stellt DB **und** den Mandanten-Prefix wieder her — beide Ebenen müssen vorhanden sein.

### Retention je Schicht (dem DSB vorzulegen — Platzhalter, DSB bestätigt)

| Schicht | Objekt | Vorschlag |
|---|---|---|
| A (pgBackRest) | Voll-Backups | 4 Wochen (`repo1-retention-full=4`) |
| A (pgBackRest) | WAL-Archiv / PITR-Fenster | bis zu 8 Full-Sets (`repo1-retention-archive`) |
| B (App-Export) | Per-Tenant-Snapshots | 30–90 Tage (DSB) |
| DSGVO | Zustellpakete (`dsgvo-exports/`) | Download-Link **1 h TTL**; ZIP kurzlebig, danach löschen |

### ⚠ Restore-Kohärenz (Vorbedingung im Restore-Runbook)

> **`PASSWORD_PEPPER`, `MFA_ENC_KEY` und `BACKUP_ENC_KEY` sind Umgebungs-Secrets und stehen
> NICHT im Backup-Artefakt.** Ein Restore in eine Umgebung mit **anderen** Secrets bricht:
> - **anderer `PASSWORD_PEPPER`** → **alle** Passwort-Prüfungen schlagen fehl (kein Login).
> - **anderes `MFA_ENC_KEY`** → TOTP-Secrets nicht entschlüsselbar → MFA-Prüfung bricht.
> - **anderes `BACKUP_ENC_KEY`** → das AES-256-GCM-Artefakt lässt sich gar nicht entschlüsseln.
>
> **Vorbedingung vor jedem Restore:** Zielumgebung hält **exakt die Secrets, mit denen das
> Backup erzeugt wurde**, oder es wird ein **Passwort-/MFA-Reset** (bzw. Neuverschlüsselung)
> eingeplant. Deshalb: Secrets je Umgebung getrennt führen (`docs/SECRETS-REGISTER.md`) und die
> passende Kopie **vor** dem Restore bereitstellen. Cross-Environment-Restore (prod→staging) ist
> nur mit den prod-Secrets **oder** anschließendem Reset lauffähig.

## Sicherheits-Checkliste Go-Live

- [ ] Frische, starke Secrets (nicht aus Test übernommen)
- [ ] `RUN_DEMO_SEED` aus, **keine** Demo-Daten in Prod
- [ ] Bootstrap-Admin-Passwort nach erstem Login geändert
- [ ] HTTPS erzwungen, gültiges Zertifikat
- [ ] `pgdata` persistent + Backup + Restore-Test
- [ ] Firewall aktiv, SSH gehärtet
- [ ] Gitea-Repo privat, Zugriff nur für das Team
- [ ] `REDIS_PASSWORD` gesetzt und in `REDIS_URL` eingetragen (F-18)
- [ ] Alle Images auf konkrete Tags gepinnt (kein `:latest`), CI grün (F-11)
- [ ] **Host-Encryption** aktiv: Daten-Volume (`pgdata` + MinIO) auf LUKS/verschlüsseltem Volume, Boot-Unlock-Verfahren dokumentiert (A oder B)
- [ ] **Verschlüsselte Backups**: pgBackRest (`aes-256-cbc`) + `age` + restic eingerichtet, Retention dem DSB vorgelegt, **Restore-Test** dokumentiert
- [ ] **Secrets-Register** (`docs/SECRETS-REGISTER.md`) gepflegt: Ownership + Rotationsregel je Umgebung, Keys nie im Artefakt-Bucket, versiegelte Offline-Kopie
- [ ] **Restore-Kohärenz** geprüft: Zielumgebung hält die zum Backup passenden `PASSWORD_PEPPER`/`MFA_ENC_KEY`/`BACKUP_ENC_KEY` (sonst Reset einplanen)

---

## Supply-Chain & Container-Härtung (F-11 / F-18)

Diese Maßnahmen sind in `Dockerfile`, `docker-compose*.yml`, `.gitea/workflows/ci.yml`
und `renovate.json` umgesetzt.

### F-11 — Supply Chain

- **`npm ci` statt `npm install`** (Lockfile bindend, reproduzierbar). Base-Image ist
  **`node:22-slim`** (Debian/glibc) statt Alpine/musl — damit greifen die im Lockfile
  hinterlegten glibc-Optional-Deps (lightningcss/oxide/argon2/sharp) zuverlässig.
- **npm 11 im Build gepinnt.** Das committete `package-lock.json` wurde mit npm 11
  erzeugt; das in `node:22.14.0` gebündelte npm 10.9.2 löst `next@16.2.12 → @swc/helpers`
  anders auf und würde `npm ci` mit *„out of sync"* abbrechen. `RUN npm i -g npm@11.19.0`
  stellt den Resolver-Gleichstand her — **ohne** Lockfile-Änderung.
  > **Offene Folgeänderung (Dependency-Lane / F-12):** Sauberer wäre, das Lockfile mit
  > npm 10 neu zu erzeugen (`rm -rf node_modules package-lock.json && npm install` unter
  > Node 22), damit die npm-Pinnung entfallen kann. Das ist eine `package-lock.json`-Änderung
  > und gehört **nicht** in diese Infra-Lane.
- **Image-Pins** (keine rollenden Tags):
  `node:22.14.0-slim`, `pgvector/pgvector:0.8.0-pg16`, `redis:7.4.2-alpine`,
  `minio/minio:RELEASE.2025-04-22T22-12-26Z`, `mailhog/mailhog:v1.0.1`.
- **Schlanke `migrate`-Stage** statt `builder` für den Migrations-/Seed-Job: kein
  `next build`, kein Build-Cache. Sie enthält weiterhin devDeps (tsx/Prisma-CLI) + `src`,
  weil `prisma/seed.ts` und `scripts/bootstrap-admin.ts` aus `../src`/`@/server` importieren.
  Ein reiner Prisma-CLI-Container würde diese Jobs brechen — die Entkopplung von Seed/Bootstrap
  vom App-Code ist als App-seitige Folgeänderung empfohlen.

### SBOM

Zwei Wege (der CI-Weg ist optional/nicht-blockierend hinterlegt):

```bash
# a) aus dem npm-Baum (CycloneDX) — braucht ein valides Lockfile (s. F-12-Hinweis):
npm ci --include=optional && npm sbom --sbom-format cyclonedx --omit dev > sbom.cyclonedx.json

# b) aus dem gebauten Image (unabhängig vom npm-Baum), z. B. mit Syft:
docker build -t isms:sbom .
syft isms:sbom -o cyclonedx-json > sbom.image.cyclonedx.json
```

### F-18 — Härtung & Netzsegmentierung

- **Redis mit `requirepass`** (`REDIS_PASSWORD`, in `REDIS_URL` eingesetzt).
- **Internes Netz** (`internal: true`) für `postgres`/`redis`/`minio`/`migrate` — kein
  Egress, kein Host-Exposure; nur `app` zusätzlich im default-Netz (Coolify-Proxy).
- **`security_opt: no-new-privileges`, `cap_drop: [ALL]`** (gezielte `cap_add` nur für die
  Entrypoints von postgres/redis, die intern per gosu den Benutzer wechseln), sowie
  **`deploy.resources.limits`** (CPU/RAM) je Dienst.
- **Dev-Compose**: Host-Ports nur noch auf `127.0.0.1` gebunden (Postgres/Redis/MinIO/Mailhog).

### CI & Renovate

- **CI**: `.gitea/workflows/ci.yml` (Spiegel `.github/workflows/ci.yml`) fährt
  `npm ci → tsc --noEmit → lint → build`, dazu ein **`npm audit`-Gate**
  (`--omit=dev --audit-level=high`, hart) plus einen informativen Volllauf.
  > **Braucht einen aktivierten Gitea-Actions-Runner** — ohne registrierten Runner läuft
  > die Pipeline nicht an.
- **Renovate** (`renovate.json`): wöchentliche, gruppierte Updates; Sicherheits-/OSV-Alerts
  sofort und priorisiert. **`next-auth`/`@auth/core` (Beta 5.x)** sind bewusst auf
  manuelles Review gesetzt (kein Auto-Merge) — Auth-Regressionen können „fail open" bedeuten (F-01).

### IM-D — E-Mail-Eingang für Vorfälle (Inbound / E-Mail-to-Ticket)

Vorfälle können per E-Mail gemeldet werden. Kunden leiten Meldungen an eine
kundenindividuelle **Intake-Adresse** `vorfall-<token>@in.certvia.de` weiter; der
`incident-inbound-worker` holt die Mails per IMAP ab und legt daraus Vorfälle an
(bzw. reiht unklare Mails in die Betreiber-Review). Der Token trägt die
Mandantenzuordnung (global eindeutig, nicht erratbar) — es gibt **kein Postfach je
Kunde**, sondern ein Catch-all.

**Globaler Setup (einmalig, DNS + Postfach):**

1. **Subdomain `in.certvia.de`** anlegen und als Mail-Domain einrichten.
2. **Catch-all-Postfach** für `*@in.certvia.de` → ein einzelnes IMAP-Postfach
   (alle `vorfall-<token>@…` landen darin). MX-Record auf den Mailhost setzen.
3. **DKIM/SPF/DMARC** für `in.certvia.de` veröffentlichen (Empfang; die
   Absender-Authentizität der weitergeleiteten Kundenmails wird über deren DKIM +
   die pro Kunde gepflegte Absender-Allowlist geprüft — SPF bricht bei Weiterleitung
   und ist bewusst nur ein Signal).
4. **IMAP-Zugang** des Catch-all-Postfachs als Secrets hinterlegen (siehe unten).

**Env (Dienst `incident-inbound-worker` in `docker-compose.coolify.yml`):**

| Variable | Zweck |
| --- | --- |
| `INCIDENT_IMAP_HOST` / `INCIDENT_IMAP_PORT` | IMAP-Server des Catch-all-Postfachs (Default-Port 993) |
| `INCIDENT_IMAP_USER` / `INCIDENT_IMAP_PASSWORD` | Zugangsdaten des Catch-all-Postfachs |
| `INCIDENT_IMAP_TLS` | `true` (Default) für IMAPS; `false` nur für STARTTLS/Plain |
| `INCIDENT_IMAP_MAILBOX` | Postfach/Ordner (Default `INBOX`) |
| `INCIDENT_IMAP_POLL_MS` | Abholintervall in ms (Default 60000, min. 15000) |
| `INCIDENT_INTAKE_DOMAIN` | Muss zur Catch-all-Subdomain passen (Default `in.certvia.de`) |

Ohne `INCIDENT_IMAP_*` beendet sich der Worker **sauber** mit einer Meldung
(kein Crash) — der übrige Betrieb ist davon unberührt. Verarbeitete Mails werden
als `\Seen` markiert; zusätzlich schützt die **Message-ID-Dedupe** gegen
Doppel-Tickets beim erneuten Abholen.

**Provisionierung je Kunde (Betreiber-Portal):** Beim Onboarding (oder später) im
Mandanten unter **E-Mail-Eingang** die Absender-Domänen (Allowlist) hinterlegen —
die Intake-Adresse wird automatisch erzeugt und angezeigt. Der Kunde richtet die
Weiterleitung ein; sobald die **erste Test-Mail** als Vorfall ankommt, springt der
Status von *Weiterleitung ausstehend* auf *verifiziert* (manueller Override im
Portal möglich). Offene Verifizierungen und zu prüfende Eingänge (kein/unbekannter
Token, Allowlist-/DKIM-Fehlschlag) listet das Betreiber-Dashboard.