Härtungs-Checkliste¶

Wenn die Instanz produktiv geht, diese Liste durcharbeiten. Alles ist optional, aber die meisten Punkte solltest du nicht überspringen. Agents und Collectors verbinden sich immer von sich aus zum Server; auf den überwachten Maschinen muss kein Port eingehend offen sein. Nur der Aktive Collector auf dem Vesana-Server baut selbst Verbindungen zu den Zielen seiner Checks auf. Die Punkte unten härten den Server selbst.

Authentifizierung¶

[ ] 2FA-Pflicht für Super-Admins und Admins per Regel unter Admin → Anmeldung & Sicherheit → 2FA & Sitzungen — Methoden: Authenticator-App (TOTP) oder Passkey/Hardware-Key (WebAuthn). Beim Einrichten entstehen Backup-Codes. Siehe 2FA.
[ ] Sitzungsdauer prüfen — Standard 30 Tage ohne Nutzung, höchstens 90 Tage; „Angemeldet bleiben" lässt sich verbieten (Login-Sitzungen)
[ ] Erstes Admin-Konto (aus dem Einrichtungsassistenten) mit starkem Passwort und 2FA — und nicht für den Alltag verwenden
[ ] Login-Rate-Limit greift — 10 Anfragen/min pro Client-IP für Login und 2FA-Prüfung; 5 falsche 2FA-Codes sperren das Konto für 30 Minuten
[ ] Hinter einem eigenen Reverse-Proxy: dessen Adresse unter Admin → Anmeldung & Sicherheit → Admin-Zugriff → Erweitert als vertrauenswürdigen Proxy eintragen, sonst zeigen Sitzungsliste und Audit-Log die Adresse des Proxys
[ ] Admin-Bereich einschränken (optional): IP-Allowlist oder eigener Admin-Container unter Admin-Zugriff — siehe Admin-Zugriff & Split-Container

Tokens¶

[ ] Agent-Tokens nur auf den Rechner legen, für den sie ausgestellt sind — ein Token gilt für genau einen Host
[ ] Verlorene Tokens/Keys sofort erneuern (Host verwalten → Token erneuern bzw. Key erneuern am Collector) — siehe Tokens & API-Keys
[ ] .env geschützt — Rechte 600 (setzt der Installer); sie enthält SECRET_KEY, FIELD_ENCRYPTION_KEY und die Datenbank-Passwörter

Verschlüsselung¶

[ ] FIELD_ENCRYPTION_KEY im Passwort-Manager + Print-Backup im Tresor
[ ] Backup vom Schlüssel separat vom DB-Backup
[ ] Niemand außer 1–2 Personen sollte den Schlüssel kennen

TLS¶

