Record append-only operator decision

2026-06-01 15:16:56 +02:00
parent 3da19421d0
commit 89114b1b12
4 changed files with 18 additions and 15 deletions
@@ -48,7 +48,6 @@ Authoritativ: `docs/AUDIT_2026-05-25_TODO.md`.
 Kurzfassung:
 - Alt-Volumes fruehestens ab 2026-06-02 freigeben
 - Borg `append-only` fuer Hetzner final klaeren; nicht erneut direkt auf produktiver `authorized_keys` testen
 - Auth-/OIDC-/CrowdSec-/Hermes-Themen bewusst geparkt
 Letzte Bestaetigung:
@@ -60,4 +59,4 @@ Letzte Bestaetigung:
 - Externer Betreibercheck: `ops/maintenance/check-external-operator.sh`; FRITZ!Box 7590 meldet FRITZ!OS `154.08.25`, DNS fuer Public Apps hat keine AAAA-Records, Host hat keine globale Provider-IPv6.
 - FRITZ!Box-UI 2026-06-01: Remote-HTTPS auf FRITZ!Box-UI aus, FTP/FTPS auf Speichermedien aus, WAN-Freigabe nur `443/tcp`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus.
 - FRITZ!Box-Konfig-Backup 2026-06-01 extern/off-system in Vaultwarden abgelegt; Datei und Kennwort bleiben ausserhalb des Repos.
- Hetzner-Account-Hygiene 2026-06-01 erledigt: 2FA aktiv, Recovery Key offline gedruckt, Zahlung ok; Storage Box SSH-only, Maintenance-Key in Vaultwarden. Append-only forced-command brach Key-Auth und wurde per Passwort-Recovery zurueckgesetzt; Borg-Repo-Zugriff danach wieder geprueft.
+- Hetzner-Account-Hygiene 2026-06-01 erledigt: 2FA aktiv, Recovery Key offline gedruckt, Zahlung ok; Storage Box SSH-only, Maintenance-Key in Vaultwarden. Append-only forced-command brach Key-Auth und wurde per Passwort-Recovery zurueckgesetzt; Operator-Entscheidung: fuer dieses Homelab bewusst nicht umsetzen.
@@ -8,7 +8,6 @@ Audit-Snapshots wurden aus der Arbeitskopie entfernt; Detailhistorie liegt in Gi
 | Prioritaet | Punkt | Naechster Schritt |
 |---|---|---|
 | P0 | Alt-Volumes nach Burn-in freigeben | Ab 2026-06-02 `ops/maintenance/release-alt-volumes.sh --dry-run` pruefen, danach nur bei sauberem Ergebnis mit `--execute` freigeben |
 | P1 | Borg `--append-only` fuer Hetzner final klaeren | Nicht erneut direkt auf produktiver `authorized_keys` testen; forced-command-Versuch am 2026-06-01 brach Key-Auth und wurde per Passwort-Recovery zurueckgesetzt. Naechster Schritt: Hetzner-Support oder temporaren Sub-Account/Scratch-Repo fuer exakt getestete Syntax nutzen. |
 | P2 | Family-Onboarding praktisch starten | Familienkonten, Vaultwarden-Organisation und Immich-Mobile-Backup gemeinsam einrichten |
 ## Bewusst geparkt
@@ -22,6 +21,7 @@ Audit-Snapshots wurden aus der Arbeitskopie entfernt; Detailhistorie liegt in Gi
 | Hermes-Agent | NAS-Stack bleibt deaktiviert; Review-Deadline 2026-07-25 |
 | USV | Anschaffung verschoben; Power-Loss-Risiko bewusst akzeptiert |
 | Zweites Off-site-Ziel | Bewusst nicht umgesetzt; neu bewerten bei Hetzner-Problemen, stark wachsendem Datenwert oder geaenderter Betreiber-Praeferenz |
 | Borg `append-only` auf Hetzner | Operator-Entscheidung 2026-06-01: nicht umgesetzt. Der forced-command-Test auf der Storage Box brach Key-Auth und wurde per Passwort-Recovery zurueckgesetzt; Nutzen steht fuer dieses Homelab nicht im Verhaeltnis zum Betriebsrisiko. |
 ## Zuletzt geschlossen
