PAM und Break-Glass-Konten für ISO 27001 im Jahr 2026

Um 02:14 Uhr an einem Sonntagmorgen erhält der Incident Commander die Nachricht, die jeder CISO fürchtet: „Die Produktionsauthentifizierung schlägt fehl. Die Administrationskonsole ist nicht erreichbar. Das Datenbank-Failover hängt fest.“

Der diensthabende Cloud-Ingenieur sieht das Problem, kann es aber nicht beheben. Seine reguläre privilegierte Rolle hängt von demselben Identitätsanbieter ab, der jetzt beeinträchtigt ist. Die Betriebsleitung fordert die Zugangsdaten für den Notfalladministrator an. Der Compliance-Verantwortliche fragt, ob das Break-Glass-Konto jemals getestet wurde. Der Datenschutzbeauftragte fragt, ob der Zugriff auf die Produktionsdatenbank personenbezogene Daten offenlegen kann. Der CISO stellt die Frage, die entscheidet, ob daraus eine kontrollierte Wiederherstellung oder ein Audit-Albtraum wird:

„Können wir nachweisen, wer den Notfallzugriff genutzt hat, warum, was getan wurde und dass das Konto anschließend zurückgesetzt wurde?“

Eine andere Organisation kann vor demselben Problem in einem ruhigeren Raum stehen. Ein FinTech-CISO sitzt nach einer Fehlkonfiguration einer Cloud-Datenbank externen Auditoren gegenüber. Der Vorfall wurde schnell behoben, aber die Ursachenanalyse war wenig beruhigend. Ein externer Entwickler hatte dauerhaft administrative Zugriffsberechtigungen. Als der primäre Administrator nicht verfügbar war, nutzte der Entwickler ein Break-Glass-Konto, das auf einem gemeinsamen Passwort basierte, das in einer „sicheren“ Notiz für das DevOps-Team hinterlegt war.

Die Auditoren konzentrierten sich nicht nur auf die Fehlkonfiguration. Sie fragten, ob der Zugriff zeitlich begrenzt war, ob individuelle Rechenschaftspflicht bestand, ob Befehle protokolliert wurden, ob personenbezogene Daten nach GDPR Article 32 geschützt waren, ob die DORA-Verpflichtungen zum IKT-Risiko erfüllt wurden und ob die NIS2-Erwartungen an Cyberhygiene nachweisbar waren.

Das ist der reale Druckpunkt von Privileged Access Management und Break-Glass-Konten im Jahr 2026. PAM ist kein Nischenprojekt der Identitätssicherheit mehr. Hier laufen Ransomware, Cloud-Kompromittierung, Lieferantenrisiko, Datenschutz, operative Resilienz und Auditnachweise zusammen.

Privilegierter Zugriff ist der Punkt, an dem Angreifer gewinnen wollen. Break-Glass-Zugriff ist der Punkt, an dem Verteidiger wiederherstellen wollen. Beide beruhen auf derselben gefährlichen Fähigkeit: erhöhtem Zugriff, der Kontrollen umgehen, Konfigurationen ändern, sensible Daten lesen, Schlüssel rotieren, Protokollierung deaktivieren, Backups wiederherstellen, Code bereitstellen oder Nachweise zerstören kann.

Die praktische Position von Clarysec ist einfach: Notfallzugriff ist notwendig, aber ungesteuerter Notfallzugriff ist ungesteuertes Risiko. Die richtige Antwort lautet nicht „keine Break-Glass-Konten“. Die richtige Antwort ist ein gesteuertes Modell für Privileged Access Management mit Inventar, Genehmigung, Zeitbegrenzungen, starker Authentifizierung, Sitzungsprotokollierung, Überprüfung nach der Nutzung, Zurücksetzen von Zugangsdaten und Auditnachweisen.

Warum privilegierter Zugriff ein Compliance-Thema auf Ebene des Leitungsorgans ist

In Umgebungen mit geringerem Reifegrad wird privilegierter Zugriff häufig als Aufgabe der IT-Administration behandelt. Jemand benötigt Administratorrechte, ein Ticket wird eröffnet, eine Rolle wird vergeben, und der Geschäftsbetrieb läuft weiter. Dieses Modell hält moderner Ransomware, Cloud-nativer Infrastruktur, NIS2-Rechenschaftspflicht, operativer Resilienz nach DORA oder der Prüfung von Datenschutzverletzungen nach GDPR nicht stand.

Die NIS2-Richtlinie verlagert die Cybersicherheits-Governance in das Leitungsorgan. Article 20 verlangt, dass Leitungsorgane wesentlicher und wichtiger Einrichtungen Maßnahmen zum Risikomanagement im Bereich Cybersicherheit billigen, deren Umsetzung überwachen und an Cybersicherheitsschulungen teilnehmen. Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Risikoanalyse, Behandlung von Sicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette, Wirksamkeit von Kontrollen, Cyberhygiene, HR-Sicherheit, Zugriffskontrolle, Asset-Management und MFA oder kontinuierliche Authentifizierung, soweit angemessen.