[ ] Echtes Cert (Let's-Encrypt oder eigene CA), nicht selbstsigned in Production
[ ] HSTS aktiv (Standard)
[ ] TLS 1.2/1.3 — Standard im eingebauten nginx; bei eigenem Reverse-Proxy dort einstellen
[ ] Erneuerung automatisch (Zertifikat aus Vesana) oder Ablauf über den Check „TLS Certificate" am Host „Vesana Server" in eine Alarm-Regel aufnehmen

Netzwerk¶

[ ] Outbound-Whitelist auf dem Server: nur erlaubte Ziele (Container-Registry, Lizenzportal, ggf. Vesana-Bibliothek community.vesana.org, Push-Dienste der Browser, SMTP, Benachrichtigungsdienste) — siehe Datenschutz & ausgehende Verbindungen
[ ] Eingehend nur 80/443 (bzw. die gewählten Ports) — alle anderen Ports geschlossen außer evtl. SSH. Sollen Agents aus fremden Netzen einliefern: Agent-Gateway aktivieren und stattdessen NUR den Gateway-Port öffentlich freigeben (UI-Port intern/VPN)
[ ] SSH mit Key-only, nicht Passwort
[ ] Fail2ban o. ä. auf SSH-Brute-Force
[ ] Firewall-Regeln dokumentiert und versioniert

Redis¶

[ ] Redis-Passwort gesetzt (REDIS_PASSWORD in der .env — erzeugt der Installer)

Container-Isolation¶

[ ] Non-root bestätigen — API-, Worker-, Receiver- und AI-Service-Container laufen als non-root (USER app, UID 1000). Einzige bewusste Ausnahme: der Updater-Container bleibt root, weil er den Docker-Socket beschreiben muss, um Updates auszuführen.
[ ] Docker-Socket nicht zusätzlich an andere Container mounten
[ ] Webserver-Container (nginx) — die Arbeitsprozesse laufen als nginx-Benutzer, keine Anpassung nötig

Logging und Monitoring¶

[ ] Audit-Log-Aufbewahrung prüfen (Admin → System → Ressourcen → Speicher; Standard: unbegrenzt)
[ ] Log-Tailing extern falls Compliance-relevant (z. B. an SIEM)
[ ] Checks am Host „Vesana Server" in eine Alarm-Regel aufnehmen — sie melden Probleme der Instanz selbst
[ ] Fehlgeschlagene Anmeldungen an überwachten Rechnern über einen Eventlog-/Script-Check + Alert-Regel melden lassen

Updates¶

[ ] GUI-Updater funktioniert (Test mit kleinem Update vor erstem Live-Update)
[ ] Sicherheitsupdates automatisch — Admin → System → Updates (für neue Installationen Standard)
[ ] Backup vor jedem Update läuft (Standard)
[ ] Update-Fenster kommuniziert (Statuspage / Wiki)

Backup¶

[ ] Automatische Backups eingeplant (Admin → System → Backup & DR)
[ ] Off-Site-Kopie (mind. wöchentlich)
[ ] Restore-Drill mind. 1× pro Quartal
[ ] .env-Backup separat

RBAC¶

Rechte vergibt Vesana über Rollen: vier eingebaute (Super-Admin, Admin, Operator, Viewer) plus eigene Rollen mit frei zusammengestellten Permissions. Eine Rolle gilt je Tenant — ein Konto (oder ein Team) kann in einem Tenant Admin sein und in einem anderen nur lesen. Was ein Konto in einem Tenant nicht darf, verweigert der Server (403); Daten anderer Tenants sieht es gar nicht. Details: Rollen & Permissions.

[ ] Permissions-Inventur — kein User mit mehr als nötig
[ ] Super-Admin nur für wenige Konten — Super-Admins sehen alle Tenants und sind von Einschränkungen ausgenommen
[ ] Auditor-Rolle für externe Auditoren (nur Lese-Permissions wie audit_log.view_tenant)
[ ] Zuweisungen „alle Tenants" nur wo wirklich gebraucht (MSP-Rollen)

AI¶

[ ] Wenn Cloud-Provider: klar sein, was an die API geht
[ ] AI-Permissions sparsam — nicht jeder User braucht ai.query/ai.analyze
[ ] KI-Websuche: Liefert das Wiki zu wenig, geht die Frage an DuckDuckGo — auch mit lokalem Ollama (siehe Datenschutz)

Smartphone / Push¶

[ ] HTTPS ist Pflicht — ohne sicheren Kontext erlaubt kein Browser Installation oder Push
[ ] Push-Schlüssel (VAPID) sichern — sie gehören zur Instanz und stecken im Backup; nach einem Neuaufbau ohne Backup müssen alle Geräte Push neu aktivieren

Custom-Code (Scripts, Profile)¶

Script-fähige Check-Typen (agent_script, agent_custom, ssh_script, ssh_custom, ssh_command, api_script, plugin_local) können beliebigen Code auf überwachten Maschinen bzw. am Collector ausführen — das ist der sensibelste Punkt im ganzen System und deshalb eigens abgesichert:

Apply-Scope pro User: Wer Script-Checks anlegen/ändern darf, ist granular einschränkbar — nach Tenant, nach Tag oder auf einzelne Hosts. Ohne eigene Einstellung gilt der Standard der Rolle: Admin darf auf allen erreichbaren Tenants Scripts anwenden, jede andere Rolle nicht (Super-Admins sind nie eingeschränkt). Eine gespeicherte Einstellung ersetzt den Standard — auch „Keine" für einen Admin.
Reichweite wird gefragt, nicht angenommen: Vor dem Speichern eines Script-Inhalts steht, wie viele Checks daran hängen — man wählt „für alle", „als eigenes Script" (Kopie) oder „nur dieses Gerät". So ändert niemand versehentlich ein von vielen Hosts geteiltes Script.
Identität bestätigen: Wer ausgeführten Code ändert (Script anlegen, Rumpf ändern, Bundle mit Code importieren), bestätigt seine Identität erneut — Standard an, abschaltbar unter Admin → Anmeldung & Sicherheit → 2FA & Sitzungen.
Aktiver Collector: läuft als eigenes Dienstkonto mit eingeschränkten Rechten, nicht als root. Server-interne Adressen (Loopback, Docker-Netze) sind für Checks gesperrt, die kein Super-Admin gespeichert hat, und pro Tenant lässt sich freigeben, ob Checks bzw. eigene Plugins über den Server laufen dürfen (Admin → Agents & Collectors → Active-Checker).
Agent Lock: Am Host selbst lässt sich festlegen, dass Scripts erst nach lokaler Freigabe laufen — Schutz für den Fall, dass Vesana selbst kompromittiert wird. Siehe Agent Lock.

Checkliste:

[ ] monitoring_scripts.create/.edit nicht für Viewer/Operator
[ ] Apply-Scope pro User sinnvoll eingeschränkt (nicht pauschal „alle Tenants")
[ ] Custom-Scripts vor Roll-out auf Test-Maschine prüfen
[ ] Profile-Imports aus unbekannter Quelle vorsichtig

Sicherheits-Updates¶

[ ] CVE-Feeds beobachten (Postgres, Redis, FastAPI, React)
[ ] Updates zeitnah einspielen (GUI-Updater, Sicherheitsupdates automatisch)

Dokumentation für Operations¶

[ ] Runbooks im Wiki — was tun bei XYZ
[ ] Kontaktliste für Eskalationen (im Wiki)
[ ] Status-Page für externe Kommunikation
[ ] Ablage FIELD_ENCRYPTION_KEY dokumentiert (wer hat Zugriff)

Compliance-spezifisch¶

Standard	Was speziell
ISO 27001	Audit-Log + 2FA + Backup-Drill ausreichend für die meisten Audits
DSGVO	Vesana überwacht Geräte, keine Personen — Logs und Benutzerkonten können aber personenbezogene Daten enthalten, siehe Datenschutz
HIPAA	Cloud-AI ausschalten oder Anbieter mit BAA wählen
PCI	Vesana ist out-of-scope wenn nicht in Card-Data-Pfad — kann aber beim Monitoring helfen