NIS2 Zugangssteuerung und Personalsicherheit: Ein vollständiger Leitfaden zu Artikel 21 Absatz 2 Buchstabe i

NIS2 Zugangssteuerung und Personalsicherheit: Ein vollständiger Leitfaden zu Artikel 21(2)(i)

Artikel 21(2)(i) der NIS2-Richtlinie verpflichtet betroffene Einrichtungen zur Implementierung von Maßnahmen, die “Personalsicherheit, Zugangssteuerungsrichtlinien und Asset-Management” umfassen. Auf den ersten Blick erscheinen dies drei voneinander getrennte Themenbereiche. In der Praxis handelt es sich jedoch um eine der weitreichendsten Maßnahmen der gesamten Richtlinie — sie stützt sich auf die Abschnitte 10 (Personalsicherheit), 11 (Zugangssteuerung) und 12 (Asset-Management) des Anhangs der CIR 2024/2690.

Dieser Leitfaden konzentriert sich auf Zugangssteuerung und Personalsicherheit — die beiden Kontrollen, die unmittelbar regeln, wie Personen mit Ihren Systemen interagieren. Das Asset-Management wird als Teil derselben gesetzlichen Anforderung behandelt, verdient jedoch eine gesonderte Betrachtung. Die hier behandelten Kontrollen adressieren gemeinsam das, was Sicherheitsexperten als das “Menschenproblem” bezeichnen: Mitarbeitende, Auftragnehmer und Administratoren sind gleichzeitig das wertvollste Gut Ihrer Organisation und der häufigste Angriffsvektor. Eine ordnungsgemäße Zugangssteuerung beantwortet eine scheinbar einfache Frage: Verfügt die richtige Person über den richtigen Zugang zu der richtigen Ressource — und nicht mehr?

Dieser Artikel erläutert, was CIR 2024/2690 technisch vorschreibt, wie es proportional für eine mittelgroße Organisation implementiert werden kann und welche NIS2-Vorlagen die einzelnen Anforderungen abdecken. Er richtet sich an IT-Manager und HR-Direktoren, die rechtliche Verpflichtungen in operative Verfahren überführen müssen.

CIR Anhang 11: Anforderungen an die Zugangssteuerung

Abschnitt 11 des CIR-Anhangs überführt die NIS2-Verpflichtung zur Zugangssteuerung in spezifische technische und organisatorische Anforderungen. Er umfasst vier Teilbereiche.

11.1 Zugangssteuerungsrichtlinie

Jede betroffene Organisation muss eine Zugangssteuerungsrichtlinie dokumentieren, die die Grundsätze dafür festlegt, wer auf was zugreifen darf. Die Richtlinie muss:

• Grundsätze der Zugangssteuerung definieren, die auf Ihre geschäftlichen und sicherheitsbezogenen Anforderungen abgestimmt sind
• Das Prinzip der geringsten Berechtigungen (Least Privilege) als grundlegende Regel etablieren — Benutzende erhalten ausschließlich den für ihre Rolle erforderlichen Mindestzugang
• Das Need-to-know-Prinzip etablieren — der Zugang zu Informationen ist auf Personen mit einem legitimen geschäftlichen Bedarf beschränkt
• Sowohl den logischen Zugang (Systeme, Anwendungen, Daten) als auch den physischen Zugang (Serverräume, gesperrte Bereiche) abdecken
• Anforderungen für verschiedene Benutzerkategorien definieren: Mitarbeitende, Auftragnehmer, Drittanbieter-Partner und privilegierte Administratoren

Die Richtlinie muss kein umfangreiches Dokument sein. Eine klare, 5–10 Seiten umfassende Richtlinie, die tatsächlich angewendet wird, ist mehr wert als ein umfassendes 40-seitiges Dokument, das unbeachtet in einem Ordner liegt. Dokument 28 (Zugangssteuerungsrichtlinie) im NIS2-Vorlagenpaket bietet einen anpassungsfähigen Rahmen, der unmittelbar auf CIR Abschnitt 11 abgestimmt ist.

11.2 Verwaltung von Zugriffsrechten

