Die private, hash-verkettete Ledger-Architektur

Jeder relevante Vorgang wird in 420+ als eigenständiges Ereignis festgehalten – etwa eine ausgeführte Aufgabe, ein Messwert, eine Freigabe, Sperre, Chargenbewegung, Korrektur oder Folgeentscheidung.

Jeder neue Eintrag enthält einen kryptografischen Fingerabdruck seines Vorgängers. So entsteht eine fortlaufende, kryptografisch verknüpfte Ereigniskette, in der die einzelnen Datensätze technisch miteinander verbunden sind.

Bestehende Einträge werden nicht überschrieben. Muss eine Angabe korrigiert, ergänzt oder neu bewertet werden, entsteht ein neues Ereignis. Dieses bleibt mit seinem Ursprung verknüpft und dokumentiert, was geändert wurde, wer die Änderung vorgenommen hat und wann sie erfolgte.

Damit bleibt nachvollziehbar:

• was ursprünglich erfasst wurde,
• welche Korrektur oder Folgeentscheidung hinzukam,
• wer für den jeweiligen Schritt verantwortlich war,
• und wie sich der Zustand eines Vorgangs entwickelte.

Wird ein früherer Eintrag nachträglich verändert, ändert sich auch sein kryptografischer Fingerabdruck. Die Verkettung stimmt dann nicht mehr mit der zuvor gebildeten Ereigniskette überein. Eine solche Abweichung kann bei der Verifikation erkannt werden.

Die Architektur ist damit tamper-evident: Nachträgliche Veränderungen können nicht unbemerkt bleiben, sofern Prüfwerte, Referenzpunkte, Schlüssel und Verifikationsmechanismen ordnungsgemäß geschützt werden.

Nicht die bloße Existenz eines Audit-Trails schafft den Unterschied, sondern die Möglichkeit, die Integrität seiner Ereigniskette technisch zu überprüfen.

Der Mehrwert liegt nicht in einem pauschalen Unveränderbarkeitsversprechen, sondern in der nachvollziehbaren, kryptografisch prüfbaren Verbindung aller relevanten Ereignisse.

Anerkannte Leitlinien zur Datenintegrität stellen an Protokollfunktionen eine Anforderung, die über die bloße Existenz eines Audit-Trails hinausgeht: Die Funktion muss jederzeit aktiviert und gesperrt sein. Es darf nicht möglich sein, sie zu deaktivieren, zu löschen oder zu verändern. Ist es administrativen Nutzern dennoch möglich, muss dieser Umstand selbst einen Eintrag im Protokoll erzeugen.

Die meisten Systeme erfüllen diese Anforderung über Berechtigungseinstellungen. Die Unveränderbarkeit wird damit zu einer Zusage: Sie muss konfiguriert, gepflegt und im Prüfungsfall als Einstellung nachgewiesen werden – und sie lässt sich mit denselben Mitteln zurücknehmen, mit denen sie gesetzt wurde.

In einer fortschreibenden, kryptografisch verketteten Architektur ergibt sich dieselbe Eigenschaft aus der Bauweise. Der Nachweis ist nicht die Beschreibung einer Einstellung, sondern die Kette selbst.

Es gibt keinen Schalter, der die Protokollierung aussetzt, und keinen Weg, einen bestehenden Eintrag zu verändern, ohne die Prüfkette zu brechen.

Diese Aussage betrifft die Anforderungen an Protokolle. Sie besagt nicht, dass die übrigen Anforderungen an computergestützte Systeme – etwa an Sicherung, Archivierung, Zugriffsverwaltung oder Validierung – im konkreten Einsatz erfüllt sind. Deren Bewertung bleibt Aufgabe des Betreibers.

Leitlinien zur Datenintegrität verlangen, dass kritische Protokolleinträge vor dem Abschluss eines Vorgangs geprüft werden – etwa vor einer Freigabe – und dass diese Prüfung dokumentiert wird. In der Praxis steht sie meist in einer Verfahrensanweisung und wird von dort nicht durchgesetzt.

Das Chargenprotokoll zeigt den erreichten Zustand. Erst die Ereigniskette zeigt, was auf dem Weg dorthin geändert, korrigiert oder nachgetragen wurde. Auffälligkeiten dieser Art werden nur sichtbar, wenn jemand vor der Freigabe hineinsieht.

Die Ablaufsteuerung von 420+ kennt Pflichtschritte, die einen Abschluss blockieren, solange sie nicht dokumentiert sind. Die Protokolldurchsicht lässt sich als ein solcher Schritt vor Freigaben einrichten.

Ob das geschieht, entscheidet der Betreiber je Prozess – dort, wo das Risiko es rechtfertigt. Die Durchsicht wird dann wie jeder andere Schritt erfasst, mit prüfender Person, Zeitpunkt und Ergebnis. Wo eine Prüfung durch eine zweite Person gefordert ist, greift dasselbe Vier-Augen-Prinzip wie an anderen kritischen Stellen.

