Auditierbare Architektur macht relevante Vorgänge nachvollziehbar: Wer oder welcher Dienst hat wann welche Aktion an welchem Objekt ausgeführt, mit welchem Ergebnis und in welchem technischen Kontext? Die Antwort muss belastbar genug für Incident Response, interne Kontrolle, Kundenprüfung oder eine konkrete regulatorische Pflicht sein.
Das bedeutet nicht, jede Zustandsänderung für immer unveränderlich zu speichern. Umfang, Integrität und Aufbewahrung müssen zum Zweck und Risiko passen. Ein zu großer Audit-Trail kann selbst zum Sicherheits- und Datenschutzproblem werden.
Dieser Beitrag beschreibt Architektur- und Sicherheitspraxis, keine Rechtsberatung. Aufbewahrungs- und Nachweispflichten unterscheiden sich je nach Branche, Vertrag, Datenart und Verarbeitung.
Audit-Trail, Security-Log und Observability unterscheiden
Die Begriffe überschneiden sich, lösen aber verschiedene Aufgaben:
| Datentyp | Primärer Zweck | Beispiel |
|---|---|---|
| Audit-Trail | fachliche oder administrative Handlung nachvollziehen | Rolle geändert, Vertrag freigegeben |
| Security-Log | Angriff oder Richtlinienverstoß erkennen und untersuchen | fehlgeschlagener Login, verdächtiger Export |
| Application-Log | technischen Fehler diagnostizieren | Timeout, Exception, Retry |
| Metrik und Trace | Verhalten und Performance eines Systems beobachten | Latenz, Queue-Tiefe, Request-Trace |
Diese Daten können über dieselbe Plattform laufen, sollten aber nicht gedankenlos in dasselbe Schema und dieselbe Aufbewahrung gezwungen werden. Ein Debug-Log hat meist einen kürzeren Nutzen als ein vertraglich geforderter Freigabenachweis. OWASP weist in seinem Logging Cheat Sheet ausdrücklich darauf hin, dass Security-, Prozess-, Audit- und Transaktionslogs unterschiedliche Zwecke und Inhalte haben können.
Mit einer Nachweismatrix beginnen
Bevor ein Event-Schema oder Speicher gewählt wird, sollte das Team pro Nachweis beantworten:
- Welcher konkrete Zweck rechtfertigt die Erfassung?
- Welche Ereignisse müssen dafür erkennbar sein?
- Welche Felder sind erforderlich, welche nur bequem?
- Wer darf die Daten schreiben, lesen und exportieren?
- Wie wird Manipulation erkannt oder verhindert?
- Wie schnell müssen Recherche und Export funktionieren?
- Wann endet der Zweck und wie werden Daten gelöscht?
Eine einfache Matrix verhindert, dass „Compliance“ als unbestimmte Begründung für vollständige Dauerprotokollierung verwendet wird.
| Zweck | Ereignisse | Integritätsbedarf | Aufbewahrung | Freigabe |
|---|---|---|---|---|
| Konto-Sicherheit | Login, MFA-Änderung, Recovery | hoch | risikobasiert definiert | Security-Team |
| Admin-Aktionen | Rollen-, Mandanten- und Exportänderungen | hoch | vertraglich/rechtlich geprüft | Vier-Augen bei Export |
| Fehleranalyse | technische Fehler und Retry | mittel | kurz, rotierend | Engineering |
| Fachlicher Nachweis | Freigabe oder Statuswechsel | abhängig vom Prozess | pro Prozess festgelegt | Process Owner |
Konkrete Zeiträume gehören in die Matrix, aber nicht als pauschale Empfehlung in einen Architekturartikel. Sie müssen aus anwendbaren Pflichten und dokumentiertem Bedarf folgen.
Ein brauchbares Audit-Ereignis entwerfen
Ein Audit-Event sollte genügend Kontext liefern, ohne den gesamten Request oder Datensatz zu kopieren. Typische Felder sind:
- stabile Event-ID,
- Event-Typ und Schema-Version,
- Zeitpunkt aus einer synchronisierten Zeitquelle,
- handelnder menschlicher oder technischer Akteur,
- Mandant und betroffenes Objekt,
- Aktion und Ergebnis,
- Korrelations- oder Trace-ID,
- Quelle, Umgebung und Dienst,
- Grund oder Ticket-Referenz bei besonders sensiblen Aktionen.
Keine Geheimnisse in Logs
Passwörter, Access Tokens, Session-IDs, private Schlüssel und vollständige Zahlungsdaten gehören nicht in Audit-Logs. Auch Gesundheitsdaten, Nachrichteninhalte und andere sensible personenbezogene Daten sollten nicht einfach als Payload kopiert werden.
Oft genügt ein stabiler interner Bezeichner. Hashing oder Pseudonymisierung kann das Risiko reduzieren, macht Daten aber nicht automatisch anonym. Freitextfelder sind besonders riskant, weil Nutzer oder Entwickler dort unkontrolliert personenbezogene Daten und Secrets ablegen können.
Ereignisse als untrusted input behandeln
Ein manipulierter Nutzername mit Zeilenumbruch oder Steuerzeichen darf keine zusätzlichen Logzeilen erzeugen. Validieren, normalisieren und encodieren Sie Event-Daten für das Zielformat. Begrenzen Sie Feldlängen und erlaubte Event-Typen. Auch interne Dienste können fehlerhafte oder kompromittierte Daten senden.
Referenzarchitektur für Audit-Trails
Eine robuste Pipeline besteht typischerweise aus sechs Schichten:
- Producer: Die Anwendung erzeugt ein typisiertes Ereignis an der Stelle, an der die relevante Aktion feststeht.
- Erfassung: Ein gemeinsamer Handler oder Collector validiert Schema, Zeit und Pflichtfelder.
- Transport: Eine Queue oder ein zuverlässiger Versand entkoppelt Anwendung und zentrale Ablage, wenn das Risikomodell dies erlaubt.
- Speicher: Ein zugriffsgeschützter Store nimmt Ereignisse auf und unterstützt Suche sowie definierte Exporte.
- Detektion: Regeln und Alerting erkennen kritische Muster; ein Log ohne Auswertung erfüllt diesen Zweck nicht.
- Lifecycle: Archivierung, Sperrung und Löschung folgen der Nachweismatrix.
Nicht jedes Produkt braucht Kafka, SIEM und WORM-Storage. Eine kleine Anwendung kann mit einer separaten Audit-Tabelle, restriktiven Datenbankrollen, Backups und überwachten Exporten beginnen. Entscheidend ist, dass das Schutzniveau zum Schadenspotenzial passt und getestet wird.
Integrität: mehr als „append-only“
Ein INSERT-only API-Endpunkt beweist nicht, dass niemand mit Datenbank-Adminrechten Einträge verändert. Mögliche Kontrollen sind:
- getrennte Rollen für Anwendung, Betrieb und Audit-Auswertung,
- kein Update/Delete-Recht für den normalen Application-User,
- Kopie in einen getrennten Sicherheitsbereich,
- unveränderbare oder zeitgesperrte Objektspeicherung für begründete Nachweise,
- Hash-Verkettung oder digitale Signaturen zur Manipulationserkennung,
- protokollierter und alarmierter Zugriff auf Audit-Daten,
- regelmäßige Wiederherstellungs- und Integritätstests.
Welche Kombination nötig ist, hängt von Bedrohungsmodell und Nachweisanforderung ab. „Unveränderbar“ darf nicht nur ein Marketinglabel des Speicherprodukts sein; Adminpfade, Backups, Schlüssel und Exportprozess gehören zur Bewertung.
Vollständigkeit und Fehlerverhalten
Der schwierigste Teil ist oft nicht der Speicher, sondern die Frage, ob jedes relevante Geschäftsergebnis genau den erwarteten Audit-Eintrag erzeugt.
Transaktion oder Outbox
Wird der Fachzustand gespeichert, aber der asynchrone Logversand scheitert, entsteht eine Lücke. Eine Transactional-Outbox kann Geschäftsänderung und zu versendendes Event in derselben Datenbanktransaktion festhalten. Ein Worker überträgt das Event anschließend. Verbraucher müssen mit Duplikaten umgehen können; eine stabile Event-ID unterstützt Idempotenz.
Fail open oder fail closed
Was passiert, wenn die Audit-Pipeline nicht erreichbar ist?
- Bei einer administrativen Hochrisiko-Aktion kann ein Abbruch vertretbar sein.
- Bei einer öffentlichen Kernfunktion kann vollständiges Blockieren die Verfügbarkeit gefährden.
Diese Entscheidung gehört ins Bedrohungsmodell. Queue-Grenzen, lokaler Puffer, Alarmierung und kontrollierter Degradationsmodus müssen vor dem Incident definiert sein.
Event Sourcing ist optional
Event Sourcing speichert Domain-Events als führende Zustandsquelle. Das kann vollständige fachliche Historie ermöglichen, bringt aber Versionierung, Projektionen, Replay, Migration und Datenschutzfragen mit sich. Ein Audit-Trail kann unabhängig von Event Sourcing aufgebaut werden. Für viele SaaS-Produkte ist eine normale Zustandsdatenbank plus gezieltes Audit-Log die einfachere Architektur.
DSGVO und Aufbewahrung
Audit-Logs können personenbezogene Daten enthalten, etwa Nutzerkennung, IP-Adresse oder Handlungen. Damit gelten unter anderem die Grundsätze aus Art. 5 DSGVO: Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung sowie Integrität und Vertraulichkeit. Art. 32 verlangt dem Risiko angemessene technische und organisatorische Maßnahmen.
Das führt zu praktischen Anforderungen:
- Zweck und Rechtsgrundlage pro Log-Kategorie dokumentieren,
- nur erforderliche Identifikatoren erfassen,
- Zugriff auf Logs stärker begrenzen als normalen Produktzugriff,
- Export und Einsicht ebenfalls protokollieren,
- feste Review- und Löschprozesse einrichten,
- Backups und abgeleitete SIEM-Daten in den Lifecycle einbeziehen,
- Auskunfts-, Lösch- und Einschränkungsprozesse technisch vorbereiten.
Das Recht auf Löschung aus Art. 17 ist nicht absolut; gesetzliche Aufbewahrung oder Rechtsansprüche können Ausnahmen begründen. Das bedeutet aber nicht, dass alle Audit-Daten unbegrenzt gespeichert werden dürfen.
GoBD nicht auf alle Logs übertragen
Die GoBD betreffen steuerlich relevante Bücher, Aufzeichnungen und Unterlagen. Sie machen nicht jedes Application- oder Security-Log automatisch zu einem aufbewahrungspflichtigen Buchungsbeleg. Wenn ein System steuerlich relevante Vorgänge dokumentiert, sollten Steuerberatung und Verantwortliche den konkreten Datenumfang anhand der aktuellen BMF-Fassung der GoBD festlegen.
Audit und Betrieb testen
Ein Dashboard mit Logzeilen ist noch kein belastbarer Nachweis. Testen Sie regelmäßig:
- Wird jede definierte Hochrisikoaktion erfasst?
- Sind Zeit, Akteur, Objekt, Ergebnis und Korrelation korrekt?
- Entstehen bei Retries Duplikate oder Lücken?
- Kann ein Nutzer Log-Injection auslösen?
- Werden Secrets und unnötige personenbezogene Daten ausgeschlossen?
- Erkennt Monitoring den Ausfall der Pipeline?
- Funktionieren Suche und Export innerhalb der benötigten Zeit?
- Werden Lese- und Exportzugriffe selbst kontrolliert?
- Greifen Löschung und Aufbewahrung auch in Archiv und Backup?
- Lässt sich Integrität nach einem Restore weiterhin prüfen?
Schlanke Einführung für ein Produktteam
- Wählen Sie fünf bis zehn kritische Aktionen statt „alles“.
- Erstellen Sie Nachweismatrix und versioniertes Event-Schema.
- Implementieren Sie einen zentralen Audit-Handler mit Tests.
- Trennen Sie Schreib-, Lese- und Exportrechte.
- Bauen Sie Alarmierung für Ausfall und relevante Security-Events.
- Definieren Sie Aufbewahrung und Löschung vor dem Produktivstart.
- Führen Sie einen Probe-Audit durch: Eine andere Person rekonstruiert einen echten Testfall nur aus den vorgesehenen Nachweisen.
Erst wenn dieser Kern funktioniert, lohnt die Erweiterung auf weitere Prozesse oder auf komplexere Speicher- und SIEM-Strukturen.
Fazit
Auditierbare Architektur ist kein Synonym für Event Sourcing, Data Vault oder unbegrenzte Immutable Logs. Sie ist eine nachweisbare Kette aus bewusst ausgewählten Ereignissen, zuverlässiger Erfassung, geschützter Integrität, kontrolliertem Zugriff und begrenzter Aufbewahrung.
Gute Teams beginnen mit dem Zweck: Welche Frage muss im Incident oder Audit beantwortet werden? Daraus ergeben sich Event, Schutz, Suchbarkeit und Löschzeitpunkt. So entsteht ein Audit-Trail, der Beweise liefert, ohne selbst zur Datenhalde zu werden.
Weiterführend
- Sichere Architektur für SaaS — Threat Modeling, Zugriffskontrolle und Security-by-Design
- Produktionsreife B2B-SaaS — Skalierung und Datenschutz in der Gesamtarchitektur
- Skalierbare Backend-Systeme — Messaging und Betriebsmodelle
- Architecture Sprint — strukturierte Architektur-Review mit festem Umfang
