Security Logging in der Praxis: Was Sie protokollieren, wie Sie Audit-Logs schützen und wie lange Sie sie aufbewahren

Security Logging beginnt mit einer Frage, die viele Teams nie ausdrücklich beantworten: Welche Fragen müssen Ihre Protokolle nach einem Sicherheitsvorfall beantworten können? Wer hat sich von wo angemeldet, wer hat sich selbst Admin-Rechte gegeben, welche Datensätze hat ein Konto gelesen, bevor es gesperrt wurde, welche Konfigurationsänderung hat einen Port in der Firewall geöffnet? Können Ihre Logs das nicht zuverlässig, vollständig und mit vertrauenswürdigen Zeitstempeln beantworten, sind sie Betriebsrauschen und keine Sicherheitsmaßnahme.

Dieser Leitfaden ist eine praxisnahe, herstellerneutrale Referenz für Engineering- und Security-Teams. Er zeigt, welche Ereignisse Sie protokollieren sollten, was in einen Audit-Log-Eintrag gehört, warum strukturiertes Logging wichtig ist, wie Sie Logs schützen, wie Sie personenbezogene Daten nach DSGVO behandeln und wie Sie eine Log-Aufbewahrung festlegen, die einer Prüfung standhält. Am Ende finden Sie eine Tabelle zum Anpassen und eine Checkliste zum Kopieren.

Welche Ereignisse Sie protokollieren sollten

Security Logging heißt nicht, alles im Debug-Level mitzuschreiben. Es ist eine bewusste Auswahl der Ereignisse, die für Erkennung, Aufklärung und Nachvollziehbarkeit zählen. Sechs Kategorien decken den Großteil ab:

• Authentifizierung: erfolgreiche und fehlgeschlagene Anmeldungen, Abmeldungen, MFA-Abfragen und -Fehler, Passwort-Resets, Ausstellung und Erneuerung von Tokens, Sitzungsabbrüche, Kontosperrungen.
• Änderungen an Berechtigungen: Rollen- und Gruppenzuweisungen, Vergabe und Entzug von Rechten, neue API-Schlüssel und Service-Accounts, Änderungen an Zugriffsrichtlinien.
• Administrative Aktionen: Anlegen und Löschen von Benutzern, Impersonation („Anmelden als“), Notfallzugänge, Änderungen über Admin-Oberflächen oder privilegierte CLIs.
• Datenzugriffe: Lesen und Exportieren sensibler Datensätze, Massenabfragen, Downloads, Zugriffe auf personenbezogene Daten oder Secrets – zumindest für besonders schützenswerte Datenbestände.
• Konfigurationsänderungen: Infrastruktur- und Anwendungskonfiguration, sicherheitsrelevante Feature-Flags, Firewall- und Netzwerkregeln sowie Änderungen an der Protokollierung selbst – das Abschalten eines Audit-Logs ist ein eigenes Ereignis.
• Sicherheitsrelevante Fehler: fehlgeschlagene Eingabevalidierung, abgelehnte Tokens, Signatur- oder Zertifikatsfehler, Rate-Limit-Treffer, Access-Denied-Antworten, unerwartete Ausnahmen im Authentifizierungscode.

Zwei Regeln halten die Liste beherrschbar. Erstens: Protokollieren Sie Fehlschläge genauso sorgfältig wie Erfolge. Eine Häufung fehlgeschlagener Anmeldungen oder verweigerter Zugriffe ist oft das früheste Signal eines Angriffs. Zweitens: Trennen Sie Sicherheitsereignisse von Debug-Ausgaben der Anwendung. Nutzen Sie eine eigene Ereigniskategorie und eine klare Richtlinie für das Log-Level, damit das Abschalten von Debug-Logs in Produktion nie unbemerkt Audit-Ereignisse entfernt.

Was in einen Audit-Log-Eintrag gehört

Ein Audit-Log-Eintrag sollte es einer unbeteiligten Person ermöglichen, den Vorgang zu rekonstruieren. Dafür braucht jedes Ereignis dieselben Kernfelder, unabhängig vom erzeugenden Dienst:

