Audit Logging
Festhalten, wer wann was getan hat
Die Idee und ihr Nutzen
Ein Sachbearbeiter einer Versicherung ändert am Vormittag die Bankverbindung eines Kunden und gibt eine Viertelstunde später eine Auszahlung von 25.000 Euro frei. Wochen später muss die interne Revision, die Prüfabteilung des Unternehmens, nachvollziehen, wer diese beiden Handlungen wann vorgenommen hat. Dafür schreiben die beteiligten Anwendungen zu jeder solchen Handlung einen Eintrag mit Person, Zeitpunkt, Vorgang und betroffenem Datensatz in ein Protokoll, in dem sich vorhandene Einträge nicht ändern oder löschen lassen, das Prüfprotokoll. Dieses Vorgehen heißt Audit Logging, auf Deutsch etwa Prüfprotokollierung. Die interne Revision kann sich auf das Prüfprotokoll nur verlassen, wenn es zu jeder Auszahlung einen Eintrag gibt und eine spätere Veränderung eines Eintrags auffällt.
Wie funktioniert es?
Um 09:14 Uhr ändert Sachbearbeiter Klaus Meier die Bankverbindung zu Vertrag 88123 in der Vertragsanwendung, die die Bankverbindungen verwaltet. Die Vertragsanwendung hängt daraufhin einen Eintrag an das Prüfprotokoll an, der festhält, wer wann was woran getan hat und mit welchem Ergebnis: Person K. Meier, 09:14 Uhr, Bankverbindung geändert, Vertrag 88123, erlaubt. Um 09:31 Uhr gibt Klaus Meier in der Schadenanwendung 25.000 Euro für Schaden 4711 frei, der zu Vertrag 88123 gehört. Auch die Schadenanwendung hängt einen Eintrag an: Person K. Meier, 09:31 Uhr, Auszahlung freigegeben, Schaden 4711, erlaubt. Jeder Eintrag erhält eine Prüfsumme, eine aus dem Inhalt berechnete Zeichenfolge, die sich bei jeder Änderung des Inhalts ändert. In die Prüfsumme des zweiten Eintrags fließt auch die Prüfsumme des ersten Eintrags ein, damit spätere Änderungen auffallen. Drei Wochen später sucht die interne Revision im Prüfprotokoll nach Auszahlungen, bei denen kurz zuvor die Bankverbindung geändert wurde, weil dieses Muster bei Betrug häufig vorkommt. Die interne Revision erhält beide Einträge und sieht, dass dieselbe Person beide Handlungen innerhalb von 17 Minuten vorgenommen hat. Ob die Handlungen fachlich begründet waren, klärt die interne Revision anhand weiterer Unterlagen. Begründet war die Änderung zum Beispiel, wenn der Kunde die neue Bankverbindung schriftlich mitgeteilt hatte.
Zum selben Kundenfall gehören in der Versicherung Daten in mehreren Anwendungen, hier in der Vertragsanwendung und in der Schadenanwendung. Sachbearbeiter bedienen die beiden Anwendungen, ein Betriebsteam betreibt sie. Die Administratoren des Betriebsteams haben weitreichende Rechte auf Servern und Datenbanken. Die interne Revision ist von Sachbearbeitern und Betriebsteam organisatorisch getrennt und soll die Handlungen beider prüfen können. Welche Handlungen sicherheitsrelevant sind und ins Prüfprotokoll gehören, legt das Unternehmen anhand von Gesetzen, Vorgaben der Aufsicht und internen Richtlinien fest. Jeder Eintrag hat feste Felder:
- Unter „Wer“ steht die angemeldete Person oder das technische Benutzerkonto, unter dem ein Programm ohne Person handelt. Handelt jemand in Vertretung, steht im Feld auch, für wen.
- „Wann“ ist der genaue Zeitpunkt, genommen von einer Uhr, die regelmäßig mit einer gemeinsamen Zeitquelle abgeglichen wird, damit Einträge verschiedener Anwendungen vergleichbar sind.
- „Was“ ist die Handlung, etwa „Auszahlung freigegeben“.
- „Woran“ nennt den betroffenen Datensatz, etwa Schaden 4711. Ob zusätzlich alter und neuer Wert festgehalten werden, hängt davon ab, was nachgewiesen werden muss und wie schützenswert diese Werte sind.
- „Wie“ nennt das Ergebnis, also erlaubt oder abgelehnt, und die Herkunft der Anfrage. Die Herkunft ist zum Beispiel der Rechner, von dem die Anfrage kam.
Die Einträge liegen in einem gesondert geschützten Speicher. Die Anwendungen dürfen in diesem Speicher nur neue Einträge hinzufügen, aber keine vorhandenen ändern oder löschen. Lesen dürfen nur ausdrücklich berechtigte Personen wie die interne Revision. Jede Prüfsumme hängt von der Prüfsumme des vorherigen Eintrags ab. Verändert jemand einen alten Eintrag, muss er deshalb alle folgenden Prüfsummen neu berechnen. Das fällt auf, wenn die zuletzt berechnete Prüfsumme zusätzlich in einem zweiten Speicher aufbewahrt wird, auf den diese Person keinen Zugriff hat. Bei der Prüfung vergleicht die interne Revision die Prüfsummen mit dem getrennt aufbewahrten Wert.
Scheitert das Schreiben eines Eintrags, ist der Nachweis lückenhaft. Das Unternehmen muss vorher entschieden haben, was die Anwendung dann tut: Sie verweigert die Handlung, oder sie speichert den Eintrag zwischen und trägt ihn später nach.
Audit Logging: zwei Handlungen später nachweisen
Wann ist es sinnvoll und wann nicht?
Audit Logging lohnt sich
- Handlungen müssen später jemandem erklärt werden. Beispiele sind Auszahlungen, Freigaben, Änderungen an Bankverbindungen, Änderungen an Zugriffsrechten und das Ansehen oder Exportieren sensibler Daten. Ohne Prüfprotokoll lässt sich Wochen später nicht mehr belegen, wer die Bankverbindung zu Vertrag 88123 geändert und wer die 25.000 Euro freigegeben hat.
- Aufsichtsbehörden und Wirtschaftsprüfer verlangen bei Versicherungen und Banken einen verlässlichen Nachweis, wer sensible Vorgänge ausgelöst hat. Das Betriebsteam darf diesen Nachweis nicht verändern können. Die normalen Anwendungsprotokolle taugen dafür nicht. Sie enthalten vor allem technische Meldungen wie Fehler und Laufzeiten. Außerdem werden sie oft nach wenigen Tagen gelöscht und können von Administratoren verändert werden. Ein Administrator, der selbst eine Auszahlung veranlasst hat, könnte dann den Eintrag dazu löschen.
- Eine Handlung und ihre Vorgeschichte verteilen sich auf mehrere Anwendungen. Die Bankverbindung ändert Klaus Meier in der Vertragsanwendung, die Auszahlung gibt er in der Schadenanwendung frei. Hält jede Anwendung solche Handlungen in eigener Form fest, muss die interne Revision die Angaben beider Anwendungen von Hand zusammenführen. Weil jeder Eintrag dieselben festen Felder hat, kann die interne Revision über beide Anwendungen hinweg gezielt nach dem Betrugsmuster „Auszahlung kurz nach Wechsel der Bankverbindung“ suchen.
Audit Logging ist nicht das Richtige
- Das Prüfprotokoll soll das normale Anwendungsprotokoll ersetzen. Technische Fehler und Laufzeiten lägen dann in einem Speicher, den nur die interne Revision lesen darf, und das Betriebsteam käme nicht an seine Fehlermeldungen. Die Einträge, nach denen die interne Revision sucht, gingen zudem zwischen den technischen Meldungen unter. Die Anwendungen schreiben technische Fehler und Laufzeiten deshalb weiterhin in ihre Anwendungsprotokolle, die das Betriebsteam auswertet.
- Handlungen haben keinen Sicherheitsbezug und keine Nachweispflicht. Ein Beispiel ist der Aufruf einer Hilfeseite. Niemand muss einen solchen Aufruf später erklären. Dann schreibt die Anwendung dafür keinen Eintrag ins Prüfprotokoll. Die interne Revision muss die wichtigen Einträge dann nicht zwischen Aufrufen von Hilfeseiten heraussuchen.
- Eine Handlung soll verhindert werden. Das Prüfprotokoll hält die Freigabe der 25.000 Euro fest, hält sie aber nicht auf. Dafür prüft die Schadenanwendung vor der Freigabe die Zugriffsrechte der Person, vergeben etwa mit Role Based Access Control, oder verlangt eine zweite Freigabe durch eine andere Person. Eine unberechtigte Auszahlung findet dann gar nicht statt, statt erst Wochen später bei der Prüfung aufzufallen.
- Es muss nur nachgewiesen werden, wie sich ein bestimmter Datensatz verändert hat, etwa die Bankverbindung zu Vertrag 88123. Lesezugriffe spielen keine Rolle, und kein Prüfer verlangt, dass die Administratoren des Betriebsteams den Nachweis nicht verändern können. Dann richtet das Team der Vertragsanwendung eine Änderungsgeschichte in der Datenbank ein, die zu jedem Datensatz alle früheren Fassungen aufbewahrt. Aus der Änderungsgeschichte lassen sich alte Werte direkt wiederherstellen oder mit dem heutigen Stand vergleichen. Ein gesondert geschützter Speicher mit verketteten Prüfsummen entfällt, weil niemand den Schutz vor Änderungen durch Administratoren verlangt.
Nachteile und typische Fehler
Das Prüfprotokoll enthält selbst sensible Daten, etwa wer welche Kundendaten angesehen hat. Das Prüfprotokoll braucht deshalb eigene Zugriffsrechte und eine Aufbewahrungsfrist, die mit dem Datenschutz vereinbar ist. Der Speicher, die Leserechte und die getrennte Aufbewahrung der Prüfsumme müssen eingerichtet und betrieben werden, und jemand muss die Einträge regelmäßig auswerten. Jede beteiligte Anwendung muss die Einträge in derselben Form schreiben. Ist der Speicher des Prüfprotokolls nicht erreichbar, kann keine Anwendung Einträge schreiben. Auch der Umfang ist eine Abwägung: Bei zu vielen Einträgen muss die interne Revision die wichtigen erst aus der Menge heraussuchen, bei zu wenigen bleibt genau die Frage offen, die später gestellt wird.
Typische Fehler und woran man sie erkennt:
- Lücke beim Schreiben: Das Schreiben eines Eintrags scheitert, die Anwendung führt die Handlung trotzdem aus und trägt den Eintrag nie nach. Erkennbar ist das an freigegebenen Auszahlungen in der Schadenanwendung, zu denen das Prüfprotokoll keinen Freigabeeintrag enthält.
- Veränderbare Einträge: Administratoren des Speichers haben volle Schreibrechte und können Einträge ändern oder löschen. Ein Administrator löscht zum Beispiel den Eintrag von 09:14 Uhr und berechnet die Prüfsummen der folgenden Einträge neu. Die verketteten Prüfsummen machen das nur sichtbar, wenn die Administratoren keinen Zugriff auf die getrennt aufbewahrte Prüfsumme haben. Erkennbar ist das an Rechten auf dem Speicher, die über das Anfügen hinausgehen, oder an einer zuletzt berechneten Prüfsumme, die im selben Speicher liegt.
- Untergegangene Einträge: Die Anwendungen schreiben auch technische Meldungen und Routinevorgänge ins Prüfprotokoll, und die wichtigen Einträge gehen in der Menge unter. Erkennbar ist das an Auswertungen der internen Revision, die überwiegend Einträge ohne Bezug zu ihrer Frage liefern.
- Fehlende Angabe: Eine Anwendung lässt im Eintrag ein Feld weg. Die Schadenanwendung schreibt zum Beispiel die Nummer des Schadens nicht mit. Die interne Revision kann die Auszahlung dann nicht mehr dem Vertrag 88123 zuordnen. Erkennbar ist das, wenn eine Prüffrage sich nur mit Rückfragen an die Fachabteilung beantworten lässt.
- Abweichende Uhren: Vertragsanwendung und Schadenanwendung nehmen den Zeitpunkt von unterschiedlich gestellten Uhren. Geht die Uhr der Schadenanwendung 20 Minuten nach, trägt die Schadenanwendung die Freigabe mit 09:11 Uhr ein, also vor der Änderung der Bankverbindung um 09:14 Uhr. Die Reihenfolge von Änderung und Freigabe lässt sich dann nicht sicher belegen. Erkennbar ist das an Einträgen, deren zeitliche Reihenfolge nicht zum fachlichen Ablauf passt.
Weiterführend
Verwandte Ansätze
- Event Sourcing: speichert jede fachliche Änderung als Ereignis und bewahrt so eine vollständige Änderungsgeschichte auf, die manche Nachfragen ebenfalls beantwortet; bloße Lesezugriffe erfasst sie aber nicht, deshalb ersetzt sie kein Prüfprotokoll.
- Observability: beschreibt technische Protokolle, Messwerte und Ablaufspuren für den Betrieb, die getrennt vom Prüfprotokoll geführt werden.
- Correlation Identifier: eine gemeinsame Kennung, mit der sich Einträge verschiedener Anwendungen demselben Vorgang zuordnen lassen.
- Defense in Depth: Sicherheit durch mehrere voneinander unabhängige Schutzmaßnahmen; das Prüfprotokoll ist eine davon, weil es Missbrauch zwar nicht verhindert, aber aufdeckbar macht.
Werkzeuge und Umsetzungen
- Hibernate Envers: speichert in Java-Anwendungen für ausgewählte Datensätze jede Änderung als eigene Version. Die Anwendung muss zusätzlich mitgeben, wer die Änderung vorgenommen hat.
- pgAudit: Erweiterung für die Datenbank PostgreSQL, die Zugriffe und Änderungen direkt in der Datenbank protokolliert.
- immudb: Datenbank, an die Einträge nur angefügt werden können. Die Datenbank verkettet Prüfsummen, sodass eine spätere Veränderung nachweisbar wird.
- Linux Audit: protokolliert sicherheitsrelevante Vorgänge auf Ebene des Betriebssystems Linux, etwa Anmeldungen und Zugriffe auf bestimmte Dateien.
Quellen
- OWASP: Logging Cheat Sheet: Empfehlungen der Sicherheitsorganisation OWASP, welche Ereignisse protokolliert werden sollten und wie Protokolle geschützt werden.
- Karen Kent, Murugiah Souppaya (NIST): Guide to Computer Security Log Management, SP 800-92: Leitfaden der US-Normungsbehörde NIST zu Aufbewahrung, Schutz der Vertraulichkeit und Unversehrtheit von Protokollen sowie zur Prüfung mit Prüfsummen.