Stack absichern (2/2): Dienste, Monitoring, Backup

Anschluss an Teil 1 #

Teil 1 deckte die vier Infrastruktur-Schichten ab: Perimeter, Zugang, Cluster und GitOps. Dieser Teil geht weiter nach innen – zur Anwendungs-Ebene und zur letzten Verteidigungslinie.

Wo Teil 1 vor allem Architektur-Entscheidungen waren, geht es hier um die Konfiguration einzelner Dienste, aktive Verteidigungs-Tools und das, was im Incident wirklich zählt: ein funktionierendes Backup.

Schicht 5: Dienste-Härtung #

Drei Dienste exemplarisch – die übrigen folgen demselben Muster.

Nextcloud #

Der prominenteste öffentliche Dienst, entsprechend das häufigste Ziel:

• 2FA für alle Nutzer verpflichtend, kein Opt-out
• Brute-Force-Protection aktiviert und auf sinnvolle Schwellen gestellt
• Rate-Limiting zusätzlich auf Traefik-Ebene (via Crowdsec, siehe Schicht 6)
• Security-Header komplett – HSTS (lange Laufzeit), CSP, X-Frame-Options, Referrer-Policy. Der eingebaute Security-Scan zeigt fehlende Header an.
• App-Whitelist – nur geprüfte Apps, keine Experimente auf der Prod-Instanz
• Updates schnell – Security-Patches via Renovate-PR, nicht manuell
• Admin-Account getrennt vom Alltags-Account, nicht SSO-verknüpft, eigenes Passwort + 2FA

Immich #

Neuer und by default weniger gehärtet. Zusätzlich zu den Nextcloud-Prinzipien:

• Registrierung deaktiviert – Nutzer legt nur der Admin an
• Public Sharing mit Ablaufdatum und Passwort – die Shared-Links sind praktisch, aber nicht offen
• ML-Container isoliert – braucht nach dem initialen Modell-Download kein Internet, NetworkPolicy setzt das durch
• Upload-Limits auf Traefik-Ebene, sonst flutet ein gekaperter Account den Speicher

Vaultwarden #

Das kritischste System – der Verlust der Passwort-DB ist der Super-GAU:

• Nicht öffentlich – nur hinter dem internen Traefik via WireGuard erreichbar. Bewusst: kostet etwas Komfort (Browser im VPN), reduziert die Angriffsfläche aber drastisch.
• Registrierung aus nach initialem Setup
• Admin-Token als Argon2-Hash (vaultwarden hash), nur als Environment-Variable aus dem SOPS-Secret – ein geleaktes Secret gibt den Token nicht im Klartext preis
• Eigener Backup-Pfad – Vaultwarden läuft bewusst auf SQLite, also konsistent sichern (SQLite-Backup-API/WAL-Checkpoint oder Litestream, kein Live-Copy). Zusätzlich zum Velero-Lauf separat auf einen Offline-Datenträger, mit eigenem Key.
• Kein SSO – bewusst: der Passwort-Manager darf nicht von dem Identity-Provider abhängen, den er selbst absichert (zirkuläre Abhängigkeit)

Schicht 6: Monitoring und Incident Response #

Verteidigung ohne Sichtbarkeit ist Hoffnung. Der Stack muss erzählen, was passiert.

Crowdsec als aktiver Schutzschild #

Crowdsec ist die Hauptverteidigung der öffentlichen Dienste – Log-aware und cluster-fähig, anders als Fail2ban:

• Log-Parser lesen Traefik- und Nextcloud-Logs via Loki-Integration
• Scenarios erkennen Credential-Stuffing, Directory-Traversal, Scanner (nmap/nikto)
• Bouncer in Traefik blockt am Reverse Proxy, bevor die Anfrage den Dienst erreicht
• Community Blocklist – bekannte Bad-IPs präventiv, nicht erst nach dem ersten Scan
• Whitelisting für Heim-IP und VPN-Endpunkte, damit man sich nicht selbst aussperrt

Sauber getrennt: Der Agent parst (hier zentral aus Loki) und meldet an die Local API (LAPI), die entscheidet; der Traefik-Bouncer setzt durch. Die Schwellen sind bewusst aggressiv – ein paar Fehlversuche, und die IP ist für Stunden weg.

Alerts – Logs und Metriken getrennt #

Loki ist für Logs da, Prometheus/Alertmanager für Metriken – beides wird zweigleisig genutzt, je nach Quelle. Kein Selbstzweck: Metriken sind für Schwellwert-Alerts gemacht, Log-Parsing nicht.