Die hash-verkettete Architektur unterstützt insbesondere:

• die Zuordnung von Ereignissen zu Personen, Rollen und Zeitpunkten,
• eine dauerhafte und konsistente Historie,
• die Verbindung von Ursprung, Korrektur und Folgeentscheidung,
• die Erkennbarkeit und technische Verifikation nachträglicher Veränderungen.

Ein Messwert bleibt dadurch nicht isoliert. Er wird Teil eines nachvollziehbaren Zusammenhangs aus Entstehung, verantwortlicher Person, Zeitpunkt, weiterer Verarbeitung und möglichen Korrekturen.

Auch eine Freigabe steht nicht losgelöst am Ende eines Prozesses. Sie bleibt mit den Aufgaben, Nachweisen, Zuständen und Entscheidungen verbunden, aus denen sie hervorgegangen ist.

Die kryptografische Verkettung ist eine zusätzliche Integritätsschicht innerhalb der Plattform. Sie macht den Audit-Trail von 420+ technisch überprüfbar und ersetzt dabei weder Validierung noch Berechtigungskonzepte oder organisatorische Kontrollen – sie ergänzt sie.

Sie garantiert nicht, dass ein ursprünglich eingegebener Wert sachlich richtig ist. Wird beispielsweise ein falscher Messwert erfasst, kann die Verkettung dessen fachliche Richtigkeit nicht beurteilen. Sie kann jedoch nachvollziehbar dokumentieren, wann und von wem der Wert erfasst wurde, wie er weiterverarbeitet wurde und ob später eine Veränderung, Korrektur oder Folgeentscheidung erfolgte.

Die Architektur schützt damit die Integrität der Historie – nicht automatisch die fachliche Qualität jedes Ausgangswerts.

Auch eine kryptografisch verkettete Ereigniskette bleibt Teil eines Gesamtsystems. Ihre Wirksamkeit setzt voraus, dass Prüfwerte, Schlüssel, Referenzpunkte und Verifikationsmechanismen angemessen geschützt werden.

Zugriffssteuerung, Rollentrennung, Vier-Augen-Prinzipien, Zeitsynchronisation, Backup, Monitoring, Audit-Trail-Reviews, Schulungen, SOPs und Validierung bleiben unverzichtbarer Bestandteil des Betriebssystems. Die Bewertung und Validierung im konkreten Einsatz liegen weiterhin in der Verantwortung des Betreibers.

Wo die Architektur eine regulatorische Anforderung unmittelbar bedient, benennen wir sie. Das betrifft die Anforderungen an die Unveränderbarkeit von Protokollen. Andere Anforderungen an computergestützte Systeme werden dadurch nicht miterfüllt.

420+ unterstützt die Anforderungen an Datenintegrität. Die Architektur begründet jedoch keine automatische GxP-, Annex-11- oder Part-11-Konformität.

Die Ledger-Architektur von 420+ benötigt keine öffentliche Blockchain, keinen Token und kein frei zugängliches Netzwerk.

Ihre betrieblichen Daten verbleiben innerhalb der vorgesehenen Infrastruktur und unter Ihrer Kontrolle. Die kryptografische Verkettung dient nicht der öffentlichen Verteilung von Informationen, sondern der nachvollziehbaren Sicherung betrieblicher Ereignisse.

Aufgaben, Messwerte, Chargenbewegungen, Freigaben, Sperren und Nachweise werden nicht erst am Ende eines Vorgangs zusammengeführt oder nachträglich mit einem Siegel versehen. Sie werden während ihrer Entstehung Teil derselben Ereigniskette.

Gerade weil diese Vorgänge innerhalb derselben Plattform entstehen, kann die kryptografische Verkettung sie ohne Medienbruch durchgängig erfassen. Ein nachträglich auf Fremdsysteme aufgesetztes Ledger kann diese Prozessnähe und Vollständigkeit nicht im Nachhinein herstellen.

Die Ereigniskette lässt sich synchron als zweiter, unabhängiger Nachweis-Strang mitführen – etwa bei einer Behörde oder einem unabhängigen Dritten. Dieser Strang entsteht in Echtzeit im Moment der Erfassung, nicht als nachträgliche Kopie. Voraussetzung ist eine unabhängige Stelle, die den Strang entgegennimmt.

Betriebsdaten müssen dafür nicht offengelegt werden. Es genügt der kryptografische Nachweis, um zu prüfen, ob die Ereigniskette seit einem festgelegten Zeitpunkt verändert wurde.

Was einmal im unabhängigen Strang eingetroffen ist, lässt sich nachträglich nicht mehr verändern – auch nicht durch den Betreiber selbst. Ob und in welcher Form ein solcher Strang im konkreten Einsatz geführt wird, hängt vom Risikoprofil, dem Validierungskonzept und der aufnehmenden Stelle ab.

Aus einer Historie, die lediglich dokumentiert wird, wird eine Ereigniskette, deren Integrität technisch überprüft werden kann.