Die CIR fordert einen formellen, dokumentierten Prozess für die Verwaltung von Benutzerzugriffsrechten über deren gesamten Lebenszyklus. Dies umfasst:

• Einen formellen Prozess zur Registrierung und Abmeldung von Benutzenden (keine Ad-hoc-Anfragen per E-Mail)
• Einen definierten Workflow: Zugriffsantrag → Genehmigung durch den Asset-Verantwortlichen → Implementierung → Überprüfung
• Regelmäßige Zugriffsüberprüfungen zur Bestätigung der Angemessenheit der Berechtigungen
• Zeitnahe Anpassung der Zugriffsrechte bei Rollenwechseln
• Sofortiger Entzug des Zugangs bei Beendigung des Arbeitsverhältnisses oder wenn der Zugang nicht mehr benötigt wird

Hinsichtlich der Häufigkeit von Zugriffsüberprüfungen schreibt die CIR “regelmäßige” Überprüfungen vor, überlässt den Rhythmus jedoch der Risikobeurteilung der Organisation. Die Leitlinien von ENISA empfehlen folgenden Mindestzeitplan:

11.3 Verwaltung privilegierter Zugangsrechte

Privilegierte Konten — solche mit Administratorrechten, erhöhten Systemberechtigungen oder Zugang zu sensiblen Konfigurationen — stellen ein überproportionales Risiko dar. Ein kompromittiertes Administratorkonto kann sich lateral bewegen, Daten exfiltrieren und Kontrollen schneller deaktivieren als ein kompromittiertes Standardbenutzerkonto. CIR Abschnitt 11 stellt spezifische Anforderungen an diese Konten:

• Führen Sie ein Inventar aller privilegierten Konten (lokale Administratoren, Domain-Administratoren, Dienstkonten, Cloud-Root-Konten)
• Verwenden Sie separate Konten für privilegierte Aufgaben — IT-Administratoren sollten ein Standardkonto für die tägliche Arbeit und ein dediziertes Administratorkonto für administrative Aufgaben haben. Keine Konten mit doppelter Funktion.
• Erzwingen Sie eine stärkere Authentifizierung für privilegierten Zugang, einschließlich Multi-Faktor-Authentifizierung
• Begrenzen Sie die Dauer des privilegierten Zugangs — Just-in-Time-Zugang (JIT), bei dem Administratoren erhöhte Berechtigungen für ein definiertes Zeitfenster anfordern, ist der empfohlene Ansatz, sofern die Werkzeuge dies erlauben
• Protokollieren und überwachen Sie alle privilegierten Zugriffsaktivitäten und bewahren Sie Protokolle für Prüfzwecke auf
• Überprüfen Sie privilegierte Konten häufiger als Standardkonten (mindestens vierteljährlich)
• Beschränken Sie, soweit praktikabel, den privilegierten Zugang auf dedizierte Administrator-Workstations, die nicht zum Surfen oder für E-Mails genutzt werden

11.4 Sicherheit von Administrationssystemen

Administrationsschnittstellen — Management-Konsolen, Fernzugriffswerkzeuge und Konfigurationsportale zur Verwaltung der Infrastruktur — müssen mit stärkeren Kontrollen als benutzerseitige Systeme geschützt werden. Dies bedeutet:

• Stärkere Authentifizierungsanforderungen für Management-Schnittstellen als für Standard-Benutzeranwendungen
• Separate Verwaltungsnetzwerke, wo dies umsetzbar ist (Out-of-Band-Management)
• Gehärtete Administrationswerkzeuge mit deaktivierten nicht benötigten Funktionen
• Fernverwaltung beschränkt auf genehmigte, authentifizierte Methoden (VPN mit MFA oder Zero-Trust-Netzwerkzugang)

Least Privilege und Need-to-know: Die Grundprinzipien

Die beiden grundlegenden Prinzipien der NIS2-Zugangssteuerung sind es wert, in praktischen Begriffen erläutert zu werden, da sie zwar häufig zitiert, aber selten konsequent umgesetzt werden.