@@ -29,7 +29,7 @@ Audit-Snapshots wurden aus der Arbeitskopie entfernt; Detailhistorie liegt in Gi
 - FRITZ!Box-Servicefenster UI-seitig abgeschlossen: FRITZ!Box-Dienste aus dem Internet sind aus (HTTPS auf FRITZ!Box-UI, FTP/FTPS auf Speichermedien), aktive WAN-Freigabe bleibt nur `443/tcp -> 192.168.178.58`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus.
 - FRITZ!Box-Konfig-Backup exportiert und extern/off-system in Vaultwarden abgelegt: `Einstellungen_FRITZ.Box_7590_154.08.25_01.06.26_1318.export`; Kennwort und Datei bleiben ausserhalb des Repos.
 - Hetzner-Account-Hygiene erledigt: externe Kontakt-/Rechnungs-Mail bestaetigt, Zahlung ok, 2FA mit Google Authenticator aktiv, Recovery Key offline ausgedruckt.
- Hetzner Storage Box geprueft: `storage-box-1`, `u565255.your-storagebox.de`, SSH-Port `23`, SSH aktiv, SMB/WebDAV aus, 64,94 GB / 1 TB belegt; Borg-UI-Key und separater Maintenance-Key funktionieren wieder nach Passwort-Recovery.
+- Hetzner Storage Box geprueft: `storage-box-1`, `u565255.your-storagebox.de`, SSH-Port `23`, SSH aktiv, SMB/WebDAV aus, 64,94 GB / 1 TB belegt; Borg-UI-Key und separater Maintenance-Key funktionieren wieder nach Passwort-Recovery. Borg `append-only` ist bewusst nicht umgesetzt.
 - Family-View Dashboard ist repo-seitig gebaut: `monitoring/grafana/dashboards/family-status.json` zeigt Family-App-Uptime, Backup-Alter, TLS-Restlaufzeit, Critical-Container und Image-Drift.
 - Alt-Volume-Freigabe ist vorbereitet: `ops/maintenance/release-alt-volumes.sh --dry-run` validiert aktive Pfade, Container-Health, Restore-Freshness und gemountete Altpfade; Test am 2026-06-01 fand vier Kandidaten und keine Blocker, Ausfuehrung bleibt wegen Cutoff bis 2026-06-02 gesperrt.
 - Borg-Nachlauf nach dem 2026-05-31-Sprint ist belegt: Archiv `Taegliche-Sicherung-2026-06-01T04:30:26.913`, 101669 Dateien, `rc=0`; Freshness-Check am 2026-06-01: Critical 0, Warnings 0.
@@ -14,7 +14,7 @@ Dieses Dokument beschreibt externe Anbieter und Konten, von denen Betrieb, Recov
 | FRITZ!Box 7590 | Router, DHCP, Telefonie, WAN | hoch | LAN ohne DHCP/Routing; auch lokale Inter-Subnet-Kommunikation kann brechen | Operator-Login auf `192.168.178.1` | FRITZ!Box-Konfig-Backup vom 2026-06-01 liegt extern/off-system in Vaultwarden; Reset-Pin und Account-Pfad bereithalten; Remote-HTTPS/FTP/FTPS aus dem Internet sind aus |
 | Domain-Registrar | Besitz `kaleschke.info` | hoch | Ohne Domain brechen Public URLs/TLS-Erneuerung | Operator-Konto ausserhalb Repo, konkreten Registrar im Account pruefen | Registrar-Zugang, 2FA-Recovery und Zahlungsweg analog/off-system sichern |
 | Cloudflare DNS | Authoritative DNS, ACME DNS-Challenge, DDNS | hoch | Neue Zertifikate/DNS-Aenderungen blockiert | Cloudflare-Konto; API-Token liegt als Host-Secret | API-Token rotierbar halten, Account-Recovery und Zone-Besitz pruefen |
