Zum Inhalt

Härtungs-Checkliste

Wenn die Instanz produktiv geht, diese Liste durcharbeiten. Alles ist optional, aber die meisten Punkte solltest du nicht überspringen.

Authentifizierung

  • [ ] 2FA Pflicht für Super-Admin und Tenant-Admin
  • [ ] 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

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, FCM, SMTP)
  • [ ] Inbound 80/443 only — alle anderen Ports geschlossen außer evtl. SSH und NSCA
  • [ ] 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)

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 als Log-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

  • [ ] Permissions-Inventur — kein User mit mehr als nötig
  • [ ] Default-Admin-Account nicht für Alltag verwenden
  • [ ] Auditor-Rolle für externe Auditoren (nur audit.view, audit.export)

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)

Mobile

  • [ ] Eigenes Firebase-Projekt, wenn Privacy gefragt (statt Shared)
  • [ ] APK-Distribution über MDM, nicht freier Download

Custom-Code (Scripts, Profile)

  • [ ] script.create nicht für Viewer/Operator
  • [ ] 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)
  • [ ] 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

Anschluss