• Wer: der Akteur als stabile Benutzer- oder Service-ID (nicht nur ein Anzeigename), dazu die Authentifizierungsmethode und gegebenenfalls die handelnde oder delegierende Identität.
• Was: die Aktion als festes Vokabular (etwa user.role.granted), Typ und ID der betroffenen Ressource und bei Änderungen der alte und neue Wert oder ein Verweis darauf.
• Wann: ein UTC-Zeitstempel mit Millisekunden aus einer synchronisierten Uhr. Ohne Zeitsynchronisation wird die Korrelation über Systeme hinweg zum Ratespiel.
• Wo: Quell-IP-Adresse oder Netzwerkzone, Dienstname, Host oder Pod, Umgebung und Region.
• Ergebnis: erfolgreich, fehlgeschlagen oder verweigert, bei Fehlern mit Grundcode.
• Korrelation: eine Request-ID oder Trace-ID, die das Audit-Ereignis mit Traces und Anwendungslogs derselben Anfrage verbindet.

Das Korrelationsfeld fehlt am häufigsten – und spart bei der Aufklärung die meiste Zeit. Mit OpenTelemetry lässt sich der aktive Trace-Kontext automatisch an jeden Log-Eintrag hängen. So springen Analysten von „Admin hat MFA für Benutzer X deaktiviert“ direkt zur konkreten Anfrage, zu den nachgelagerten Aufrufen und zu Fehlern im Umfeld.

Strukturiertes Logging für Sicherheitsereignisse

Freitext-Logzeilen sind schwer abzufragen und fehleranfällig. Strukturiertes Logging bedeutet, Ereignisse als Schlüssel-Wert-Datensätze mit stabilem Schema auszugeben. Dann ist „alle fehlgeschlagenen Admin-Anmeldungen von außerhalb der EU in den letzten 30 Tagen“ eine Abfrage und kein Projekt für reguläre Ausdrücke. Ein minimales Audit-Ereignis könnte so aussehen (Beispielwerte):

{
  "timestamp": "2026-10-21T08:14:03.512Z",
  "event.category": "audit",
  "event.action": "user.role.granted",
  "event.outcome": "success",
  "actor.id": "usr_4821",
  "actor.auth_method": "sso+mfa",
  "target.type": "user",
  "target.id": "usr_9907",
  "change.role.new": "billing-admin",
  "source.ip": "203.0.113.24",
  "service.name": "admin-api",
  "deployment.environment": "production",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736"
}

Legen Sie die Feldnamen einmal fest und setzen Sie sie in einer gemeinsamen Bibliothek oder in der Telemetrie-Pipeline durch. Wo die OpenTelemetry Semantic Conventions ein Attribut definieren, verwenden Sie es; für Audit-spezifische Felder dokumentieren Sie eigene Namen. Versionieren Sie das Schema, damit Änderungen keine Erkennungsregeln brechen.

Logs schützen: Integrität, Zugriff und Trennung

Angreifer mit privilegiertem Zugriff versuchen häufig, Protokolle zu löschen oder zu verändern. Ein Audit-Log, das das kompromittierte System selbst umschreiben kann, ist ein schwacher Nachweis. Vier Maßnahmen machen Logs vertrauenswürdig:

• Logs schnell vom Host wegschicken: Leiten Sie Ereignisse nahezu in Echtzeit an einen zentralen Speicher weiter, statt sie nur auf der erzeugenden Maschine zu halten. Log-Aggregation ist eine Sicherheitsmaßnahme, nicht nur Komfort.
• Speicher und Rechte trennen: Legen Sie Audit-Logs in einem eigenen Account, Projekt oder Mandanten ab. Wer Produktionssysteme administriert, darf den eigenen Audit-Trail nicht löschen können.
• Manipulation erkennbar machen: Nutzen Sie Append-only- oder WORM-Speicher, Object Locks, Hash-Ketten oder signierte Batches, damit Änderungen und Lücken auffallen.
• Zugriff auf Logs steuern und protokollieren: Schon das Lesen von Audit-Logs ist sensibel und sollte rollenbasiert erfolgen und selbst protokolliert werden. Verschlüsseln Sie Logs bei der Übertragung und im Ruhezustand.