Für SaaS-Anbieter, Managed Service Provider, Managed-Security-Anbieter, Cloud-Services, Rechenzentren und andere Organisationen der digitalen Infrastruktur hängt die Anwendbarkeit von NIS2 von Sektor, Größe, Rolle, grenzüberschreitender Auswirkung und Niederlassung in der EU ab. Die operative Lehre ist eindeutig: Zugriffskontrolle ist nicht mehr in einem technischen Anhang versteckt. Sie ist Teil der Cyberhygiene-Baseline, die das Management genehmigen, überwachen und korrigieren muss.

Für Finanzunternehmen ändert der Digital Operational Resilience Act die Sprache, nicht aber das zugrunde liegende Risiko. DORA gilt seit dem 17. Januar 2025 und schafft ein einheitliches Rahmenwerk für das Management von IKT-Risiken, die Meldung schwerwiegender IKT-bezogener Vorfälle, Tests der digitalen operativen Resilienz und das IKT-Drittparteienrisikomanagement. Article 5 verlangt Governance- und Kontrollregelungen für IKT-Risiken, wobei das Leitungsorgan die Regelungen für IKT-Risiken definiert, genehmigt, überwacht und dafür verantwortlich ist. Article 6 verlangt ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken mit Richtlinien, Verfahren, Protokollen und Werkzeugen zum Schutz von IKT-Assets. Article 17 verlangt einen IKT-bezogenen Vorfallmanagementprozess, der sichere Betriebsabläufe erkennt, aufzeichnet, klassifiziert, eskaliert und wiederherstellt.

GDPR ergänzt die Perspektive von Datenschutz und Rechenschaftspflicht. Article 5(1)(f) verlangt, dass personenbezogene Daten mit Integrität und Vertraulichkeit verarbeitet werden. Article 5(2) verlangt Rechenschaftspflicht. Article 25 verlangt Datenschutz durch Technikgestaltung und Datenschutz durch datenschutzfreundliche Voreinstellungen. Article 32 verlangt geeignete technische und organisatorische Maßnahmen für die Sicherheit der Verarbeitung. Wenn ein privilegierter Benutzer Kundendatensätze exportieren, auf besondere Kategorien personenbezogener Daten zugreifen, Audit-Protokolle deaktivieren oder Aufbewahrungseinstellungen ohne Überprüfung ändern kann, hat die Organisation nicht nur einen IAM-Fehler gemacht. Sie kann möglicherweise keine angemessene Sicherheit nachweisen.

ISO/IEC 27001:2022 ist das Managementsystem-Rückgrat, mit dem diese Verpflichtungen in einem integrierten Programm behandelt werden können. Klausel 4.2 verlangt, dass die Organisation interessierte Parteien und deren Anforderungen versteht, einschließlich gesetzlicher, regulatorischer und vertraglicher Verpflichtungen. Klausel 5.1 verlangt Führung und Verpflichtung. Klausel 6.1.2 verlangt eine Informationssicherheitsrisikobeurteilung. Klausel 6.1.3 verlangt Risikobehandlung. Klausel 8 verlangt operative Planung und Steuerung.

Für privilegierten Zugriff verschiebt dies die Diskussion von „Welches PAM-Werkzeug sollen wir kaufen?“ zu „Welche Risiken behandeln wir, welche Kontrollen wurden ausgewählt, wer ist verantwortlich, wie werden sie betrieben, und welche Nachweise belegen ihre Wirksamkeit?“

PAM ist keine einzelne Kontrolle, sondern eine Nachweiskette

Ein PAM-Werkzeug kann Passwörter in Tresoren verwahren, Sitzungen vermitteln, Tastatureingaben aufzeichnen, Zugangsdaten rotieren und Just-in-time-Zugriff durchsetzen. Diese Fähigkeiten sind wichtig. Hat die Organisation jedoch privilegierte Rollen nicht definiert, Notfallzugriff nicht genehmigt, Zugriff nicht Assets zugeordnet, Rechte nicht überprüft, Protokolle nicht geschützt und Administratoren nicht geschult, wird das Werkzeug zu einer Teilkontrolle mit schwacher Belastbarkeit im Audit.

Der wirksamste Ansatz für die Governance privilegierten Zugriffs besteht darin, in Kontrollergebnissen zu denken, nicht in Werkzeugnamen.

