Finanzdienstleister und das Vertrauensproblem im eigenen Audit-Trail

Eine Bank kann in der Regel ein Prüfprotokoll vorlegen, wenn eine Aufsichtsbehörde danach fragt. Weit weniger Banken können jedoch eine schwierigere Frage beantworten: Könnte jemand mit administrativem Zugriff dieses Protokoll still und heimlich bearbeitet haben, bevor es vorgelegt wurde? Wenn die Antwort auch nur theoretisch „ja“ ist, ist das Protokoll kein Beweis. Es ist dann lediglich ein Dokument, das jemand mit den richtigen Zugangsdaten so schreiben konnte, dass es jede gewünschte Aussage über die Transaktionshistorie eines Kunden trifft.

Aufsichtsbehörden und Prüfer stellen diese Frage inzwischen gezielt, denn der Wert eines Audit-Trails hängt vollständig davon ab, ob er das tatsächliche Geschehen widerspiegelt – und nicht das, was ein Administrator lieber dokumentieren würde. Dieser Artikel beleuchtet, was einen Audit-Trail für Finanzinstitute wirklich als Beweis vertrauenswürdig macht – und woran die Protokollierung in den meisten Unternehmen in der Praxis scheitert.

Executive Summary

Der Nutzen eines Audit-Trails für Aufsichtsbehörden oder interne Ermittler hängt vollständig vom Vertrauen in seine Integrität ab – und dieses Vertrauen darf sich nicht allein auf Richtlinien stützen. Wenn administrativer Zugriff auf die zugrunde liegende Protokollspeicherung technisch eine Bearbeitung ermöglicht, ist ein Bearbeitungsverbot per Richtlinie nicht gleichbedeutend mit technischer Unmöglichkeit. Für Verantwortliche in den Bereichen Sicherheit und Compliance zählt der architektonische Standard: Kann eine Einzelperson, einschließlich Systemadministrator, den Datensatz tatsächlich verändern?

wichtige Erkenntnisse

1. Ein Protokoll, das ein Administrator bearbeiten oder löschen kann, ist kein Beweis – unabhängig vom Detaillierungsgrad. Der Beweiswert hängt davon ab, ob der Datensatz veränderbar war.
2. Der Zugriff auf die zugrunde liegende Protokollspeicherung muss architektonisch eingeschränkt sein, nicht nur durch Richtlinien. Ein Bearbeitungsverbot ist wirkungslos, wenn die technische Möglichkeit zur Bearbeitung weiter besteht.
3. Aufgabentrennung ist ebenso wichtig wie Zugriffsbeschränkung. Die Person, die eine Transaktion durchführt, und diejenige, die das Protokoll prüft oder kontrolliert, dürfen nicht dieselbe Rolle haben.
4. Vollständigkeit und Unmittelbarkeit sind Teil der Vertrauenswürdigkeit, nicht davon zu trennen. Ein Protokoll, das unter Last nur stichprobenartig aufzeichnet oder Einträge verzögert schreibt, schafft ein Zeitfenster, in dem Ereignisse vor der Erfassung gelöscht werden könnten.
5. Aufsichtsbehörden fragen zunehmend, wie ein Protokoll geschützt wird – nicht nur, was es enthält. Ein Institut, das nicht beantworten kann, wer einen Datensatz hätte verändern können, ist auf diese Frage nicht vorbereitet.

Warum „Wir haben detaillierte Protokolle“ für Finanzinstitute der falsche Ansatz ist

Die meisten Diskussionen über Prüfprotokolle konzentrieren sich auf die Abdeckung. Abdeckung ist wichtig, beantwortet aber nicht die entscheidende Einstiegsfrage.

Details ohne Integrität sind nur eine gut geschriebene Geschichte

Ein Protokoll mit vielen Details zu Kundentransaktionen ist nur so vertrauenswürdig wie die Garantie, dass es nachträglich nicht verändert wurde. Ein Administrator mit Datenbankzugriff kann im Prinzip ein detailliertes Protokoll genauso einfach bearbeiten wie ein lückenhaftes.

Die entscheidende Frage: Wer hätte das ändern können?

Die wichtigste Einstiegsfrage bei der Bewertung eines Prüfprotokolls ist nicht, was es aufzeichnet, sondern wer technisch in der Lage ist, es nachträglich zu verändern.

Was Integrität von Protokollen zu einer architektonischen – und nicht nur prozeduralen – Frage macht

Eine Richtlinie, die Administratoren das Bearbeiten von Protokollen untersagt, setzt voraus, dass sie sich daran halten. Eine architektonische Kontrolle entzieht ihnen die technische Möglichkeit dazu.

Kein dauerhafter Zugriff auf die zugrunde liegende Protokollspeicherung

Die stärkste Ausprägung dieser Kontrolle ist, dass weder die eigenen IT-Administratoren des Instituts noch der Plattformanbieter regulären Zugriff auf das Betriebssystem oder die Datenbank haben, in denen Protokolle gespeichert werden.

Ausnahmen müssen Ausnahmen bleiben – und dürfen kein Hintertürchen sein

Eine zulässige Ausnahme unterscheidet sich von einem Hintertürchen dadurch, dass der Zugriff nur temporär, mit expliziter Freigabe durch mehrere Parteien und vollständig protokolliert erfolgt.

Aufgabentrennung als unabhängige, zweite Schutzmaßnahme

Wenn dieselbe Rolle sowohl Kundengelder bewegen als auch die Protokolle dieser Aktionen prüfen kann, besteht ein grundlegender Interessenkonflikt.

Wer handelt, sollte nicht prüfen

Echte Aufgabentrennung bedeutet, dass Compliance-, Prüfungs- und Richtlinienfunktionen anderen Rollen zugeordnet werden als der operativen Administration.

Den Standard schaffen, bevor die Aufsicht danach fragt

Der Praxistest besteht darin, ehrlich zu fragen, wer technisch die Prüfprotokolle des Instituts verändern könnte – und ob die Rollen für Durchführung und Prüfung tatsächlich getrennt sind.

Wie eine Data Control Plane Beweissicherheit architektonisch verankert

Die Kiteworks Data Control Plane läuft auf einer gehärteten Architektur, bei der weder Kiteworks noch die eigenen IT-Administratoren des Instituts regulären Zugriff auf das Betriebssystem oder die Datenbank – einschließlich der Protokollspeicherung – haben; jeder Support-Zugriff ist temporär, doppelt autorisiert und wird vollständig protokolliert. Spezielle Compliance-, Auditor- und CISO-Rollen trennen operative Administration von Prüfungsfunktionen. Jede Aktion über alle Kanäle wird vollständig und unmittelbar in einem fälschungssicheren, nicht gedrosselten Prüfprotokoll erfasst, das direkt in SIEM-Tools eingespeist wird.

Institute, die testen möchten, ob ihr aktueller Audit-Trail der Frage „Könnte ein Admin das bearbeitet haben?“ standhält, können eine individuelle Demo vereinbaren.