Audit Logging

Einfach erklärt

Audit Logging protokolliert sicherheitsrelevante Ereignisse – unveränderlich und nachvollziehbar.

Was loggen:

Event	Beispiel
Authentication	Login, Logout, Failed Login
Authorization	Berechtigungsänderungen
Data Access	Wer hat welche Daten gelesen
Admin Actions	Konfigurationsänderungen
Security Events	Blocked Requests, Anomalien

Technischer Deep Dive

Audit Log Format

{
  "timestamp": "<ISO-8601-Zeitstempel>",
  "event_type": "user.login",
  "actor": {
    "user_id": "user-123",
    "ip": "192.168.1.1"
  },
  "action": "login",
  "resource": "auth-service",
  "outcome": "success",
  "metadata": {
    "mfa_used": true
  }
}

Best Practices

Prinzip	Umsetzung
Immutable	Write-once Storage
Centralized	Alle Logs an einem Ort
Structured	JSON, nicht Freitext
Secured	Zugriff nach Need-to-know, rollenbasiert und überwacht

Audit Logs vs. Anwendungs-Logs

Audit Logging ist nicht dasselbe wie normales Logging:

Aspekt	Anwendungs-Log	Audit-Log
Zweck	Debugging, Betrieb	Nachweis, Compliance, Forensik
Zielgruppe	Entwickler, Ops	Auditoren, Security, Rechtsabteilung
Veränderbarkeit	Rotation, Löschung üblich	Unveränderlich, manipulationssicher
Inhalt	Technische Details, Stack Traces	Wer, was, wann, worauf, Ergebnis
Aufbewahrung	Kurz (Tage bis Wochen)	Lang, nach Policy und Rechtslage

Ein häufiger Fehler ist, beides zu vermischen: Audit-Events verschwinden dann in der Masse der Debug-Ausgaben und unterliegen denselben kurzen Rotationszyklen.

Audit Logging für KI-Agenten und LLM-Anwendungen

Sobald KI-Systeme eigenständig handeln, wird Nachvollziehbarkeit zur Kernanforderung:

• Agenten-Aktionen protokollieren: Wenn ein KI-Agent Tools aufruft, Daten liest oder Änderungen vornimmt, muss jeder Schritt auditierbar sein – inklusive der Frage, welcher Nutzer oder welches Ereignis den Agenten ausgelöst hat.
• Prompt- und Antwort-Trails: Für kritische Anwendungen sollte nachvollziehbar sein, welche Eingaben zu welcher Modellausgabe geführt haben – etwa um Fehlentscheidungen oder Prompt-Injection-Vorfälle zu rekonstruieren.
• Attribution über die Kette: Bei Agenten, die andere Dienste aufrufen, braucht es eine durchgängige Korrelation (z. B. Trace-IDs), damit sich eine Aktion vom auslösenden Menschen bis zur ausgeführten Operation zurückverfolgen lässt.
• Vorsicht mit sensiblen Inhalten: Prompts können personenbezogene Daten enthalten. Audit-Logs von LLM-Anwendungen brauchen deshalb Redaction-Mechanismen und klare Retention-Regeln – Nachvollziehbarkeit darf nicht zum Datenschutzproblem werden.
• Regulatorischer Rückenwind: Der EU AI Act verlangt für Hochrisiko-KI-Systeme automatische Aufzeichnungen (“Logging-Fähigkeiten”) über den Betrieb – Audit Logging wird damit für viele KI-Anwendungen zur Pflicht.

Typische Stolperfallen

Fehler	Folge	Besser
Sensible Daten im Log	Log wird selbst zum Sicherheitsrisiko	Redaction, Pseudonymisierung
Logs nur lokal gespeichert	Angreifer löscht Spuren mit	Zentraler, schreibgeschützter Log-Speicher
Kein Monitoring der Logs	Vorfälle werden erst spät entdeckt	Alerting auf verdächtige Muster
Uhrzeiten nicht synchron	Ereignisse lassen sich nicht korrelieren	NTP, einheitliche Zeitzone (UTC)
Unbegrenzte Aufbewahrung	Datenschutz- und Kostenproblem	Dokumentierte Retention- und Löschregeln

Abgrenzung zu verwandten Begriffen

• Observability (Metriken, Traces, Logs) dient dem Systemverständnis im Betrieb – Audit Logging dem rechtssicheren Nachweis von Handlungen.
• SIEM-Systeme werten Audit- und Sicherheits-Logs zentral aus und erkennen Angriffsmuster.
• Compliance-Standards wie SOC 2 und ISO 27001 fordern Audit Logging als Kontrolle – das Log ist der Nachweis, dass andere Kontrollen funktionieren.