Der Zenith Controls: The Cross-Compliance Guide Zenith Controls behandelt ISO/IEC 27002:2022-Maßnahme 8.2, Privilegierte Zugriffsrechte, als Schwerpunkt von PAM. Er klassifiziert diese Maßnahme als präventiv, unterstützt Vertraulichkeit, Integrität und Verfügbarkeit und ist am Cybersicherheitskonzept Protect, der operativen Fähigkeit Identitäts- und Zugriffsmanagement und der Sicherheitsdomäne Protection ausgerichtet.

Maßnahme 8.2 ist wirkungsvoll, weil sie mit den angrenzenden Maßnahmen verbunden ist, die privilegierten Zugriff prüfbar machen:

Deshalb endet eine Auditfrage selten bei „Haben Sie ein PAM-System?“ Die stärkeren Auditfragen lauten: Gibt es ein Inventar privilegierter Konten? Sind privilegierte Rollen genehmigt? Sind Rechte zeitlich begrenzt? Sind Notfall-Zugangsdaten abgesichert? Können Sie nachweisen, wer sie genutzt hat? Werden Befehle protokolliert? Sind Lieferantenadministratoren einbezogen? Werden Zugriffsrechte überprüft? Wurden Zugangsdaten zurückgesetzt? Wurden Ausnahmen risikobasiert akzeptiert?

Die Zugriffsrechte-Zuordnung in Zenith Controls macht den Punkt direkt: Das Management von Zugriffsrechten operationalisiert Zugriffskontrollprinzipien wie das Prinzip der minimalen Berechtigung, Need-to-know und Autorisierung, während privilegierte Konten besondere Prüfung und einen zeitnahen Widerruf erfordern, sobald sie nicht mehr erforderlich sind.

Richtlinienanforderungen für vertrauenswürdigen Break-Glass-Zugriff

Ein Break-Glass-Konto ist kein gemeinsames Administratorpasswort in einem versiegelten Umschlag. Im Jahr 2026 ist dieses Modell für Cloud, FinTech, SaaS, Gesundheitswesen, Managed Services und regulierte digitale Betriebsumgebungen zu schwach.

Ein belastbares Break-Glass-Modell benötigt sieben Mindestregeln in der Richtlinie:

1. Das Konto muss dokumentiert sein.
2. Das Konto muss genehmigt sein.
3. Die Nutzung muss, soweit technisch möglich, eindeutig zurechenbar sein.
4. Die Nutzung muss auf echte Notfälle beschränkt sein.
5. Die Nutzung muss protokolliert und überprüft werden.
6. Zugangsdaten oder Authentifizierungsfaktoren müssen nach der Nutzung zurückgesetzt oder rotiert werden.
7. Das Konto muss getestet und in den Auditumfang einbezogen werden.

Die Richtlinienbibliothek von Clarysec überführt diese Grundsätze in verwendbare Governance-Sprache.

Die User Account and Privilege Management Policy-sme User Account and Privilege Management Policy - SME legt fest:

„Notfallzugriff (z. B. „Break-Glass“-Administratorkonten) muss klar dokumentiert, abgesichert und nur dann genutzt werden, wenn dies absolut notwendig ist.“

Aus Abschnitt „Risikobehandlung und Ausnahmen“, Richtlinienklausel 7.3.1.

Dieselbe SME-Richtlinie fährt fort:

„Solche Konten müssen protokolliert, nach der Nutzung überprüft und nach jedem Notfallereignis zurückgesetzt werden.“

Aus Abschnitt „Risikobehandlung und Ausnahmen“, Richtlinienklausel 7.3.2.

Für die alltägliche Rechteerweiterung verlangt die SME-Richtlinie außerdem:

„Erhöhte oder administrative Berechtigungen erfordern eine zusätzliche Genehmigung durch die Geschäftsführung oder die IT-Leitung und müssen dokumentiert, zeitlich begrenzt und regelmäßig überprüft werden.“

Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.2.2.

Für größere Organisationen geht der Enterprise-Richtliniensatz weiter. Die User Account and Privilege Management Policy User Account and Privilege Management Policy verlangt:

„Privilegierte Sitzungen müssen vollständig protokolliert werden, einschließlich der ausgeführten Befehle und vorgenommenen Aktionen. Protokolle müssen regelmäßig durch benannte Prüfer überprüft werden.“

Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Richtlinienklausel 6.4.2.

Dieselbe Richtlinie verlangt in Klausel 6.2.5, dass temporäre oder Notfallkonten mit privilegiertem Zugriff einem dokumentierten Break-Glass-Verfahren folgen; Klausel 7.4 beschreibt die Anforderungen an dieses Verfahren.

Die Access Control Policy Access Control Policy stärkt die Aufbewahrung für Auditzwecke:

„Genehmigungsentscheidungen müssen für Auditzwecke protokolliert und mindestens 2 Jahre aufbewahrt werden.“

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.3.2.

Die Logging and Monitoring Policy-sme Logging and Monitoring Policy - SME beschreibt Erwartungen an die Authentifizierungsprotokollierung:

