Betriebssicherheit

Prüfen Sie mit dieser Checkliste die Mindestanforderungen für einen sicheren Self-Hosting-Betrieb – vor dem Produktivstart, vor Updates und bei Störungen.

Umgebung trennen

Betreiben Sie jede Umgebung mit eigener Konfiguration, eigener Datenbank, eigenem Speicher, eigenen Geheimnissen und eigenem Ingress. Teilen Sie keine produktiven Geheimnisse, Datenpfade oder Datenbanken mit Test- oder Abnahmeumgebungen.

Workspace ist als zustandsarmer Server ausgelegt. Halten Sie dauerhafte Daten außerhalb des Serverprozesses:

  • PostgreSQL als externer Datenbankdienst
  • persistenter Speicher außerhalb des Containers oder Serverprozesses
  • Geheimnisse in einer Geheimnisverwaltung
  • Ingress, TLS und Weiterleitungs-Header in der Edge-Schicht

Geheimnisse schützen

Speichern Sie NUCLEUS_KEY, Datenbankzugänge, Mailzugänge und API-Zugangsdaten nicht in Images, Paketen, Skripten oder öffentlicher Dokumentation. Geben Sie Geheimnisse zur Laufzeit über Ihre Plattform bereit.

Der Server kann den Laufzeitschlüssel aus /run/secrets/nucleus-key lesen. Wenn dieser Pfad nicht verfügbar ist, kann der Prozess NUCLEUS_KEY aus der Umgebung lesen.

Schlüsseltausch planen

Workspace verwendet den Laufzeitschlüssel für verschlüsselte Konfiguration und weitere Kryptodomänen. Behandeln Sie einen Wechsel deshalb als kontrollierten Rollout mit Sicherung, Secret-Verteilung, Neustarts, Inventur und Erfolgskontrolle.

Unterscheiden Sie Legacy-Bundle-Migration, geplante Routine-Rotation und Emergency bei einem kompromittierten Key. Root-Key sicher rotieren hilft Ihnen bei der Auswahl und führt durch die gemeinsamen Prüfungen.

Netzwerk begrenzen

Führen Sie externe Anfragen über einen kontrollierten Ingress oder Reverse Proxy. Öffnen Sie den Serverprozess nicht direkt für öffentliche Clients.

Beschränken Sie interne Abhängigkeiten auf die notwendigen Netzpfade:

  • Datenbank
  • Speicher-Backend
  • Mail- oder Integrationsdienste
  • Monitoring und Log-Erfassung

Setzen Sie Timeouts, Header-Limits und Request-Größenlimits in Ihrer Edge-Schicht passend zu Ihrer Betriebsumgebung.

Forwarded-Header absichern

Der Reverse Proxy muss eingehende Forwarded- und X-Forwarded-*-Header von Clients verwerfen und selbst neu setzen. Workspace darf öffentliche URL-Informationen nur aus vertrauenswürdigen Proxies übernehmen.

Pflegen Sie die Proxy-Netze in routing.trusted_proxy_cidrs, sobald Workspace hinter einem Reverse Proxy oder Load Balancer läuft. Akzeptiert werden JSON-Arrays oder kommagetrennte CIDR-Listen.

Setzen Sie bei TLS-Terminierung vor Workspace konsistent:

  • X-Forwarded-Proto: https oder Forwarded: proto=https
  • X-Forwarded-Host für hostbasiertes Routing

Logs und Diagnose begrenzen

Erfassen Sie Server- und Ingress-Logs so, dass Sie Anfragen, Startfehler, Upstream-Fehler und Proxy-Fehlkonfigurationen korrelieren können. Geben Sie Logs nur weiter, nachdem Sie personenbezogene Daten, Tokens, Cookies, Adressen und Zugangsdaten entfernt haben.

Aktivieren Sie zusätzliche Incident-Diagnostik nur gezielt und zeitlich begrenzt. Nutzen Sie dafür den globalen Konfigurationswert ops.diagnostics.incident_debug.enabled und deaktivieren Sie ihn nach der Analyse wieder.

Backup und Restore vorbereiten

Definieren Sie Backup, Restore, RPO und RTO vor dem Produktivstart. Sichern Sie mindestens:

  • PostgreSQL-Datenbank
  • persistenten Speicher
  • verschlüsselte Serverkonfiguration
  • dazugehörige Laufzeitschlüssel
  • verwendete Release-Artefakte und Prüfsummen

Testen Sie Restore-Prozesse außerhalb der Produktionsumgebung. Ein erfolgreiches Backup ohne getesteten Restore ist kein belastbarer Rollback-Pfad.