Log-basiert (Loki-Ruler):

• gescheiterte SSH-Logins jenseits einer Schwelle
• Admin-Aktionen in Proxmox und Nextcloud (Rollen-Änderungen, Passwort-Resets)
• neue Kanidm-Admin-Sessions – eine, die nicht du warst, ist ein Incident

Metrik-basiert (Prometheus/Alertmanager):

• 5xx-Quote in Traefik – deutet auf Angriff oder Ausfall
• Backup-Failures über die Velero-Metriken (velero_backup_*) – ein gescheitertes Backup ist eine Baseline-Verletzung

Die Alerts gehen an einen persistenten Kanal (Matrix, Signal, E-Mail), der auch im Incident erreichbar bleibt – nicht an einen Kanal, der im selben Stack läuft.

Außensicht mit Gatus #

Ergänzend prüft ein externer Endpoint-Checker (Gatus) die Dienste von außen – aus der Perspektive von Nutzer und Angreifer. Wird Gatus rot, während der Cluster sich intern gesund meldet, sitzt das Problem dazwischen: DNS, Zertifikat, Reverse Proxy oder Provider-Firewall.

Incident-Response-Basics #

Ein Runbook für den Worst Case, in Stichworten im Repo:

1. Erkennen – Auslöser? (Alert, merkwürdiges Verhalten, externer Hinweis)
2. Isolieren – WireGuard-Zugänge revoken, betroffene Dienste offline (Traefik-Route weg = ein Commit)
3. Analysieren – Logs sichern (Loki-Snapshot), Images/Volumes für Forensik snapshotten
4. Wiederherstellen – aus Velero restoren, Secrets rotieren, Keys neu ausrollen
5. Dokumentieren – Post-Mortem, auch nur für dich selbst

Die Secrets-Rotation danach ist länger als gedacht: DB-Passwörter, API-Tokens, SOPS-Keys, WireGuard-Keys, SSH-Host-Keys, Kanidm-Admin-Credentials. Im GitOps-Flow eine Reihe von Commits, keine Panik-Session mit kubectl edit.

Schicht 7: Backup-Sicherheit #

Backup ist die letzte Verteidigungslinie – und deshalb das häufigste Ziel moderner Ransomware. Ein Backup, das gelöscht oder verschlüsselt werden kann, ist keins.

Immutability #

Backup gehört auf S3-kompatiblen Object Storage mit Object Lock – auf diese Eigenschaft kommt es an, unabhängig vom Anbieter:

• Object Lock beim Anlegen des Buckets aktivieren – bei den meisten S3-Implementierungen nicht nachrüstbar, also von Anfang an mitdenken
• COMPLIANCE- statt GOVERNANCE-Mode – GOVERNANCE kann ein privilegierter User umgehen, COMPLIANCE niemand, auch nicht der Account-Inhaber
• Velero-User nur schreiben, nicht löschen – Write-Only; Delete-Rechte hat nur ein separater Admin-User
• Retention im Bucket erzwingen – der Object Store hält die Objekte, unabhängig von Velero
• Zusätzliche Kopie offsite – ein zweiter Job, der nur in Pull-Richtung läuft (z. B. das alte Homelab spiegelt den Cloud-Bucket)

Das ist die 3-2-1-Regel: drei Kopien, zwei Medien, eine offline/offsite. Die offline-Komponente ist bei Ransomware der entscheidende Unterschied.

Verschlüsselung #

Backups liegen auf fremder Infrastruktur – Verschlüsselung ist Pflicht. Wichtig ist, was Velero verschlüsselt:

• Volume-Daten via Kopia/Restic – der Repo-Key liegt in SOPS, nicht im Backup-Ziel
• Resource-Backups (K8s-Manifeste inkl. der live aus etcd gelesenen Secrets) verschlüsselt Velero nicht – sie landen als Tarball im Bucket. Da viele Object-Stores keine Default-Verschlüsselung at rest bieten: entweder serverseitig verschlüsseln (SSE-C mit eigenem Key) oder Secrets ausschließen, weil sie via GitOps/SOPS reproduzierbar sind. Nicht: „ist ja verschlüsselt" annehmen und Klartext-Secrets liegen lassen.
• Key-Rotation dokumentiert – Backup-Keys sind schwer zu rotieren (alte Backups brauchen alte Keys), also sorgfältig verwahren
• Key-Escrow – der Backup-Key zusätzlich verschlüsselt an einem zweiten Ort (Tresor, Schließfach, Vertrauensperson). Wer den Hauptspeicher verliert, darf nicht gleichzeitig die Backups verlieren.