Least Privilege bedeutet, die für die Ausführung einer bestimmten Aufgabe erforderlichen Mindestberechtigungen zu gewähren — nicht mehr. Ein Marketing-Analyst, der Kundendaten aus dem CRM lesen muss, benötigt keinen Schreibzugang auf Finanzsysteme. Ein Anwendungssupport-Techniker, der einen Dienst neu starten muss, benötigt keine vollständigen Domain-Administratorrechte.

Die praktische Konsequenz ist eine Änderung der Denkweise: Beginnen Sie mit keinem Zugang und fügen Sie Berechtigungen hinzu, sobald diese begründet sind, anstatt mit umfangreichen Berechtigungen zu beginnen und das Nicht-Benötigte zu entfernen. Letzterer Ansatz — der dem aktuellen Vorgehen der meisten Organisationen entspricht — führt konsequent zu einer Anhäufung übermäßiger Zugriffsrechte im Laufe der Zeit.

Need-to-know erweitert das Prinzip von Berechtigungen auf Informationen. Selbst wenn eine Benutzerin oder ein Benutzer technisch Zugang zu einem System hat, sollte der Zugang zu bestimmten Daten innerhalb dieses Systems auf Personen mit einem aktuellen, legitimen geschäftlichen Bedarf beschränkt sein. Dies gilt für Dokumente, Datenbanken, Berichte, E-Mail-Verteilerlisten und physische Bereiche.

Der praktische Treiber für Need-to-know ist die Informationsklassifizierung: Klassifizieren Sie zunächst Ihre Informationen und definieren Sie dann, wer Zugang zu welcher Klassifizierungsstufe benötigt. Dies verhindert das häufige Versagen, bei dem sensible Informationen in gemeinsam genutzten Ordnern gespeichert werden, auf die alle zugreifen können, weil es “einfacher ist”.

Rollenbasierte Zugangssteuerung (RBAC)

Für die meisten Organisationen ist die rollenbasierte Zugangssteuerung (RBAC) die praktischste Umsetzung dieser Prinzipien. Anstatt Berechtigungen einzelnen Benutzenden zuzuweisen, definieren Sie Rollen mit spezifischen Berechtigungssätzen und weisen Benutzende dann den Rollen zu. Dies ist skalierbar, lässt sich einfach prüfen und macht den JML-Prozess (weiter unten beschrieben) erheblich handhabbarer.

Eine typische RBAC-Struktur für eine mittelgroße Organisation könnte folgendermaßen aussehen:

Die entscheidende Disziplin besteht darin, die Rollendefinitionen regelmäßig zu überprüfen — Rollen häufen im Laufe der Zeit Berechtigungen an, wenn Ausnahmen gewährt und nie überprüft werden.

Der Joiner-Mover-Leaver-Prozess (JML)

Der Joiner-Mover-Leaver-Prozess ist das operative Rückgrat der Personalsicherheit für die Zugangssteuerung. Er definiert genau, welche Maßnahmen ergriffen werden, wenn eine Person der Organisation beitritt, die Rolle wechselt oder sie verlässt. Ohne einen dokumentierten JML-Prozess wird die Zugangssteuerung reaktiv und inkonsistent — dies ist die häufigste Ursache für die Anhäufung übermäßiger Zugriffsrechte und der häufigste Mangel bei NIS2-Audits der Zugangssteuerung.

Joiner-Prozess (Neue Mitarbeitende oder Auftragnehmer)

1. HR informiert IT/Sicherheit über den neuen Mitarbeitenden mit Rollendetails und Eintrittsdatum — idealerweise 5–10 Werktage im Voraus
2. Basisanfrage für den Zugang wird auf Grundlage des vordefinierten Berechtigungssatzes der Rolle erhoben (RBAC-Rollenzuweisung)
3. Vorgesetzte genehmigen jeden zusätzlichen Zugang über die Rollenbasislinie hinaus
4. Konten werden vor dem Eintrittsdatum erstellt und konfiguriert
5. Schulung zur Sicherheitsbewusstsein wird innerhalb der ersten Woche durchgeführt
6. Zugangsdaten werden über einen sicheren Kanal bereitgestellt — nicht per unverschlüsselter E-Mail
7. Dokumentierte Bestätigung der Akzeptanzrichtlinie für die Nutzung (und der HR-Sicherheitsrichtlinie) wird vom neuen Mitarbeitenden eingeholt

Mover-Prozess (Rollenwechsel, Versetzung oder Beförderung)

1. Vorgesetzte oder HR informieren IT/Sicherheit über den Rollenwechsel, das Wirksamkeitsdatum und die Details der neuen Rolle
2. Aktuelle Zugriffsrechte werden mit den Anforderungen der neuen Rolle abgeglichen
3. Zugang entziehen, der für die neue Rolle nicht mehr erforderlich ist — dies ist der Schritt, den die meisten Organisationen versäumen, was im Laufe der Zeit zu einer Anhäufung von Berechtigungen führt
4. Zugang gewähren, der für die neue Rolle erforderlich ist
5. Zugangsdatensätze und RBAC-Rollenzuweisung aktualisieren
6. Den Mitarbeitenden über etwaige neue Sicherheitsverantwortlichkeiten im Zusammenhang mit der neuen Rolle informieren

Leaver-Prozess (Kündigung, Beendigung des Arbeitsverhältnisses oder Vertragsende)

Ein kritischer Punkt: Deaktivieren Sie Konten, anstatt sie sofort zu löschen. Gelöschte Konten vernichten Prüfpfad-Nachweise, die für die Untersuchung von Vorfällen oder behördliche Inspektionen benötigt werden könnten. Bewahren Sie deaktivierte Konten für die Dauer Ihrer Protokollaufbewahrungsfrist auf und löschen Sie sie anschließend.

CIR Anhang 10: Personalsicherheit

Abschnitt 10 der CIR befasst sich mit der personenbezogenen Seite der Sicherheit — er stellt sicher, dass Mitarbeitende und Auftragnehmer angemessen überprüft werden, über ihre Verantwortlichkeiten informiert sind und sicher aus dem Unternehmen ausscheiden.

10.1 Überprüfung vor der Einstellung

Hintergrundprüfungen müssen proportional zur Sensitivität der Stelle und dem damit verbundenen Systemzugang sein. Die CIR schreibt kein spezifisches Überprüfungsniveau für alle Rollen vor — das Verhältnismäßigkeitsprinzip bestimmt die Entscheidung.

Ein praktischer Rahmen für die meisten Organisationen:

• Standardrollen (kein privilegierter Zugang): Identitätsverifizierung, Referenzprüfung, Überprüfung der Arbeitsberechtigung
• Rollen mit Zugang zu sensiblen Daten: Wie oben, zusätzlich Überprüfung des beruflichen Werdegangs und der Qualifikationen
• IT-Administratoren und Rollen mit privilegiertem Zugang: Erweiterte Hintergrundprüfung, ggf. Überprüfung der finanziellen Hintergründe, berufliche Referenzprüfung

Dokumentieren Sie das erforderliche Überprüfungsniveau für jede Rollenkategorie und halten Sie die durchgeführten Prüfungen fest. Verhältnismäßigkeit ist entscheidend: Die Forderung nach einem polizeilichen Führungszeugnis für eine administrative Juniorrolle ohne Systemzugang ist unverhältnismäßig; keine Prüfung für einen Cloud-Infrastruktur-Administrator durchzuführen, ist unzureichend.

10.2 Sicherheit während des Beschäftigungsverhältnisses

Sicherheitsverantwortlichkeiten müssen in Stellenbeschreibungen und Arbeitsverträgen definiert sein, nicht nur in Richtliniendokumenten, die Mitarbeitende möglicherweise nie lesen. Wesentliche Anforderungen:

