NIS2-Protokollierung: was zu protokollieren ist, wie lange Protokolle aufzubewahren sind und wie man sie auswertet

NIS2-Protokollierung: die Anforderungen im Überblick

Die Anforderungen an die NIS2-Protokollierung stehen in Anhang, Nummer 3.2 der Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024. Die Verordnung konkretisiert die Bewältigung von Sicherheitsvorfällen, die Artikel 21 Absatz 2 Buchstabe b der NIS2-Richtlinie, der Richtlinie (EU) 2022/2555, nennt, ohne Protokolle zu erwähnen. Nummer 3.2 verlangt Verfahren und Instrumente zur Überwachung und Protokollierung von Aktivitäten, eine Liste der zu protokollierenden Anlagen und Werte auf Grundlage der Risikobewertung, die regelmäßige Überprüfung der Protokolle, Alarmschwellen soweit angemessen und eine zeitnahe Reaktion auf Alarme. Protokolle werden „für einen vorab festgelegten Zeitraum“ geführt und gesichert und vor unbefugten Zugriffen oder Änderungen geschützt. Die Zeitquellen werden synchronisiert, soweit durchführbar, und die Systeme für Überwachung und Protokollierung sind redundant.

Weder Artikel 21 noch Nummer 3.2 legt eine Zahl von Tagen fest; die Aufbewahrungsfrist ist daher eine Entscheidung, die das Unternehmen trifft und dokumentiert. Die am 26. Juni 2025 veröffentlichte Technical Implementation Guidance der ENISA knüpft sie an „geschäftliche Erfordernisse, die Ergebnisse der Risikobewertung und rechtliche Anforderungen/Pflichten“. Im Folgenden wird jede Nummer auf eine Umgebung mit 10 bis 60 VMware-Hosts und 500 bis 2.000 VMs übertragen; die zehn Maßnahmen insgesamt behandelt unser Leitfaden zu NIS2 Artikel 21.

Durchführungsverordnung 2024/2690 Nummer 3.2: Geltungsbereich und Wortlaut

Die Verordnung bindet nur die „betreffenden Einrichtungen“ ihres Artikels 1, digitale Anbieter wie DNS-Diensteanbieter, Anbieter von Cloud-Computing-Diensten, Anbieter von Rechenzentrumsdiensten, Anbieter verwalteter Dienste und Anbieter verwalteter Sicherheitsdienste. Die Leitlinie der ENISA sagt, ihre Hinweise könnten „von anderen öffentlichen oder privaten Stellen als nützlich für die Verbesserung ihrer Cybersicherheit angesehen werden“; andere Unternehmen können Nummer 3.2 daher als Referenz nutzen. Ob NIS2 für ein Unternehmen gilt, ist eine rechtliche Bewertung für seine Rechtsabteilung.

Nummer 3.2.1 verlangt Verfahren und Instrumente, „um Aktivitäten in ihrem Netz- und Informationssystem zu überwachen und zu protokollieren, damit sie Ereignisse, die als Sicherheitsvorfälle betrachtet werden könnten, erkennen“. Nach Nummer 3.2.2 erfolgt die Überwachung automatisch, soweit durchführbar, wird „vorbehaltlich der betrieblichen Kapazitäten entweder kontinuierlich oder in regelmäßigen Zeitabständen durchgeführt“ und soll möglichst wenige falsch positive und falsch negative Ergebnisse liefern.

Wendet eine betreffende Einrichtung eine Anforderung nicht an, die nur „soweit angemessen“, „soweit anwendbar“ oder „soweit durchführbar“ gilt, muss sie ihre Begründung nach Artikel 2 Absatz 2 „in verständlicher Weise dokumentieren“.

Was nach Nummer 3.2.3 zu protokollieren ist, nach Log-Quellen

Nummer 3.2.3 verlangt, dass die Einrichtungen Protokolle „führen, dokumentieren und überprüfen“ und auf Grundlage der Risikobewertung nach Nummer 2.1 eine Liste der Anlagen und Werte erstellen, die Gegenstand der Protokollierung sind. Soweit angemessen, enthalten die Protokolle die zwölf folgenden Punkte, hier mit typischen Quellen in einer mittelgroßen VMware-Umgebung.

Durchführungsverordnung (EU) 2024/2690, Anhang, Nummer 3.2.3 (eur-lex.europa.eu); Inhalte der ESX-Logdateien aus Broadcom KB 306962. Quellen und Beispielereignisse sind unsere Zusammenfassung.

