# Homelab Review Matrix

Typ: Inventar/Review-Landkarte - Stand: 2026-06-26 - Status: aktiv

Diese Matrix erzwingt Abdeckung, nicht Methode. Jede Domaene wird
threat-model-first und mit echtem Ist-Zustand geprueft: Repo, Compose,
Runbooks, Host-Checks, Docker Inspect, API-Exports und Restore-Belege.
Generische Best-Practice-Listen sind hier nur Hilfsmittel, nicht das Ziel.

## Ritual

1. Aelteste oder sicherheitskritische Domaene aus dem Review-Log waehlen.
2. Genau diese eine Domaene tief pruefen.
3. Repo-Soll und Live-Ist getrennt halten: "belegt", "nicht belegt",
   "offene Host-Pruefung".
4. Keine Secret-Werte lesen, zitieren oder ins Repo schreiben.
5. Konkrete Befunde in die passende Heimat ueberfuehren:
   `MASTER_TODO.md` fuer offene Arbeit, `DECISIONS.md` fuer Entscheidungen,
   Zielbild in Architecture/Inventare/Service Catalog, Ablauf in Runbooks.

Kadenz-Vorschlag: eine Domaene alle zwei Wochen. Sicherheitskritisch haeufiger:
Exposure, Identity, Backup-Restore, Data Privacy/Egress, GitOps-Control-Plane.

## Review-Log

| # | Domaene | Reifegrad (1-5) | Zuletzt geprueft | Befund / offene Punkte |
|---|---|:---:|:---:|---|
| 1 | Exposure & Ingress | ? | - | |
| 2 | Identity & Access | ? | - | Authelia-Ausnahmen und native Auth regelmaessig gegen Live-Routen testen |
| 3 | Secrets & Key-Management | ? | in Umsetzung | SOPS+age-Migration/Rotation offen; keine Secret-Werte in Git |
| 4 | Netzwerk-Segmentierung & Blast Radius | ? | - | |
| 5 | Container- & Host-Haertung | ? | - | |
| 6 | Supply Chain | ? | teilweise | Digest-Pinning belegt; Signatur-Verifikation/SBOM/CVE-Gate offen |
| 7 | Backup != Restore | ? | - | Borg->Hetzner belegt; Restore-Drills/Immutability weiter rotieren |
| 8 | Datenintegritaet | ? | - | |
| 9 | Observability-Luecken | ? | - | Alert-on-Absence/Dead-Man-Switch belegt, weiter beweisen |
| 10 | Exit & Portierbarkeit | ? | - | |
| 11 | Update- & Patch-Hygiene | ? | teilweise | Renovate belegt; Host/Engine/Auth-Layer separat betrachten |
| 12 | Data Privacy / Egress / Datenklassifikation | 2 | 2026-06-26 | OpenAI-/Mail-/Healthchecks-/ntfy-/Borg-Egress kartiert; Retention/Loeschpfade und Dawarich-Abdeckung offen |
| 13 | GitOps-Control-Plane & Drift | 3 | 2026-06-26 | Repo-Soll stark; Live-Abgleich fuer Komodo/Runtime/Traefik/Authelia offen; Self-Stack und manuelle Sync-Ausnahmen sind hoechster Hebel |

## 12 - Data Privacy / Egress / Datenklassifikation

**Bedrohung:** Personenbezogene oder sensible Daten verlassen das Lab
unkontrolliert: falscher Dienst, falscher Token, keine Retention, kein
Loesch-/Exportpfad.

**Leitfragen**

- Welche Dienste verarbeiten personenbezogene oder sensible Daten?
- Welche Daten verlassen das Lab an externe Dritte, ueber welchen Pfad und mit
  welchem Token/Account?
- Welche Retention gilt beim Dritten? Gibt es Loeschung, Export und Opt-out?
- Gibt es pro Dienst eine Datenklasse und eine erlaubte Egress-Klasse?
- Driftet die reale Datenverarbeitung von `SERVICE_CATALOG.md`,
  `EXTERNAL_DEPENDENCIES.md`, Architecture oder Restore-Doku ab?

**Messpunkte**

```bash
rg -n "OPENAI|api\.openai|ANTHROPIC|api_key|API_KEY|webhook|https?://" -g "docker-compose.y*ml" -g "*.env*"
rg -ni "openai|gpt|external|cloud|telemetry|analytics" apps/ ops/ monitoring/
rg -n "httpRequest|emailReadImap|webhook|openai|Authorization|api/v1" apps/n8n/workflows -g "*.json"
rg -n "Dawarich|dawarich|OpenAI|healthchecks.io|ntfy.sh|GitHub Mirror|Hetzner|GMX" docs HOMELAB_ARCHITECTURE_MASTER_V2.md
```

**Befund 2026-06-26**

| Pfad | Belegt | Risiko |
|---|---|---|
| Paperless-GPT -> OpenAI | `apps/paperless-gpt/docker-compose.yml` nutzt OpenAI fuer LLM/Vision OCR | Dokumenttext/Bilder/Metadaten koennen extern verarbeitet werden; Retention/Loeschpfad nicht im Repo dokumentiert |
| n8n Mail -> OpenAI -> Gitea | Workflow-JSON im Repo, Export war inaktiv; live nicht verifiziert | Mailinhalt bis 8000 Zeichen kann an OpenAI gehen; Live-Status und Retention offen |
| GMX IMAP/SMTP | n8n, Vaultwarden, Authelia/Mailpfade dokumentiert | Mailprovider-Retention und Scope nicht als Matrix erfasst |
| Borg -> Hetzner | `EXTERNAL_DEPENDENCIES.md`, Borg-Scope | Verschluesselte Offsite-Kopie vieler Datenklassen; Immutability/Retention weiter beweisen |
| ntfy/Healthchecks | self-hosted + externe Cloud-Waechter dokumentiert | Alert-/Checknamen koennen operative Metadaten leaken |
| Dawarich | Service Catalog + Compose vorhanden | Standortdaten sind hochsensibel; Architecture/Auth/Restore/Backup-Abdeckung war nicht konsistent sichtbar |

