Wogegen Audit-Trails im öffentlichen Sektor tatsächlich standhalten müssen
Eine Behörde kann in der Regel ein Zugriffsprotokoll vorlegen, wenn eine Aufsichtsbehörde dies verlangt. Weit weniger Behörden 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, ist das Protokoll kein Beweis. Es ist dann lediglich ein Dokument, das jemand mit den richtigen Zugangsdaten so verfassen konnte, dass es beliebige Aussagen darüber enthält, wer auf einen Bürgerdatensatz zugegriffen hat.
Dieser Artikel beleuchtet, was einen Audit-Trail für Behörden tatsächlich als Beweismittel vertrauenswürdig macht – und an welchen Stellen die Protokollierung in den meisten Behörden diesem Anspruch leise nicht genügt.
Executive Summary
Der Nutzen eines Audit-Trails für eine Aufsichtsbehörde 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 zugrundeliegende Protokollspeicherung technisch eine Bearbeitung ermöglicht, ist ein Verbot per Richtlinie nicht gleichbedeutend mit technischer Unmöglichkeit. Für IT- und Compliance-Verantwortliche ist der praktische Maßstab architektonisch: Kann irgendeine Person, einschließlich Systemadministrator, den Datensatz tatsächlich verändern?
Wichtige Erkenntnisse
- Ein Protokoll, das ein Administrator bearbeiten oder löschen kann, ist kein Beweis – unabhängig vom Detailgrad.
- Der Zugriff auf die zugrundeliegende Protokollspeicherung muss architektonisch beschränkt sein, nicht nur durch Richtlinien.
- Die Trennung von Aufgaben ist genauso wichtig wie Zugriffsbeschränkungen. Die Person, die auf einen Bürgerdatensatz zugreift, und die Person, die diesen Zugriff prüft, sollten nicht dieselbe Rolle haben.
- Vollständigkeit und Unmittelbarkeit sind Teil der Vertrauenswürdigkeit – nicht davon getrennt.
- Aufsichtsbehörden fragen zunehmend, wie ein Protokoll geschützt ist – nicht nur, was es enthält.
Warum „Wir haben detaillierte Protokolle“ für Behörden der falsche Ansatz ist
Die meisten Diskussionen über Audit-Protokollierung drehen sich um die Abdeckung. Abdeckung ist wichtig, beantwortet aber nicht die entscheidende Einstiegsfrage.
Details ohne Integrität sind nur eine gut erzählte Geschichte
Ein Protokoll mit vielen Details darüber, wer auf einen Bürgerdatensatz 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 ist nicht, was ein Protokoll aufzeichnet, sondern wer technisch in der Lage ist, es nachträglich zu verändern.
Was Protokollintegrität architektonisch statt prozedural macht
Eine Richtlinie, die Administratoren das Bearbeiten von Protokollen untersagt, setzt voraus, dass sich Administratoren daran halten. Eine architektonische Kontrolle nimmt die technische Möglichkeit zur Bearbeitung vollständig weg.
Kein dauerhafter Zugriff auf die zugrundeliegende Protokollspeicherung
Die stärkste Ausprägung dieser Kontrolle ist, dass weder die IT-Administratoren der Behörde noch der Plattformanbieter regulären Zugriff auf das Betriebssystem oder die Datenbank haben, in der Protokolle gespeichert werden.
Ausnahmen müssen Ausnahmen bleiben – und kein Hintertürchen sein
Was eine vertretbare Ausnahme von einem Hintertürchen unterscheidet, ist: Der Zugriff ist zeitlich begrenzt, erfordert eine doppelte Autorisierung und wird selbst vollständig protokolliert.
Trennung von Aufgaben als zweiter, unabhängiger Schutzmechanismus
Wenn dieselbe Rolle sowohl auf Bürgerdatensätze zugreifen als auch die Protokolle dieser Zugriffe prüfen kann, besteht ein Interessenkonflikt.
Wer handelt, sollte nicht auditieren
Echte Trennung von Aufgaben bedeutet, dass Compliance-, Audit- und Richtlinienfunktionen anderen Rollen zugeordnet werden als der operativen Administration.
Den Standard schaffen, bevor die Aufsichtsbehörde danach fragt
Der Praxistest besteht darin, ehrlich zu prüfen, wer technisch die Audit-Logs der Behörde verändern könnte – und ob die Rollen für operative Aufgaben und Audit 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 IT-Administratoren der Behörde regulären Zugriff auf das zugrundeliegende Betriebssystem oder die Datenbank – einschließlich der Audit-Log-Speicherung – haben; jeder Support-Zugriff ist temporär, doppelt autorisiert und wird selbst vollständig protokolliert. Spezielle Compliance- und Auditor-Rollen trennen operative Administration von Audit-Funktionen, und jede Aktion über alle Kanäle wird vollständig und unmittelbar in einem fälschungssicheren, nicht gedrosselten Audit-Log erfasst, das direkt in SIEM-Tools eingespeist wird.
Behörden, die testen möchten, ob ihr aktueller Audit-Trail der Frage „Könnte ein Administrator dies bearbeitet haben?“ standhält, können eine individuelle Demo vereinbaren.
Häufig gestellte Fragen
Ein Audit-Trail ist nur dann vertrauenswürdig, wenn seine Integrität architektonisch garantiert ist – das heißt, niemand, auch kein Systemadministrator, kann Datensätze nachträglich technisch verändern oder löschen. Eine Richtlinie allein reicht nicht aus, wenn eine Bearbeitung technisch möglich bleibt.
Ausführliche Details zu Zugriffsereignissen sind nur so zuverlässig wie die Garantie, dass das Protokoll nachträglich nicht bearbeitet werden kann. Ohne architektonische Beschränkungen ist ein detailliertes Protokoll lediglich eine gut geschriebene Geschichte, die jemand mit Zugangsdaten hätte fälschen können.
Die Trennung von Aufgaben stellt sicher, dass die Rolle, die auf Bürgerdatensätze zugreift, von der Rolle getrennt ist, die diese Zugriffe prüft oder auditiert. So werden Interessenkonflikte vermieden und Compliance- sowie Audit-Funktionen von der operativen Administration getrennt.
Dazu gehören: Kein dauerhafter Zugriff auf die zugrundeliegende Protokollspeicherung für IT-Administratoren oder Anbieter, temporäre und doppelt autorisierte Ausnahmen, die selbst protokolliert werden, sowie vollständige und unmittelbare Erfassung jeder Aktion in einem fälschungssicheren Protokoll, das direkt in SIEM-Systeme eingespeist wird.