Admin-Tab: Tresor-Historie (Protokolle)

Admin

Der Admin-Bereich Protokolle bündelt drei getrennte Sichten: die PII-Audit-Protokolle (welche personenbezogenen Daten erkannt wurden), die Tresor-Historie (was sich inhaltlich geändert hat) und das API-Zugriffsprotokoll (wer technisch zugegriffen hat). Dieser Artikel beschreibt vor allem die Tresor-Historie und ihre Abgrenzung. Die PII-Audit-Protokolle sind separat dokumentiert. → Admin-Tab: Audit-Protokoll (PII)

Was die Tresor-Historie erfasst

Die Tresor-Historie ist ein fachliches Änderungs-Audit: Sie hält fest, dass und wie sich der Inhalt zentraler (geteilter) Tresore geändert hat. Erfasst wird jede Inhaltsmutation an einem zentralen Tresor:

Operationen: Erstellen, Aktualisieren, Löschen, Umbenennen, Verschieben.
Wer: der handelnde Nutzer (bzw. System bei automatischen Vorgängen wie der Import-Übernahme).
Wann: Zeitpunkt der Änderung.
Welche Operation und welcher Pfad im Tresor betroffen war.
Inhalts-Hash (vorher/nachher): ein Prüfwert des Inhalts vor und nach der Änderung. Stimmen die Hashes nicht überein, gilt der Inhalt als geändert — das ist der manipulationssichere Änderungsnachweis, ohne den Inhalt selbst zu speichern.
Schreibweg: über welchen Weg die Änderung kam (App/REST, MCP-Werkzeug oder Import).

Das Audit deckt alle Schreibwege ab — auch die Import-Übernahme, die früher ohne Nachweis in den Tresor schrieb.

Was bewusst nicht erfasst wird

Persönliche Tresore. Nur zentrale/geteilte Tresore werden auditiert; private Tresore der Nutzer bleiben außen vor.
Kein gespeicherter Inhalt. In dieser Ausbaustufe wird nur der Hash festgehalten, nicht der Text selbst.
Kein Diff und kein Rollback. Vorher/Nachher-Vergleich und Wiederherstellung sind als spätere Ausbaustufe vorgesehen, hier noch nicht enthalten.

Tresor-Historie vs. API-Zugriffsprotokoll

Beide Sichten liegen im Bereich Protokolle, beantworten aber unterschiedliche Fragen:

	Tresor-Historie	API-Zugriffsprotokoll
Fragt	Was hat sich inhaltlich geändert?	Wer hat technisch zugegriffen?
Fokus	Inhaltliche Änderungen / Governance	Technische Zugriffe inkl. abgelehnter Versuche
Typische Einträge	Operation, Pfad, Inhalts-Hash (vorher/nachher)	Methode, Pfad, Status (inkl. Ablehnung), Dauer, IP
Umfang	Nur zentrale Tresore, nur Inhaltsmutationen	Zugriffe auf Wissens-Endpunkte und MCP-Schreibwerkzeuge

Das API-Zugriffsprotokoll hieß ursprünglich „Wissens-Audit”, dann „Zugriffsprotokoll”, und trägt nach der finalen UI-Restrukturierung diesen Namen. Inhalt und Logik bleiben unverändert; neu ist die klare Trennung der Sichten unter Protokolle.

Verknüpfung über die Request-/CorrelationId

Beide Protokolle tragen für denselben Vorgang dieselbe Request-/CorrelationId. Damit lässt sich ein Eintrag der Tresor-Historie („dieser Pfad wurde geändert”) mit dem zugehörigen Zugriffseintrag („von diesem Nutzer über diesen Endpunkt, Status OK”) zusammenführen — die inhaltliche und die technische Sicht auf denselben Request.

Wo zu finden & Bedienung

Admin-Bereich Protokolle → Tresor-Historie (nur für Administratoren). Die Ansicht ist paginiert und filterbar.

Spalten: Zeitpunkt, Quelle (handelnder Nutzer bzw. System), Operation, Vault, Pfad, Inhalt (der „geändert”-Indikator: Hash vorher ≠ nachher).
Filter: Vault-Slug, Benutzer-ID, Operation (Erstellt, Aktualisiert, Gelöscht, Umbenannt, Verschoben) und „Pfad enthält”.

Admin → Protokolle → Tresor-Historie: oben die Filterleiste (Vault-Slug, Benutzer-ID, Operation, Pfad enthält), darunter die Tabelle mit den Spalten Zeitpunkt, Quelle, Operation, Vault, Pfad und Inhalt.

Datenschutz-Einordnung

Auditiert werden ausschließlich zentrale Tresore — keine persönlichen Tresore der Nutzer.
Festgehalten werden Metadaten und ein Inhalts-Hash, nicht der Inhalt selbst. Der Hash dient dem Nachweis, dass eine Änderung stattfand, nicht der Rekonstruktion des Inhalts.
Das Audit ist append-only und stützt Nachweis- und Rechenschaftspflichten gegenüber Compliance und Governance.