„Authentifizierungsprotokolle: erfolgreiche und fehlgeschlagene Anmeldeversuche, Sitzungsdauer, MFA-Nutzung“

Aus Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.4.2.

Zusammen verwandeln diese Klauseln Notfallzugriff von einem heroischen Ausweichverfahren in ein kontrolliertes Ereignis. Das Konto ist außergewöhnlich, die Governance ist es nicht.

Der Zenith-Blueprint-Ansatz zur Umsetzung von PAM

Der Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandelt privilegierten Zugriff als praktisches Umsetzungsproblem, nicht als theoretische Kontrollaussage. In der Phase Controls in Action, Schritt 19, Technologische Kontrollen I, heißt es:

„In jedem Informationssystem ist privilegierter Zugriff Macht, und mit dieser Macht geht Risiko einher.“

Aus der Phase Controls in Action, Schritt 19: Technologische Kontrollen I.

Schritt 19 verlangt, dass Organisationen privilegierte Konten in On-Premises-, Cloud-, SaaS-, Entwicklungs- und Infrastrukturumgebungen identifizieren. Dazu gehören Domänenadministratoren, Root-Benutzer, Cloud-Tenant-Administratoren, Datenbank-Superuser und Controller von CI/CD-Pipelines. Zudem wird betont, privilegierten Zugriff durch rollenbasierte Zugriffskontrolle (RBAC), Just-in-time-Rechteerweiterung und Genehmigungs-Workflows zu minimieren.

Das ist wichtig, weil viele schwere Vorfälle nicht mit dem formalen Break-Glass-Konto beginnen. Sie beginnen mit dauerhaft bestehenden Berechtigungen. Ein Cloud-Ingenieur behält Owner-Rechte „für den Fall der Fälle“. Ein Datenbankadministrator behält Produktionszugriff nach einem Teamwechsel. Ein CI/CD-Servicekonto verfügt über weitreichende Berechtigungen über Umgebungen hinweg. Ein Managed-Service-Provider-Konto ist von MFA ausgenommen, weil „schneller Zugriff erforderlich ist“.

Schritt 20 des Zenith Blueprint erweitert dieselbe Logik auf privilegierte Hilfsprogramme. Er weist Organisationen an, ein Inventar privilegierter Hilfsprogramme zu erstellen oder zu aktualisieren, die Ausführung auf autorisierte Administratoren zu beschränken, zu verifizieren, dass die Nutzung protokolliert und mit Warnmeldungen versehen ist, und Skriptprotokollierung zu erwägen, etwa PowerShell-Protokollierung über Gruppenrichtlinien. Dies ist kritisch, weil ein privilegiertes Konto häufig nur der Einstiegspunkt ist. Der Schaden entsteht, wenn der Angreifer Werkzeuge ausführt, die Kontrollen deaktivieren, Zugangsdaten auslesen oder laterale Bewegung ermöglichen.

Schritt 22 formalisiert den Zugriffskontrolllebenszyklus. Er fordert strukturierte Bereitstellung und Deprovisionierung, idealerweise integriert mit HR und unterstützt durch Zugriffsanfrage-Workflows, mit quartalsweisen dokumentierten Berechtigungsüberprüfungen. Schritt 16 verknüpft den Lebenszyklus mit dem Offboarding, indem eine Mitarbeiter-Austritts-Checkliste verlangt wird, die HR und IT gemeinsam nutzen, einschließlich Kontodeaktivierung, Rückgabe von Assets und NDA-Erinnerungen.

Der Zenith Blueprint macht PAM zu einem verbundenen Betriebsmodell: Identität, HR, privilegierte Hilfsprogramme, Protokollierung, Incident Response, Berechtigungsüberprüfung und Auditnachweise verstärken sich gegenseitig.

Ein praktisches Governance-Modell für Break-Glass im Jahr 2026

Ein gut konzipierter Break-Glass-Prozess muss während eines Ausfalls funktionieren. Wenn er von demselben Identitätsanbieter, Ticketsystem und Chat-Dienst abhängt, die während der Störung nicht verfügbar sind, ist er nur Theater.

Gleichzeitig darf Notfallzugriff nicht zu einem bequemen Umgehungskanal werden. Clarysec gestaltet Break-Glass-Governance typischerweise in vier Ebenen: Prävention, Aktivierung, Beobachtung und Wiederherstellung.

Für Cloud-Umgebungen sind Tenant-Administratoren, Cloud-Root-Konten, Notfalladministratoren für Identitätsanbieter, privilegierte Servicekonten, Datenbank-Masterbenutzer, Kubernetes-cluster-admin-Rollen, CI/CD-Deploy-Schlüssel, Administratoren von Secrets-Vaults und Supportkonten Dritter einzubeziehen.

