Sicherheit im Betrieb

Keine Standard-Zugänge

Der erste Admin entsteht nur bei leerer Benutzertabelle und nur aus FOUNDRY_BOOTSTRAP_ADMIN_BADGE und FOUNDRY_BOOTSTRAP_ADMIN_PIN. Der mitgelieferte Compose-Stack verlangt beide Werte. Der Bootstrap-PIN muss mindestens vier Zeichen enthalten und darf nicht ausschließlich aus derselben wiederholten Ziffer bestehen. Sobald ein Benutzer existiert, legt der Bootstrap bei weiteren Starts kein Konto mehr an. Die Variablen sind kein Mechanismus zum Zurücksetzen eines Zugangs.

Die laufende Pflege findet unter „Benutzer“ statt, nicht in deploy/.env. Admins legen dort weitere Zugänge an, deaktivieren und reaktivieren Konten oder verwenden „PIN zurücksetzen“. Es gibt derzeit keine Funktion zum Ändern der Rolle eines bestehenden Benutzers. Die vollständigen Abläufe und Grenzen beschreibt Benutzer & Audit.

Diese Aussage gilt für die WERKSPUR-Anmeldung. PostgreSQL und die mitgelieferten Broker besitzen lokale Standardwerte für Entwicklung. Ändern Sie diese in gemeinsam genutzten Umgebungen. Entfernen oder beschränken Sie außerdem die Broker-Portfreigaben der Compose-Datei.

Die private Installationsidentität im Volume /var/lib/werkspur/license ist ebenfalls Schlüsselmaterial. Sichern und schützen Sie sie getrennt von der signierten, nicht geheimen Lizenzdatei. Den vollständigen Ablauf beschreibt Lizenzbetrieb.

Registrierte Stationen

Für operator und planner muss ein nicht leerer Stationsname im Stationsregister vorhanden sein. Ein unbekannter Name wird auch bei gültigem Badge und gültiger PIN abgelehnt. Ein Stationsname beginnt mit einem Kleinbuchstaben und enthält danach nur Kleinbuchstaben, Ziffern und Bindestriche.

Ein leeres Stationsfeld ist für jede Rolle zulässig. Admins umgehen die Stationsprüfung; ihr eingegebener Wert wird dennoch in der Sitzung gespeichert. Das Stationsregister ist deshalb eine Zuordnungs- und Audit-Grenze für benannte Bediener- und Planerterminals, aber keine allgemeine Netzwerkzugangskontrolle. Wie Sie eine Station anlegen, zeigt Grund-Codes, Stationen & Abteilungen. Weitere Rollen- und Anmeldegrenzen finden Sie unter Rollen & Stationen.

Im mitgelieferten Stack sind NATS, MQTT sowie AMQP einschließlich der Management-Oberfläche vom Host aus erreichbar. Diese Freigaben dienen Entwicklung und Fehlersuche. Entfernen Sie die betreffenden ports-Einträge im Produktivbetrieb oder binden Sie sie an 127.0.0.1. deploy/docker-compose.yml markiert die betroffenen Stellen.

Die Audit-Kette prüfen

Admins prüfen die Kette unter „Audit-Protokoll“. Die Seite verwendet den Admin-Endpunkt GET /api/audit/verify. Filter, Ergebnisfelder und Grenzen der Oberfläche beschreibt Benutzer & Audit.

Für eine Prüfung über die Kommandozeile verwenden Sie werkspur verify-audit. Das Kommando liest die Ereignisse direkt aus der in FOUNDRY_POSTGRES_URL angegebenen Datenbank. Stellen Sie ihm denselben Master-Schlüssel wie der laufenden Anwendung bereit. Das JSON-Prüfergebnis enthält unter anderem ok, mode und bei einem Bruch broken_at. Bei ok: false endet das Kommando mit einem Exit-Code ungleich null.