**Naechste Optimierungen**

- OpenAI-Retention, Datenkontrollen, Loesch-/Exportpfad und erlaubte Datenklassen
  fuer Paperless-GPT und n8n dokumentieren.
- Paperless-GPT nur ueber Tag-/Allowlist oder klare Ausschlussregel auf
  Dokumente anwenden.
- Dawarich in Architecture/Auth/Restore/Backup-Scope konsistent eintragen oder
  bewusst als Ausnahme dokumentieren.
- Healthchecks/ntfy-Naming-Regel: keine PII, keine Pfade, keine Secrets, keine
  aussagekraeftigen internen Namen in Payloads.

## 13 - GitOps-Control-Plane & Drift

**Bedrohung:** Der Steuerpfad driftet vom deklarierten Sollzustand ab oder wird
kompromittiert. Gitea, Komodo, Webhooks, Traefik dynamic config und Authelia
Host-Config verteilen Fehler auf alle Stacks.

**Leitfragen**

- Stimmen lokaler Clone, Gitea `origin/master`, Komodo Stack Workspace,
  Docker Runtime und Host-Dateien ueberein?
- Welche Stacks laufen live ohne Repo-Quelle, und welche Repo-Compose-Dateien
  haben keinen Komodo-Stack?
- Welche Stack-ENV-Werte werden live in Komodo gepflegt und sind nicht in Git?
- Wie sind Gitea->Komodo-Webhooks authentifiziert, auf Branch `master`
  begrenzt und gegen falsche Ausloeser geschuetzt?
- Wer hat Schreibrechte auf Gitea, Komodo und Bot-/Deploy-Tokens?
- Kann ein Push direkt deployen, oder gibt es technische Branch Protection?
- Ist der Recovery-Pfad ohne laufendes Komodo belegt?

**Messpunkte**

```bash
powershell -ExecutionPolicy Bypass -File .\ops\policy-checks\check_repo.ps1
SEND_NTFY=0 bash /mnt/user/services/homelab-infra/services/posture-check/compose-runtime-drift.sh
SEND_NTFY=0 bash /mnt/user/services/homelab-infra/services/posture-check/komodo-stack-hygiene.sh
bash /mnt/user/services/homelab-infra/services/authelia-diff.sh
bash /mnt/user/services/homelab-infra/services/traefik-dynamic-diff.sh
```

**Befund 2026-06-26**

| Bereich | Belegt | Risiko |
|---|---|---|
| Repo-Soll | `check_repo.ps1`: 0 Critical; lokaler `HEAD` == `origin/master` | Git-Ebene sauber |
| Runtime-Ist | Aus der Windows-Shell nicht gegen Unraid verifizierbar | Host-Pruefung offen; lokale Docker-Missing-Meldungen nicht als Homelab-Drift werten |
| Komodo Self-Stack | `ops/komodo/docker-compose.yml` ist Spiegel/Recovery-Anker; live inline in Komodo | Repo-Aenderung wirkt nicht live; hoechster Drift-Hebel |
| Stack-ENV | Komodo Stack-ENV bewusst nicht vollstaendig in Git | Git allein ist kein vollstaendiger Sollzustand |
| Traefik dynamic | Manuelle Sync-Ausnahme; `traefik-dynamic-diff.sh` (read-only, in `posture-check.sh` als `traefik_dynamic_drift`) vergleicht Repo-Spiegel<->Host | Auth-Middlewares/File-Routen koennen vom Repo abweichen; Drift-Check vorhanden, Host-Lauf bewerten |
| Authelia Host-Config | `authelia-diff.sh` vergleicht `access_control` | Live-Host-Datei und OIDC-Clientnamen muessen regelmaessig abgeglichen werden |
| Gitea/Komodo Integritaet | Webhook-Regeln dokumentiert; Branch Protection nicht repo-belegt | Prozess-Gate belegt, technisches Enforcement offen |

**Naechste Optimierungen**

- Auf dem Unraid-Host `compose-runtime-drift.sh` und
  `komodo-stack-hygiene.sh` ausfuehren und Ergebnisse in
  `/mnt/user/services/posture-check/*.json` bewerten.
- Traefik dynamic Drift-Check analog Authelia-Diff als read-only Check
  betreiben (`services/traefik-dynamic-diff.sh` / `traefik_dynamic_drift`).
- Komodo Inline-Compose gegen `ops/komodo/docker-compose.yml` diffen, Secret-
  Werte maskieren, nur Variablennamen/Pfade dokumentieren.
- Gitea Branch Protection, aktive Hooks, PATs und Deploy-Keys live
  inventarisieren; ungenutzte Zugriffe entfernen.
- Healthchecks-Doku-Widerspruch "Webhook offen" vs "Webhook aktiv" am 2026-06-26
  bereinigt: Status lebt in `docs/MASTER_TODO.md` (Webhook seit 2026-06-23 aktiv);
  SERVICE_CATALOG, Architecture §7.6 und `ops/healthchecks/README.md` nachgezogen.
  Optional: Gitea-Hook `last_status` live gegenpruefen.