Härtungs-Checkliste¶

Wenn die Instanz produktiv geht, diese Liste durcharbeiten. Alles ist optional, aber die meisten Punkte solltest du nicht überspringen. Die Grundhaltung von Vesana ist outbound-only: Der Server hat keine ausgehende Verbindung zu überwachten Maschinen, Agents und Collectors verbinden sich immer von innen nach außen. Das reduziert die Angriffsfläche strukturell — die Punkte unten härten den Server selbst.

Authentifizierung¶

[ ] 2FA Pflicht für Super-Admin und Tenant-Admin — verfügbare Methoden: TOTP (Authenticator-App wie Aegis/Authy/Google Authenticator) oder WebAuthn (Hardware-Key/Passkey). Backup-Codes sind beim Aktivieren Pflicht.
[ ] Passwort-Komplexität in Admin-Settings auf hoch
[ ] JWT-Lebensdauer auf 8–24 h begrenzen (kürzer = häufiger Login, sicherer)
[ ] Default-Admin-Account umbenennen oder deaktivieren — nicht admin@example.com lassen
[ ] Login-Rate-Limit verifizieren — Default 10 req/min pro IP für Login und 2FA-Verify, 3 req/min für 2FA-Resend

Tokens¶

[ ] Agent-Tokens minimal verteilen — nur einer pro Host
[ ] Collector-API-Keys mit langem Prefix benennen, sodass beim Leak sofort klar ist welcher Tenant
[ ] Personal-Access-Tokens mit kurzer Lebensdauer (z. B. 90 Tage) und gezieltem Scope

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 (Default ja)
[ ] TLS 1.2+ only in nginx-Config
[ ] A/A+ bei SSL Labs
[ ] Renewal automatisiert (Let's-Encrypt) oder Kalender-Reminder vor Ablauf

Netzwerk¶

[ ] Outbound-Whitelist auf dem Server: nur erlaubte Ziele (Registry, Lizenzportal, Push-Dienste der Browser, SMTP)
[ ] Inbound 80/443 only — alle anderen Ports geschlossen außer evtl. SSH und NSCA. 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

API-Replicas und Locking¶

[ ] Wenn mehrere API-Replicas: Distributed Locks via Redis funktionieren (System-Tab beobachten)
[ ] Redis-Auth aktiv (REDIS_PASSWORD gesetzt — Default ja, prüfen)

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
[ ] Frontend-Image (nginx) läuft mit eingebautem nginx-User — keine Anpassung nötig

Logging und Monitoring¶

[ ] Audit-Log aktiv und Retention konfiguriert
[ ] Log-Tailing extern falls Compliance-relevant (z. B. an SIEM)
[ ] System-Health-E-Mail-Alarm an Super-Admins
[ ] Failed-Login-Alerts über einen Eventlog-/Script-Check + Alert-Regel anlegen

Updates¶

[ ] GUI-Updater funktioniert (Test mit kleinem Update vor erstem Live-Update)
[ ] Backup vor jedem Update läuft (Default ja, prüfen)
[ ] Update-Fenster kommuniziert (Statuspage / Wiki)

Backup¶

[ ] Backup-Sidecar aktiv
[ ] Off-Site-Kopie (mind. wöchentlich)
[ ] Restore-Drill mind. 1× pro Quartal
[ ] .env-Backup separat

RBAC¶

Vesana ist deny-by-default: Jeder API-Endpunkt verlangt eine explizite Permission — ohne passende Permission gibt es 403, nie ein implizites „darf trotzdem". Vier Basis-Rollen (Super-Admin, Admin, Operator, Viewer) decken die Standardfälle ab; Custom-Roles erlauben granulare Permission-Zusammenstellung darüber hinaus. tenant_access steuert unabhängig davon, welche Mandanten ein User überhaupt sieht (ein Tenant, mehrere, oder alle als Super-Admin) — jede Datenbank-Query ist zusätzlich automatisch nach Tenant gefiltert.

[ ] Permissions-Inventur — kein User mit mehr als nötig
[ ] Default-Admin-Account nicht für Alltag verwenden
[ ] Auditor-Rolle für externe Auditoren (nur Lese-Permissions wie audit_log.view_tenant)
[ ] tenant_access prüfen — Cross-Tenant-Read 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-Sichtbarkeit Toggle in User-Pref erklären (Datenschutz-Wunsch)

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, custom, ssh_script, ssh_custom) können beliebigen Code auf überwachten Maschinen 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.
Sandbox des Aktiven Collectors: Scripts laufen mit eingeschränkten Capabilities, nicht mit vollen Root-Rechten. Server-interne Adressen (Loopback, Docker-Netze) sind für Checks nicht-privilegierter Nutzer gesperrt, und pro Tenant lässt sich freigeben, ob Netzwerk-Checks bzw. eigene Plugins über den Server laufen dürfen (Admin → Agents & Collectors → Active-Checker, ab v1.9.437).

Checkliste:

[ ] script.create 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
[ ] Policies, die Scripts ausrollen — nur Super-Admin erlaubt (systemseitig erzwungen, nicht konfigurierbar)

Sicherheits-Updates¶

[ ] CVE-Feeds beobachten (Postgres, Redis, FastAPI, React)
[ ] Docker-Images regelmäßig pullen (GUI-Updater macht das)

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	klar: keine personenbezogenen Daten überwacht (sondern Geräte). Login-Daten ja → Auftragsverarbeitung-Vertrag mit Anbieter
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