Audit-Log nach BSI ORP.4: Was wirklich gefordert ist

12. Mai 2026 · Sat-iTec Systemhaus GmbH · 7 Min. Lesezeit

Wer BSI-Grundschutz im KMU umsetzt, stolpert spätestens bei ORP.4 + OPS.1.1.5 über Audit-Logging. Hier zeigen wir, was wirklich gefordert ist — mit konkreten Action-IDs, Aufbewahrungsfristen und Code-Beispielen aus ITscanner.

Was BSI ORP.4 / OPS.1.1.5 wirklich verlangen

Die beiden BSI-Bausteine sind in der Praxis verzahnt:

• ORP.4 — Identitäts- und Berechtigungsmanagement: legt fest, dass Authentifizierungs-Events protokolliert werden müssen — Logins, Logouts, Lockouts, Passwortwechsel.
• OPS.1.1.5 — Protokollierung: legt fest, wie generell mit Logs umzugehen ist — Aufbewahrung, Manipulationsschutz, SIEM-Anbindung.

Die wichtigsten Pflichtfelder pro Log-Eintrag:

1. Zeitstempel — UTC, Millisekunden-Genauigkeit.
2. Akteur — wer hat die Aktion ausgelöst? (User-ID oder Service-ID)
3. Quelle — von wo? (IP-Adresse, Hostname, User-Agent)
4. Kategorie — Auth, Daten, Konfig, …
5. Aktion — was wurde gemacht? (Standardisierte Action-ID)
6. Ziel — woran wurde es gemacht? (Ressource, Pfad, Eintrag-ID)
7. Ergebnis — Erfolg oder Fehlschlag mit Grund

Welche Events müssen geloggt werden — vollständige Liste

30+ Standard-Action-IDs decken ein typisches IT-Audit-Tool ab. ITscanner v2.09 implementiert genau diese Liste.

Aufbewahrungsfrist — wie lange?

BSI-Standard: mindestens 90 Tage, in regulierten Branchen oft länger:

• KMU-Standard-Absicherung: 90 Tage minimum, 365 Tage empfohlen.
• Krankenhäuser (KRITIS): 3 Jahre nach §8a BSIG.
• Banken / Versicherer: 10 Jahre nach §147 AO.
• Steuerrelevante Logs (HGB §257): 6-10 Jahre, je nach Buchhaltungs-Bezug.

ITscanner default = 365 Tage. Lässt sich pro Mandant konfigurieren.

Manipulationsschutz — Hash-Verkettung

OPS.1.1.5 verlangt, dass Logs „vor unbefugter Veränderung geschützt" werden. Das klingt abstrakt — praktisch bedeutet es: Hash-Verkettung (Hash-Chaining).

Wie es funktioniert:

// Jeder Log-Eintrag hat:
//   - timestamp, user, source, action, target, result (die Daten)
//   - prev_hash (SHA-256 des vorherigen Eintrags)
//   - hash (SHA-256 dieser Daten + prev_hash)

func (s *AuditLog) Append(entry *Entry) error {
    last, _ := s.GetLastEntry()
    entry.PrevHash = last.Hash

    data := entry.Serialize()
    h := sha256.Sum256(append([]byte(entry.PrevHash), data...))
    entry.Hash = hex.EncodeToString(h[:])

    return s.DB.Insert(entry)
}

// Verifikation:
func (s *AuditLog) Verify() error {
    entries := s.GetAll()
    var prevHash string
    for _, e := range entries {
        data := e.Serialize()
        expected := sha256.Sum256(append([]byte(prevHash), data...))
        if hex.EncodeToString(expected[:]) != e.Hash {
            return fmt.Errorf("manipulation detected at entry %d", e.ID)
        }
        prevHash = e.Hash
    }
    return nil
}

Wenn jemand einen Eintrag in der Mitte verändert, sind alle nachfolgenden Hashes ungültig. Manipulation ist sofort auffindbar.

SIEM-Forwarding nach Splunk/QRadar/Sentinel

Größere Setups wollen Logs an ein SIEM streamen. ITscanner unterstützt drei Formate:

1. Syslog (RFC 5424)

<134>1 2026-05-12T19:14:02Z itscanner ITSCAN 4832 - -
action=auth.login user=g.loeb src=192.168.5.42 result=ok mfa=totp

Klassiker für Linux-SIEMs, Splunk, Graylog. UDP/TCP/TLS.

2. CEF (Common Event Format)

CEF:0|Sat-iTec|ITscanner|2.09|auth.login|User Login|3|src=192.168.5.42 suser=g.loeb cs1Label=MFA cs1=totp

Standard für ArcSight, IBM QRadar, FortiSIEM.

3. JSON-Webhook

POST https://splunk.example.com/services/collector/event
{
  "time": 1715533042.123,
  "host": "itscanner.example.com",
  "source": "itscanner",
  "sourcetype": "_json",
  "event": {
    "action": "auth.login",
    "user": "g.loeb",
    "src": "192.168.5.42",
    "result": "ok",
    "mfa": "totp"
  }
}

Optimal für Splunk HEC (HTTP Event Collector), Sentinel Data Connector, Datadog.

Was unterlassen werden sollte

1. Logs lokal halten ohne Backup

Wenn ein Angreifer Ihr System kompromittiert, kann er die lokalen Logs löschen. Live-Forward an SIEM oder mindestens stündliches Off-Site-Backup ist Pflicht.

2. Personenbezogene Daten im Log-Body

Nur Account-ID loggen, nicht den Klartext-Namen oder die E-Mail-Adresse. DSGVO Art. 5(1)(c) Datenminimierung. ITscanner separiert das automatisch.

3. Logs nicht regelmäßig auswerten

Audit-Logs zu sammeln und nie reinzuschauen ist sinnlos. Mindestens wöchentlich grep'en oder SIEM-Alerts auf auth.lockout, vault.read, config.change setzen.

Verwandte Beiträge

• MFA mit TOTP selbst hosten
• CVE-Scanner mit CISA KEV
• BSI-Grundschutz-Tool für KMU