NIS2: Technische Maßnahmen auf Plattformebene
NIS2UmsuCG Artikel 21: Zehn Kategorien technischer Sicherheitsmaßnahmen. Keine davon endet mit "Wir haben eine Richtlinie dazu".
NIS2 schreibt keine konkreten Tools oder Konfigurationen vor. Es definiert, was nachweisbar erreicht sein muss. Die Lücke zwischen "Wir haben eine Sicherheitsrichtlinie" und "Hier ist die dokumentierte Evidenz unseres gehärteten Plattformzustands" ist genau der Punkt, an dem Organisationen NIS2-Audits scheitern.
lennlay schließt diese Lücke mit definierten Plattform-Baselines, automatisierten Compliance-Scans und einer Änderungshistorie, die im Audit auf jede Frage eine Antwort hat.
Was die zehn Anforderungskategorien auf Serverebene konkret bedeuten
NIS2 beschreibt Anforderungskategorien, keine Umsetzungsrezepte. Was auf Plattformebene nachweisbar umgesetzt sein muss, bestimmt der Auditor. Sechs der zehn Kategorien sind direkt auf Plattformebene adressierbar.
Risikoanalyse und Sicherheitsrichtlinien
Welche Plattformen existieren? Was ist ihr Sicherheitszustand? Jede Abweichung vom definierten Zielzustand ist ein dokumentiertes Risiko. Ohne definierte Baseline gibt es keinen Zielzustand und damit keine belastbare Risikoanalyse.
Incident-Handling
Was war der Konfigurationsstand zum Zeitpunkt des Sicherheitsvorfalls? Ohne Git-basiertes Konfigurationsmanagement: unbekannt. Mit GitOps ist es eine Abfrage mit Autor, Zeitstempel und Änderungsgrund.
Business Continuity und Disaster Recovery
Plattformen müssen aus einem definierten, reproduzierbaren Zustand wiederhergestellt werden können. Golden Images und Ansible Collections liefern genau das: Reproduzierbarkeit auf der Grundlage eines dokumentierten Sollzustands.
Sicherheit bei Systembeschaffung und -entwicklung
Neue Server müssen den definierten Härtungsstandard erfüllen, ab Tag 1, nicht nach dem ersten Incident-Report. GIaaS liefert hardened Baselines als Ausgangszustand, nicht als nachträgliche Maßnahme.
Wirksamkeitsprüfung der Sicherheitsmaßnahmen
Der automatisierte Compliance-Scan prüft, ob die definierten Maßnahmen tatsächlich umgesetzt sind. Nicht als Einmalprüfung, sondern kontinuierlich. Ohne Scanner bleibt die Wirksamkeit eine Behauptung, keine Evidenz.
Zugangskontrollen und Asset-Management
Jeder Server ist dokumentiert. Jede Konfigurationsänderung ist einem Autor zugeordnet, mit Zeitstempel und Begründung. Git-basiertes Konfigurationsmanagement ist Asset-Management und Änderungsnachweis in einem.
Die Kategorien (d) Lieferkettensicherheit, (g) Schulungen und Cybersicherheitshygiene, (h) Kryptographie und (j) Multi-Faktor-Authentifizierung liegen außerhalb des Plattform-Hardening-Scopes und sind über ergänzende Maßnahmen adressierbar.
Wer unter NIS2 fällt
Das NIS2UmsuCG unterscheidet zwei Kategorien betroffener Einrichtungen mit unterschiedlichen Größenschwellen und Anforderungsniveaus. Die Einstufung bestimmt den Umfang der Aufsicht und die Schwere der Sanktionen.
- Energie (Strom, Gas, Fernwärme, Erdöl, Wasserstoff)
- Transport (Straße, Schiene, Luft, Wasser)
- Banken und Kreditinstitute
- Finanzmarktinfrastruktur
- Gesundheit (Krankenhäuser, Labore, Pharma)
- Trinkwasserversorgung
- Abwasserentsorgung
- Digitale Infrastruktur (IXPs, DNS, TLD, Cloud, Rechenzentren)
- IKT-Dienste (Managed Services, Managed Security)
- Öffentliche Verwaltung (Bundes- und Landesebene)
- Weltraum
- Post- und Kurierdienste
- Abfallwirtschaft
- Chemie
- Lebensmittelproduktion und -vertrieb
- Verarbeitendes Gewerbe: Medizinprodukte, Elektronik, Fahrzeuge, Maschinenbau
- Digitale Dienste (Online-Marktplätze, Suchmaschinen, soziale Netzwerke)
- Forschungseinrichtungen
Wesentliche Einrichtungen unterliegen proaktiver Aufsicht durch das BSI und sind zur Registrierung verpflichtet. Wichtige Einrichtungen werden reaktiv beaufsichtigt, die Pflichten aus Artikel 21 gelten jedoch für beide Kategorien gleichermassen.
Welche lennlay-Maßnahme welche Artikel-21-Pflicht erfüllt
Artikel 21 definiert, was nachgewiesen werden muss. lennlay liefert die technischen Artefakte, die diesen Nachweis ermöglichen.
| lennlay-Maßnahme | Artikel 21 | Was nachgewiesen wird |
|---|---|---|
| Definierte Baselines (CIS L1/L2 oder Custom Policy) | (a) + (e) | Versioniertes Policy-Artefakt mit Regel-IDs, Datum, Scope und Ausnahme-Log |
| Automatisierter Compliance-Scan und Reports | (f) | Strukturierter Report: Sollzustand, Istzustand, Abweichungen, Ausnahmen mit Risikobewertung |
| Git-basiertes Konfigurationsmanagement | (b) + (i) | Audit-Trail mit Autor, Zeitstempel und Begründung jeder Konfigurationsänderung |
| GIaaS Golden Images | (c) + (e) | Reproduzierbarer Wiederherstellungszustand und standardisierter Ausgangszustand für neue Systeme |
| Drift-Erkennung | (f) | Abweichungen werden sichtbar, bevor sie im Audit oder Störfall relevant werden |
| Lifecycle-Management | (e) | Nachvollziehbarer Patchstand mit dokumentierten Support-Enden und Upgrade-Zeitplänen |
Sechs Bausteine für auditierbaren NIS2-Nachweis auf Plattformebene
Definierte Plattform-Baselines
CIS Level 1 oder Level 2 als versioniertes Policy-Artefakt. Jede Plattform hat einen dokumentierten Sollzustand mit Regel-IDs, Datum, Scope und Ausnahme-Log. Keine Beschreibung, sondern ein maschinenlesbares und nachweisbares Regelwerk.
Automatisierter NIS2-Nachweis
Der lennlay Compliance-Scanner prüft live gegen definierte Policies. Der Report enthält Sollzustand, Istzustand, Abweichungen und Ausnahmen mit Risikobewertung. Direkt verwendbar für Auditoren und interne Revisionen.
Änderungshistorie als Beweis
Git-Commits als Audit-Trail. Jede Konfigurationsänderung ist mit Autor, Zeitstempel und Begründung dokumentiert. Für den Artikel-21(b)-Nachweis gilt: Welcher Zustand zum Zeitpunkt des Incidents aktiv war, ist eine Git-Abfrage, keine Rekonstruktion.
GIaaS für reproduzierbare Systeme
Hardened Baselines für RHEL, Tomcat, Apache HTTP Server und JBoss EAP als verwaltete, policy-gesteuerte Artefakte. Neue Systeme starten im definierten Sollzustand, nicht im Rohzustand.
Drift-Erkennung
Kontinuierliches oder regelmäßiges Scanning vergleicht Ist-Zustand mit der definierten Baseline. Abweichungen erscheinen, bevor sie im Audit oder im Störfall relevant werden, nicht danach.
EaaS für NIS2-Projekte
Marcel König (RHCA/RHCE) und Matthias Siegl für NIS2-Readiness-Assessment, Baseline-Definition und Scanner-Setup. Punkt-in-Zeit-Engagement oder laufende Begleitung, je nach Projektphase.
Von der Baseline-Definition zum Audit-Report: vier Schritte
NIS2-Compliance ist kein Projektziel, das einmal erreicht wird. Es ist ein laufender Nachweis, dass die Maßnahmen tatsächlich wirken. Die folgende Kette macht diesen Nachweis strukturell.
Baseline definieren
Schriftliche Policy: welcher Standard gilt (CIS L1/L2, NIST, intern), welche Ausnahmen bestehen und aus welchem Grund. Das Policy-Artefakt ist das Fundament aller nachfolgenden Nachweise.
Umsetzen
Ansible Collections installieren und konfigurieren gemäß Baseline. GIaaS-Image als Ausgangszustand. Jede Aktion ist versioniert und einem Autor zugeordnet.
Prüfen
Compliance-Scanner läuft gegen produktive Instanzen. Strukturiertes Ergebnis: Pass/Fail pro Kontrolle, Abweichungen mit Schweregrad, Ausnahmen mit Risikobewertung. Kein manueller Aufwand, kein Interpretationsspielraum.
Nachweisen
Report für den Auditor: aktueller Compliance-Stand, dokumentierte Abweichungen, Ausnahmen mit Begründung, vollständige Änderungshistorie. Ein strukturiertes Dokument, direkt für die Prüfung verwendbar.
NIS2 fragt nach Beweisen, nicht nach Absichten. lennlay liefert die Artefakte, die im Audit Bestand haben.
