Die Kette, die jede Lücke meldet

Die zweite Frage, die ein guter Auditor stellt

Die erste Frage, die jeder Prüfer stellt, ist einfach: „Zeigen Sie mir, was passiert ist." Die meisten Systeme können das inzwischen leidlich gut — ein Protokoll, eine Log-Datei, ein Audit-Trail, der jede Aktion mitschreibt. Wer bei dieser ersten Antwort stehen bleibt, hat aber nur die halbe Prüfung bestanden.

Die zweite Frage ist unbequemer: „Woher weiß ich, dass hier niemand nachträglich etwas gelöscht oder geändert hat?" Eine Textdatei, an die per Konvention nur angehängt wird, ist genau das — eine Konvention. Sie hält, solange sich jeder daran hält, der Schreibrechte auf diese Datei hat. Ein Systemadministrator mit einem Texteditor kann eine Zeile entfernen, und die Datei sieht danach genauso vollständig aus wie vorher. Niemand würde es merken, es sei denn, er hätte zufällig eine ältere Kopie zum Vergleich.

Für ein Werkzeug, dessen gesamtes Geschäftsmodell auf Belegbarkeit beruht, ist diese zweite Frage nicht optional. Sie ist der eigentliche Punkt.

Wie die Kette dieses Problem tatsächlich löst

JiCos Antwort ist eine Hash-Kette, und das Prinzip dahinter ist überraschend einfach zu erklären, auch wenn die Umsetzung Sorgfalt braucht: Jede Zeile im Audit-Trail und im Ausgangsbuch trägt zwei Werte — den kryptografischen Hash der unmittelbar vorherigen Zeile, und einen eigenen Hash über beides zusammen, den Vorgänger-Hash plus den eigenen Inhalt. Diese Verkettung reißt nicht an Tagesgrenzen ab; sie zieht sich über Tagesdateien hinweg durch.

Der Effekt: Wird irgendeine Zeile nachträglich geändert, gelöscht oder eine neue dazwischengeschoben, passt der Hash der nächsten Zeile nicht mehr zu ihrem vermeintlichen Vorgänger. Die Prüfung findet die exakte Stelle, an der die Kette bricht — mit Dateiname, Zeilennummer und dem konkreten Grund: geändert, weil der Inhalt nicht mehr zum gespeicherten Hash passt; gelöscht oder umsortiert, weil der Vorgänger-Hash nicht mehr stimmt; oder eine fehlende Tagesdatei, wo eine hätte sein müssen.

Das ist bewusst eine Kette und keine Signatur mit einem einzelnen Schlüssel. Der Unterschied ist wichtiger, als er zunächst klingt: Eine Signatur, deren privater Schlüssel auf derselben Maschine liegt wie die zu schützenden Daten, lässt sich von jedem neu setzen, der ohnehin schon Zugriff auf die Maschine hat — ein manipulierter Datensatz würde dann einfach neu signiert, und die Signatur würde wieder „gültig" aussehen. Die Kette macht jede Änderung innerhalb der Datei sofort sichtbar. Aber gegen ein vollständiges Neuschreiben der ganzen Historie oder ein sauberes Abschneiden am Ende hilft auch die cleverste Kette nichts, solange der Beweis komplett auf derselben Maschine liegt wie der mögliche Angreifer.

Deshalb die Prüfpunkte außerhalb der Maschine

Genau an dieser Stelle setzen die Prüfpunkte an, und sie sind der Teil des Systems, der die Kette erst wirklich beweiskräftig macht. Der aktuelle Kopf der Kette — sozusagen ihr jüngster verketteter Fingerabdruck — wird stündlich als eigenes Ereignis ins Protokoll geschrieben, mit der Möglichkeit, ihn zusätzlich an ein SIEM-System des Kunden weiterzuleiten, sofern eines im Einsatz ist.

Wer diesen Kopf zu einem bestimmten Zeitpunkt irgendwo außerhalb der Maschine festgehalten hat — im eigenen SIEM, in einer Akte, notiert bei einer routinemässigen Kontrolle — kann jederzeit später verlangen, dass genau dieser Kopf noch Teil der aktuellen Kette ist. Ist er es nicht mehr, wurde zwischenzeitlich etwas manipuliert, und zwar nachweislich nach diesem Zeitpunkt. Diese Prüfung führt der Befehl jico audit check --against audit=HASH durch. Die eigentliche Beweiskraft liegt also nicht in der Datei selbst — eine Datei allein kann man immer komplett ersetzen —, sondern darin, dass jemand außerhalb der Maschine einen Zeitpunkt dokumentiert hat, gegen den sich später unabhängig prüfen lässt.

Der Unterschied zu einem gewöhnlichen Log-Ordner

Die meisten Systeme, die von sich behaupten, ein „Audit-Log" zu führen, meinen damit tatsächlich nicht viel mehr als eine Sammlung von Textdateien mit Zeitstempeln, die irgendwo auf einem Server liegen. Das ist besser als gar keine Aufzeichnung, aber es beantwortet nur die erste der beiden Fragen von oben — was ist passiert —, nicht die zweite: ob sich jemand nachträglich daran zu schaffen gemacht hat.

Der Unterschied zur Hash-Kette ist an dieser Stelle keine Frage der Häufigkeit, mit der protokolliert wird, sondern eine Frage der Beweislast. Ein gewöhnliches Log kann im Zweifel nur behaupten, vollständig zu sein — jemand mit ausreichenden Rechten müsste einem einfach glauben. Eine verkettete, extern verankerte Protokollierung kann diese Vollständigkeit tatsächlich beweisen, unabhängig davon, wer gerade Administratorrechte auf dem betroffenen System hat. Für eine interne Revision oder eine Anfrage einer Datenschutzbehörde ist genau dieser Unterschied entscheidend — nicht ob protokolliert wird, sondern ob sich das Protokoll selbst als unverändert nachweisen lässt.

Was diese Kette absichert — und was bewusst draußen bleibt

Hier lohnt ein zweiter Blick, weil er zeigt, dass Belegbarkeit und Datensparsamkeit bei JiCo keine zwei Ziele sind, die man gegeneinander abwägen muss, sondern in derselben Datei zusammenfallen: Die Kette enthält keinen Klartext. Was sie absichert, ist die Redaktionsbilanz — wie viele Treffer welchen Typs die Schleuse in einem bestimmten Vorgang abgefangen hat —, nicht die abgefangenen Werte selbst.

Ein Auditor, der die Kette prüft, erhält damit exakt den Nachweis, den er braucht: dass der Prozess lückenlos war, dass zwischen Vorschlag, Entscheid und Ausführung nichts nachträglich verändert wurde. Er erhält nicht die Personendaten, um die es in diesem Prozess ursprünglich ging — für die bräuchte er weiterhin einen eigenen, separat begründeten Zugriff auf Jira oder auf ein noch laufendes, befristetes Mapping. Das ist kein Kompromiss zwischen zwei konkurrierenden Anforderungen. Es ist die Erkenntnis, dass eine Prüfung des Prozesses und eine Kenntnis der Inhalte zwei verschiedene Dinge sind — und dass man für die erste die zweite gar nicht braucht.