Prüffest protokollieren: warum eine Änderungsliste nicht genügt
Fast jede Anwendung führt eine Änderungsliste. Fast keine davon hält einer Prüfung stand, denn wer die Daten ändern kann, kann auch die Liste ändern. Der Unterschied ist kleiner, als man denkt, und er entscheidet im Streitfall.
Warum eine Änderungsliste nicht genügt
Eine Tabelle mit den Spalten „wer, wann, was“ beantwortet die Frage, solange niemand ein Interesse daran hat, sie zu verändern. Genau dann wird sie aber gebraucht. Wer Datenbankzugang hat, kann eine Zeile bearbeiten oder entfernen, und hinterher ist nicht zu sehen, dass etwas fehlt. Eine Liste, deren Lücken unsichtbar sind, ist kein Nachweis.
Die Kette: jeder Eintrag versiegelt seinen Vorgänger
Jeder Protokolleintrag enthält einen Streuwert des vorherigen Eintrags. Wer einen Eintrag nachträglich ändert oder entfernt, bricht damit die Kette ab dieser Stelle, und das ist nachrechenbar.
Streuwert heißt: eine kurze Prüfzahl, die sich aus dem Inhalt ergibt und sich bei der kleinsten Änderung vollständig ändert. Weil jeder Eintrag die Prüfzahl seines Vorgängers mit aufnimmt, hängt der letzte Eintrag rechnerisch an allen vorherigen. Ein Befehl rechnet die Kette durch und sagt, ob und ab welcher Stelle sie bricht.
Dazu kommt eine zweite Sicherung auf Ebene der Datenbank: Auf der Protokolltabelle liegt eine Sperre, die Änderungen und Löschungen von vornherein abweist. Die Kette beweist, dass nichts verändert wurde, die Sperre verhindert, dass es versucht wird.
Vier Fallen, die uns die Kette gebrochen haben
Alle vier sind echte Befunde aus laufenden Systemen. Jede einzelne hat dazu geführt, dass das Protokoll seine Aufgabe nicht mehr erfüllt hätte.
Der Verweis auf den handelnden Benutzer war so eingerichtet, dass er beim Löschen des Kontos automatisch geleert wird. Das ist für normale Daten richtig und für ein Protokoll zerstörend: Die Benutzerkennung geht in die Prüfzahl ein. Jede Löschung nach Datenschutzrecht und jedes Entfernen von Demodaten zerriss damit die Kette. Heute steht der Wert im Protokoll ohne Verweis: Die Kennung bleibt, das Konto darf verschwinden.
Die Kette brach reproduzierbar, sobald Kommazahlen im Spiel waren. Ursache war die Datenbank: In ihrem Datenformat für strukturierte Werte wird aus einer 5,0 eine 5. Die Prüfzahl war aber über den Wert gebildet worden, der hineingeschrieben wurde. Seitdem werden Kommazahlen für die Protokollierung als Text festgehalten. Die allgemeine Lehre: Was in die Prüfzahl eingeht, muss unverändert wieder herauskommen.
Die Klartexte der Einträge wurden übersetzt, und zwar in die Sprache dessen, der sie gerade ansah. Ein Nachweis, der je Leser anders aussieht, ist kein Nachweis. Das Protokoll ist heute fest in einer Sprache. Nebenbei fiel dabei auf, dass die Tests in einer anderen Sprache liefen als das Programm und deshalb grün waren, ohne etwas zu belegen.
Ein Protokoll, das bei jeder Änderung Vorher und Nachher aller Felder mitschreibt, hält damit auch Bankverbindungen im Klartext fest, und zwar unveränderlich, also für immer. Das ist das Gegenteil von Datensparsamkeit. Solche Felder werden deshalb nur gekürzt protokolliert, und die Kürzung liegt an einer einzigen Stelle im Code, damit sie nicht an einer zweiten vergessen wird. Die Änderung selbst bleibt nachweisbar, der Wert steht nicht dabei.
Was ein Protokoll nicht leistet
- Es beweist nicht, dass die Eingabe richtig war, nur dass sie seither nicht verändert wurde. Wer falsch erfasst, erzeugt einen unveränderlichen Falscheintrag. Eine Korrektur ist deshalb ein neuer Eintrag, nie eine Überschreibung.
- Der Zeitstempel kommt vom eigenen Server und ist damit nicht gegen den Betreiber selbst gerichtet. Wo das nötig ist, kommt ein Zeitstempel von einer unabhängigen Stelle dazu. In einem System zur Führerscheinkontrolle ist genau das eingebaut, weil dort im Zweifel ein Gericht liest.
- Eine ausgeblendete Schaltfläche ist keine Sperre. Das gehört nicht unmittelbar zum Protokoll und hat dieselbe Wurzel: Was nachweisbar verhindert werden soll, muss serverseitig verhindert werden, nicht in der Anzeige. Wir haben eine Auswertung gefunden, die laut Zugangsblatt für eine Rolle nicht erreichbar war und über die Adresszeile doch aufging.
Woran Sie erkennen, ob es ernst gemeint ist
Gibt es einen Befehl, der die Vollständigkeit prüft?
Wenn die Prüfung nur im Kopf des Entwicklers existiert, findet sie nicht statt.
Was passiert, wenn ein Benutzer gelöscht wird?
Das Protokoll muss vollständig bleiben. Die zugehörige Person darf verschwinden.
Steht zu jeder protokollierten Aktion ein verständlicher Satz?
Ein Protokoll aus technischen Schlüsseln liest im Prüfungsfall niemand.
Stehen Bankverbindungen oder Gesundheitsdaten im Klartext darin?
Dann ist das Protokoll selbst zum Problem geworden.
Gebaut ist das in der Fahrerverwaltung (Fallstudie), in der Führerscheinkontrolle, im Mandantenportal und in der Baustellen-App (Fallstudie). Es ist derselbe Baustein, jedes Mal mit einer anderen Prüfungsfrage davor.
Erzählen Sie, was heute weh tut.
Ein paar Sätze genügen: was gemacht wird, womit es heute gemacht wird und woran es hakt. Sie bekommen eine ehrliche Einschätzung, auch dann, wenn die Antwort lautet: dafür brauchen Sie uns nicht.