Betriebssicherheit

Diese Seite beschreibt die Mindestanforderungen für einen sicheren Self-Hosting-Betrieb von Workspace. Nutzen Sie sie als Checkliste vor Produktivstart, Update und Störungsanalyse.

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 nutzt den Laufzeitschlüssel für verschlüsselte Konfiguration und root-key-gebundene Kryptodomänen. Behandeln Sie einen Schlüsseltausch deshalb als kontrollierte Betriebsaufgabe, nicht als spontane Änderung einer einzelnen Umgebungsvariable.

Unterscheiden Sie zwei Fälle:

  • Bestehende Installationen mit einem einzelnen Legacy-NUCLEUS_KEY heben Sie zuerst auf das Bundle-Format nucleus-root-key-bundle.v1. Dabei bleibt das bestehende Schlüsselmaterial gleich.
  • Eine echte Root-Key-Rotation fügt neues Schlüsselmaterial hinzu, verteilt es an alle beteiligten Prozesse, aktiviert die neue kid erst nach erfolgreicher Konvergenz und entfernt alte Keys erst später.

Planen Sie für eine Rotation ein Wartungsfenster oder einen kontrollierten Rollout. Rollen Sie dasselbe Bundle über Ihre zentrale Secret-Verteilung an alle Prozesse aus, die verschlüsseln, entschlüsseln, signieren oder verifizieren. Dazu gehören mindestens der Workspace-Server und der Ingress.

Führen Sie die Rotation in Phasen durch:

  1. Bereiten Sie eine neue kid vor, ohne sie sofort zu aktivieren.
  2. Verteilen Sie das vorbereitete Bundle über Ihre Secret-Verteilung.
  3. Starten Sie die betroffenen Go-Dienste neu.
  4. Prüfen Sie die Bundle-Konvergenz und die Root-Key-Gates.
  5. Aktivieren Sie die neue kid erst, wenn die Verteilung sauber ist.
  6. Verschlüsseln Sie die Konfiguration mit der aktiven kid neu.
  7. Beobachten Sie Drain und Runtime-Aktivität, bevor Sie alte Keys entfernen.

Nutzen Sie für die konkrete Ausführung die betrieblichen Runbooks zur Root-Key-Bundle-Migration und zur periodischen Root-Key-Rotation. Die öffentliche Admin-Dokumentation beschreibt nur die Betriebslogik; die kommandogenauen Abläufe bleiben in den Runbooks.

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.