Ein Audit-Log — die manipulationssichere Aufzeichnung, wer wann was getan hat — ist eines der Features, nach denen niemand fragt, bis er es dringend braucht. Im Self-Service-Segment scheint es verzichtbar; sobald ein Produkt aber in regulierte Branchen oder ins Enterprise-Segment vordringt, wird das Audit-Log zur Voraussetzung. Es ist gleichzeitig ein Sicherheits-, ein Compliance- und ein Vertriebsthema. Dieser Beitrag zeigt, wie man es richtig baut.
Audit-Log ist nicht gleich Application-Log
Eine grundlegende Unterscheidung: Application-Logs dienen den Entwicklern zur Fehlersuche und sind flüchtig, technisch und unstrukturiert. Ein Audit-Log dagegen dokumentiert geschäftlich relevante Handlungen aus Nutzersicht — wer eine Einstellung geändert, einen Datensatz gelöscht, einen Nutzer eingeladen oder eine Berechtigung erteilt hat. Es ist strukturiert, langlebig und für Menschen lesbar, oft auch für die Kunden selbst. Verwechselt man beides und versucht, das Audit-Log aus den technischen Logs zu rekonstruieren, scheitert man an Lücken und Unlesbarkeit.
Welche Ereignisse hineingehören
Loggen Sie geschäftlich und sicherheitsrelevant bedeutsame Ereignisse: Authentifizierung (Anmeldung, fehlgeschlagene Versuche, Abmeldung), Änderungen an Berechtigungen und Rollen, Erstellung, Änderung und Löschung wichtiger Datensätze, Änderungen an Konfiguration und Sicherheitseinstellungen, Exporte von Daten und administrative Eingriffe. Pro Eintrag erfassen Sie: wer (Nutzer und Mandant), was (die Aktion), wann (Zeitstempel), worauf (die betroffene Ressource) und idealerweise den Kontext (vorher/nachher bei Änderungen, IP, verwendetes Gerät). Der alte und der neue Wert bei Änderungen sind oft das Wertvollste — sie machen aus «Einstellung geändert» ein nachvollziehbares «von X auf Y geändert».
Unveränderlichkeit ist nicht verhandelbar
Ein Audit-Log, das sich nachträglich ändern lässt, ist als Nachweis wertlos — gerade gegenüber Innentätern, die ihre Spuren verwischen wollen. Gestalten Sie das Log deshalb append-only: Einträge werden nur hinzugefügt, nie geändert oder gelöscht. Technisch lässt sich das über Datenbankberechtigungen absichern, die kein UPDATE oder DELETE auf die Audit-Tabelle erlauben, über getrennte Speicher, oder über kryptografische Verkettung, bei der jeder Eintrag den vorherigen referenziert, sodass eine nachträgliche Manipulation auffällt. Für die meisten SaaS genügt eine strikt append-only geführte, von der Anwendung getrennte Tabelle.
Mandantentrennung und Zugriff
Im Multi-Tenant-SaaS gehört jeder Audit-Eintrag eindeutig zu einem Mandanten, und die Mandantentrennung muss auch hier strikt gelten — kein Kunde darf die Audit-Logs eines anderen sehen. Überlegen Sie, welche Einträge dem Kunden selbst zugänglich gemacht werden: Viele Enterprise-Kunden verlangen, ihre eigenen Audit-Logs einsehen oder exportieren zu können, um ihre eigenen Compliance-Pflichten zu erfüllen. Ein dem Kunden zugängliches Audit-Log ist damit ein direktes Verkaufsargument im gehobenen Segment.
Performance und Aufbewahrung
Audit-Logs wachsen schnell und dürfen die Produktivdatenbank nicht ausbremsen. Schreiben Sie sie asynchron, wo möglich, und trennen Sie sie physisch von den Transaktionsdaten. Definieren Sie eine Aufbewahrungsstrategie, die regulatorische Anforderungen und Speicherkosten ausbalanciert: heisse Daten für den schnellen Zugriff, ältere Einträge in günstigeren Archivspeicher ausgelagert. Achten Sie auf das Spannungsfeld mit der DSGVO — auch Audit-Logs können personenbezogene Daten enthalten und unterliegen damit der Speicherbegrenzung. Definieren Sie deshalb auch für das Audit-Log eine begründete Aufbewahrungsfrist.
Vom Pflichtfeature zum Vertrauensanker
Ein gut gemachtes Audit-Log zahlt auf mehr ein als auf Compliance. Es beschleunigt die Fehlersuche («wer hat das geändert?»), unterstützt den Support, schreckt internen Missbrauch ab und ist im Sicherheitsvorfall die Grundlage der Aufklärung. Vor allem aber signalisiert es Reife: Ein Kunde, der sieht, dass jede relevante Handlung nachvollziehbar protokolliert wird, vertraut dem Produkt eher seine kritischen Prozesse an. Das Audit-Log wird so vom Pflichtfeature zum Vertrauensanker.
Fazit
Bauen Sie das Audit-Log als eigenständiges, geschäftlich lesbares und append-only geführtes System, getrennt von den technischen Application-Logs. Loggen Sie die sicherheits- und geschäftsrelevanten Ereignisse mit vollständigem Kontext inklusive Vorher-Nachher-Werten, sichern Sie die Unveränderlichkeit technisch ab, wahren Sie die Mandantentrennung und machen Sie das Log Ihren Kunden zugänglich. Definieren Sie eine begründete Aufbewahrungsfrist im Einklang mit der DSGVO. Wer das früh anlegt, hat im entscheidenden Moment — Audit, Vorfall oder Enterprise-Deal — die Antwort parat, statt sie mühsam rekonstruieren zu müssen.
Was nicht ins Audit-Log gehört
Ebenso wichtig wie die Frage, was hineingehört, ist die Frage, was draussen bleibt. Loggen Sie niemals Passwörter, vollständige Zahlungsdaten, Sicherheits-Tokens oder andere Geheimnisse — ein Audit-Log, das Zugangsdaten enthält, verwandelt das Sicherheitsfeature in ein Sicherheitsrisiko. Auch sensible Inhalte sollten Sie nur referenzieren, nicht im Klartext mitschreiben. Bei Änderungen an personenbezogenen Daten genügt oft, dass eine Änderung stattfand und durch wen, ohne den vollständigen alten und neuen Wert sensibler Felder zu protokollieren. Diese Zurückhaltung ist nicht nur Datenschutz, sondern reduziert auch die Angriffsfläche des Logs selbst.
Definieren Sie deshalb beim Design des Audit-Logs bewusst eine Negativliste: Welche Felder und Inhalte werden niemals protokolliert? Diese Liste gehört in dieselbe Dokumentation wie die Liste der protokollierten Ereignisse. So entsteht ein Log, das maximale Nachvollziehbarkeit mit minimalem zusätzlichem Risiko verbindet — genau die Balance, die ein Audit-Log zu einem Vertrauens- und nicht zu einem Risikofeature macht.
Planen Sie schliesslich die Auswertbarkeit von Anfang an mit. Ein Audit-Log entfaltet seinen Wert erst, wenn man es im Ernstfall schnell durchsuchen und filtern kann — nach Nutzer, Zeitraum, Ressource oder Aktionstyp. Ein Log, das zwar vollständig, aber praktisch nicht durchsuchbar ist, hilft im Sicherheitsvorfall wenig. Investieren Sie deshalb in eine sinnvolle Struktur und Indizierung, die typische Untersuchungsfragen — wer hat in diesem Zeitraum auf diese Ressource zugegriffen? — in Sekunden beantwortet, statt eine forensische Suche durch Rohdaten zu erfordern.