„Zeigen Sie mir März.“ – Anmeldeprotokolle, die einem Prüfer standhalten

Das Windows-Sicherheitsprotokoll überschreibt sich nach Tagen, liegt auf jedem Server einzeln und lässt sich von jedem Administrator löschen. Für NIS2, ISO 27001 und den IT-Grundschutz reicht das nicht. Dieser Beitrag zeigt, wie man Anmeldungen aus vielen Domänen und einzelnen Servern so sammelt, dass man sie ein Jahr später vorlegen kann – und was dabei in der Praxis schiefgeht.

Das Problem: Protokollieren ist nicht Nachweisen

Jeder Windows-Server protokolliert Anmeldungen von selbst: 4624 bei Erfolg, 4625 bei Fehlversuch, 4771 und 4776 auf dem Domänencontroller für Kerberos und NTLM, 4740 bei Kontosperrung. Das Problem ist nicht das Protokollieren, sondern alles danach.

Die Anforderungen dahinter sind konkret: NIS2 Art. 21 Abs. 2 verlangt Verfahren zur Erkennung und Bewältigung von Sicherheitsvorfällen und damit die Protokolle, aus denen Vorfälle erkennbar sind. Der IT-Grundschutz-Baustein OPS.1.1.5 (Protokollierung) fordert zentrale Sammlung, Schutz vor Manipulation und definierte Aufbewahrung; DER.1 die Auswertung. ISO 27001 A.8.15 verlangt, dass Protokolle erzeugt, gespeichert, geschützt und analysiert werden. In allen drei Fällen steht „geschützt“ – und genau das kann das Bordmittel nicht.

Die Umsetzung: eine Zentrale, zwei Wege zur Quelle

Der ISW Logon Sentinel sammelt Anmeldeereignisse von beliebig vielen Windows-Servern an einer Zentrale, versiegelt sie täglich und bewahrt sie für eine einstellbare Frist auf. Die Zentrale ist ein Windows-Dienst mit SQLite oder SQL Server als Ablage; die Konsole läuft auf beliebig vielen Arbeitsplätzen.

Weg 1: der Agent

Ein Dienst auf dem Server liest das Sicherheitsprotokoll fortlaufend mit und meldet signiert an die Zentrale – ausgehend per HTTPS, kein offener Port auf dem Quellserver, keine Vertrauensstellung zwischen den Domänen. Der Agent läuft auf Domänencontrollern, Mitgliedsservern, Terminalservern und Servern außerhalb jeder Domäne. Er puffert bis 2 GB, wenn die Zentrale nicht erreichbar ist, und nummeriert jedes Paket fortlaufend. Die Installation ist ein Aufruf ohne Parameter: eine vorgaben.json mit Adresse, Zertifikat-Fingerabdruck und Mandant neben die Programmdatei legen, install ausführen.

{
  "CollectorUrl": "https://sentinel.beispiel.de:8443",
  "PinnedServerThumbprint": "E73C501F…",
  "Tenant": "Kunde17"
}

& ".\ISW Logon Sentinel Agent.exe" install

Weg 2: WinRM ohne Dienst

Soll auf einem System nichts installiert werden, holt die Zentrale das Sicherheitsprotokoll per WinRM selbst ab – alle fünf Minuten, bis zu 32 Ziele parallel. Das Konto braucht auf dem Ziel nur die Gruppe „Ereignisprotokollleser“ und WinRM-Zugriff, keinen Administrator. In der eigenen Domäne läuft das über Kerberos ohne Kennwort; außerhalb mit einem lokalen Konto über NTLM – dann gehört SSL auf 5986 mit Zertifikat dazu.

Das Archiv: Hash-Kette und Versiegelung

Jedes Ereignis wird mit Roh-XML und SHA-256 in eine Tagesdatei je Mandant und Domäne geschrieben; jeder Hash schließt den vorherigen ein. Um Mitternacht wird die Datei versiegelt und gepackt. Wer nachträglich eine Zeile entfernt oder ändert, bricht die Kette – und die Zentrale prüft die Ketten täglich. Die Datenbank hält die Ereignisse zusätzlich für die Datenbankfrist (Dashboards, Suche, Berichte); das Archiv für die Aufbewahrungsfrist. Beides setzt der Betreiber, freigegeben vom Datenschutzbeauftragten, und jede Löschung nach Frist steht im Löschprotokoll.

Was ein Prüfer bekommt

Fallstricke aus der Praxis

Ein Hoster hat das Werkzeug an mehreren hundert Servern eingeführt – Domänencontroller, Terminalserver, Server in Kundendomänen, Dutzende außerhalb jeder Domäne. Das meiste davon lief sofort. Vier Dinge nicht, und alle vier gehören in jede Einführung:

