Benutzer & Audit
Die Seiten „Benutzer“ und „Audit-Protokoll“ stehen nur Admins zur Verfügung. Die Benutzerverwaltung regelt den laufenden Zugang. Das Audit-Protokoll zeigt die gespeicherten Ereignisse und prüft, ob ihre kryptografische Verkettung noch stimmt. Die fachliche Bedeutung der Ereignisse erklärt Rückverfolgbarkeit & Genealogie.
Benutzer anlegen
Öffnen Sie unter „Administration“ die Seite „Benutzer“. Im Bereich „Benutzer hinzufügen“ tragen Sie „Badge“, „Name“ und „Start-PIN“ ein. Wählen Sie außerdem eine der Rollen operator, planner oder admin. Mit „Benutzer hinzufügen“ legen Sie den Zugang an.
Der Server verlangt einen eindeutigen, nicht leeren Badge-Wert und einen nicht leeren Namen. Für die PIN prüft er eine Mindestlänge von vier Byte; vier ASCII-Zeichen erfüllen diese Grenze. Die Oberfläche aktiviert die Schaltfläche erst, wenn Badge, Name und PIN ausgefüllt sind. Eine bereits verwendete Badge-ID lehnt der Server ab.
Die PIN wird nicht im Klartext gespeichert. Das Ereignis UserCreated enthält Badge, Name und Rolle, aber keine PIN.
Rollen
Die Rollen bilden eine feste Rangfolge. admin umfasst die Rechte von planner, planner die Rechte von operator.
operatornutzt veröffentlichte Ansichten und führt freigegebene Aktionen am Terminal aus.plannerkann zusätzlich Ansichten entwerfen, prüfen und veröffentlichen.adminverwaltet zusätzlich Benutzer, Audit, Navigation und die übrige Konfiguration.
Die Benutzerseite zeigt die Rolle als technischen Bezeichner. Die Rolle lässt sich dort nur beim Anlegen auswählen. Für einen bestehenden Benutzer gibt es derzeit weder in der Oberfläche noch in der Benutzer-API eine Funktion zum Rollenwechsel. Weitere Einzelheiten zu Berechtigungen und Stationen finden Sie unter Rollen & Stationen.
PIN zurücksetzen
Wählen Sie beim betreffenden Benutzer „PIN zurücksetzen“. Tragen Sie im Feld „neue PIN“ mindestens vier ASCII-Zeichen ein und bestätigen Sie mit „Speichern“. Die alte PIN ist dafür nicht erforderlich.
Der Reset ersetzt den gespeicherten PIN-Hash und hebt zugleich eine bestehende Sperre nach Fehlversuchen auf. Das Audit-Ereignis UserPINReset hält nur fest, dass ein Reset stattgefunden hat. Die neue PIN steht weder im Ereignis noch in der Benutzerliste.
Nach fünf falschen PIN-Eingaben sperrt der Server den Zugang für fünf Minuten. Ein Admin kann diese Wartezeit mit einem PIN-Reset beenden.
Deaktivieren und reaktivieren
Mit „Deaktivieren“ entziehen Sie einem Benutzer den Zugang, ohne seinen Datensatz zu löschen. Seine bestehenden Sitzungen verlieren beim nächsten API-Aufruf ihre Gültigkeit. Bereits gespeicherte Ereignisse behalten den ursprünglichen Akteur.
Der aktuell angemeldete Admin kann sich nicht selbst deaktivieren. Die Oberfläche blendet die Schaltfläche für das eigene Konto aus, und der Server erzwingt dieselbe Regel. Auch den letzten aktiven Admin lehnt der Server als Ziel einer Deaktivierung ab.
Ein inaktiver Benutzer erhält den Status „inaktiv“. Mit „Reaktivieren“ geben Sie den Zugang wieder frei. Anlegen, Deaktivieren, Reaktivieren und PIN-Reset erzeugen jeweils ein Ereignis im Benutzer-Stream.
Audit filtern
Öffnen Sie „Audit-Protokoll“. Die Tabelle zeigt „Zeit“, „Typ“, „Akteur“, „Terminal“ und „Stream“, neue Ereignisse zuerst. Mit „Details“ öffnen Sie die gespeicherten Felder data und meta; mit „ausblenden“ schließen Sie diese Ansicht wieder.
Die sichtbaren Filter arbeiten mit exakten Werten:
- „Akteur-Badge“ grenzt auf genau einen Badge-Wert ein.
- „Ereignistyp“ erwartet den technischen Typ, zum Beispiel
UserDeactivated. - „Stream“ erwartet den vollständigen Stream-Namen, zum Beispiel
user:<id>. - „Filtern ab“ schließt Ereignisse ab dem gewählten Zeitpunkt ein.
- „Filtern bis“ schließt den gewählten Endzeitpunkt selbst aus.
Mehrere ausgefüllte Felder werden gemeinsam angewendet. Starten Sie die Abfrage mit „Suchen“. Die erste Seite enthält höchstens 100 Ereignisse. Wenn weitere vorhanden sein können, lädt „Mehr laden“ die nächstälteren Ereignisse nach.
Die API unterstützt zusätzlich einen exakten Terminalfilter und ein einstellbares Limit bis 500. Dafür gibt es in der aktuellen Oberfläche keine Eingabefelder.
Kette prüfen
Beim Öffnen des Audit-Protokolls startet automatisch eine vollständige Prüfung. „Erneut prüfen“ wiederholt sie. Das Prüfergebnis nennt Modus, geprüfte Ereignisse, Streams und Prüfpunkte.
„✓ Kette intakt“ bedeutet, dass die Prüfung alle Stream-Ketten, die Kette der Prüfpunkte und den Vergleich mit dem zuletzt gespeicherten Stand ohne Bruch abgeschlossen hat. Anschließend versucht der Server, einen neuen Prüfpunkt als nächste Basis zu speichern. „✗ Manipulation erkannt“ nennt die zuerst gefundene Bruchstelle als Ereignis, Prüfpunkt, Stream-Spitze oder als rückläufige Gesamtzahl der Ereignisse.
Der Modus im Prüfergebnis ist wesentlich. Mit einem gültigen Schlüssel aus FOUNDRY_SECRET_KEY oder, falls diese Variable leer ist, aus der über FOUNDRY_SECRET_KEY_FILE benannten Datei prüft WERKSPUR eine HMAC-Verkettung. Nur wenn beide Variablen fehlen, verwendet die Anwendung eine reine SHA-256-Verkettung. Die betriebliche Bedeutung und die Prüfung über die Kommandozeile beschreibt Sicherheit im Betrieb.
Grenzen
Das Audit-Protokoll ist kein allgemeines Zugriffsprotokoll. Es zeigt Ereignisse aus dem Event Store, nicht jeden Seitenaufruf oder jede Leseabfrage. Leere Felder bei Akteur oder Terminal können bei Systemereignissen zulässig sein.
Eine intakte Kette beweist die unveränderte Verkettung der gespeicherten Ereignisse. Sie beweist nicht, dass eine fachliche Eingabe richtig war oder dass ein Benutzer seinen Badge nicht weitergegeben hat. Im schlüssellosen Modus könnte jemand mit vollständigem Datenbankzugriff eine veränderte Kette neu berechnen. HMAC schützt dagegen nur, solange der Schlüssel getrennt von der Datenbank geschützt bleibt.
Die Detailansicht kann fachliche Nutzdaten enthalten. Beschränken Sie den Admin-Zugang deshalb auf Personen, die diese Daten sehen dürfen. Wenn die Prüfung kein Ergebnis liefert oder eine Suche unerwartet leer bleibt, kontrollieren Sie die Anwendungslogs. Die Seite stellt Fehler beim Laden derzeit nicht als eigenen Fehlerstatus dar.