Skip to content

Einen hash-verketteten Änderungs-Ledger lesen und selbst nachprüfen

Ein verkettetes Protokoll ist so viel wert, wie eine zweite Person allein prüfen kann. Was eine Zeile enthält, was die Kette von sich aus beweist, und was sie anderen Kontrollen überlässt. Dann, wie ein Prüfer einen Export mit eigenen Werkzeugen nachprüft.

Aktualisiert · 7 Min. Lesezeit

Was eine Zeile enthält

Ein Änderungs-Ledger verdient seinen Namen, indem er für jemanden lesbar ist, der nicht im Raum war. Jede governte Änderung schreibt eine Zeile. Die Zeile ist absichtlich langweilig.

Wann, und wer
Ein Zeitstempel. Die E-Mail-Adresse der Person, die gehandelt hat. Die Rolle, die sie in diesem Moment hatte. Die Rolle wird zu dem Zeitpunkt aufgeschrieben, nicht später nachgeschlagen. Rollen ändern sich, und dieses Protokoll handelt von dem Tag, an dem es passiert ist.
Wo, und was
Die Oberfläche, auf der die Änderung gemacht wurde. Die ausgeführte Aktion. Das Ziel, auf das sie gewirkt hat. Die semantische Schicht, das Relay, Anbieterschlüssel, Skriptläufe und die Admin-Konsole schreiben alle hierher.
Der Zustand, als Hashes
Ein Inhalts-Hash des Zustands davor und einer des Zustands danach. Die Werte selbst bleiben aus dem Ledger heraus. Ein Protokoll einer Änderung von Zugangsdaten kann existieren, ohne dass die Zugangsdaten auch nur in der Nähe sind.
Die Verbindung
Der Hash des vorherigen Eintrags und der eigene Hash dieses Eintrags. Diese zwei Felder sind die Kette.
Details
Ein kleines Wörterbuch mit Kontext. Es läuft durch denselben Filter wie der Operator-Audit-Trail. Geheimnisförmige Schlüssel werden entfernt, bevor irgendetwas die Datei erreicht.

Er steht neben dem Operator-Audit-Trail und ersetzt ihn nicht. Zwei Protokolle, zwei Leser. Der Audit-Trail ist die Konsolenhistorie, die ein Administrator während der Woche überfliegt. Der Ledger ist das, was jemand ein Jahr später liest, ohne Erinnerung an irgendetwas davon.

Was die Kette beweist

Jeder Eintrags-Hash ist ein SHA-256 über zwei zusammengefügte Dinge. Erstens die kanonische Form des Eintrags mit entferntem eigenem Hash. Zweitens der Hash des vorherigen Eintrags. Kanonisch bedeutet: die Schlüssel in eine feste Reihenfolge sortiert, ohne überflüssigen Leerraum. Derselbe Eintrag serialisiert dann immer zu denselben Bytes. Der erste Eintrag verweist auf vierundsechzig Nullen.

Was diese Konstruktion bringt, lohnt sich genau zu sagen. Ändern Sie ein Zeichen eines festgehaltenen Feldes, löschen Sie eine Zeile oder vertauschen Sie zwei Zeilen. Jede Verbindung von diesem Punkt an passt nicht mehr. Die Prüfung geht die ganze Datei durch. Sie meldet den Index der ersten schlechten Zeile und den Grund. Dieser Grund ist einer von dreien: eine fehlerhafte Zeile, eine gebrochene Verbindung oder ein Hash, der nicht zu seinem eigenen Inhalt passt.

Die erste schlechte Zeile zu nennen ist der grösste Teil des Werts. Irgendwo in fünfzigtausend Zeilen stimmt etwas nicht, das ist ein Alarm. Zeile 8.214, Hash-Abweichung, das ist ein Ausgangspunkt. Es grenzt die Frage auch ein, denn alles davor hat die Prüfung bestanden.

Die Funktion ist reines SHA-256 ohne geheimen Schlüssel. Das ist ein bewusster Tausch. Eine Konstruktion mit Schlüssel würde beweisen, dass das Protokoll von uns stammt. Eine ohne Schlüssel lässt jeden, der den Export hält, ihn mit dreissig Zeilen eigenem Skript prüfen. Für einen Prüfer ist das mit Abstand die nützlichere Eigenschaft.

Fragen für andere Kontrollen

Eine Kette beantwortet eine Frage gut und mehrere andere gar nicht. Zu wissen, welche welche ist, zählt. Es bewahrt eine Kontrolle davor, für Arbeit vertraut zu werden, die sie nie getan hat.

  • Ob eine Änderung überhaupt festgehalten wurde. Eine Kette sagt nichts über einen Eintrag, der nie geschrieben wurde. Schreibvorgänge sind serialisiert und nur anhängend. Ein Schreibvorgang, der scheitert, protokolliert laut und gibt nichts zurück, ohne die Aktion des Administrators zu unterbrechen. Das ist der richtige Tausch für eine laufende Konsole. Es bedeutet aber, dass Vollständigkeit am Schreibpfad hängt, nicht an der Kette. Fragen Sie, was passiert, wenn ein Schreibvorgang scheitert, und wie Sie es erfahren würden.
  • Was die Änderung tatsächlich war. Vorher und nachher sind Inhalts-Hashes. Der Ledger bestätigt, dass sich der Zustand geändert hat und dass er zu einem Zustand passt, den Sie bereits halten. Einen alten Wert aus einem Hash zurückzulesen übersteigt das, was ein Hash kann. Genau deshalb können Geheimnisse ganz aus dem Ledger herausgehalten werden.
  • Ob die ganze Datei neu geschrieben wurde. Eine Kette ohne Schlüssel erkennt eine teilweise Bearbeitung. Wer jede Zeile neu schreiben kann, könnte jede Verbindung neu berechnen. Was das beantwortet, sind der nur anhängende Schreibpfad und die Dateiberechtigungen. Vor allem aber sind es die Kopien, die bereits jemand anderes hält.
  • Ob die Kette neu gestartet ist. Wenn das Ende beim Start nicht gelesen werden kann, geht das Anhängen von der Genesis-Verbindung aus weiter. Die Prüfung markiert die Nahtstelle und glättet sie nie. Eine gebrochene Verbindung an einer Neustartgrenze hat meist eine langweilige Erklärung. Sie verdient die Frage trotzdem.