Zu den Nachweisbeispielen der ENISA für Nummer 3.2.3 gehören Auszüge aktueller und historischer DNS- und DHCP-Protokolle; DHCP-Einträge ordnen eine IP-Adresse aus einem Firewall-Protokoll einer bestimmten Maschine zu.

Log-Quellen in einer Umgebung mit 10 bis 60 VMware-Hosts

Bei 500 bis 2.000 VMs erzeugt die vollständige Protokollierung jedes Gastsystems mehr Daten, als ein IT-Team auswerten kann; die Risikobewertung wählt daher die Systeme aus, deren Kompromittierung am schwersten wiegt: die Domänencontroller und den Verzeichnisdienst, vCenter und die Hosts, den Backup-Server und seine Repositories, Firewalls und VPN, Jump-Hosts und den Passwort-Tresor, aus dem Internet erreichbare Server und die wichtigsten Geschäftsanwendungen. Die übrigen VMs senden die Ereignisse ihrer Sicherheitstools und ihre Anmeldungen.

Broadcoms KB 318939 beschreibt die ESX-Einstellung Syslog.global.logHost als „eine kommagetrennte Liste entfernter Server, an die Protokolle über das Syslog-Protokoll gesendet werden“, und warnt: „Ist das Feld logHost leer, werden keine Protokolle weitergeleitet.“ Auf dem Host zeichnet auth.log „erfolgreiche und fehlgeschlagene Authentifizierungen an der ESXi Shell“ auf und shell.log die Nutzung der Shell, „einschließlich Aktivieren/Deaktivieren und jedes eingegebenen Befehls“ (KB 306962). Die Dokumentation von Broadcom zu vSphere 8.0 und 9.0 begrenzt die Log-Weiterleitung von vCenter auf drei Syslog-Ziele. Audit-Datensätze und die zugehörigen Härtungseinstellungen behandelt unser Leitfaden zur Härtung von ESXi gegen Ransomware.

Auf dem Backup-Server sind die festzuhaltenden Ereignisse Administratoranmeldungen, Kontoänderungen und das Löschen von Jobs, Wiederherstellungspunkten oder Repositories, also Buchstabe f. Bei GPU-Servern und einer privaten KI-Plattform gehören Anmeldungen am BMC und dessen Ereignisprotokolle zu Buchstabe j, und Anmeldungen, Änderungen durch Administratoren, neue API-Schlüssel und Modell-Deployments auf der Plattform zu den Buchstaben c und e. Alarmregeln für privilegierte Ereignisse stehen in unserem Leitfaden zu Privileged Access Management.

Wir würden zwei Collector im Verwaltungsnetz platzieren, auf verschiedenen Hosts oder an verschiedenen Standorten, verwaltet mit Konten außerhalb des produktiven Verzeichnisdienstes, die einen zentralen Log-Speicher oder ein SIEM mit eigenem Backup speisen.

Die Ereigniszentralisierung im SIEM gehört zu unserer Leistung Cyber-Resilienz, umgesetzt von unserem Engineering-Partner Vixen.UNO. Schicken Sie uns die Liste der Systeme, die heute an eine zentrale Stelle protokollieren, und der Systeme, die es nicht tun.

NIS2-Log-Aufbewahrung: wie lange Protokolle aufzubewahren sind

Nummer 3.2.5 bestimmt: „Die betreffenden Einrichtungen führen und sichern die Protokolle für einen vorab festgelegten Zeitraum und schützen sie vor unbefugten Zugriffen oder Änderungen.“ Die Leitlinie der ENISA sagt, die Aufbewahrungsfrist solle „im Einklang stehen mit“ Nummer 4.2.2 Buchstabe f, nach der Sicherungspläne „Aufbewahrungsfristen entsprechend geschäftlichen und regulatorischen Anforderungen“ umfassen. Außerdem schreibt die ENISA: „Die Aufbewahrungsdauer der gesicherten Protokolle sollte nicht kürzer sein als der Überprüfungszeitraum der Protokolle“.

Außerhalb des EU-Rechts sagt die SIEM-Leitlinie für Praktiker, die das Australian Cyber Security Centre des ASD und die CISA am 27. Mai 2025 mit Partnern veröffentlicht haben, dass für Organisationen, die neu in die Erkennung einsteigen, ein Ausgangspunkt für Protokolle mit administrativen und sicherheitsbezogenen Ereignissen „mindestens ein Jahr betragen kann“ und für informative Protokolle 90 Tage.

