ISO 27001-Leitfaden zu Auditnachweisen für Zugriffskontrolle

Es ist 09:10 Uhr am Audittag. Maria, CISO einer schnell wachsenden FinTech- und Cloud-Plattform, hat ihre Richtlinie zur Zugriffskontrolle geöffnet. Die IT-Leitung exportiert Conditional-Access-Einstellungen aus dem Identitätsanbieter. HR sucht nach dem Austrittsticket eines Finanzanalysten, der das Unternehmen vor sechs Wochen verlassen hat. Der interne Auditor blickt auf und stellt die Frage, mit der alle gerechnet haben:
„Zeigen Sie mir, wie Zugriff für einen Benutzer mit privilegiertem Zugriff auf personenbezogene Daten beantragt, genehmigt, durchgesetzt, überprüft und entzogen wird.“
Dieser eine Satz kann offenlegen, ob ein Zugriffskontrollprogramm auditfähig ist oder lediglich auf dem Papier gut aussieht.
Marias Team verfügte über ein ausgereiftes Informationssicherheits-Managementsystem, einen jährlichen Rezertifizierungszyklus nach ISO/IEC 27001:2022, implementierte Multi-Faktor-Authentifizierung, rollenbasierte Zugriffskontrollen in Kernsystemen und vierteljährliche Tabellen zur Berechtigungsüberprüfung. Dieses Audit war jedoch anders. Die Anforderungsliste des Auditors umfasste auch die Vorbereitung auf neue regulatorische Anforderungen. Für Marias Organisation bedeutete das NIS2, DORA und GDPR, betrachtet durch dieselbe operative Perspektive: Identität, Zugriff, Authentifizierung, Berechtigung und Nachweise.
Das Problem vieler CISOs besteht nicht darin, dass Zugriffskontrolle nicht existiert. Das Problem ist, dass Nachweise fragmentiert vorliegen. Onboarding-Genehmigungen liegen in Jira oder ServiceNow. MFA-Einstellungen befinden sich in Microsoft Entra ID, Okta oder einem anderen Identitätsanbieter. Berechtigungen für AWS, Azure und Google Cloud liegen in separaten Konsolen. Privilegierte Aktionen werden vielleicht in einem PAM-Werkzeug protokolliert, vielleicht aber auch gar nicht. Der HR-Status befindet sich in BambooHR, Workday oder Tabellen. Berechtigungsüberprüfungen werden möglicherweise per E-Mail freigegeben.
Wenn ein Auditor IAM, MFA, PAM, Ereignisse aus Eintritts-, Wechsel- und Austrittsprozessen, personenbezogene Daten, Cloud-Administration und regulatorische Erwartungen miteinander verknüpft, zerfallen fragmentierte Nachweise sehr schnell.
Audits zur Zugriffskontrolle nach ISO/IEC 27001:2022 sind nicht nur technische Konfigurationsprüfungen. Sie sind Prüfungen des Managementsystems. Sie untersuchen, ob Identitäts- und Zugriffsrisiken verstanden, behandelt, umgesetzt, überwacht und verbessert werden. Wenn NIS2, DORA und GDPR ebenfalls relevant sind, müssen dieselben Nachweise risikobasierte Zugriffsgovernance, starke Authentifizierung, nachvollziehbare Genehmigungen, fristgerechten Entzug von Zugriffsrechten, Beschränkung von Berechtigungen, Schutz personenbezogener Daten und Rechenschaftspflicht des Managements belegen.
Die praktische Antwort ist kein größerer Ordner. Sie besteht in einem einheitlichen Nachweismodell für Zugriffskontrolle, das beim ISMS-Geltungsbereich und den Risiken beginnt, über Richtlinien- und Kontrolldesign in IAM- und PAM-Werkzeuge überführt wird und sauber auf ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST und COBIT abgebildet ist.
Warum Zugriffskontrolle der regulatorische Dreh- und Angelpunkt ist
Zugriffskontrolle ist zu einem Thema für Leitungsorgane und Aufsichtsbehörden geworden, weil kompromittierte Identitäten inzwischen ein häufiger Weg zu Betriebsunterbrechungen, Datenpannen, Betrug und Exponierung in der Lieferkette sind.
Nach NIS2 bringen Articles 2 und 3 in Verbindung mit Annex I und Annex II viele mittlere und größere Einrichtungen in aufgeführten Sektoren als wesentliche oder wichtige Einrichtungen in den Geltungsbereich. Dazu gehören digitale Infrastruktur und Anbieter von IKT-Service-Management, etwa Cloud-Computing-Service-Provider, Rechenzentrumsdienstleister, Managed Service Provider und Managed Security Service Provider. Die Mitgliedstaaten mussten NIS2 bis Oktober 2024 umsetzen und nationale Maßnahmen ab Oktober 2024 anwenden; Listen der Einrichtungen sind bis April 2025 vorzulegen. Article 20 macht Leitungsorgane dafür verantwortlich, Maßnahmen zum Cybersicherheits-Risikomanagement zu genehmigen und deren Umsetzung zu überwachen. Article 21 verlangt technische, operative und organisatorische Maßnahmen, einschließlich Richtlinien zur Zugriffskontrolle, Richtlinien für Asset-Management, Cyberhygiene, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Aufrechterhaltung des Geschäftsbetriebs, Sicherheit der Lieferkette sowie MFA oder kontinuierliche Authentifizierung, soweit angemessen.
DORA ergänzt für Finanzunternehmen und relevante IKT-Drittdienstleister eine sektorspezifische Ebene operativer Resilienz. Articles 1, 2 und 64 legen DORA als einheitliches Rahmenwerk fest, das ab dem 17. Januar 2025 gilt. Articles 5 und 6 verlangen Governance und ein dokumentiertes Rahmenwerk für das Management von IKT-Risiken. Article 9 behandelt Schutz und Prävention, einschließlich IKT-Sicherheitsrichtlinien, Verfahren, Protokollen und Werkzeugen. Articles 24 bis 30 ergänzen Tests der digitalen operationalen Resilienz und das Management von IKT-Drittparteienrisiken. Für Finanzunternehmen werden Nachweise zur Zugriffskontrolle damit zu Resilienznachweisen, nicht nur zu Nachweisen der IT-Administration.
GDPR bringt die Perspektive personenbezogener Daten ein. Articles 2 und 3 definieren einen breiten Anwendungsbereich für die Verarbeitung in der EU und die Ausrichtung auf den EU-Markt. Article 5 verlangt Integrität, Vertraulichkeit und nachweisbare Rechenschaftspflicht. Article 25 verlangt Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen. Article 32 verlangt geeignete technische und organisatorische Maßnahmen. In der Praxis bedeutet dies kontrollierten Zugriff, sichere Authentifizierung, Protokollierung, Überprüfung und fristgerechte Entfernung für Systeme, die personenbezogene Daten verarbeiten.
ISO/IEC 27001:2022 stellt Organisationen den Managementsystem-Mechanismus bereit, um diese Verpflichtungen zu bündeln. Clauses 4.1 bis 4.3 verlangen, dass die Organisation Kontext, interessierte Parteien, gesetzliche und vertragliche Anforderungen, Schnittstellen, Abhängigkeiten und den ISMS-Geltungsbereich versteht. Clauses 6.1.1 bis 6.1.3 verlangen Informationssicherheitsrisikobeurteilung, Risikobehandlung, Vergleich mit Annex A, eine Anwendbarkeitserklärung und Genehmigung von Behandlungsplänen und Restrisiko. Clause 8.1 verlangt operative Steuerung, dokumentierte Informationen darüber, dass Prozesse wie geplant durchgeführt wurden, Änderungssteuerung und Steuerung extern bereitgestellter Prozesse.
Die Auditfrage lautet daher nicht: „Haben Sie MFA?“ Sie lautet: „Können Sie für Identitäten und Systeme im Geltungsbereich nachweisen, dass Zugriffsrisiken gesteuert, behandelt, umgesetzt, überwacht und verbessert werden?“
Die Nachweiskette vom ISMS-Geltungsbereich bis zum IAM-Nachweis aufbauen
Clarysec beginnt die Auditvorbereitung für Zugriffskontrolle damit, Nachweise aus dem geschäftlichen Kontext heraus nachvollziehbar zu machen. ISO/IEC 27001:2022 erwartet, dass das ISMS in Organisationsprozesse integriert und an die Bedürfnisse der Organisation angepasst ist. Ein SaaS-Anbieter mit 30 Personen und eine multinationale Bank werden nicht dieselbe Zugriffsarchitektur haben, aber beide benötigen eine schlüssige Nachweiskette.
| Nachweisebene | Was sie belegt | Typische Quellsysteme | Wert für mehrere Regelwerke |
|---|---|---|---|
| ISMS-Geltungsbereich und Anforderungen interessierter Parteien | Welche Systeme, Daten, Vorschriften und Drittparteienabhängigkeiten im Geltungsbereich liegen | ISMS-Geltungsbereich, Compliance-Register, Dateninventar, Lieferantenregister | Unterstützt ISO/IEC 27001:2022 Clauses 4.2 und 4.3, NIS2-Scoping, Abbildung von IKT-Abhängigkeiten nach DORA, Rechenschaftspflicht nach GDPR |
| Zugriffsrisikobeurteilung | Warum IAM, MFA, PAM und Überprüfungen risikobasiert erforderlich sind | Risikoregister, Bedrohungsszenarien, Behandlungsplan | Unterstützt ISO/IEC 27001:2022 Clause 6.1, ISO/IEC 27005:2022, IKT-Risikomanagementrahmen nach DORA, Risikomaßnahmen nach NIS2 |
| Richtlinien und Standards | Was die Organisation verlangt | Richtlinie zur Zugriffskontrolle, Berechtigungsrichtlinie, Richtlinie für Onboarding und Austritt | Übersetzt regulatorische Erwartungen in verbindliche interne Regeln |
| IAM- und PAM-Konfiguration | Ob Kontrollen technisch umgesetzt sind | IdP, HRIS, ITSM, PAM, Cloud-IAM, SaaS-Administrationskonsolen | Belegt Prinzip der minimalen Berechtigung, MFA, RBAC, Genehmigungs-Workflows und Kontrollen für privilegierte Sitzungen |
| Überprüfungs- und Überwachungsaufzeichnungen | Ob Zugriff im Zeitverlauf angemessen bleibt | Berechtigungsrezertifizierungskampagnen, SIEM, PAM-Protokolle, Bestätigungen durch Vorgesetzte | Belegt laufenden Kontrollbetrieb, Überwachung nach DORA, Cyberhygiene nach NIS2, Datenminimierung nach GDPR |
| Offboarding- und Ausnahmeaufzeichnungen | Ob Zugriff entzogen und Ausnahmen gesteuert werden | HR-Austrittsliste, Deaktivierungsprotokolle, Ausnahmenregister | Belegt fristgerechten Entzug von Zugriffsrechten, Restrisikoakzeptanz und Vermeidung von Verstößen |
ISO/IEC 27005:2022 ist nützlich, weil die Norm empfiehlt, gesetzliche, regulatorische, vertragliche, branchenspezifische und interne Anforderungen in einem gemeinsamen Risikokontext zusammenzuführen. Clauses 6.4 und 6.5 betonen Risikokriterien, die organisatorische Ziele, Gesetze, Lieferantenbeziehungen und Einschränkungen berücksichtigen. Clauses 7.1 und 7.2 ermöglichen ereignisbasierte und assetbasierte Szenarien. Für Zugriffskontrolle bedeutet das, strategische Szenarien wie „privilegierter SaaS-Administrator exportiert EU-Kundendaten“ zusammen mit Asset-Szenarien wie „verwaister AWS-IAM-Schlüssel ist an Produktivspeicher angebunden“ zu bewerten.
In Clarysecs Zenith Blueprint: 30-Schritte-Roadmap eines Auditors wird diese Nachweiskette in der Phase „Kontrollen in der Praxis“ aufgebaut. Schritt 19 konzentriert sich auf technische Maßnahmen für Endpoint- und Zugriffsmanagement, während Schritt 22 den organisatorischen Zugriffslebenszyklus formalisiert.
Der Zenith Blueprint weist Teams an zu prüfen, ob Provisionierung und Deprovisionierung strukturiert sind, soweit möglich mit HR integriert werden, durch Zugriffsanfrage-Workflows unterstützt und vierteljährlich überprüft werden. Außerdem verlangt er, Identitätstypen zu dokumentieren, Kontrollen für individuelle, gemeinsame und Serviceidentitäten durchzusetzen, starke Passwortrichtlinien und MFA anzuwenden, inaktive Konten zu beseitigen und sichere Aufbewahrung in Tresoren oder Dokumentation für Service-Zugangsdaten vorzuhalten.
Genau so testen Auditoren Zugriffskontrolle: jeweils eine Identität, ein System, eine Genehmigung, eine Berechtigung, eine Überprüfung und ein Entzug von Zugriffsrechten.
Was für auditfähige Nachweise zur Zugriffskontrolle zu sammeln ist
Ihr Nachweispaket zur Zugriffskontrolle sollte es einem Auditor ermöglichen, beliebige Benutzer auszuwählen und den Lebenszyklus nachzuvollziehen: Antrag, Genehmigung, Zuweisung, Authentifizierung, erhöhte Berechtigung, Überwachung, Überprüfung und Entzug von Zugriffsrechten.
Ein belastbares Nachweispaket umfasst:
- Richtlinie zur Zugriffskontrolle und Richtlinie für Benutzerkonten
- Verfahren für Eintritts-, Wechsel- und Austrittsprozesse
- Rollenmatrix oder Zugriffskontrollmatrix
- Liste der Anwendungen, Plattformen und Datenablagen im Geltungsbereich
- MFA-Konfiguration des Identitätsanbieters
- Conditional-Access-Richtlinien und Ausnahmenliste
- Inventar privilegierter Konten
- PAM-Workflow-Nachweise, einschließlich Genehmigungen und Sitzungsprotokollen
- Aktuelle Ergebnisse von Berechtigungsrezertifizierungskampagnen
- Stichproben von Manager-Bestätigungen und Abhilfemaßnahmen
- HR-Austrittsbericht, abgeglichen mit Deaktivierungsprotokollen
- Inventar von Servicekonten, Verantwortliche, Rotationsaufzeichnungen und Nachweise aus Schlüsselablagen
- Verfahren für Break-Glass-Konten und Testprotokoll
- Nachweise zu Vorfällen oder Warnmeldungen im Zusammenhang mit fehlgeschlagenen Anmeldungen, Privilegieneskalation oder inaktiven Konten
- Einträge in der Anwendbarkeitserklärung für zugriffsbezogene Annex A-Maßnahmen
Clarysec-Richtlinien machen diese Erwartung ausdrücklich. In der SME-Richtlinie zur Zugriffskontrolle ist die Anforderung einfach und auditfokussiert:
„Für jede Bereitstellung, Änderung und Entfernung von Zugriff muss eine sichere Aufzeichnung geführt werden.“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Clause 6.1.1.
Dieselbe SME-Richtlinie verknüpft RBAC und MFA außerdem direkt mit Rollenverantwortlichkeiten:
„Implementiert rollenbasierte Zugriffskontrollen (RBAC) und setzt starke Authentifizierung durch, z. B. Multi-Faktor-Authentifizierung (MFA).“
Aus Abschnitt „Rollen und Verantwortlichkeiten“, Clause 4.2.3.
Für größere Organisationen verlangt die Unternehmens-Richtlinie für Onboarding und Austritt, dass das IAM-System Kontoerstellung, Rollen- und Berechtigungszuweisungen sowie Deaktivierungsereignisse protokolliert, rollenbasierte Zugriffsvorlagen unterstützt und mit HR-Systemen für Auslöser aus Eintritts-, Wechsel- und Austrittsprozessen integriert ist. Diese Clause hilft, die Auditdarstellung an einer Stelle zusammenzuführen: standardisiertes Onboarding, HR-ausgelöster Identitätslebenszyklus und nachvollziehbare IAM-Ereignisse.
IAM, MFA, PAM und Überprüfungen auf ISO/IEC 27001:2022-Maßnahmen abbilden
Clarysecs Zenith Controls: Leitfaden für regelwerksübergreifende Compliance behandelt Zugriffskontrolle als zusammenhängende Maßnahmenfamilie, nicht als Checklistenpunkt. Für ISO/IEC 27001:2022 sind insbesondere folgende Maßnahmen relevant:
- Control 5.15, Zugriffskontrolle
- Control 5.16, Identitätsmanagement
- Control 5.17, Authentifizierungsinformationen
- Control 5.18, Zugriffsrechte
- Control 8.2, Privilegierte Zugriffsrechte
- Control 8.3, Einschränkung des Informationszugriffs
- Control 8.5, Sichere Authentifizierung
- Control 8.15, Protokollierung
- Control 8.16, Überwachungstätigkeiten
Für Authentifizierungsinformationen ordnet Zenith Controls Control 5.17 als präventive Maßnahme ein, die Vertraulichkeit, Integrität und Verfügbarkeit unterstützt, mit der operativen Fähigkeit des Identitäts- und Zugriffsmanagements. Die Zuordnung verbindet die Maßnahme direkt mit Identitätsmanagement, sicherer Authentifizierung, Rollen und Verantwortlichkeiten, zulässiger Nutzung und Einhaltung von Richtlinien. Zugangsdaten-Sicherheit umfasst den Lebenszyklus von Authentifikatoren, sichere Ausgabe, Speicherung, Zurücksetzung, Widerruf, MFA-Token, private Schlüssel und Service-Zugangsdaten.
Für Zugriffsrechte ordnet Zenith Controls Control 5.18 der formalen Vergabe, Überprüfung, Änderung und dem Entzug zu. Die Maßnahme ist mit Zugriffskontrolle, Identitätsmanagement, Funktionstrennung, privilegierten Zugriffsrechten und kontinuierlicher Compliance-Überwachung verknüpft. Diese Maßnahme übersetzt das Prinzip der minimalen Berechtigung in Nachweise.
Für privilegierte Zugriffsrechte ordnet Zenith Controls Control 8.2 dem besonderen Risiko erhöhter Konten zu, einschließlich Domänenadministratoren, Root-Benutzern, Cloud-Tenant-Administratoren, Datenbank-Superusern und CI/CD-Controllern. Der Leitfaden verknüpft privilegierten Zugriff mit Identitätsmanagement, Zugriffsrechten, Einschränkung des Informationszugriffs, sicherer Authentifizierung, Remote-Arbeit, Protokollierung und Überwachung.
| Auditthema | Zugriffsnachweise nach ISO/IEC 27001:2022 | NIS2-Zuordnung | DORA-Zuordnung | GDPR-Zuordnung |
|---|---|---|---|---|
| IAM-Lebenszyklus | Workflow für Eintritts-, Wechsel- und Austrittsprozesse, Zugriffsanfragen, Genehmigungen, Rollenvorlagen, Deaktivierungsprotokolle | Article 21 Maßnahmen zum Risikomanagement, Richtlinien zur Zugriffskontrolle und Richtlinien für Asset-Management | Articles 5, 6 und 9 Governance, IKT-Rahmenwerk für Risikomanagement, logische Sicherheit und Zugriffskontrolle | Articles 5, 25 und 32 Rechenschaftspflicht, Minimierung und Sicherheit |
| MFA | IdP-Richtlinie, Conditional-Access-Screenshots, MFA-Registrierungsstatistiken, Ausnahmegenehmigungen | Article 21(2)(j) MFA oder kontinuierliche Authentifizierung, soweit angemessen | Sicherer Zugriff auf kritische IKT-Systeme und IKT-Risikokontrollen | Geeignete technische Maßnahmen gegen unbefugten Zugriff |
| PAM | Inventar privilegierter Konten, Genehmigungen, JIT-Rechteerweiterung, Sitzungsprotokolle, Rotation in Schlüsselablagen | Article 21(2)(i) risikobasierte Zugriffskontrolle und Richtlinien für Asset-Management | Schutz von IKT-Systemen, operative Resilienz und Überwachung | Einschränkung und Auditierung erhöhter Zugriffe auf personenbezogene Daten |
| Berechtigungsüberprüfung | Vierteljährliche oder halbjährliche Überprüfungsaufzeichnungen, Bestätigungen durch Vorgesetzte, Abhilfetickets | Cyberhygiene, Richtlinien zur Zugriffskontrolle und Richtlinien für Asset-Management | Laufende Überwachung, rollenbasierter Zugriff und Widerrufsprozesse | Datenschutz durch datenschutzfreundliche Voreinstellungen und nachweisbare Rechenschaftspflicht |
| Offboarding | HR-Austrittsliste, Nachweis zur Kontosperrung oder -löschung, Widerruf von Token | Fristgerechte Entfernung nicht benötigter Zugriffe | Steuerung des IKT-Zugriffs über den gesamten Lebenszyklus | Verhinderung unbefugten Zugriffs auf personenbezogene Daten |
Ein einzelner gut gestalteter Bericht zur Berechtigungsüberprüfung kann ISO/IEC 27001:2022, NIS2, DORA und GDPR unterstützen, wenn er Geltungsbereich, Systemverantwortlichen, Prüfer, Kontenliste, Rollenbegründung, Kennzeichnung privilegierter Konten, Entscheidungen, Entfernungen, Ausnahmen und Abschlussdatum enthält.
MFA-Nachweise sind mehr als ein Screenshot
Ein häufiger Auditfehler besteht darin, einen Screenshot vorzulegen, auf dem „MFA enabled“ steht. Auditoren benötigen mehr. Sie müssen wissen, wo MFA gilt, wer ausgeschlossen ist, wie Ausnahmen genehmigt werden, ob privilegierte Konten abgedeckt sind und ob die technische Konfiguration der Richtlinie entspricht.
Aus dem Zenith Blueprint, Phase „Kontrollen in der Praxis“, Schritt 19, ergibt sich: Auditoren werden fragen, wie Passwort- und MFA-Richtlinien durchgesetzt werden, welche Systeme geschützt sind, für wen MFA gilt und ob kritische Anwendungen mit einem Stichprobenkonto getestet werden können. Nachweise können IdP-Konfiguration, Conditional-Access-Richtlinien, MFA-Registrierungsstatistiken und Verfahren zur Passwortzurücksetzung umfassen.
Für Unternehmensumgebungen legt Clarysecs Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen fest:
„Soweit technisch umsetzbar, ist Multi-Faktor-Authentifizierung (MFA) verpflichtend für: 6.3.2.1 Administrator- und Root-Konten 6.3.2.2 Fernzugriff (VPN, Cloud-Plattformen) 6.3.2.3 Zugriff auf sensitive oder regulierte Daten“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Clause 6.3.2.
Damit entsteht eine direkte Brücke für das Audit. Wenn MFA für Administratorkonten, Fernzugriff und regulierte Daten verpflichtend ist, sollte das Nachweispaket Listen von Administrator- und Root-Konten, Fernzugriffskonfiguration, Conditional-Access-Richtlinien für Cloud-Plattformen, Listen von Anwendungen mit sensitiven Daten, MFA-Registrierungsberichte, Ausnahmegenehmigungen, kompensierende Kontrollen und aktuelle Nachweise zur Überprüfung von Warnmeldungen bei fehlgeschlagenen Anmeldungen oder MFA-Bypass-Versuchen enthalten.
Für NIST SP 800-53 Rev. 5 entspricht dies IA-2 Identification and Authentication, IA-5 Authenticator Management, AC-17 Remote Access und AU-2 Event Logging. Für COBIT 2019 unterstützt es DSS05.04 Manage user identity and logical access sowie zugehörige Praktiken zur Sicherheitsüberwachung.
Unterstützende ISO-Normen erweitern das Bild. ISO/IEC 27018:2020 erweitert Authentifizierungserwartungen für die Verarbeitung personenbezogener Daten in der Public Cloud. ISO/IEC 24760-1:2019 unterstützt die Bindung und das Lebenszyklusmanagement von Authentifikatoren. ISO/IEC 29115:2013 führt Vertrauensniveaus für Authentifizierung ein, hilfreich bei der Entscheidung, wo Hardware-Token oder phishingresistente MFA erforderlich sind. ISO/IEC 27033-1:2015 unterstützt starke Netzwerkauthentifizierung für Remote- oder netzübergreifenden Zugriff.
PAM-Nachweise sind der schnellste Weg zu einer wesentlichen Feststellung oder einem sauberen Audit
Bei privilegiertem Zugriff werden Auditoren besonders kritisch, weil privilegierte Konten Kontrollen umgehen, Daten extrahieren, Persistenz schaffen und Protokolle verändern können. In Zenith Blueprint, Schritt 19, heißt es:
„In jedem Informationssystem ist privilegierter Zugriff Macht – und mit dieser Macht geht Risiko einher.“
Die Anleitung konzentriert sich darauf, wer privilegierten Zugriff hat, was dieser erlaubt, wie er verwaltet wird und wie er im Zeitverlauf überwacht wird. Sie empfiehlt ein aktuelles Inventar, Prinzip der minimalen Berechtigung, RBAC, zeitbasierte oder Just-in-time-Rechteerweiterung, Genehmigungs-Workflows, eindeutige personenbezogene Konten, Vermeidung gemeinsamer Konten, Protokollierung von Break-Glass-Konten, PAM-Systeme, Rotation von Zugangsdaten, Ablage in Tresoren, Sitzungsaufzeichnung, temporäre Rechteerweiterung, Überwachung und regelmäßige Überprüfung.
Clarysecs Unternehmens-Richtlinie zur Zugriffskontrolle macht daraus eine Kontrollanforderung:
„Administrativer Zugriff muss streng kontrolliert werden durch: 5.4.1.1 Separate privilegierte Konten 5.4.1.2 Sitzungsüberwachung und -aufzeichnung 5.4.1.3 Multi-Faktor-Authentifizierung 5.4.1.4 Zeitlich begrenzte oder workflowgesteuerte Rechteerweiterung“
Aus Abschnitt „Governance-Anforderungen“, Clause 5.4.1.
Dieses Zitat ist beinahe ein Audit-Testskript. Wenn die Richtlinie separate Administratorkonten fordert, zeigen Sie die Liste privilegierter Konten und belegen Sie, dass jedes Konto einer benannten Person zugeordnet ist. Wenn sie Sitzungsüberwachung fordert, zeigen Sie aufgezeichnete Sitzungen oder PAM-Protokolle. Wenn sie MFA fordert, zeigen Sie die Durchsetzung für jeden privilegierten Zugriffspfad. Wenn sie zeitlich begrenzte Rechteerweiterung fordert, zeigen Sie Ablaufzeitstempel und Genehmigungstickets.
Die SME-Version ist ebenso eindeutig. Die Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen legt fest:
„Erhöhte oder administrative Berechtigungen erfordern eine zusätzliche Genehmigung durch den General Manager oder die IT-Leitung und müssen dokumentiert, zeitlich begrenzt sowie regelmäßigen Überprüfungen unterzogen werden.“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Clause 6.2.2.
Für kleinere Organisationen ist dies oft der Unterschied zwischen „wir vertrauen unserem Admin“ und „wir steuern privilegierte Risiken“. Der Auditor verlangt nicht in jedem SME Unternehmenswerkzeuge, aber er verlangt risikoadäquate Nachweise. Ein Ticket, eine Genehmigung, eine temporäre Gruppenzuweisung, MFA-Durchsetzung und ein Überprüfungsnachweis können ausreichen, wenn der Geltungsbereich begrenzt und das Risiko geringer ist.
Berechtigungsüberprüfung belegt den laufenden Betrieb des Prinzips der minimalen Berechtigung
Berechtigungsüberprüfung zeigt, ob sich Berechtigungen unbemerkt ansammeln. Sie zeigt auch, ob Führungskräfte verstehen, welche Zugriffe ihre Teams tatsächlich besitzen.
Die Unternehmens-Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen verlangt:
„Vierteljährliche Überprüfungen aller Benutzerkonten und zugehörigen Berechtigungen müssen durch IT Security in Zusammenarbeit mit den Abteilungsleitern durchgeführt werden.“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Clause 6.5.1.
Für SMEs legt die Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen einen verhältnismäßigen Zyklus fest:
„Alle Benutzerkonten und Berechtigungen müssen alle sechs Monate überprüft werden.“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Clause 6.4.1.
Eine belastbare Berechtigungsüberprüfung enthält Systemname, Geltungsbereich, Name des Prüfers, Exportdatum, Überprüfungsdatum, Identitätsverantwortlichen, Abteilung, Vorgesetzten, Beschäftigungsstatus, Rolle oder Zugriffsberechtigung, Kennzeichnung privilegierter Konten, Kennzeichnung der Datensensitivität, Entscheidung, Abhilfeticket, Abschlussdatum, Verantwortlichen für Ausnahmen und Ablaufdatum der Ausnahme.
In Zenith Controls wird Zugriffsrechte 5.18 zu regelwerksübergreifenden Nachweisen. Der Leitfaden ordnet Zugriffsrechte GDPR Article 25 zu, weil Zugriff by Design und by Default beschränkt sein sollte. Er ordnet sie NIS2 Article 21(2)(i) zu, weil Richtlinien zur Zugriffskontrolle und Richtlinien für Asset-Management risikobasierte Zuweisung, fristgerechte Entfernung nicht benötigter Zugriffe und formalen Widerruf verlangen. Er ordnet sie DORA zu, weil Finanz-IKT-Systeme rollenbasierten Zugriff, Überwachung und Widerrufsprozesse benötigen.
NIST-orientierte Auditoren testen dies häufig anhand von AC-2 Account Management, AC-5 Separation of Duties und AC-6 Least Privilege. Auditoren mit COBIT 2019 prüfen DSS05.04 Manage user identity and logical access und DSS06.03 Manage roles, responsibilities, access privileges and levels of authority. ISACA ITAF-Auditoren konzentrieren sich darauf, ob Nachweise ausreichend, verlässlich und vollständig sind.
Offboarding und Token-Widerruf lassen sich leicht stichprobenartig prüfen
Austritte gehören zu den einfachsten Punkten, um nachzuweisen, ob der Lebenszyklus funktioniert. Auditoren wählen häufig einen kürzlich ausgeschiedenen Mitarbeiter aus und verlangen HR-Austrittsaufzeichnung, Ticket, Protokoll zur Kontodeaktivierung, Nachweis der SaaS-Deaktivierung, VPN-Entfernung, MFA-Widerruf, Entfernung von API-Token und Rückgabe von Vermögenswerten.
In der Richtlinie für Onboarding und Austritt legt Clarysec fest:
„Beendete Konten müssen gesperrt oder gelöscht werden, und zugehörige Zugriffstoken müssen widerrufen werden, einschließlich Fernzugriff (VPN), MFA-App-Bindungen und API-Token.“
Aus Abschnitt „Anforderungen an die Umsetzung der Richtlinie“, Clause 6.3.3.
Das ist wichtig, weil moderner Zugriff nicht nur aus Benutzername und Passwort besteht. Zugriff kann über Refresh-Token, API-Schlüssel, SSH-Schlüssel, OAuth-Genehmigungen, Servicekonten, lokale Administratorrechte, mobile Sitzungen und Drittparteienportale fortbestehen. Eine deaktivierte HR-Aufzeichnung ohne Token-Widerruf ist als Nachweis unvollständig.
Der Zenith Blueprint, Phase „Kontrollen in der Praxis“, Schritt 16, fordert Organisationen auf, eine dokumentierte Austritts-Checkliste, Nachweise eines aktuellen Austrittsfalls, ein Protokoll zur Deaktivierung von Benutzerkonten aus AD oder MDM, ein unterzeichnetes Formular zur Rückgabe von Vermögenswerten und Offboarding-Dokumentation mit Vertraulichkeitspflichten bereitzuhalten.
Marias Auditor fragte nach einem ausscheidenden Senior Developer, der privilegierten Zugriff auf Produktionsdatenbanken hatte. Ihr Team legte die Richtlinie für Onboarding und Austritt, die anhand von Zenith Blueprint Schritt 16 erstellte Austritts-Checkliste, das HR-ausgelöste ITSM-Ticket, das Deaktivierungsprotokoll des Verzeichnisses, den Widerruf des VPN-Zertifikats, die Entfernung aus der GitHub-Organisation, die Löschung des AWS-IAM-Schlüssels und das geschlossene Verifikationsticket mit Unterschrift des IT-Managers vor. Die Nachweise waren vollständig, fristgerecht und direkt auf die Richtlinie zurückgeführt.
Führen Sie vor dem Auditor einen Drei-Stichproben-Nachweissprint durch
Eine praktische Übung zur Vorbereitung besteht darin, vor dem Audit drei Stichproben auszuwählen:
- Einen neuen Mitarbeiter, der in den letzten 90 Tagen eingetreten ist
- Einen privilegierten Benutzer mit Administrationszugriff auf Cloud, Datenbank, Produktion oder IAM
- Einen ausgeschiedenen oder rollenveränderten Mitarbeiter aus den letzten 90 Tagen
| Stichprobe | Zu sammelnde Nachweise | Bestehenskriterium | Häufige Feststellung |
|---|---|---|---|
| Neuer Mitarbeiter | HR-Eintrittsaufzeichnung, Zugriffsanfrage, Genehmigung, Rollenzuweisung, MFA-Registrierung, erste Anmeldung | Zugriff wurde erst nach Genehmigung gewährt und entspricht der Rolle | Zugriff wurde vor Genehmigung gewährt oder Rolle ist zu weit gefasst |
| Privilegierter Benutzer | Geschäftliche Begründung, separates Administratorkonto, MFA-Nachweis, PAM-Genehmigung, Sitzungsprotokoll, vierteljährliche Überprüfung | Berechtigung ist personenbezogen, begründet, soweit möglich zeitlich begrenzt, überwacht und überprüft | Gemeinsames Administratorkonto, fehlende MFA, kein Sitzungsnachweis |
| Austritt oder Wechsel | HR-Ereignis, Austritts- oder Rollenänderungsticket, Deaktivierungsprotokolle, VPN-Entfernung, Widerruf von MFA- oder API-Token, Abschluss der Überprüfung | Zugriff wurde unverzüglich und vollständig entfernt | SaaS-Konto weiterhin aktiv, API-Token nicht widerrufen, alte Gruppenmitgliedschaft verbleibt |
Verbinden Sie anschließend jede Stichprobe mit den ISMS-Aufzeichnungen: Risikoszenario, Behandlungsentscheidung, Auswahl der Maßnahme in der Anwendbarkeitserklärung, Richtlinienklausel, technische Konfiguration, Überprüfungsaufzeichnung und Korrekturmaßnahme, falls eine Lücke besteht.
Damit wird Auditvorbereitung von Dokumentensammlung zu Kontrollvalidierung.
Bereiten Sie sich auf unterschiedliche Auditperspektiven vor
Unterschiedliche Audit-Hintergründe führen zu unterschiedlichen Fragen, selbst wenn die Nachweise dieselben sind.
| Auditorenperspektive | Hauptfokus | Erwartete Nachweise |
|---|---|---|
| ISO/IEC 27001:2022-Auditor | ISMS-Prozess, Risikobehandlung und Kontrollbetrieb | Risikobeurteilung, SoA, genehmigte Richtlinien, Zugriffsanfragen, Überprüfungsaufzeichnungen, Deaktivierungsprotokolle |
| Auditpraxis nach ISO/IEC 19011:2018 | Stichproben, Bestätigung durch mehrere Quellen und Konsistenz | Passworteinstellungen, Sperrschwellen, Genehmigungszeitstempel, Ausführungsaufzeichnungen, Interviews |
| ISMS-Auditor nach ISO/IEC 27007:2020 | Durchführung und Wirksamkeit von ISMS-Audits | Rollenbeschreibungen im Vergleich zu tatsächlichen Berechtigungen, Genehmigungspfad für privilegierten Zugriff, Widerrufsprotokolle |
| NIST-fokussierter Assessor | Technische Umsetzung und Kontrolltests | Nachweise zu AC-2, AC-5, AC-6, AC-17, IA-2, IA-5 und AU-2 aus IAM-, PAM- und SIEM-Werkzeugen |
| COBIT 2019- oder ISACA-Auditor | Governance, Verantwortlichkeit und Verlässlichkeit der Nachweise | Prozessnachweise zu DSS05.04 und DSS06.03, Kennzahlen, Ausnahmen, Nachverfolgung von Abhilfemaßnahmen |
| DORA-Prüfer | IKT-Risiko, Resilienz und Kritikalität | Zugriffslisten kritischer Systeme, Überwachung privilegierter Zugriffe, Administrationskontrollen für Drittparteien, Verknüpfungen zu Resilienztests |
| NIS2-Prüfer | Rechenschaftspflicht des Managements und Risikomaßnahmen | Aufsicht durch das Leitungsorgan, Maßnahmen zur Zugriffskontrolle nach Article 21, MFA-Abdeckung, Vorfallsbereitschaft |
| GDPR-Prüfer | Vertraulichkeit personenbezogener Daten und Rechenschaftspflicht | Zugriffsbeschränkungen für personenbezogene Daten, Nachweise zu privacy-by-default nach Article 25, Sicherheitsmaßnahmen nach Article 32 |
Nachweise, die alle diese Perspektiven abdecken, zeigen ein ausgereiftes Compliance-Programm und reduzieren Doppelarbeit.
Häufige Feststellungen und vorbeugende Maßnahmen
Feststellungen zur Zugriffskontrolle sind vorhersehbar. Die vorbeugenden Maßnahmen sind es ebenfalls.
| Feststellung | Warum sie relevant ist | Vorbeugung |
|---|---|---|
| Berechtigungsüberprüfung existiert, privilegierte Konten sind aber ausgeschlossen | Administrationsrechte erzeugen das höchste Auswirkungsrisiko | Kennzeichnung privilegierter Konten, PAM-Aufzeichnungen und Administrationsgruppen in jede Überprüfung einbeziehen |
| MFA ist für Mitarbeitende aktiviert, aber nicht für Servicedesks, Auftragnehmer oder Cloud-Administratoren | Angreifer zielen auf Ausnahmen | MFA-Abdeckungsbericht und Ausnahmenregister mit Ablaufdaten pflegen |
| Eintrittsprozess ist dokumentiert, Wechsel werden aber nicht gesteuert | Schleichende Rollenausweitung entsteht nach Rollenwechseln | Berechtigungsüberprüfung bei jedem Abteilungs- oder Rollenwechsel auslösen |
| Gemeinsame Administratorkonten existieren ohne kompensierende Kontrollen | Rechenschaftspflicht ist schwach | Durch personenbezogene Administratorkonten ersetzen oder Tresor-Auschecken und Sitzungsprotokollierung durchsetzen |
| Austritte sind im Verzeichnis deaktiviert, aber in SaaS-Plattformen aktiv | Zugriff besteht außerhalb des zentralen IdP fort | Anwendungsinventar und Offboarding-Checkliste für jedes System pflegen |
| Passwörter von Servicekonten sind unbekannt oder werden nie rotiert | Nicht-menschliche Identitäten werden zu versteckten Hintertüren | Verantwortliche zuweisen, Geheimnisse in Tresoren speichern, Zugangsdaten rotieren und Nutzungsprotokolle prüfen |
| Richtlinie verlangt vierteljährliche Überprüfung, Nachweise zeigen aber jährliche Überprüfung | Richtlinie und Praxis weichen voneinander ab | Zyklus risikobasiert anpassen oder dokumentierte Anforderung durchsetzen |
| Zugriffsgenehmigungen liegen in E-Mails ohne Aufbewahrungsregel | Prüfpfad ist fragil | ITSM-Workflows und eine an der Richtlinie ausgerichtete Aufbewahrung nutzen |
Die Unternehmens-Richtlinie zur Zugriffskontrolle ergänzt eine Aufbewahrungsanforderung, die einen der häufigsten Nachweisfehler verhindert:
„Genehmigungsentscheidungen müssen für Auditzwecke protokolliert und mindestens 2 Jahre aufbewahrt werden.“
Aus Abschnitt „Governance-Anforderungen“, Clause 5.3.2.
Wenn Genehmigungen nach einer E-Mail-Bereinigung verschwinden, hat die Kontrolle möglicherweise funktioniert, aber das Audit kann sich nicht darauf stützen. Aufbewahrung ist Teil des Kontrolldesigns.
Rechenschaftspflicht des Managements benötigt Zugriffskennzahlen
NIS2 Article 20 und DORA Articles 5 und 6 machen Zugriffskontrolle zu einem Managementthema, weil kompromittierte Identitäten zu Betriebsunterbrechungen, regulatorischen Meldungen, Datenpannen und Kundenschäden führen können. ISO/IEC 27001:2022 Clauses 5.1 bis 5.3 verlangen außerdem, dass die oberste Leitung das ISMS an der Geschäftsstrategie ausrichtet, Ressourcen bereitstellt, die Bedeutung kommuniziert, Verantwortlichkeiten zuweist und kontinuierliche Verbesserung fördert.
Nützliche Kennzahlen zur Zugriffskontrolle sind:
- Prozentsatz kritischer Systeme mit SSO-Abdeckung
- Prozentsatz privilegierter Konten mit MFA
- Anzahl dauerhaft privilegierter Konten im Vergleich zu JIT-Konten
- Abschlussquote von Berechtigungsüberprüfungen
- Anzahl entzogener übermäßiger Berechtigungen
- Einhaltung des SLA für Austrittsdeaktivierung
- Anzahl inaktiver Konten
- Abdeckung von Verantwortlichen für Servicekonten
- Abdeckung der PAM-Sitzungsaufzeichnung
- Anzahl und Alter von MFA-Ausnahmen
Diese Kennzahlen helfen dem Management, Risikobehandlungen zu genehmigen und Aufsicht nachzuweisen. Sie machen Audits außerdem glaubwürdiger, weil die Organisation zeigen kann, dass Zugriffskontrolle als laufendes Risiko überwacht und nicht vor jedem Audit neu entdeckt wird.
Verstreute Nachweise in Auditsicherheit überführen
Wenn Nachweise zur Zugriffskontrolle nach ISO/IEC 27001:2022 über HR, ITSM, IAM, PAM, Cloud-Konsolen und Tabellen verteilt sind, ist der nächste Schritt nicht eine weitere Neufassung der Richtlinie. Der nächste Schritt ist eine Nachweisarchitektur.
Beginnen Sie mit dieser Abfolge:
- Systeme, Identitäten und Daten im Geltungsbereich definieren.
- NIS2-, DORA-, GDPR- und vertragliche Anforderungen in den ISMS-Kontext abbilden.
- Risikoszenarien im Stil von ISO/IEC 27005:2022 nutzen, um IAM, MFA, PAM und Berechtigungsüberprüfung zu priorisieren.
- Anwendbarkeitserklärung und Risikobehandlungsplan aktualisieren.
- Richtlinienklauseln mit tatsächlichen IAM- und PAM-Workflows abstimmen.
- Den Drei-Stichproben-Nachweissprint durchführen.
- Lücken schließen, bevor der Auditor sie findet.
- Ein wiederverwendbares Nachweispaket für Zertifizierung, Kunden-Due-Diligence und regulatorische Prüfungen pflegen.
Clarysec kann Sie bei der Umsetzung mit dem Zenith Blueprint: 30-Schritte-Roadmap eines Auditors unterstützen, Anforderungen mit Zenith Controls: Leitfaden für regelwerksübergreifende Compliance querzuordnen und Anforderungen mit dem passenden Clarysec-Richtliniensatz zu operationalisieren, einschließlich Richtlinie zur Zugriffskontrolle, Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen und Richtlinie für Onboarding und Austritt.
Auditbereitschaft bei Zugriffskontrolle bedeutet nicht, nachzuweisen, dass Sie ein IAM-Werkzeug gekauft haben. Sie bedeutet nachzuweisen, dass Identitäts-, Authentifizierungs-, Berechtigungs- und Überprüfungsprozesse reale Geschäftsrisiken reduzieren und die für Ihre Organisation relevanten Standards und Vorschriften erfüllen.
Laden Sie die Clarysec-Toolkits herunter, führen Sie den Drei-Stichproben-Nachweissprint durch und überführen Sie Ihre Nachweise zur Zugriffskontrolle von einem verstreuten Durcheinander in ein klares, wiederholbares und belastbares Auditportfolio.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council