1. Leserecht ist nicht gleich Leserecht

Auf Dutzenden Servern konnte das Abholkonto sich per WinRM anmelden, das Sicherheitsprotokoll aber nicht lesen. Auf Arbeitsgruppen-Servern greift keine Gruppenrichtlinie – die lokale Gruppe „Ereignisprotokollleser“ muss je Server gefüllt werden. Und auf manchen Domänencontrollern scheitert Get-WinEvent -LogName Security für dieses Konto an den Protokolleigenschaften, während wevtutil dieselben Ereignisse liefert. Der Logon Sentinel liest seit 2.2 beide Wege.

# auf einem Server außerhalb der Domäne, als Administrator
Add-LocalGroupMember -Group "Ereignisprotokollleser" -Member "Abholkonto"
auditpol /set /subcategory:{0CCE9215-69AE-11D9-BED3-505054503030} /success:enable /failure:enable

2. Mitgliedsserver protokollieren Fehlversuche oft nicht

Die Vorgabe für „Anmelden überwachen“ auf Mitgliedsservern ist häufig nur Erfolg. Ein Terminalserver liefert dann 4624, aber kein 4625 – und Fehlversuche mit Domänenkonten per Kerberos entstehen ohnehin nur auf dem DC. Für das volle Bild gehört je Domäne der DC dazu, und die Überwachungsrichtlinie gehört per GPO auf „Erfolg und Fehler“. Der Verbindungstest der Zentrale zeigt die Richtlinie je Ziel; prüfen lässt sie sich sprachunabhängig über die GUID:

auditpol /get /subcategory:{0CCE9215-69AE-11D9-BED3-505054503030}

3. Ein Zertifikatswechsel an der Zentrale ist ein Rollout

Agenten und Konsole heften beim ersten Verbinden den Fingerabdruck des Zentralen-Zertifikats an und akzeptieren danach nur dieses – strenger als eine Vertrauenskette, und bewusst so, weil eigenständige Kundendomänen der eigenen PKI ohnehin nicht vertrauen. Die Kehrseite: Wird das Zertifikat erneuert oder versehentlich gelöscht, erzeugt die Zentrale zwar ein neues und läuft weiter, aber jeder Agent verweigert die Verbindung und puffert. Ein Zertifikatswechsel ist deshalb kein Klick, sondern ein geplanter Vorgang: neues Zertifikat binden, Fingerabdruck per Gruppenrichtlinie oder config --thumbprint an alle Agenten verteilen, Konsole neu anheften. Wer das Zertifikat der PKI vor Ablauf verlängert und den Fingerabdruck im selben Zug ausrollt, merkt nichts; wer es im laufenden Betrieb verliert, hat bis zum Rollout eine Lücke – die der Puffer der Agenten zwar überbrückt, aber nur bis 2 GB.

# Fingerabdruck zentral per GPO (Registrierung) an alle Agenten
HKLM\SOFTWARE\Policies\ISW\LogonSentinel\PinnedServerThumbprint = "<neuer Fingerabdruck>"

4. Nichts liefern und nichts melden sind zwei Zustände

Der eigentliche Fehler war nicht das Leserecht, sondern dass das Werkzeug „0 Ereignisse“ meldete, wo es „Zugriff verweigert“ hätte sagen müssen – und der Verbindungstest dazu „Null ist kein Fehler“. Wochenlang. Seit 2.2 sagt der Test jedem Ziel, was fehlt: Leserecht, Überwachungsrichtlinie, Rolle (nur DCs zählen in der Abdeckung), Uhrabweichung. Ein Ziel, das nichts liefern kann, ist rot.

Fazit

Anmeldeprotokolle hat jeder. Vorlegen kann sie fast niemand – weil das Bordmittel vergisst, verstreut ist und sich löschen lässt. Eine zentrale Ablage mit Hash-Kette, Vollständigkeitsnachweis und Löschprotokoll macht aus dem Protokoll einen Beleg. Und sie muss laut werden, wenn eine Quelle schweigt. Wer Firewall, Proxy und Anwendungen korrelieren will, braucht ein SIEM. Wer belegen muss, dass die Anmeldeprotokollierung über zwölf Monate lückenlos war, braucht genau das hier.

Quellen: BSI IT-Grundschutz-Kompendium Edition 2023, Bausteine OPS.1.1.5 Protokollierung und DER.1 Detektion von sicherheitsrelevanten Ereignissen; Richtlinie (EU) 2022/2555 (NIS2) Art. 21; ISO/IEC 27001:2022 Anhang A.8.15 Logging; ISW Logon Sentinel Anwenderhandbuch 2.2.1.