Überwachen Sie außerdem die Logging-Pipeline selbst. Eine Quelle, die plötzlich keine Ereignisse mehr sendet, ist entweder defekt oder wurde gezielt zum Schweigen gebracht – beides verdient einen Alarm.

Personenbezogene Daten in Logs und die DSGVO

Sicherheitsprotokolle enthalten fast immer personenbezogene Daten: Benutzer-IDs, IP-Adressen, E-Mail-Adressen, manchmal Anfrageinhalte. Die DSGVO verbietet das nicht, ihre Grundsätze gelten aber vollständig. Art. 5 Abs. 1 DSGVO verlangt unter anderem, dass Daten für festgelegte Zwecke erhoben (Zweckbindung), auf das notwendige Maß beschränkt (Datenminimierung) und nicht länger als nötig in identifizierbarer Form gespeichert werden (Speicherbegrenzung). Art. 32 DSGVO nennt Pseudonymisierung und Verschlüsselung als mögliche Sicherheitsmaßnahmen.

Daraus ergeben sich einige technische Regeln:

• Keine Secrets und keine unnötigen Inhalte: Passwörter, Tokens, Session-Cookies, vollständige Kartennummern, Gesundheitsdaten oder Freitext-Nachrichten gehören nicht in Logs.
• Beim Ingest maskieren oder pseudonymisieren: Ersetzen Sie E-Mail-Adressen und Namen durch stabile pseudonyme IDs, kürzen oder hashen Sie IP-Adressen, wo der volle Wert nicht nötig ist, und entfernen Sie bekannte sensible Felder, bevor die Daten in den Langzeitspeicher gelangen.
• Zweck dokumentieren: Halten Sie im Verzeichnis von Verarbeitungstätigkeiten fest, wozu jede Log-Kategorie dient (etwa Erkennung und Aufklärung von Sicherheitsvorfällen), und nutzen Sie Sicherheitslogs nicht für fremde Zwecke wie Leistungskontrolle von Beschäftigten.
• Planmäßig löschen: Setzen Sie Aufbewahrungsfristen je Kategorie automatisch durch und stellen Sie sicher, dass Backups und Exporte denselben Regeln folgen.

Binden Sie Ihren Datenschutzbeauftragten früh ein. Da Audit-Logs grundsätzlich geeignet sein können, Verhalten von Beschäftigten zu überwachen, hat in vielen Unternehmen auch der Betriebsrat ein Mitbestimmungsrecht.

Log-Aufbewahrung: Frist ableiten statt raten

Die häufigste Frage zu Audit-Logs lautet: Wie lange müssen wir sie aufbewahren? Die ehrliche Antwort: Es gibt keine einheitliche gesetzliche Regel, nach der Sicherheitslogs X Tage aufzubewahren sind. Sie leiten die Datenaufbewahrung je Log-Kategorie aus drei Eingangsgrößen ab und dokumentieren die Begründung.

1. Zweck

Fragen Sie, wie lange das Log für seinen Zweck tatsächlich gebraucht wird. Für die Aufklärung von Vorfällen ist ein sinnvoller Bezugspunkt, wie lange Angriffe in Ihrer Umgebung typischerweise unentdeckt bleiben und wie weit eine Untersuchung zurückblicken müsste. Für die Fehlersuche reichen oft wenige Tage bis Wochen. Nach dem Grundsatz der Speicherbegrenzung setzt der Zweck die Obergrenze für identifizierbare Daten.

2. Rechtliche Pflichten

Manche Gesetze schreiben die Aufbewahrung bestimmter Unterlagen vor. § 257 HGB und § 147 AO regeln etwa Fristen für Geschäftsunterlagen: zehn Jahre für Handelsbücher und Jahresabschlüsse, acht Jahre für Buchungsbelege, sechs Jahre für Handels- und Geschäftsbriefe. Diese Pflichten betreffen Geschäftsunterlagen – etwa eine Rechnung im Abrechnungssystem –, nicht technische Logs als solche. Ein Webserver-Zugriffslog ist in aller Regel keine Geschäftsunterlage und erbt keine zehnjährige Frist, nur weil das Unternehmen dem HGB unterliegt. Branchenregeln (Finanzen, Gesundheit, Telekommunikation) können eigene Anforderungen enthalten; prüfen Sie, was für Sie gilt.