Für hybride Umgebungen sind Domänenadministratoren, Backup-Administratoren, Hypervisor-Administratoren, Firewall-Administratoren, EDR-Konsolenadministratoren und Benutzer privilegierter Hilfsprogramme einzubeziehen.

Für datenschutzsensitive Umgebungen sind Administratoren einzubeziehen, die auf Datenbanken mit personenbezogenen Daten, Protokolle mit Kennungen, HR-Aufzeichnungen, biometrische Daten zur Identitätsprüfung, Betrugsüberwachungssysteme oder Kundensupport-Werkzeuge zugreifen können.

Der Zielzustand ist leicht zu beschreiben und schwer vorzutäuschen: Jeder Notfallpfad ist bekannt, genehmigt, abgesichert, beobachtbar, reversibel und überprüft.

Eine 60-minütige Break-Glass-Nachweisübung

Ein CISO oder Compliance-Verantwortlicher kann diese Woche eine nützliche Break-Glass-Übung durchführen, ohne ein neues Werkzeug zu kaufen. Das Ziel besteht nicht nur darin zu bestätigen, dass das Konto funktioniert. Das Ziel besteht darin zu belegen, dass die Kontrolle Nachweise erzeugt.

Szenario

Angenommen, der primäre Identitätsanbieter ist beeinträchtigt. Die reguläre Just-in-time-Rechteerweiterung ist nicht verfügbar. Ein Produktionsdatenbank-Cluster benötigt Notfall-Konfigurationsänderungen, um den Service wiederherzustellen. Das Break-Glass-Cloud-Administratorkonto muss aktiviert werden.

Schritt 1: Bestätigen, dass das Konto im privilegierten Inventar enthalten ist

Nutzen Sie den Zenith Blueprint, Phase Controls in Action, Schritt 19, um zu validieren, dass das Konto im Inventar privilegierter Konten aufgeführt ist. Erfassen Sie Kontoname und Umgebung, Geschäftsinhaber, technischen Verantwortlichen, erreichbare Systeme, Auswirkungen auf personenbezogene Daten, Authentifizierungsmethode, Tresor-Speicherort, Rotationsmethode und Datum des letzten Tests.

Fehlt das Konto, behandeln Sie dies als Kontrolllücke und nehmen Sie es in das Risikoregister auf.

Schritt 2: Richtlinienkonformität prüfen

Ordnen Sie das Ereignis den Anforderungen der User Account and Privilege Management Policy an dokumentierte Break-Glass-Verfahren und privilegierte Sitzungsprotokollierung zu. Wenn Sie ein SME sind, verwenden Sie die Klauseln 7.3.1 und 7.3.2 der User Account and Privilege Management Policy-sme als Mindestbaseline: dokumentiert, abgesichert, erforderlich, protokolliert, überprüft und zurückgesetzt.

Ordnen Sie die Aufbewahrung von Genehmigungen Klausel 5.3.2 der Access Control Policy zu, die verlangt, dass Genehmigungsentscheidungen protokolliert und mindestens 2 Jahre aufbewahrt werden.

Schritt 3: Einen Notfallzugriffsdatensatz eröffnen

Erstellen Sie vor oder bei der Aktivierung ein Ticket oder einen Vorfallsdatensatz. Nehmen Sie Folgendes auf:

• Notfallgrund
• Betroffener Service
• Angefordertes Konto
• Antragsteller
• Genehmigender
• Startzeit
• Erwartete Endzeit
• Kunden- oder regulatorische Auswirkung
• Auswirkung auf personenbezogene Daten nach GDPR
• Überwachungskennzeichen für NIS2- oder DORA-Meldung

Warten Sie nicht bis zum Ende, um die Geschichte zu rekonstruieren. Der Auditwert ist am höchsten, wenn der Datensatz beginnt, bevor der Zugriff genutzt wird.

Schritt 4: Aktivieren und beobachten

Aktivieren Sie das Break-Glass-Konto. Bestätigen Sie, dass MFA oder eine kompensierende Authentifizierung verwendet wird, die Sitzung aufgezeichnet wird, Befehle oder administrative Aktionen protokolliert werden, Protokolle an eine zentrale Protokollierung weitergeleitet werden, die Zeitsynchronisierung die Rekonstruktion der Zeitachse unterstützt und eine Warnmeldung für die Nutzung des Notfallkontos erzeugt wird.

Dies steht im Einklang mit Zenith Controls für 8.15 Protokollierung, wo Protokollierung als grundlegende Datenschicht für die Überwachung beschrieben wird und darauf hingewiesen wird, dass privilegierte Benutzer und die Ausführung privilegierter Hilfsprogramme umfassend protokolliert werden müssen.

Schritt 5: Schließen, zurücksetzen und überprüfen

