Manipulationssicherer Audit-Log
Ein Protokoll, das nicht leise überschrieben werden kann.
Ein Log, das Sie bearbeiten können, ist kein Beweis – es ist ein Vorschlag. Clavitors Audit-Trail ist eine kryptografische Kette: Jedes Ereignis wird in das vorherige gehasht, die Position der Kette wird auf separater Infrastruktur bestätigt und ein einziger Durchlauf prüft das Ganze erneut, um zu beweisen, dass nichts geändert, gelöscht oder neu geordnet wurde. Nicht „wir versprechen, dass wir es nicht angefasst haben". Überprüfen Sie es selbst.
Jede Aktion ist protokolliert.
Ein Anmeldedaten-Tresor ist nur so vertrauenswürdig wie das Protokoll darüber, wer ihn verwendet hat. Clavitor protokolliert jeden Anmeldedaten-Lesezugriff, jedes Ausfüllen, jede TOTP-Anfrage, jeden Login, jede administrative Änderung – und jede Ablehnung. Jedes Ereignis enthält, wer, was, wann, von wo und wie es endete.
Wer und welche Art
Jedes Ereignis wird einem bestimmten Akteur zugeordnet und mit dem Akteurtyp gekennzeichnet – Mensch, Browser-Erweiterung oder KI-Agent. Die Aktivität von Agenten hebt sich von der menschlichen Aktivität auf derselben Zeile ab, sodass eine Harvesting-Fähigkeit nicht im Rauschen des normalen Gebrauchs verborgen bleiben kann.
Der vollständige Lebenszyklus
Erstellen, Lesen, Aktualisieren, Löschen – und jede Verwendung. Autofill und Proxy-Injection werden genauso protokolliert wie ein manuelles Lesen. Nichts greift lautlos auf Anmeldedaten zu; es gibt keinen Weg zu einem Geheimnis, der keine Zeile hinterlässt.
Ergebnisse, nicht nur Erfolge
Jedes Ereignis protokolliert, wie es endete – Erfolg, Fehler oder Ablehnung – mit einem Grundcode. Ein blockierter Agent, ein ratenbegrenzter Burst, eine abgelehnte IP, ein fehlgeschlagener Login: alles protokolliert. Auditoren kümmern sich mehr darum, was gestoppt wurde, als was erfolgreich war.
Die Kette
In die Historie gehasht.
Jede Audit-Zeile ist durch einen Hash an die vorherige gebunden. Ändern Sie eine frühere Zeile – bearbeiten Sie ein Feld, löschen Sie ein Ereignis, ordnen Sie zwei Zeilen neu an – und jeder Hash danach stimmt nicht mehr überein. Die Manipulation ist nicht verborgen; sie ist strukturell und laut.
# every row carries the hash of the row before it row_hash = SHA256( prev_hash | event_id | created_at | data ) # any edit, delete, or reorder breaks the recomputation # rows are append-only — never UPDATEd, never DELETEd
Dies ist dasselbe Append-Only-Prinzip, auf dem der gesamte Tresor aufgebaut ist – der Audit-Log erhält keine schwächere Version davon. Warum nichts jemals überschrieben wird →
Extern bestätigt
Eine lokale Neufassung reicht nicht aus.
Eine Kette allein schützt vor Bearbeitungen innerhalb des Logs. Aber der Betreiber, der die Festplatte besitzt, könnte theoretisch die gesamte Kette von einem gefälschten Ausgangspunkt neu berechnen. Daher lebt die Kette nicht nur auf der Box, die sie schreibt.
Der Kopf jeder Tresorkette ist an separate Infrastruktur verankert – ein Einweg-Zeuge, der aufzeichnet, wo die Kette zu jedem Zeitpunkt war. Um die Historie überzeugend neu zu schreiben, müssten Sie das Log und den Zeugen im Gleichschritt besiegen, ohne jemals uneins zu sein.
Ein zweites System merkt sich die Position
Die POP, die das Log schreibt, pusht ihren Kettenkopf – Sequenz und Hash – als Best-Effort-Zeugen an die Zentrale. Die Zentrale ist nie im Schreibpfad, sodass sie den Tresor niemals verlangsamen kann; sie merkt sich nur, wie die Kette zuletzt aussah.
Wenn das lokale Log jemals kürzer als die aufgezeichnete Position wird, ist das ein Rücklauf. Wenn eine aufgezeichnete Position mit einem anderen Hash zurückkommt, ist das eine Gabelung. Beides ist ein Abschneiden oder ein Umschreibversuch – und beides löst einen Operator-Alarm aus, sobald es erkannt wird.
Bei Bedarf verifizieren
Ein Durchlauf. Intakt oder defekt.
Sie müssen uns kein Wort davon glauben. Der Tresor durchläuft die Kette von der ersten Zeile an, berechnet jeden Hash neu und teilt Ihnen das Ergebnis mit – ein Verifizierungsabzeichen, das „intakt" oder, wenn sich ein einzelnes Byte bewegt hat, „defekt" anzeigt. Es gibt kein Gelb, kein „wahrscheinlich in Ordnung". Eine Sicherheitsprüfung, die fehlschlägt, muss lautstark fehlschlagen; diese tut es.
Verschlüsselt und dennoch abfragbar
Das Protokoll beweist, wer gehandelt hat – ohne preiszugeben, was er berührt hat.
Der Audit-Log ist at rest mit demselben feldweisen Schema verschlüsselt wie die von ihm verfolgten Anmeldedaten. Nur die strukturellen Spalten – Ereignis-ID, Eintrag-ID, Zeitstempel – bleiben im Klartext, da das alles ist, was eine Abfrage benötigt. Eine gestohlene Festplatte liefert undurchsichtige Token, keine Karte Ihrer IPs, Akteure und Zugriffsmuster.
Pivots funktionieren immer noch, ohne diese preiszugeben. Jede Zeile enthält schlüsselbasierte Hash-Bucket-Token, sodass „alles, was diese IP getan hat“ oder „jeder abgelehnte Lesezugriff“ als indizierte Suche ausgeführt wird und nur die übereinstimmenden Zeilen entschlüsselt – niemals der gesamte Korpus, niemals ein Klartext-Index, den ein Festplattendieb lesen könnte. Sie erhalten die Abfrage. Der Angreifer erhält Rauschen.
Der Bericht
Compliance-Nachweise, auf Abruf.
Der Audit-Log ist eine erstklassige Seite im Tresor – kein Export, den Sie nachträglich rekonstruieren. Filtern Sie nach Akteur, Eintrag, IP oder Datumsbereich. Klicken Sie auf eine beliebige Zelle, um zu pivotieren. Sortieren Sie nach einer beliebigen Spalte. Gruppieren Sie nach Tag, Aktion, Ergebnis oder Akteur. Facetten-Chips zeigen Live-Zählungen, während Sie eingrenzen. Exportieren Sie das Ergebnis als CSV für Ihr SIEM oder Ihren Auditor.
CMMC LEVEL 2
Audit- und Rechenschaftsnachweise
NIST SP 800-171 Kontrollen 3.3.1 (Aufzeichnen des Notwendigen), 3.3.2 (Verknüpfung mit Identität) und 3.3.8 (Schutz der Log-Integrität) verlangen pro Ereignis Identität, IP und Zeitstempel, geschützt und manipulationssicher gespeichert. Clavitor zeichnet alle drei auf, verschlüsselt das Log und verkettet es.
SOC 2 · ISO 27001
Überwachungsnachweise, abfragbar
Trust Services Kriterium CC7.2 und ISO/IEC 27001 A.8.15 verlangen Protokolle von Authentifizierungs- und privilegierten Aktionen. Jeder Zugriff auf Anmeldedaten ist ein solches Ereignis – Akteur-getypt, Ergebnis-gestempelt, verschlüsselt, filterbar und exportierbar.
HIPAA · DSGVO
Rechenschaftspflicht, per Design
HIPAA §164.312(b) Audit-Kontrollen und DSGVO Artikel 32 Rechenschaftspflichten werden durch dasselbe Log beantwortet. Kein separates Compliance-Modul, keine Zusatzgebühr – der Audit-Trail ist Teil des Produkts. Enterprise-Pläne fügen den Export über Tresore hinweg zu Ihrem SIEM hinzu.
Richtlinien werden zu Beweismitteln.
Ohne ein vertrauenswürdiges Protokoll ist jede Behauptung über Zugriffskontrolle nur eine Richtlinie – „wir schauen nicht hin", „Agenten sind bereichsbeschränkt", „nichts leckt". Mit einem verketteten, bestätigten, verifizierbaren Log werden diese Behauptungen zu Dingen, die Sie prüfen können. Das ist der Unterschied zwischen der Bitte, uns zu vertrauen, und der Möglichkeit, es selbst zu überprüfen.
Sehen Sie die andere Hälfte des Protokolls.
Der Audit-Trail beweist, wer gehandelt hat. Unveränderlichkeit beweist, dass die Daten, auf die er zugegriffen hat, nie leise darunter geändert wurden.