Mit einem gültigen Master-Schlüssel verwendet WERKSPUR einen daraus abgeleiteten HMAC-Schlüssel. Eine Person mit Datenbankzugriff, aber ohne Master-Schlüssel, kann eine geänderte Kette nicht passend neu berechnen. Ohne FOUNDRY_SECRET_KEY und FOUNDRY_SECRET_KEY_FILE verwendet eine selbst erstellte Bereitstellung eine reine SHA-256-Verkettung. Diese erkennt Änderungen nur, solange niemand mit vollständigem Datenbankzugriff auch die Hashes und Prüfpunkte neu berechnet. Das Feld mode nennt hmac oder sha256.

Die Prüfung umfasst die Ketten der einzelnen Ereignis-Streams, die Prüfpunktkette und den Vergleich mit dem zuletzt gespeicherten Prüfpunkt. Sie belegt weder die fachliche Richtigkeit einer ursprünglichen Eingabe noch jeden Lesezugriff. Diese Grenzen und den Zusammenhang mit den gespeicherten Ereignissen erläutern Benutzer & Audit und Rückverfolgbarkeit & Genealogie.

Master-Schlüssel

FOUNDRY_SECRET_KEY enthält einen base64-kodierten 32-Byte-Master-Schlüssel. Die Anwendung verschlüsselt damit Secret-Werte über AES-256-GCM. Für die Audit-Kette leitet sie einen getrennten HMAC-Schlüssel aus demselben Master-Schlüssel ab.

Ein selbst gestarteter Prozess kann stattdessen FOUNDRY_SECRET_KEY_FILE verwenden. Die Datei darf den Schlüssel base64-kodiert oder als genau 32 Rohbytes enthalten. Wenn beide Variablen gesetzt sind, hat FOUNDRY_SECRET_KEY Vorrang. Der mitgelieferte Compose-Stack reicht die Dateivariable nicht weiter und verlangt ausdrücklich FOUNDRY_SECRET_KEY.

Ohne den ursprünglichen Schlüssel lassen sich gespeicherte Secrets nicht entschlüsseln. Eine Audit-Prüfung mit einem anderen Schlüssel meldet außerdem einen Bruch der vorhandenen HMAC-Kette. Für Umzug und Wiederherstellung benötigen Sie deshalb exakt denselben Wert. Sichern Sie ihn getrennt vom Server, beispielsweise im Passwortmanager Ihres Betriebs.

deploy/docker-compose.yml verlangt den Wert bereits bei der Interpolation. In einer angepassten Bereitstellung ohne Master-Schlüssel bleibt der Secret-Speicher deaktiviert; Schreibzugriffe auf Secrets antworten mit 503. Sobald bereits mindestens ein Secret gespeichert ist, verhindert ein fehlender Schlüssel den Anwendungsstart. Eine automatische Schlüsselrotation oder Wiederherstellung ohne den bisherigen Schlüssel ist nicht vorhanden.

Einen neuen Schlüssel erzeugen Sie mit einem einzigen Kommando:

openssl rand -base64 32

Tragen Sie das Ergebnis in deploy/.env ein und legen Sie eine getrennte Sicherung an. Ändern Sie den Wert nicht, solange die zugehörige Datenbank verwendet wird. Anlage und Referenzierung einzelner Secrets beschreibt Secrets.

Idempotente Aktionsaufrufe

Die Aktions-Widgets der Oberfläche senden bei POST /api/actions/{name}/invoke einen Idempotency-Key. Nach einem unklaren Fehler verwenden sie denselben Schlüssel erneut, solange Eingaben und Kontext unverändert bleiben. Der Server führt denselben Aktionsnamen mit demselben Schlüssel nicht erneut aus. Eine Wiederholung liefert die gespeicherte Antwort mit Idempotency-Replayed: true.

Diese Zusage gilt nur für den Aktionsendpunkt und nur, wenn der Client den Header sendet. Ohne Header findet keine Deduplizierung statt. Zulässig sind 8 bis 128 Zeichen aus Buchstaben, Ziffern und Bindestrichen. Weitere Einzelheiten zur Aufbewahrungsdauer und zur sicheren API-Nutzung finden Sie unter API & Authentifizierung.

Nach einer unterbrochenen Live-Verbindung laden offene Ansichten ihren Stand bei Wiederverbindung neu. Dafür ist keine zusätzliche Umgebungsvariable erforderlich.