3. Rahmenwerke und Regulierung

• ISO/IEC 27001:2022 enthält in Anhang A die Controls 8.15 Protokollierung (Logging) und 8.16 Überwachungstätigkeiten (Monitoring activities). 8.15 betrifft Erzeugung, Speicherung, Schutz und Auswertung von Protokollen über Aktivitäten, Ausnahmen, Fehler und andere relevante Ereignisse, 8.16 die Überwachung auf anomales Verhalten. Eine feste Aufbewahrungsfrist schreibt die Norm nicht vor; Sie legen sie risikobasiert in Ihrem ISMS fest.
• NIS2 (Richtlinie (EU) 2022/2555) verlangt in Art. 21 geeignete und verhältnismäßige Risikomanagementmaßnahmen, darunter die Bewältigung von Sicherheitsvorfällen. Für bestimmte digitale Dienste ergänzt die Durchführungsverordnung (EU) 2024/2690, dass Logs für einen vorab festgelegten Zeitraum aufzubewahren, zu sichern und vor unbefugtem Zugriff oder Änderungen zu schützen sind – ebenfalls ohne feste Zahl. Details finden Sie in unserem Beitrag zu den NIS2-Monitoring-Anforderungen.
• BSI IT-Grundschutz, Baustein OPS.1.1.5 Protokollierung, fordert eine Sicherheitsrichtlinie für die Protokollierung, die regelt, wie, wo und was protokolliert wird, eine Zeitsynchronisation der protokollierenden Systeme und – vor allem in größeren Informationsverbünden – eine zentrale Protokollierungsinfrastruktur. Prüfen Sie die genauen Anforderungen in der aktuellen Edition des Kompendiums.

Aus diesen Eingangsgrößen entstehen typischerweise Stufen: ein kurzer Zeitraum mit vollem Detail für den Betrieb, ein längerer für sicherheitsrelevante Ereignisse und eine Langzeitaufbewahrung nur für den engen Kreis von Datensätzen mit Rechtsgrundlage, idealerweise pseudonymisiert.

Referenztabelle: Ereignistypen, Felder und Begründung der Aufbewahrung

Nutzen Sie die Tabelle als Ausgangspunkt für Ihre Protokollierungsrichtlinie. Die letzte Spalte zeigt die zu dokumentierende Begründung, keine gesetzliche Vorgabe.

Ereignistyp	Zu protokollierende Felder	Sensibilität	Typische Begründung der Aufbewahrung
Authentifizierung (Anmeldung, MFA, Abmeldung, Sperre)	Akteur-ID, Methode, Ergebnis, Grund, Quell-IP, User-Agent, Trace-ID	Mittel bis hoch (IP, Benutzer-ID)	Lang genug, um Kontoübernahmen über das erwartete Erkennungsfenster aufzuklären
Berechtigungsänderungen (Rollen, Rechte, API-Schlüssel)	Akteur, Zielidentität, alte und neue Berechtigung, Genehmiger, Ergebnis	Hoch	Dauer des Zugriffs plus Untersuchungsfenster; Nachweis für Rezertifizierungen und Audits
Admin-Aktionen und Notfallzugänge	Akteur, handelnde Identität, Aktion, Ziel, Begründung oder Ticket-ID	Hoch	Nachvollziehbarkeit privilegierter Nutzung; abgestimmt auf die Auditzyklen des ISMS
Datenzugriffe und Exporte	Akteur, Datenbestand, Anzahl Datensätze, Abfrage- oder Filterverweis, Ergebnis	Hoch (kann personenbezogene Daten offenlegen)	Eingrenzung von Datenschutzverletzungen, nötig zur Bewertung von Meldepflichten
Konfigurationsänderungen	Akteur, Komponente, Diff oder Change-Verweis, Deployment-ID, Ergebnis	Mittel	Ursachenanalyse und Nachweis im Change-Management
Sicherheitsrelevante Fehler (verweigert, ungültiges Token, Rate-Limit)	Quelle, Endpunkt, Fehlercode, Akteur falls bekannt, Trace-ID	Mittel	Erkennung von Angriffsmustern; nach Aggregation oft kürzere Frist ausreichend
Debug- und Zugriffslogs der Anwendung	Request-Metadaten, Latenz, Statuscode, Trace-ID	Gering bis mittel	Nur Fehlersuche; kurz halten und personenbezogene Daten minimieren