Ein Anbieter, der alle vier bereitwillig beantwortet, ist nützlicher als einer, der sagt, die Kette decke sie ab.

Einen Export selbst nachprüfen

Der Export kommt als JSON oder CSV, aus der Ledger-Konsole genommen. Er trägt die Filter, die angewendet wurden. Nehmen Sie für die Prüfung das JSON. Die CSV flacht die Detailspalte ab, damit ein Mensch sie lesen kann, und der Hash wurde über eine andere Form berechnet.

  1. Beginnen Sie mit einem vorherigen Hash aus vierundsechzig Nullen.
  2. Kopieren Sie für jede Zeile der Reihe nach das Objekt und entfernen Sie sein Eintrags-Hash-Feld.
  3. Serialisieren Sie den Rest als JSON. Sortieren Sie die Schlüssel, lassen Sie keine Leerzeichen zwischen den Tokens und maskieren Sie Nicht-ASCII-Zeichen.
  4. Hängen Sie den vorherigen Hash an diesen Text an. Kodieren Sie das Ergebnis als UTF-8. Nehmen Sie den SHA-256-Digest in hexadezimaler Kleinschreibung.
  5. Vergleichen Sie ihn mit dem festgehaltenen Eintrags-Hash. Vergleichen Sie den festgehaltenen vorherigen Hash der Zeile mit dem, den Sie mitgebracht haben. Dann tragen Sie den eigenen Hash dieser Zeile weiter.
  6. Halten Sie bei der ersten Zeile an, bei der einer der Vergleiche scheitert. Halten Sie ihren Index fest, und welcher Vergleich gescheitert ist.

Eine Neuberechnung, die in jeder Zeile abweicht, zeigt meist auf den Serialisierer, nicht auf den Ledger. Das gilt auch für die allererste Zeile. Schlüsselreihenfolge, Leerraum und Unicode-Maskierung ändern jeweils die gehashten Bytes. Eines davon falsch zu machen liefert eine einheitliche, selbstsichere und völlig falsche Antwort.

Behalten Sie das Skript. Eine Prüfung, die Sie bei Bedarf erneut ausführen können, ist eine Kontrolle. Eine Prüfung, die jemand einmal in einem Meeting durchgeführt hat, ist eine Anekdote.

Warum der Export weiter reist

Die Konsole zeigt ein Prüfabzeichen, das bei jedem Seitenaufruf über die ganze Datei berechnet wird. Ein Bruch taucht auf, sobald jemand hinsieht. Es ist auch, unvermeidlich, der Schreiber, der über sich selbst berichtet.

Der Bildschirm ist auch im gewöhnlichen Sinn eine Ansicht. Er ist nach Oberfläche, nach Akteur und nach Datumsbereich gefiltert. Er ist neueste zuerst sortiert und auf eine handliche Zeilenzahl gedeckelt. Der Export wendet dieselben Filter mit einer weit grösseren Obergrenze an. Bevor Sie aus einer Zahl einen Schluss ziehen, wissen Sie, welche der beiden Sie lesen.

Ein Export kann das Gebäude verlassen, ein Bildschirm nicht. Ein heute genommener Export, den Ihr Prüfer hält, fixiert die Kette auf heute. Jede spätere Abweichung zwischen seiner Kopie und Ihrer zeigt sich in einem schlichten Vergleich. Er verlangt Vertrauen in keine der beiden Parteien. Das ist die Eigenschaft, um die man die ganze Routine bauen sollte.

Ein Export gewinnt mit Alter und Entfernung an Wert. Eine Kopie, in Ihren eigenen Händen, auf derselben Maschine, ist ein Backup. Eine Reihe von Kopien ist ein Beleg. Nehmen Sie sie nach Zeitplan und bewahren Sie sie dort auf, wo das Produkt keinen Schreibzugriff hat.

Eine Routine, die Sie wiederholen können

  1. Exportieren Sie am Ende jeder Periode den vollen Bereich als JSON. Wenden Sie keine Filter an.
  2. Prüfen Sie ihn mit Ihrem eigenen Skript, und bewahren Sie Export und Skript zusammen auf.
  3. Vergleichen Sie den neuen Export mit dem vorherigen. Jede Zeile, die beide teilen, sollte identisch sein, Zeichen für Zeichen. Das ist die Prüfung, die ein Neuschreiben erwischt, das die Kette allein offenlässt.
  4. Prüfen Sie stichprobenartig eine Handvoll Zeilen gegen Änderungen, an die sich jemand erinnert. Prüfen Sie den Akteur und die daneben festgehaltene Rolle.
  5. Bewahren Sie jeden Export dort auf, wo das Produkt keinen Schreibzugriff hat.
  6. Halten Sie fest, wer ihn genommen hat und wann, neben der Datei, nicht in einem separaten System.

Der dritte Schritt macht aus einer in sich stimmigen Datei eine geprüfte. Er kostet einen Vergleichsbefehl. Alles andere auf dieser Seite ist Vorbereitung darauf, ihn auszuführen.