Durchführungsverordnung (EU) 2024/2690, Anhang, Nummern 2.1, 3.2.5, 3.5.4 und 4.2.2 Buchstabe f; ENISA Technical Implementation Guidance v1.0 (26. Juni 2025); Verordnung (EU) 2016/679, Artikel 5 Absatz 1 Buchstabe e; SIEM-Leitlinie für Praktiker von ASD und CISA (27. Mai 2025). Die Spalten Entscheidung und Eingangsgrößen sind unsere Zusammenfassung dieser Quellen.

Halten Sie das Ergebnis je Log-Klasse schriftlich fest: die Frist im durchsuchbaren Speicher, die Frist im Backup und wer löschen darf. Zu den Nachweisbeispielen der ENISA gehören „Eine Aufbewahrungsfrist ist festgelegt“ und „Die Protokolle enthalten keine Daten, deren Aufbewahrungsfristen abgelaufen sind.“ Wie sich die DSGVO, Branchenvorschriften oder Kundenverträge auf die Fristen auswirken, ist eine rechtliche Bewertung für die Rechtsabteilung des Unternehmens.

Schutz der Protokolle, Zeitsynchronisation und Redundanz

Zum Schutz der Protokolle nennt die Leitlinie der ENISA zu Nummer 3.2.5 Zugriffskontrolle, Verschlüsselung, Hashing und die „Protokollierung aller Zugriffe auf Protokolldateien und aller Änderungen daran“. Ein Domänenadministratorkonto sollte weder die Collector öffnen noch die Aufbewahrungseinstellungen des Speichers ändern; verwenden Sie daher separate Administratorkonten mit MFA, und halten Sie eine Kopie auf einem Speicher, der das Löschen vor dem Ende der Aufbewahrungsfrist verweigert.

Nummer 3.2.6 verlangt, soweit durchführbar, dass „alle Systeme zeitlich synchronisiert sind, um Protokolle zwischen den Systemen für die Ereignisbewertung miteinander in Beziehung setzen zu können“. Die ENISA schlägt NTP oder PTP vor, einen zentralen Zeitserver innerhalb der Einrichtung und „mehrere Zeitquellen, um einen Single Point of Failure zu vermeiden“, und ergänzt: „Verwenden Sie authentifiziertes NTP, um zu verhindern, dass böswillige Akteure Ihre Zeitsynchronisation manipulieren.“ Richten Sie Hosts, vCenter, Firewalls, Switches, BMCs und den Domänencontroller, der der Domäne die Zeit liefert, auf dieselben zwei internen Zeitserver mit mehr als einer Upstream-Quelle aus.

Dieselbe Nummer verlangt, dass „für die Überwachung und Protokollierung Redundanzsysteme zur Verfügung stehen“ und dass deren Verfügbarkeit „unabhängig von den von ihnen überwachten Systemen überwacht“ wird. Die Leitlinie der ENISA zu dieser Nummer empfiehlt, „separate Tools zur Überwachung von Kapazität und Verfügbarkeit“ der primären Überwachungs- und Protokollierungssysteme einzusetzen. Für eine mittelgroße Umgebung sind zwei Collector, eine zweite Kopie des zentralen Speichers und eine Prüfung, die außerhalb des überwachten Clusters läuft, ein Weg, diesem Wortlaut zu entsprechen.

Auswertung der Protokolle, Alarmschwellen und Reaktion auf Alarme

Nummer 3.2.4 verlangt, dass die Protokolle „regelmäßig auf ungewöhnliche oder unerwünschte Trends überprüft“ werden, dass soweit angemessen Alarmschwellen festgelegt werden und dass „im Falle eines Alarms zeitnah eine qualifizierte und angemessene Reaktion eingeleitet wird“. Zu den indikativen Schwellenwerten der ENISA gehören „drei oder mehr Kontosperrungen innerhalb von 15 Minuten“ und „zwei oder mehr Fälle von Rechteausweitung (z. B. von normalem Nutzer zu Admin) innerhalb von 24 Stunden“, mit der Fußnote „Die Schwellenwerte hängen von der betrieblichen Umgebung ab.“