Nach der Notfallaufgabe deaktivieren Sie das Konto oder versetzen es wieder in den versiegelten Status, rotieren Zugangsdaten oder setzen den Authentifizierungsfaktor zurück, überprüfen Sitzungsprotokolle, dokumentieren Befehle und Konfigurationsänderungen, bestätigen, dass kein unnötiger Datenzugriff stattgefunden hat, aktualisieren den Vorfallsdatensatz, erfassen Lessons Learned und entscheiden, ob Meldegrenzen nach NIS2, DORA oder GDPR ausgelöst werden.

Wenn auf personenbezogene Daten zugegriffen wurde, binden Sie den Datenschutzbeauftragten ein. Wenn das Ereignis eine Serviceunterbrechung verursacht hat oder wesentliche Auswirkungen haben könnte, binden Sie den Verantwortlichen für NIS2- oder DORA-Meldungen ein. Wenn das Break-Glass-Konto nicht funktioniert hat, dokumentieren Sie dies als Feststellung zur operativen Resilienz, nicht lediglich als IAM-Problem.

Cross-Compliance-Zuordnung für PAM- und Break-Glass-Kontrollen

Das stärkste Governance-Modell dupliziert keine Kontrollen für jede Regulierung. Es baut eine Nachweiskette auf, die mehrere Verpflichtungen unterstützt.

NIST CSF 2.0 ist besonders nützlich, wenn PAM in ein Current Profile und Target Profile übersetzt wird. Die Profilmethode beginnt mit dem Geltungsbereich und sammelt anschließend Richtlinien, Risikoprioritäten, Register, Anforderungen, Praktiken und Arbeitsrollen, bevor ein priorisierter Maßnahmenplan erstellt wird. Für privilegierten Zugriff bedeutet dies, das Profil auf Identitätssicherheit, Cloud-Administration, Ransomware-Resilienz, kritische Finanzsysteme oder Lieferantenzugriff auszurichten.

Für Finanzunternehmen im Anwendungsbereich von DORA fungiert DORA als sektorspezifisches EU-Cyberresilienzregime für gleichwertige NIS2-Risiko- und Vorfallverpflichtungen. Das macht NIS2 nicht irrelevant. Es bedeutet, dass das Finanzunternehmen DORA als maßgebliches Regime für IKT-Risiko- und Vorfallanforderungen verwenden sollte und zugleich die Koordination mit nationalen Cybersicherheitsstrategien, zuständigen Behörden und CSIRTs aufrechterhält, soweit anwendbar.

Wie Auditoren Nachweise für privilegierten Zugriff testen

Auditoren bewerten PAM nicht nur durch Lesen von Richtlinien. Sie triangulieren Richtlinie, Konfiguration, Protokolle, Tickets, Interviews und beobachtete Praxis.

Die Auditmethodik von Zenith Controls für privilegierte Zugriffsrechte verweist auf Auditpraktiken nach ISO/IEC 19011:2018. Auditoren prüfen Richtlinien, die erhöhte Rechte, Bereitstellung, Überwachung und Widerrufsverfahren definieren. Sie untersuchen Benutzerkonteninventare, Aufzeichnungen zur Berechtigungszuweisung und Protokolle. Sie bestätigen Nachweise durch Interviews, PAM-Werkzeuge, Verzeichnisdienste und Protokollstichproben.

Für Zugriffsrechte stellt Zenith Controls fest, dass Auditoren Benutzerzugriffsanfragen stichprobenartig prüfen, dokumentierte Genehmigungen verifizieren und bestätigen, dass die IT nur genehmigten Zugriff vergeben hat. Sie vergleichen außerdem Benutzerrollen mit tatsächlichen Rechten und prüfen, ob das Prinzip der minimalen Berechtigung durchgesetzt wird. Für die Protokollierung prüfen Auditoren Protokollierungsumfang, Ereignistypen, Aufbewahrungsfristen, Schutzmaßnahmen und tatsächliche Protokolleinträge. Sie bewerten, ob fehlgeschlagene Anmeldungen, Zugriff auf sensible Daten und Konfigurationsänderungen erfasst und überprüft werden.

Ein gutes Break-Glass-Nachweispaket umfasst:

• Genehmigte Notfallzugriffsanfrage
• Vorfalls- oder Störungskontext
• Identität des Benutzers, der den Zugriff aktiviert
• Identität des Genehmigenden
• Start- und Endzeit
• MFA- oder Authentifizierungsnachweis
• Sitzungsaufzeichnung oder Befehlsprotokoll
• Systemprotokolle und SIEM-Warnmeldung
• Vorgenommene Änderungen
• Bestätigung des Zurücksetzens von Zugangsdaten
• Überprüfung nach der Nutzung
• Bewertung des Datenzugriffs
• Bewertung regulatorischer Meldepflichten
• Korrekturmaßnahmen, falls etwas fehlgeschlagen ist