-| Hetzner Storage Box | Off-site Borg Backup | kritisch | Restore aus Off-site ggf. nicht moeglich | Hetzner-Konto / Storage-Box-Zugang ausserhalb Repo | Borg-Passphrase ist offline gesichert; Hetzner 2FA/Recovery/Zahlung sind bestaetigt; Storage Box ist SSH-only, Maintenance-Key liegt in Vaultwarden; Borg `--append-only` bleibt wegen Storage-Box-forced-command-Problem offen |
+| Hetzner Storage Box | Off-site Borg Backup | kritisch | Restore aus Off-site ggf. nicht moeglich | Hetzner-Konto / Storage-Box-Zugang ausserhalb Repo | Borg-Passphrase ist offline gesichert; Hetzner 2FA/Recovery/Zahlung sind bestaetigt; Storage Box ist SSH-only, Maintenance-Key liegt in Vaultwarden; Borg `append-only` wird per Operator-Entscheidung nicht umgesetzt |
 | GitHub Mirror | Externer Repo-Mirror `michaelkaleschke-spec/homelab-infra` | mittel/hoch | Gitea-Verlust abfederbar, Repo-Bootstrap bleibt moeglich | GitHub-Konto; PAT liegt in Gitea-Mirror-Settings, nicht im Repo | Mirror-Status regelmaessig pruefen; lokalen Clone als zweite Kopie behalten |
 | Tailscale | Remote-/Operator-Zugang | hoch | Remote-Zugriff erschwert, lokale Bedienung bleibt | Tailnet-Konto; Node `Kallilabcore`, IPv4 `100.80.98.33` | Break-glass per LAN und physischem Zugriff; Tailnet-Recovery-Codes sichern |
 | GMX SMTP | Authelia Notifier | mittel | Mail-Notifier faellt aus, Login selbst nicht zwingend | GMX-Konto; SMTP-Secret liegt hostseitig | ntfy/zweiter SMTP als Fallback pruefen |
@@ -78,6 +78,6 @@ Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaeng
 | 2026-05-26 | Bekannte externe Abhaengigkeiten aus Repo-/Betriebsdoku dokumentiert; keine Secret-Werte aufgenommen. Borg-Passphrase ist laut Operator offline gesichert. | Account-Besitz, 2FA-Recovery-Codes und Zahlungswege extern bestaetigen |
 | 2026-05-26 | Telekom-DSL und FRITZ!Box 7590 (damals FRITZ!OS 8.21) als WAN-/Router-Abhaengigkeit aufgenommen; Ausfallschutz nicht eingerichtet | FRITZ!OS-Update am 2026-06-01 als `154.08.25` beobachtet |
 | 2026-05-28 | FRITZ!Box-Portfreigaben bereinigt: aktiv bleibt nur `443/tcp`; `80/tcp` entfernt, `222/tcp` bewusst nicht angelegt; UPnP-Recht fuer VONETS-Bridge deaktiviert | IPv6-/Dienste-Review am 2026-06-01 nachgezogen |
-| 2026-06-01 | Externer Betreibercheck vorbereitet: `docs/EXTERNAL_OPERATOR_RUNBOOK.md` und `ops/maintenance/check-external-operator.sh`; FRITZ!Box meldet per TR-064 FRITZ!OS `154.08.25`, Public DNS hat keine AAAA-Records, Host hat keine globale Provider-IPv6 | Hetzner Account-Hygiene und Borg append-only im Konto/Storage-Box-SSH-Key-Setup bestaetigen |
+| 2026-06-01 | Externer Betreibercheck vorbereitet: `docs/EXTERNAL_OPERATOR_RUNBOOK.md` und `ops/maintenance/check-external-operator.sh`; FRITZ!Box meldet per TR-064 FRITZ!OS `154.08.25`, Public DNS hat keine AAAA-Records, Host hat keine globale Provider-IPv6 | Account-Hygiene am 2026-06-01 nachgezogen |
 | 2026-06-01 | FRITZ!Box-UI gegengeprueft und Konfig-Backup extern/off-system in Vaultwarden abgelegt; Remote-HTTPS auf FRITZ!Box-UI aus, FTP/FTPS auf Speichermedien aus, nur `443/tcp -> 192.168.178.58`, keine aktive IPv6-Freigabe sichtbar, UPnP-Selbstfreigaben aus | Bei naechstem Router-Update erneut exportieren |