Nummer 3.4.2 ergänzt „ein Verfahren für die Korrelation und Analyse von Protokollen“, und Nummer 3.5.4 verlangt, dass die Tätigkeiten zur Reaktion auf Sicherheitsvorfälle protokolliert und Nachweise gesammelt werden; die Meldefristen, die von diesen Aufzeichnungen abhängen, behandelt unser Leitfaden zur Meldung von Sicherheitsvorfällen nach NIS2. Für eine mittelgroße Umgebung schlagen wir diesen Prüfzyklus vor.

1. Bearbeiten Sie jeden Alarm, sobald er auslöst, da Nummer 3.2.4 eine zeitnahe Reaktion verlangt, und erfassen Sie an jedem Arbeitstag jeden Alarm des Vortags nach den vorab festgelegten Kriterien als Ereignis oder als Sicherheitsvorfall.
2. Lesen Sie wöchentlich einen zusammenfassenden Bericht auf Trends hin, etwa Anmeldungen außerhalb der Arbeitszeit oder zunehmende fehlgeschlagene Authentifizierungen, und passen Sie Schwellen an, die ohne Grund auslösen.
3. Gleichen Sie monatlich die Liste der protokollierten Anlagen und Werte mit dem Asset-Inventar und dem Inventar in vCenter ab, und prüfen Sie, ob jede Quelle innerhalb des letzten Tages Protokolle gesendet hat.
4. Bewerten Sie vierteljährlich wiederholte Sicherheitsvorfälle, wie es Nummer 3.4.2 Buchstabe b von den betreffenden Einrichtungen verlangt.
5. Überprüfen Sie jährlich und nach erheblichen Sicherheitsvorfällen die Verfahren und die Liste der protokollierten Anlagen und Werte (Nummer 3.2.7; die ENISA schreibt „mindestens jährlich“), und stellen Sie eine Stichprobe von Protokollen aus dem Backup wieder her.

Aufzeichnungen von Schwachstellenscans gehören zu Nummer 6.10 und Aufzeichnungen über Patches zu Nummer 6.6; beide behandelt unser Leitfaden zur Behandlung von Schwachstellen nach NIS2.

Unsere Leistung Cyber-Resilienz umfasst einen Incident-Response-Plan mit Rollen, Maßnahmen und Fristen. Beschreiben Sie im Formular unten, wer heute die Protokolle prüft und wer außerhalb der Bürozeiten Alarme erhält.

SIEM-Pflicht nach NIS2 und Nummer 3.2.1

Nummer 3.2.1 verlangt Verfahren und Instrumente, ohne eine Produktkategorie zu nennen. Zu den Nachweisbeispielen der ENISA für die automatisierte Überwachung nach Nummer 3.2.2 gehören SIEM-Systeme, die „eingesetzt werden, um Daten zu analysieren und Abweichungen von etablierten Mustern zu erkennen“, neben EDR- und XDR-Tools. Ein zentraler Log-Speicher mit Alarmierung und Suche ist ein Weg, diesem Wortlaut zu entsprechen, und ein SIEM automatisiert einen großen Teil des Verfahrens für die Korrelation und Analyse von Protokollen, das Nummer 3.4.2 Buchstabe d verlangt. Die Kategorien der Tools und wer nachts die Alarme überwacht, behandelt unser Vergleich von EDR, XDR, SIEM und MDR.

Allgemeine Information zum EU-Recht mit Stand Oktober 2026, keine Rechtsberatung im Einzelfall.

Was wir tun

Im Rahmen unserer Leistung Cyber-Resilienz richtet unser Engineering-Partner Vixen.UNO die Ereigniszentralisierung im SIEM und EDR/XDR auf Workstations und Servern ein, auf Lösungen von Trend Micro, Cisco und weiteren Herstellern. Das Security- und Compliance-Assessment prüft Infrastruktur, Zugriffe, Backups und die Einhaltung der NIS2-Anforderungen, und Sie erhalten eine Risikokarte und einen priorisierten Maßnahmenplan. Die NIS2-Compliance-Karte ist ein technisches Assessment, und die rechtliche Bewertung der Compliance erstellt Ihre Rechtsabteilung. Änderungen werden in vereinbarten Wartungsfenstern mit Rollback-Plan ausgerollt, danach folgt Support unter einem vereinbarten SLA, und die Ingenieure unseres Partners arbeiten in Ihrer Umgebung unter Ihren Zugriffsregeln, wie unsere Seite Sicherheit & Compliance beschreibt. Aufbewahrungsfristen und die Empfänger von Alarmen bleiben Entscheidungen Ihres Unternehmens.

FAQ