Aktionsprotokoll prüfen, ohne dem Verfasser zu vertrauen
Ein Audit-Log ist nur dann ein Beleg, wenn jemand anderes als sein Autor es nachrechnen kann. Füge einen Export ein, und dein Browser berechnet jeden Hash neu, folgt der Kette und prüft die Signatur des Siegels per WebCrypto. Es ist derselbe Apache-2.0-Verifizierer, den das Produkt ausliefert.
JSON aus einem Audit-Export einfügen oder die Datei ablegen. Die Prüfung läuft lokal; im Netzwerk-Panel deines Browsers erscheint keine Anfrage.
Dieses Tool läuft im Browser und braucht JavaScript.
Beobachtungen, keine Urteile. Deine Eingabe wird für dieses Ergebnis verarbeitet und in ein Nutzungsjournal geschrieben, das die Datenschutzerklärung beschreibt; sonst wird nichts gespeichert.
Hinweis · Zwei Prüfungen, weil jede für etwas blind ist
Die Kette entdeckt einen veränderten oder entfernten Eintrag, aber kein abgeschnittenes Ende: Schneide das Log nach Eintrag 400 ab, und die Kette bis 400 ist makellos. Das Siegel entdeckt das abgeschnittene Ende, aber keinen Eintrag, der bearbeitet und neu gehasht wurde. verifyLog macht beides; verifyChain und verifySeal sind für Werkzeuge exportiert und keins davon ist allein eine Prüfung.
Einen Export prüfen
-
Export holen
GET /v1/audit/export mit deinem API-Schlüssel oder bb.audit.export() im SDK. Das Bündel enthält die Einträge, die Siegel, die sie abdecken, und einen Abschnitt howToVerify, der die Algorithmen nennt.
-
Hier einfügen
Der Verifizierer parst das Bündel, kodiert jeden Eintrag kanonisch neu und berechnet seinen SHA-256. Ein Hash, der nicht zum gespeicherten passt, oder ein prev, das nicht auf den Vorgänger zeigt, ist ein Kettenproblem mit Index und Grund.
-
Siegel-Urteil lesen
Je Siegel der abgedeckte Bereich, der Algorithmus und ob die Signatur über den Kopf-Hash gegen den öffentlichen Schlüssel im Export aufgeht. Ein unversiegeltes Ende wird als unversiegelt gemeldet, nicht als kaputt.
-
Schlüssel festnageln
Eine Signatur, die gegen einen Schlüssel aus derselben Datei aufgeht, beweist, dass die Datei in sich stimmig ist. Vergleiche publicKey mit dem Schlüssel, den du früher über /v1/audit/seals geholt hast, um zu zeigen, dass es der erwartete ist.
Was geprüft wird, Byte für Byte
Jeder Eintrag im Aktionsprotokoll von Browserberg trägt den Hash seines Vorgängers und seinen eigenen, SHA-256 über eine kanonische Kodierung seiner Felder. Diese Kodierung ist von Hand geschrieben und längenpräfixiert: Jedes Feld wird als seine Bytelänge gefolgt von seinen Bytes geschrieben, in fester Reihenfolge. Das klingt pedantisch, bis man die Alternative bedenkt. JSON.stringify ordnet Schlüssel nach Einfügereihenfolge und escaped Zeichen je nach Sprache anders; ein Verifizierer in Python oder Go wäre sich mit unserem über die Bytes uneins und würde jeden Eintrag als manipuliert melden. Eine längenpräfixierte Kodierung lässt sich aus einer Seite Beschreibung nachbauen und liefert überall dieselben Bytes.
Das Siegel
Ein Siegel deckt einen Bereich von Einträgen ab, from bis to, und signiert den Kopf-Hash dieses Bereichs zusammen mit dem Hash, bei dem der Bereich begann. Es gibt zwei Algorithmen. ed25519 ist ein lokaler Schlüssel, das Opt-in für einen Kunden, der den ganzen Stack selbst betreibt und sich damit selbst gegenüber attestiert. ecdsa-p256-sha256 ist der Algorithmus des gehosteten Dienstes: Der private Schlüssel liegt im OVHcloud KMS und berührt den Host, der das Log schreibt, nie. Die Signatur ist als rohes r||s-Paar gespeichert, zufällig genau die Form, die WebCrypto nativ prüft, also keine DER-Umwandlung. Jedes Siegel nennt seinen Algorithmus, und der Verifizierer verzweigt danach; einen unbekannten lehnt er ab, statt ihn zu überspringen.
Warum das im Browser läuft
Ein Verifizierer, den die Partei hostet, die das Log geschrieben hat, ist wenig wert. Dieser hier ist der Code des Audit-Pakets selbst, Apache-2.0, für den Browser gebündelt, mit WebCrypto für SHA-256 und die Signaturprüfung. Du kannst ihn lesen, offline laufen lassen oder portieren. Die API bietet zusätzlich POST /v1/audit/verify als Hilfe für den Support, und der Abschnitt howToVerify im Export sagt offen, dass die Prüfung zählt, die du selbst gemacht hast.
Was die Prüfung nicht sagt
Ein Log, das aufgeht, ist ein Log, das sich seit der Versiegelung nicht verändert hat. Es ist kein Log, das wahr ist. Die Einträge halten fest, was die Plattform im Auftrag eines Kunden getan hat: das observe, den Klick, die Extraktion, mit Hashes über Ein- und Ausgaben. Ob die Seite, die der Agent sah, die war, die der Kunde meint, ist eine Frage an den Lauf, nicht ans Log. Der Verifizierer kann auch nicht sagen, dass der Schlüssel unserer ist: Wer fälscht, kann mit einem frischen Schlüsselpaar ein in sich stimmiges Bündel erzeugen. Das Festnageln des Schlüssels gegen ein Siegel, das du zu anderer Zeit über einen anderen Kanal geholt hast, schließt diese Lücke, und das Tool sagt das, statt einen grünen Haken zu zeigen, der mehr verspricht.
Einträge nach dem letzten Siegel werden nur auf die Kette geprüft. Bei einem lebenden Log ist das normal, und das Urteil lautet unversiegelt, nicht ungültig. Brauchst du einen Bereich geschlossen, versiegelt POST /v1/audit/seal ihn jetzt.
Fragen zur Integrität von Audit-Logs
Was ist ein hash-verkettetes Audit-Log?
Ein Protokoll, in dem jeder Eintrag den Hash des vorherigen enthält, sodass eine Änderung oder Entfernung jeden Hash danach bricht. Das ist die Struktur hinter manipulationssicheren Logs und, in anderem Zusammenhang, Blockchains.
Warum reicht eine Hash-Kette allein nicht?
Weil die Kette nicht weiß, wo das Log endet. Lösche die letzten hundert Einträge, und der Rest ist eine tadellose Kette. Ein signiertes Siegel über einen Bereich fixiert das Ende, deshalb wird beides geprüft.
Schickt das Tool mein Log irgendwohin?
Nein. Parsen, Hashen und Signaturprüfung laufen in deinem Browser mit WebCrypto. Du kannst es im Netzwerk-Panel nachsehen oder die Seite laden und die Verbindung trennen.
Wie sieht eine gescheiterte Kettenprüfung aus?
Eine Liste von Problemen, jedes mit Index des Eintrags und Grund: Hash passt nicht, prev passt nicht, Eintrag fehlerhaft. Das erste Problem ist meist das entscheidende; alles danach scheitert als Folge.
Kann ich das Log in eigenem Code prüfen?
Ja. Der Verifizierer ist Apache-2.0, hängt von nichts anderem im Produkt ab, und die kanonische Kodierung ist so dokumentiert, dass sie in einer anderen Sprache dieselben Bytes ergibt.
Export holen und versiegeln
# Export mit Einträgen, Siegeln und howToVerify
curl https://browserberg.com/v1/audit/export \
-H "Authorization: Bearer $BROWSERBERG_API_KEY" > audit-export.json
# Den offenen Bereich jetzt versiegeln
curl -X POST https://browserberg.com/v1/audit/seal \
-H "Authorization: Bearer $BROWSERBERG_API_KEY"
import { Browserberg } from '@browserberg/sdk';
const bb = new Browserberg({ apiKey: process.env.BROWSERBERG_API_KEY });
const seals = await bb.audit.seals();
for (const s of seals) console.log(s.from, s.to, s.algorithm, s.publicKey);
const bundle = await bb.audit.export();
// Das Bündel hier einfügen, oder mit dem Apache-2.0-Verifizierer lokal prüfen.
Ein Log erzeugen, das sich zu prüfen lohnt
Fünf Browserstunden, keine Karte. Aufgabe laufen lassen, Log exportieren, hier einfügen.