-| 2026-06-01 | Hetzner-Account-Hygiene erledigt: externe Mail ok, Zahlung ok, 2FA aktiv, Recovery Key offline gedruckt. Storage Box: SSH aktiv, SMB/WebDAV aus, Maintenance-Key in Vaultwarden, Borg-Repo-Zugriff nach Recovery geprueft. | Borg `--append-only` nur noch ueber Hetzner-Support oder Scratch/Sub-Account erneut testen |
+| 2026-06-01 | Hetzner-Account-Hygiene erledigt: externe Mail ok, Zahlung ok, 2FA aktiv, Recovery Key offline gedruckt. Storage Box: SSH aktiv, SMB/WebDAV aus, Maintenance-Key in Vaultwarden, Borg-Repo-Zugriff nach Recovery geprueft. Borg `append-only` wird bewusst nicht umgesetzt. | Keine Folgeaktion |
@@ -46,8 +46,11 @@ Im Repo nur das Datum der Bestaetigung dokumentieren, nie Zugangsdaten.
 ## 3. Borg Append-Only
-Ziel: Der produktive Backup-Client darf neue Archive schreiben, aber nicht
+Status: **bewusst nicht umgesetzt**.
-normal prune/delete/compact als unbeschraenkter Client ausfuehren.
+
 Ziel der Haertung waere gewesen: Der produktive Backup-Client darf neue Archive
 schreiben, aber nicht normal prune/delete/compact als unbeschraenkter Client
 ausfuehren.
 Hetzner dokumentiert Borg-Zugriff auf Storage Boxen inklusive `--remote-path`
 fuer Borg-Versionen; fuer Borg 1.4 wird `--remote-path=borg-1.4` empfohlen.
@@ -55,7 +58,7 @@ Hetzner bestaetigt auch, dass append-only moeglich ist. Borg selbst setzt
 append-only pro SSH-Key typischerweise ueber einen forced command in
 `authorized_keys` um.
-Zielmodell, aber **nicht ungeprueft auf der produktiven Storage Box anwenden**:
+Getestetes Zielmodell, aber **nicht auf der produktiven Storage Box aktiv**:
 ```text
 command="borg-1.4 serve --append-only --restrict-to-repository /home/hetzner_borg_appdata_critical",restrict ssh-ed25519 <backup-public-key> borg-ui-append-only
@@ -67,15 +70,16 @@ Hinweise:
 - Stand 2026-06-01: Ein forced-command-Versuch auf der produktiven
  Storage-Box-`authorized_keys` brach die Key-Authentifizierung. Recovery
  erfolgte per Storage-Box-Passwort und Upload einer bereinigten
-  `authorized_keys` mit Borg-UI-Key und Maintenance-Key. Daher Append-only erst
+  `authorized_keys` mit Borg-UI-Key und Maintenance-Key.
-  nach Hetzner-Support-Klaerung oder in einem temporaren Sub-Account/Scratch-Repo
+- Operator-Entscheidung 2026-06-01: Append-only wird fuer dieses Homelab nicht
-  erneut testen.
+  umgesetzt. Der zusaetzliche Schutz steht hier nicht im Verhaeltnis zum
  Betriebsrisiko und zur Komplexitaet.
 - Pfad auf der Storage Box vor dem Eintragen pruefen. Bei Hetzner werden Pfade
  im Borg-Repo haeufig relativ als `./repo-name` verwendet; in
  `authorized_keys` muss der serverseitige Pfad zur Storage-Box-Home-Struktur
  passen.
- Der produktive Borg-UI-Key sollte langfristig append-only sein, ist aktuell
+- Der produktive Borg-UI-Key bleibt bewusst uneingeschraenkt, damit die
-  aber bewusst wieder uneingeschraenkt, damit die produktiven Backups laufen.
+  produktiven Backups laufen.
 - Ein separater Maintenance-Key bleibt fuer bewusste Retention/Prune/Compact
  noetig und liegt in Vaultwarden; lokale temporare Key-Dateien wurden geloescht.
 - Append-only verhindert nicht, dass ein kompromittierter Client Archive als