Restore-Drills #

Unklar, ob das Backup funktioniert? Dann funktioniert es nicht.

• Monatlicher Restore-Test eines zufälligen Dienstes auf Test-Cluster/-Namespace
• Vierteljährlicher Full-Cluster-Restore in einer Staging-Umgebung
• Dokumentierte RTO/RPO – ohne Zielwerte keine Messung

Restore-Drills fördern zuverlässig Überraschungen zutage: fehlende Secrets, zu enge NetworkPolicies, vergessene StorageClasses. Genau dafür macht man sie.

Fazit über beide Teile #

Sicherheit ist kein Produkt, das man installiert – es ist eine Reihe von Entscheidungen, konsequent durchgezogen. Die gute Nachricht: steht die Architektur (Ansible, Flux, SOPS), ist die Baseline größtenteils Konfiguration, keine tägliche Arbeit. Einmal in Rollen und Manifests verankert, rollt sie auf jeden neuen Knoten und jede Migration mit. Die drei Prinzipien in je einem Satz:

1. Zwiebelprinzip – jede Schicht steht für sich, damit ein Durchbruch nicht den ganzen Stack öffnet.
2. Admin-Trennung – SSO für Dienste, getrennte Identitäten mit Hardware-Keys für Admin.
3. Backup-first – ein Stack ohne getestetes, unveränderliches Backup ist ein Stack auf Kredit.

Alles andere folgt daraus.

Abschluss der Serie #

Damit endet „Private Cloud 2026". Angefangen hat die Serie mit einer einzigen Frage: Lässt sich eine vollwertige private Cloud auf eigener Hardware zuhause betreiben, ohne dass sie zum zweiten Vollzeitjob wird? Über Architektur, GitOps, Backup und zuletzt die Security-Baseline ist daraus ein vollständiges Bild geworden.

Der rote Faden war nie „mach es so", sondern „hier sind die Entscheidungen und was sie kosten" – jede Schicht eine bewusste Wahl mit ehrlichen Trade-offs, kein Tutorial, das eine Lösung als alternativlos verkauft. Genau das war Absicht: Diese Serie ist die Entscheidungs-Ebene, das Warum. Theorie gibt es jetzt genug.

Ausblick: der Umzug in die „richtige" Cloud #

Diese Serie war die private Cloud zuhause. Der nächste Schritt steht schon fest: Das Ganze zieht um – in die echte Cloud. Das Ziel bleibt dabei unverändert. Weiterhin alles selbst verwaltet, volle Kontrolle, kein Managed-Kubernetes, kein fertiger Dienst von der Stange. Was sich ändert, ist nur, wessen Hardware darunter läuft: nicht mehr die Bleche im Keller, sondern die gemieteten Rechner eines Hosters. Gleiche Prinzipien, gleicher Anspruch an digitale Souveränität – anderer Standort.

Der Reiz liegt für mich an zwei Stellen, und genau die werden den Schwerpunkt der neuen Serie bilden.

Zum einen der Umzug selbst: die technischen Hürden, die nur im echten Durchlauf auftauchen. Wie kommen Daten und Volumes ohne tagelange Downtime hinüber? Wie bekommt man die Datenbanken konsistent rüber, was passiert beim Cutover, und gibt es einen Weg zurück, wenn etwas schiefläuft? Lokales Storage, das eigene Netz, die Bleche, auf die man sich verlassen konnte – all das fällt weg und muss neu gedacht werden.

Zum anderen die Sicherheit in der neuen Umgebung. Auf fremder Infrastruktur sieht die Angriffsfläche anders aus: öffentlich erreichbar statt im Heimnetz versteckt, die Firewall des Providers statt des eigenen Routers, Daten und Backups, die physisch jemand anderem gehören. Die Baseline aus diesen beiden Teilen ist die Grundlage – aber sie muss sich in der Cloud erst beweisen, und an einigen Stellen verschiebt sich, was „ausreichend" bedeutet.

Die Serie entsteht, wenn der Umzug tatsächlich passiert und ich die Schritte live durchgehe – mit den konkreten Configs, den realen Zahlen und den Stolpersteinen, die kein Plan vorhersieht.

Dieser Artikel erschien zuerst auf LinkedIn. Gedanken dazu, Fragen oder eigene Erfahrungen mit digitaler Souveränität — ich freue mich auf die Diskussion: