Externe Datenverifikation: Wie Prozessdaten unabhängig geprüft werden

Ein externer Prüfer braucht einen klaren Prüfauftrag

Der Prüfauftrag muss benennen, welche Aufzeichnungen und welche Aussage außerhalb des Ursprungssystems geprüft werden sollen. Davon hängen Datenumfang, Verfahren und akzeptierter Bezugspunkt ab.

Vor dem Empfang die erwartete Aussage festlegen

Für den Prüfauftrag werden Objekt, Zeitraum und erforderliche Aufzeichnungen festgelegt. Dazu kommt die technische Aussage: Soll die unveränderte Datei geprüft werden, die Zugehörigkeit ausgewählter Einträge zu einer früheren Wurzel oder die Konsistenz zweier Protokollstände? Diese Nachweise sind nicht austauschbar.

Der Empfänger benötigt außerdem einen akzeptierten Weg zum Referenzwert und den erforderlichen Vertrauensinformationen. Erst danach lässt sich beurteilen, ob das angebotene Paket den Auftrag überhaupt trägt. Ein bloßer Hinweis auf verwendete Kryptografie beschreibt noch kein prüfbares Verfahren.

Beispiel: Eine Chargenhistorie für eine externe Prüfung

In einem fiktiven Szenario stellt ein Betrieb für eine Produktionscharge die ausgeführten Arbeitsschritte, verwendeten Materialien, Messwerte, Prüfungen, Freigaben und Korrekturen bereit. Das Exportformat legt Reihenfolge, Feldtypen, Zeitzone und Anlagenstruktur eindeutig fest.

Automatisierte Compliance-Nachweise entstehen aus den bei der Prozessausführung zusammengeführten Informationen. Eine externe Verifikation ergänzt deren technische Prüfbarkeit; sie stellt weder fehlende Prozessbezüge her noch vervollständigt sie eine fachlich unzureichende Aussage.

Ein Electronic Batch Record kann dabei die fachliche Ausgangsaufzeichnung der Charge bilden; die externe Verifikation prüft anschließend eine andere Ebene – die Übereinstimmung mit einem unabhängigen Bezugspunkt.

Die maßgeblichen Aufzeichnungen wurden in diesem Szenario bereits am Ende des Prüfzeitraums in einer festgelegten Darstellung kryptografisch gebunden. Die zugehörige Baumwurzel wurde getrennt signiert und mit einem vertrauenswürdigen Zeitstempel gesichert. Für den späteren Export erhält der Prüfer ausgewählte unveränderte Aufzeichnungen und ihre Inklusionsnachweise zur damaligen Wurzel. Ein Exportverzeichnis beschreibt die Auswahl. Die Nachweise belegen die Zugehörigkeit zum gebundenen Bestand, nicht dessen fachliche Vollständigkeit.

Der externe Prüfer kann nun schrittweise kontrollieren:

1. Ist das Paket vollständig und entspricht es dem angekündigten Umfang?
2. Liegen die vereinbarten unveränderten Dateibytes vor beziehungsweise lässt sich die festgelegte kanonische Darstellung reproduzieren?
3. Führen die neu berechneten Blatt-Hashes mit den mitgelieferten Nachweispfaden zur früher gesicherten Baumwurzel?
4. Ist die Signatur mathematisch gültig und der Schlüssel dem Aussteller zugeordnet?
5. Passt der Zeitstempel zum Prüfwert und war das Zertifikat zu diesem Zeitpunkt prüfbar?
6. Sind alle fachlich erforderlichen Ereignisse, Begründungen und Freigaben enthalten?

Die ersten fünf Schritte betreffen überwiegend die technische Verifikation. Der sechste Schritt ist eine fachliche Bewertung. Erst ihre Verbindung erzeugt einen brauchbaren Nachweis für den konkreten Prüfzweck.

Welche Bestandteile ein verifizierbares Datenpaket benötigt

Eine belastbare Prüfung beginnt nicht mit dem Hashwert, sondern mit einer eindeutig definierten Datenmenge. Der Empfänger muss erkennen können, welche Aufzeichnungen einbezogen sind, aus welchem Zeitraum sie stammen, welche Version des Exportformats gilt und ob Anlagen oder referenzierte Objekte dazugehören.

Ein Verifikationspaket kann insbesondere enthalten:

• die exportierten Prozess- und Metadaten,
• eine eindeutige Paket- oder Nachweiskennung,
• den fachlichen und zeitlichen Umfang des Exports,
• Formatversion und Festlegung auf unveränderte Dateibytes oder eine definierte kanonische Darstellung,
• Bezeichnung und Parameter des Hashverfahrens,
• Hashwerte einzelner Dateien oder eine gemeinsame Prüfwurzel,
• Signatur, Zertifikatsinformationen oder Zeitstempelnachweis,
• gegebenenfalls einen Inklusions- oder Konsistenznachweis,
• eine verständliche Prüfanleitung und das erwartete Ergebnis.

Die Aussage hängt vom gewählten Vertrauensmodell ab

Jedes Verifikationsverfahren benötigt mindestens einen Ausgangspunkt, dem der Prüfer vertraut. Das kann ein öffentlicher Schlüssel, ein Zertifikat, eine Zeitstempelstelle, ein signierter Prüfpunkt oder ein organisatorisch getrennt verwahrter Referenzwert sein.

Die Konstruktion sollte offenlegen, wer diesen Bezugspunkt erzeugt, wer Schlüssel verwaltet, wie Sperrungen und Wechsel behandelt werden und wie der Prüfer gültige Informationen erhält. Ein „unabhängiger“ Dienst ist nur dann tatsächlich unabhängiger, wenn Betrieb, Berechtigungen und Beweismittel nicht vollständig unter derselben unkontrollierten Änderungsmöglichkeit stehen.

Auch Verfügbarkeit gehört zum Modell. Ein Nachweis, der nur über einen später abgeschalteten Dienst geprüft werden kann, verliert praktischen Wert. Exportformat, Algorithmen, Zertifikatsinformationen und erforderliche Prüfdaten sollten deshalb so dokumentiert werden, dass eine vorgesehene Offline- oder Langzeitprüfung möglich bleibt.

Vor dem Hashwert steht eine reproduzierbare Darstellung

Gleiche fachliche Informationen können technisch unterschiedlich codiert sein. Abweichende Feldreihenfolgen, Leerzeichen, Zeitzonen, Dezimaltrennzeichen oder Zeichenkodierungen verändern die Bytefolge und damit den Hashwert, obwohl der dargestellte Inhalt gleich erscheint.

Das Verfahren muss festlegen, was geprüft wird: entweder exakt die archivierten Dateibytes oder eine gemeinsam definierte kanonische Darstellung strukturierter Inhalte. Im ersten Fall werden die Bytes unverändert gehasht. Im zweiten benötigen Sender und Prüfer dieselben Serialisierungsregeln, etwa für Zahlen, Datumswerte und Feldreihenfolgen. Die verwendete Formatversion gehört dann ebenfalls in den Nachweis.

Diese Festlegung ist keine Nebensache. Ohne reproduzierbare Darstellung kann der Empfänger nicht unterscheiden, ob ein abweichender Hashwert auf eine tatsächliche Datenänderung oder lediglich auf eine andere technische Ausgabe zurückgeht.

Ein Hashwert ist ein Prüfwert, noch kein unabhängiger Nachweis

Ein kryptografischer Hashalgorithmus bildet eine Nachricht auf einen Digest fester Länge ab. NIST beschreibt in FIPS 180-4, dass solche Digests dazu verwendet werden können, Änderungen einer Nachricht seit ihrer Berechnung zu erkennen.^[1]

Für die externe Verifikation berechnet der Empfänger den Hashwert über die nach den vereinbarten Regeln dargestellten Daten neu. Stimmt das Ergebnis mit dem geschützten Referenzwert überein, passen die geprüften Bytes zu diesem Bezugspunkt. Weicht es ab, ist mindestens eine der Voraussetzungen nicht erfüllt: Daten, Umfang, Reihenfolge, Format oder Prüfwert unterscheiden sich.

Ein mit demselben Paket ausgelieferter, ungeschützter Hashwert reicht allerdings nicht aus. Wer Daten unbemerkt ersetzen könnte, könnte regelmäßig auch einen neuen Hashwert beilegen. Erst ein getrennt geschützter Referenzwert macht die Prüfung gegenüber dem erzeugenden System aussagekräftiger.

Eine Hash-Verkettung kann darüber hinaus die Reihenfolge fortlaufender Einträge absichern. Für einen externen Prüfer bleibt dennoch entscheidend, welcher Kettenstand vertrauenswürdig verankert wurde und wie er diesen Bezugspunkt erhält.

Digitale Signaturen verbinden Integrität mit einem Signaturschlüssel

Eine digitale Signatur kann nachweisen, dass signierte Daten seit der Signatur nicht unbemerkt verändert wurden und dass die Signatur mit einem bestimmten privaten Schlüssel erzeugt wurde. FIPS 186-5 beschreibt digitale Signaturen zur Erkennung unautorisierter Änderungen und zur Authentisierung der Identität des Signierenden.^[2]

Der Empfänger benötigt dafür den passenden öffentlichen Schlüssel und eine belastbare Zuordnung dieses Schlüssels zum behaupteten Aussteller. Zertifikate, Zertifikatsketten, Sperrinformationen und definierte Vertrauensanker sind deshalb Teil des Prüfmodells. Eine mathematisch gültige Signatur beantwortet allein noch nicht, ob der Signierende zum betreffenden Zeitpunkt befugt war oder ob seine Identität ordnungsgemäß geprüft wurde.

Auch die Bedeutung der Signatur muss feststehen. Sie kann lediglich den technischen Exportdienst kennzeichnen, eine fachliche Freigabe abbilden oder bestätigen, dass eine bestimmte Organisation das Paket ausgegeben hat. Diese Aussagen dürfen nicht miteinander vermischt werden.

Vertrauenswürdige Zeitstempel belegen einen früheren Datenstand

Für viele Prüfungen ist nicht nur wichtig, welche Daten vorliegen, sondern auch, ob der zugehörige Prüfwert bereits zu einem bestimmten Zeitpunkt existierte. RFC 3161 beschreibt hierfür ein Time-Stamp Protocol. Eine Time Stamping Authority versieht den Hashabdruck der Daten mit einer vertrauenswürdigen Zeitangabe und signiert das Zeitstempeltoken.^[3]

Die Vertrauensstelle muss den eigentlichen betrieblichen Inhalt dafür nicht erhalten. Nach dem RFC wird nur der Hashabdruck übermittelt. Bei einer späteren Prüfung werden Daten, Hashabdruck, Zeitstempeltoken, Signatur und Zertifikatsstatus zusammen kontrolliert.

Der Zeitstempel unterstützt den Nachweis, dass der bezeichnete Datenabdruck bereits zum bestätigten Zeitpunkt vorlag; die angegebene Zeitgenauigkeit und die Richtlinie der Zeitstempelstelle sind dabei zu berücksichtigen. Er beweist nicht, wann der reale Vorgang stattgefunden hat oder ob eine in den Daten gespeicherte Uhrzeit richtig ist. Für diesen Zusammenhang bleiben gesicherte Zeitquellen, Prozesskontext und organisatorische Kontrollen erforderlich.

Veröffentlichte Prüfpunkte ermöglichen Kontrolle ohne Offenlegung der Daten