Wenn Ihre Übung dieses Paket nicht erzeugen kann, ist die Kontrolle nicht auditbereit.

Das verborgene Versagen: privilegierter Drittparteienzugriff

Viele Organisationen steuern Mitarbeiteradministratoren besser als Lieferantenadministratoren. Für Cloud-, SaaS-, FinTech- und Managed-Service-Umgebungen ist das verkehrt herum.

NIS2 Article 21 umfasst Sicherheit der Lieferkette und Beziehungen zu direkten Lieferanten und Serviceanbietern. DORA Articles 28 bis 30 gehen für Finanzunternehmen weiter und verlangen eine IKT-Drittparteienrisikostrategie, Register der IKT-Serviceverträge, gebotene Sorgfalt, Bewertung von Konzentrationsrisiken, Auditrechte, Kündigungsrechte, Exit-Strategien und vertragliche Sicherheitsmaßnahmen.

Privilegierter Lieferantenzugriff sollte im PAM-Geltungsbereich liegen, wenn der Lieferant Produktivsysteme administrieren, kritische oder wichtige Funktionen unterstützen, auf personenbezogene Daten zugreifen, Sicherheitskonfigurationen ändern, Backups verwalten, Code bereitstellen oder Überwachungswerkzeuge betreiben kann.

Clarysec erwartet typischerweise, dass Kontrollen für privilegierten Lieferantenzugriff Folgendes umfassen:

• Namentlich benannte Lieferantenbenutzer, keine gemeinsamen Lieferantenkonten
• Vertragliche Sicherheitsanforderungen für privilegierten Zugriff
• MFA und sicherer Fernzugriff
• Zeitlich begrenzte Zugriffsfenster
• Kundengenehmigung für Notfallzugriff
• Sitzungsprotokollierung oder gleichwertige Prüfpfade
• Sofortiger Widerruf bei Personalwechsel
• Verpflichtungen zur Zusammenarbeit bei Vorfällen
• Aufbewahrung von Nachweisen abgestimmt auf Auditbedarfe des Kunden
• Exit-Plan zur Entfernung von Lieferantenzugriff

Die Ergebnisse zur Lieferkette in NIST CSF 2.0 passen hier sehr gut. Sie fordern Rollen und Verantwortlichkeiten von Lieferanten, Priorisierung von Lieferanten nach Kritikalität, Anforderungen in Verträgen, gebotene Sorgfalt, laufende Überwachung, Einbindung von Lieferanten in die Vorfallplanung und Risikopläne nach Vertragsende.

Wenn ein Managed-Service-Provider-Konto von Ihrem internen PAM-Workflow ausgenommen ist, ist das keine Bequemlichkeit. Es ist eine risikoreiche Ausnahme, die in das Risikoregister, das Lieferantenregister und die Berechtigungsüberprüfung gehört.

Häufige PAM- und Break-Glass-Feststellungen im Jahr 2026

In Clarysec-Engagements sind die Feststellungen selten überraschend. Meist handelt es sich um Kombinationen aus guten Absichten, operativem Druck und unvollständigen Nachweisen.

Die häufigsten Feststellungen sind:

• Break-Glass-Konten existieren, sind aber nicht im Inventar privilegierter Konten aufgeführt.
• Notfallkonten sind von regulären Berechtigungsüberprüfungen ausgenommen.
• Die Organisation kann nicht nachweisen, wer ein Notfallkonto genutzt hat.
• Das Konto wurde nach der Nutzung nicht zurückgesetzt.
• Privilegierte Sitzungen werden protokolliert, Befehle jedoch nicht.
• Protokolle existieren lokal, sind aber nicht vor privilegierten Benutzern geschützt.
• Cloud-Root-Konten werden nicht getestet.
• MFA-Wiederherstellungsprozesse sind nicht dokumentiert.
• Privilegierter Zugriff für CI/CD-Pipelines und Servicekonten wird ignoriert.
• Drittparteien-Supportzugriff umgeht interne Genehmigung.
• Zugriffsgenehmigungen liegen in Chat-Nachrichten vor, werden aber nicht als Auditnachweis aufbewahrt.
• Offboarding entfernt E-Mail und VPN, aber nicht SaaS-Administratorrechte.
• Der Datenschutzbeauftragte wird nicht einbezogen, wenn privilegierter Zugriff personenbezogene Daten offenlegen kann.
• Incident-Playbooks enthalten keine Entscheidungspunkte für Meldungen nach NIS2, DORA oder GDPR.

Jede Feststellung kann über ISO/IEC 27001:2022-Risikobehandlung behandelt werden. Identifizieren Sie das Risiko, weisen Sie einen Verantwortlichen zu, wählen Sie Kontrollen aus, aktualisieren Sie die Anwendbarkeitserklärung, setzen Sie den Behandlungsplan um und bewahren Sie dokumentierte Nachweise auf. Das ist die Stärke eines ISMS anstelle einer verstreuten Sammlung von Sicherheitsaufgaben.