• Sicherheitsverantwortlichkeiten in den Stellenbeschreibungen aller Rollen mit Systemzugang dokumentieren
• Sicherheitsklauseln in Arbeitsverträgen aufnehmen (Vertraulichkeit, akzeptable Nutzung, Meldepflicht bei Vorfällen)
• Schulung zur Sicherheitsbewusstsein während des Onboardings durchführen — nicht optional, nicht auf “wenn Zeit ist” verschieben
• Laufendes Sicherheitsbewusstseinsprogramm, das auf die Schulungsanforderungen gemäß Artikel 21(2)(g) abgestimmt ist
• Richtlinie zur akzeptablen Nutzung von allen Mitarbeitenden unterzeichnen lassen
• Einen dokumentierten Disziplinarverfahrensprozess bei Verstößen gegen die Sicherheitsrichtlinie — verhältnismäßig zur Schwere, konsequent angewendet

10.3 Beendigung und Wechsel

Abschnitt 10.3 behandelt die sicherheitsbezogenen Aspekte der Beendigung des Beschäftigungsverhältnisses und von Rollenwechseln — die HR-seitige Komponente des oben beschriebenen JML-Prozesses. Zu den spezifischen Anforderungen gehören:

• Dokumentierte Verfahren zum Entzug von Zugriffsrechten (der oben beschriebene Leaver-Prozess)
• Verfahren zur Rückgabe physischer Gegenstände — Laptop, Mobilgerät, Zugangskarten, Hardware-Token
• Nachvertragliche Vertraulichkeitspflichten beim Ausscheiden einschärfen — Mitarbeitende müssen verstehen, dass NDA-Verpflichtungen nach ihrem letzten Arbeitstag fortbestehen
• Wissenstransferverfahren für Mitarbeitende in kritischen Sicherheitsrollen — Sicherheitswissen, Zugangsdaten und Verantwortlichkeiten müssen vor dem Ausscheiden dokumentiert und übergeben werden

Praktische Umsetzung für KMU: Drei Phasen

Die vollständigen Anforderungen können als einzelnes Projekt überwältigend wirken. Ein phasenweiser Ansatz macht die Umsetzung handhabbar. Diese Phasen orientieren sich an der Methodik der NIS2-Compliance-Checkliste.

Phase 1 — Grundlage (Wochen 1–4)

• Dokumentieren Sie eine Zugangssteuerungsrichtlinie, die die wesentlichen Grundsätze definiert (Least Privilege, Need-to-know, RBAC-Struktur, Überprüfungsrhythmus)
• Erstellen Sie eine Zugriffsrechtsmatrix, die Ihre wichtigsten Rollen den Systemen und Berechtigungsstufen zuordnet
• Implementieren Sie MFA für alle administrativen und Fernzugänge umgehend
• Etablieren Sie einen formellen HR–IT-Benachrichtigungsprozess für Eintritte, Rollenwechsel und Austritte
• Führen Sie eine erste Zugriffsüberprüfung durch, um offensichtlich übermäßige Berechtigungen zu identifizieren (achten Sie insbesondere auf ehemalige Mitarbeitende mit aktiven Konten und Benutzende, die die Rolle gewechselt haben)

Phase 2 — Ausbau (Wochen 4–8)

• Implementieren Sie einen formellen Workflow für Zugriffsanträge und -genehmigungen (ein einfaches Ticketformular ist für die meisten KMU ausreichend)
• Legen Sie einen regelmäßigen Zugriffsüberprüfungsplan fest und weisen Sie die Verantwortung zu
• Erstellen Sie separate Administratorkonten für IT-Mitarbeitende mit privilegiertem Zugang
• Aktivieren Sie die Protokollierung des Zugangs auf kritischen Systemen (Active Directory, Cloud-Konsolen, Finanzanwendungen)
• Fügen Sie Sicherheitsklauseln in Arbeitsverträge ein und aktualisieren Sie die Richtlinie zur akzeptablen Nutzung
• Definieren Sie rollenbasierte Überprüfungsanforderungen und dokumentieren Sie, welche Prüfungen durchgeführt werden

Phase 3 — Reife (Fortlaufend)

• Implementieren Sie eine Lösung für die Verwaltung privilegierter Zugänge (PAM), sofern Budget und Umfang dies rechtfertigen
• Automatisieren Sie die JML-Bereitstellung und -Aufhebung, wo HR- und Identitätsmanagementsysteme eine Integration ermöglichen
• Etabl