Viele einzelne Datensätze können über eine Baumstruktur zu einem gemeinsamen Wurzelwert zusammengefasst werden. Ein einzelner Datensatz lässt sich dann mit einem Inklusionsnachweis gegen diese Wurzel prüfen, ohne dass alle anderen Inhalte offengelegt werden müssen.

RFC 9162 nutzt Merkle-Bäume für Certificate Transparency. Das Verfahren erlaubt Inklusionsnachweise für einzelne Einträge und Konsistenznachweise zwischen früheren und späteren Zuständen eines Append-only Logs.^[4] Der dort geregelte Anwendungsfall betrifft Zertifikate; das technische Prinzip zeigt jedoch, wie signierte Prüfpunkte und kompakte Nachweise voneinander getrennt werden können.

Für betriebliche Prozessdaten kann ein regelmäßig außerhalb des operativen Systems gesicherter Wurzelwert als Prüfpunkt dienen. Der Empfänger erhält dann nur die Daten, die er prüfen darf, sowie den zugehörigen Nachweispfad. Andere Chargen, Personen oder Geschäftsgeheimnisse müssen nicht Teil des offengelegten Pakets sein.

Was ein fehlgeschlagener Nachweis aussagt

Eine gescheiterte Prüfung ist zunächst ein technischer Befund. Sie kann bedeuten, dass Daten verändert wurden. Ebenso möglich sind eine unvollständige Übertragung, ein falsches Exportformat, eine andere Kanonisierung, ein fehlender Nachweispfad, ein abgelaufenes Zertifikat oder eine nicht verfügbare Vertrauensinformation.

Das Prüfergebnis sollte deshalb nicht nur „gültig“ oder „ungültig“ melden, sondern die geprüften Stufen ausweisen: Datenumfang, Hashberechnung, Signatur, Zertifikatskette, Zeitstempel, Inklusion und Konsistenz. So bleibt erkennbar, an welcher Voraussetzung die Kontrolle scheitert.

Ein technischer Fehler darf weder automatisch als Manipulationsnachweis noch als bloßes Formatproblem abgetan werden. Er löst eine Untersuchung aus, in der Ursache, betroffene Daten, mögliche Auswirkungen und erforderliche Maßnahmen nachvollziehbar bewertet werden.

Prüfbarkeit verlangt nicht die Veröffentlichung betrieblicher Inhalte

Externe Verifikation sollte nach dem Prinzip der Zweckbindung und Datenminimierung gestaltet werden. Der Empfänger erhält nur die Inhalte, die er für den Prüfauftrag benötigt. Personenbezug, Geschäftsgeheimnisse und Daten anderer Chargen können ausgeschlossen, pseudonymisiert oder über selektive Nachweise getrennt werden. Werden Inhalte innerhalb einer bereits gehashten Datei geschwärzt oder pseudonymisiert, entsteht jedoch eine andere Bytefolge. Ihr ursprünglicher Dateinachweis gilt dafür nicht unverändert weiter. Der Empfänger muss erkennen können, ob er ein Original oder eine abgeleitete Darstellung prüft; deren Verbindung zum früheren Nachweis benötigt ein dafür vorgesehenes Verfahren.

Ein veröffentlichter Hashwert ist zwar keine lesbare Kopie des Ausgangsinhalts. Bei kleinen oder vorhersagbaren Wertebereichen können jedoch Rückschlüsse oder Durchprobieren möglich sein. Prüfpunkte sollten daher keine unnötigen Informationen preisgeben. Zufällige Bindungswerte können Teil eines dafür ausgelegten Schutzverfahrens sein. Baumstrukturen ermöglichen Nachweise für ausgewählte Einheiten, verhindern für sich allein aber kein Erraten kleiner Wertebereiche.

Die Data Provenance hilft zusätzlich zu erklären, aus welchen Vorgängen und Quellen die exportierten Aussagen hervorgegangen sind. Sie darf aber ebenfalls nur in dem Umfang offengelegt werden, der für die konkrete Prüfung erforderlich ist.

Langfristige Verifikation benötigt Erneuerung

Kryptografische Verfahren bleiben nicht unbegrenzt gleich belastbar. Algorithmen können geschwächt, Schlüssel kompromittiert, Zertifikate abgelaufen oder Vertrauensdienste eingestellt werden. Ein heute gültiger Nachweis ist deshalb nicht automatisch über jede Aufbewahrungsfrist hinweg prüfbar.

RFC 4998 beschreibt Evidence Records für den langfristigen Nachweis von Existenz und Integrität digitaler Daten. Die Spezifikation sieht Archivzeitstempel und deren Erneuerung vor, bevor verwendete kryptografische Mechanismen ihre Eignung verlieren.^[5]

Ein Langzeitkonzept muss daher festlegen, wann Nachweise erneuert, welche alten Informationen mit einbezogen und wie Algorithmuswechsel dokumentiert werden. Die ursprünglichen Daten dürfen dabei nicht durch eine bloß aktuelle Signatur ersetzt werden; vielmehr muss die neue Beweisschicht die bisherige Nachweiskette nachvollziehbar fortführen.

Interne Kontrolle und unabhängige Prüfung sind verschiedene Ebenen

Innerhalb eines Betriebssystems kontrollieren Rollen, Berechtigungen, Freigaben und Protokolle, wer Daten erzeugen oder verändern darf. Diese Kontrollen sind notwendig, befinden sich aber im selben organisatorischen und technischen Verantwortungsbereich wie die Daten selbst.

Eine externe Verifikation verschiebt den Prüfpunkt. Ein Auditor, Auftraggeber, Labor, Geschäftspartner oder eine Behörde kann ein bereitgestelltes Paket mit einem Nachweis vergleichen, dessen Integrität nicht allein von der aktuell dargestellten Anwendung abhängt. Je nach Verfahren liegt dieser Bezugspunkt bei einer unabhängigen Vertrauensstelle, in einem getrennt betriebenen Verifikationsdienst oder in einem zuvor veröffentlichten Protokoll.

„Extern“ bedeutet daher nicht zwingend „öffentlich“. Betriebs- und personenbezogene Daten müssen für die Prüfbarkeit nicht im Internet erscheinen. Häufig genügt es, einen Hashwert oder eine daraus gebildete Sammelwurzel außerhalb des operativen Systems zu sichern. Der eigentliche Inhalt bleibt im geschützten Verantwortungsbereich und wird nur für einen konkreten Prüfzweck bereitgestellt.

Externe Verifikation erfordert weder eine öffentliche Blockchain noch die Offenlegung der Betriebsdaten.

Was externe Datenverifikation nicht leistet

Sie macht eine Organisation nicht allein durch kryptografische Nachweise compliant.

Datenintegrität entsteht über den gesamten Lebenszyklus aus geeigneter Erfassung, Zuordnung, Kontrolle, Aufbewahrung und Korrektur. Externe Verifikation ergänzt diese Kontrollen um eine unabhängig nachvollziehbare technische Prüfung, ersetzt sie aber nicht.

Sie beweist nicht, dass ein ursprünglich erfasster Messwert sachlich richtig war.

Sie ersetzt keine fachliche Prüfung, Freigabe oder Behördenentscheidung.

Das Ergebnis muss genauer sein als „gültig“

Ein brauchbarer Abschluss benennt die geprüften Einheiten, den verwendeten Bezugspunkt und die erfolgreichen oder fehlgeschlagenen Prüfschritte. Ein passender Inklusionsnachweis bestätigt die Zugehörigkeit zum gebundenen Bestand; er bestätigt nicht die Vollständigkeit der Auswahl.

Der Empfänger kann darauf seine weitere Untersuchung aufbauen. Fehlende Aufzeichnungen, unklare Vertrauensinformationen und offene fachliche Fragen müssen erkennbar bleiben, auch wenn einzelne kryptografische Prüfschritte erfolgreich waren.