Wie gute Praxis aussieht

Ein reifes PAM- und Break-Glass-Betriebsmodell verfügt über fünf wiederkehrende Routinen.

Erstens: privilegierten Zugriff monatlich oder kontinuierlich inventarisieren. Beziehen Sie menschliche Administratoren, Servicekonten, Notfallkonten, Cloud-Rollen, CI/CD-Identitäten, Datenbankbenutzer, privilegierte Hilfsprogramme und Drittparteienadministratoren ein.

Zweitens: das Prinzip der minimalen Berechtigung durch Rollen, Just-in-time-Rechteerweiterung und Genehmigungen durchsetzen. Dauerhafte Berechtigungen müssen selten, begründet und häufiger überprüft werden als Standardbenutzerzugriffe.

Drittens: privilegiertes Verhalten überwachen. Protokollieren Sie Authentifizierung, Sitzungsdauer, MFA-Nutzung, Befehle, Konfigurationsänderungen, Datenexporte, fehlgeschlagene Versuche, Rechteerweiterung und Ausführung privilegierter Hilfsprogramme.

Viertens: Break-Glass-Konten vor dem Notfall testen. Ein Break-Glass-Konto, das nie getestet wurde, ist eine Annahme, keine Kontrolle.

Fünftens: an das Management berichten. NIS2 und DORA heben Cybersicherheit und IKT-Risiko beide in die Verantwortung des Leitungsorgans. Das Leitungsorgan benötigt nicht jedes Befehlsprotokoll, aber Kennzahlen: Anzahl privilegierter Konten, überfällige Überprüfungen, Notfallaktivierungen, Lieferantenadministratorkonten, fehlgeschlagene Tests, kritische Ausnahmen und Status der Mängelbehebung.

Hier wird das Toolkit von Clarysec praktisch. Die Richtlinienbibliothek liefert die Governance-Sprache. Der Zenith Blueprint liefert die Umsetzungssequenz. Zenith Controls liefert die Cross-Compliance-Zuordnung, Kontrollbeziehungen, unterstützende Standards und Auditmethodik.

Nächste Schritte: Notfallzugriff in auditbereite Resilienz verwandeln

Wenn Ihre Organisation Break-Glass-Zugriff in den letzten 90 Tagen nicht getestet hat, beginnen Sie dort. Starten Sie nicht mit einem Workshop zur Werkzeugauswahl. Beginnen Sie mit Nachweisen.

1. Erstellen oder aktualisieren Sie Ihr Inventar privilegierter Konten.
2. Identifizieren Sie jedes Break-Glass-Konto und jeden Notfall-Administratorpfad.
3. Ordnen Sie jedes Konto dem Geschäftsinhaber, Systemverantwortlichen und den Datenauswirkungen zu.
4. Bestätigen Sie die Richtlinienabdeckung mit Clarysecs User Account and Privilege Management Policy User Account and Privilege Management Policy oder User Account and Privilege Management Policy-sme User Account and Privilege Management Policy - SME.
5. Nutzen Sie den Zenith Blueprint Zenith Blueprint, Phase Controls in Action, Schritte 19, 20, 22 und 16, um privilegierten Zugriff, privilegierte Hilfsprogramme, Lebenszyklusüberprüfungen und Offboarding zu verbinden.
6. Nutzen Sie Zenith Controls Zenith Controls, um ISO/IEC 27002:2022-Maßnahmen 8.2, 5.18 und 8.15 den Nachweiserwartungen von NIS2, DORA, GDPR und NIST zuzuordnen.
7. Führen Sie eine Break-Glass-Nachweisübung durch und zeichnen Sie die Ergebnisse auf.
8. Nehmen Sie Lücken in den Risikobehandlungsplan auf und verfolgen Sie die Mängelbehebung bis zum Abschluss.

Privilegierter Zugriff ist Macht. Break-Glass-Zugriff ist Notfallmacht. Im Jahr 2026 werden diejenigen Organisationen sauber von Ransomware, Cloud-Ausfällen und Identitätsstörungen wiederherstellen, die nachweisen können, dass Notfallzugriff vor, während und nach der Krise kontrolliert war.

Clarysec kann Ihnen helfen, diesen Nachweis aufzubauen, von Richtlinien über Kontrollzuordnung bis zu auditfähigen Nachweisen. Beginnen Sie mit dem Zenith Blueprint, kombinieren Sie ihn mit der User Account and Privilege Management Policy und der Access Control Policy, und nutzen Sie anschließend Zenith Controls, um zu zeigen, wie Ihr PAM-Programm ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 und COBIT 2019 unterstützt.