Checkliste Security Logging zum Kopieren

Übernehmen Sie diese Checkliste in Ihr Wiki oder Ticketsystem und gehen Sie sie gemeinsam mit Engineering, Security und Datenschutz durch:

CHECKLISTE SECURITY LOGGING
[ ] Protokollierungsrichtlinie vorhanden: was, wie, wo, Verantwortliche, Prüftermin
[ ] Ereigniskatalog umfasst Authentifizierung, Rechteänderungen,
    Admin-Aktionen, Datenzugriffe, Konfigurationsänderungen, Sicherheitsfehler
[ ] Fehlschläge und Verweigerungen werden protokolliert, nicht nur Erfolge
[ ] Jedes Audit-Ereignis enthält: wer, was, wann (UTC), wo, Ergebnis, Trace-ID
[ ] Strukturiertes Format mit dokumentiertem, versioniertem Schema
[ ] Alle Systeme nutzen synchronisierte Uhren (NTP)
[ ] Ereignisse verlassen den Quell-Host nahezu in Echtzeit
[ ] Audit-Logs getrennt gespeichert; Admins können eigenen Trail nicht löschen
[ ] Append-only-/WORM-Speicher oder Hash-Ketten zur Manipulationserkennung
[ ] Verschlüsselung bei Übertragung und Speicherung; rollenbasierter Lesezugriff, protokolliert
[ ] Alarm, wenn eine Log-Quelle keine Ereignisse mehr sendet
[ ] Keine Secrets, Passwörter, Tokens oder unnötigen Inhalte in Logs
[ ] Personenbezogene Daten vor der Langzeitspeicherung maskiert oder pseudonymisiert
[ ] Zweck je Log-Kategorie dokumentiert (Verzeichnis von Verarbeitungstätigkeiten)
[ ] Aufbewahrungsfrist je Kategorie mit dokumentierter Begründung
[ ] Automatische Löschung, auch in Backups und Exporten
[ ] Erkennungsregeln und Dashboards mit Beispielereignissen getestet
[ ] Richtlinie mindestens jährlich und nach größeren Vorfällen überprüft

Wie Obseria beim Security Logging unterstützt

Obseria ist eine OpenTelemetry-native Observability-Plattform mit Datenhaltung in der EU. Sie ersetzt weder Ihr ISMS noch Ihre rechtliche Bewertung, liefert aber die technischen Bausteine für die oben beschriebenen Praktiken: strukturierte, mit Traces korrelierte Logs, Verarbeitung vor der Speicherung und je Datenstrom konfigurierbare Aufbewahrung. Mehr dazu unter Log Analytics und im Use Case Sicherheit und Zuverlässigkeit.

• Obseria Pipeline filtert, maskiert personenbezogene Daten und routet Ereignisse, bevor sie gespeichert werden – Datenminimierung direkt beim Ingest.
• Obseria Lake speichert Logs, Metriken, Traces und Events ohne Indizes und macht längere Aufbewahrung für sicherheitsrelevante Datenströme bezahlbar.
• Trace-Korrelation verbindet Audit-Ereignisse mit den Anfragen, Diensten und Fehlern in ihrem Umfeld.
• Anomalie-Erkennung und Alerting melden ungewöhnliche Muster wie gehäufte Fehlanmeldungen oder verstummte Log-Quellen.

Sie möchten sehen, wie Ihre Audit-Ereignisse als strukturierte, korrelierte Daten aussehen? Testen Sie Obseria kostenlos und binden Sie Ihre erste OpenTelemetry-Quelle in wenigen Minuten an.