Das Audit-Trail eines Unternehmens unterliegt der gleichen Prüfung wie das seiner Mandanten
In der Regel kann eine Kanzlei ein Aktivitätenprotokoll vorlegen, wenn ein Mandant oder Gericht dies verlangt. Weit weniger Kanzleien können jedoch eine schwierigere Frage beantworten: Könnte jemand mit administrativem Zugriff dieses Protokoll unbemerkt bearbeitet haben, bevor es vorgelegt wurde? Ist die Antwort auch nur theoretisch ja, gilt das Protokoll nicht als Beweis. Es ist dann lediglich ein Dokument, das jemand mit den richtigen Berechtigungen so verfassen konnte, dass es beliebige Aussagen darüber enthält, wer auf eine Aktenakte zugegriffen hat.
Dieser Artikel beleuchtet, was einen Audit-Trail für eine Kanzlei tatsächlich als Beweis vertrauenswürdig macht – und an welchen Stellen die Protokollierung in den meisten Kanzleien stillschweigend scheitert.
Executive Summary
Der Nutzen eines Audit-Trails für Mandanten, Gerichte oder interne Ermittler hängt vollständig vom Vertrauen in dessen 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 Risikoverantwortliche zählt der architektonische Standard: Kann jede Einzelperson, einschließlich Systemadministratoren, tatsächlich den Datensatz verändern?
Wichtige Erkenntnisse
- Ein Protokoll, das ein Administrator bearbeiten oder löschen kann, ist kein Beweis – unabhängig vom Detaillierungsgrad.
- Der Zugriff auf die zugrunde liegende Protokollspeicherung muss architektonisch beschränkt sein, nicht nur durch Richtlinien.
- Die Trennung von Aufgaben ist ebenso wichtig wie Zugriffsbeschränkungen. Die Person, die auf eine Aktenakte zugreift, und die Person, die das Protokoll prüft, dürfen nicht dieselbe Rolle innehaben.
- Vollständigkeit und Unmittelbarkeit sind Teil der Vertrauenswürdigkeit – nicht davon getrennt.
- Mandanten fragen zunehmend, wie ein Protokoll geschützt wird – nicht nur, was es enthält.
Warum „Wir haben detaillierte Protokolle“ für Kanzleien der falsche Ansatz ist
Die meisten Gespräche über Audit-Protokollierung 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 darüber, wer auf eine Aktenakte zugegriffen hat, ist nur so vertrauenswürdig wie die Garantie, dass es nachträglich nicht verändert wurde.
Die wirklich entscheidende Frage: Wer hätte dies ändern können?
Die richtige Einstiegsfrage lautet nicht, was ein Protokoll aufzeichnet, sondern wer es nachträglich technisch verändern kann.
Was macht Protokollintegrität zu einer Architektur- und nicht nur einer Prozessfrage?
Eine Richtlinie, die Administratoren das Bearbeiten von Protokollen untersagt, setzt voraus, dass Administratoren 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 der Kanzlei noch der Plattformanbieter regulären Zugriff auf das Betriebssystem oder die Datenbank haben, in der die Protokolle gespeichert werden.
Ausnahmen müssen Ausnahmen bleiben – und dürfen kein Hintertürchen sein
Was eine vertretbare Ausnahme von einer Hintertür unterscheidet, ist, ob der Zugriff zeitlich begrenzt, doppelt autorisiert und selbst vollständig protokolliert ist.
Aufgabentrennung als zweiter, unabhängiger Schutzmechanismus
Wenn dieselbe Rolle sowohl auf eine Aktenakte zugreifen als auch das Protokoll dieses Zugriffs prüfen kann, besteht ein inhärenter Interessenkonflikt.
Wer handelt, sollte nicht auditieren
Echte Aufgabentrennung weist Compliance-, Audit- und Richtlinienfunktionen anderen Rollen zu als der operativen Administration.
Den Standard schaffen, bevor Mandanten danach fragen
Der Praxistest besteht darin, ehrlich zu prüfen, wer technisch die Audit-Logs der Kanzlei verändern könnte und ob die Rollen für operative Tätigkeiten und Audits wirklich 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 IT-Administratoren der Kanzlei regulären Zugriff auf das zugrunde liegende Betriebssystem oder die Datenbank haben – einschließlich der Audit-Log-Speicherung. Jeder Support-Zugriff ist temporär, doppelt autorisiert und wird vollständig protokolliert. Spezielle Compliance- und Auditor-Rollen trennen die operative Administration von Audit-Funktionen. Jede Aktion über alle Kanäle wird vollständig und unmittelbar in einem fälschungssicheren, nicht limitierten Audit-Log erfasst, das direkt in SIEM-Tools eingespeist wird.
Kanzleien, die prüfen möchten, ob ihr aktueller Audit-Trail der Frage „Könnte ein Admin dies bearbeitet haben?“ standhält, können eine individuelle Demo vereinbaren.
Häufig gestellte Fragen
Ein Protokoll, das ein Administrator bearbeiten oder löschen kann, ist kein Beweis – unabhängig vom Detaillierungsgrad. Der Datensatz könnte nachträglich so verändert worden sein, dass er beliebige Aussagen darüber enthält, wer auf eine Aktenakte zugegriffen hat.
Eine Richtlinie, die Administratoren das Bearbeiten von Protokollen untersagt, setzt voraus, dass sie sich daran halten. Eine architektonische Kontrolle entzieht ihnen von vornherein die technische Möglichkeit, auf die zugrunde liegende Protokollspeicherung zuzugreifen oder diese zu bearbeiten.
Die Aufgabentrennung stellt sicher, dass die Person, die auf eine Aktenakte zugreift, nicht dieselbe Rolle ist, die das Protokoll dieses Zugriffs prüft oder verändern könnte. So wird ein Interessenkonflikt zwischen operativen Handlungen und Audit-Funktionen ausgeschlossen.
Die Kiteworks Data Control Plane nutzt eine gehärtete Architektur, bei der weder Kiteworks noch IT-Administratoren der Kanzlei regulären Zugriff auf die Protokollspeicherung haben. Jeder Support-Zugriff ist temporär, doppelt autorisiert und wird vollständig protokolliert. Spezielle Compliance- und Auditor-Rollen halten Audit-Funktionen strikt getrennt von operativen Tätigkeiten.