⚡ LIMITED TIME Get our FREE €500+ Compliance Starter Kit
Get It Now →

ISO 27001-Leitfaden zu Auditnachweisen für Zugriffskontrolle

Igor Petreski
14 min read
ISO 27001-Nachweiszuordnung für Zugriffskontrolle für IAM, MFA, PAM, NIS2, DORA und GDPR

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.

NachweisebeneWas sie belegtTypische QuellsystemeWert für mehrere Regelwerke
ISMS-Geltungsbereich und Anforderungen interessierter ParteienWelche Systeme, Daten, Vorschriften und Drittparteienabhängigkeiten im Geltungsbereich liegenISMS-Geltungsbereich, Compliance-Register, Dateninventar, LieferantenregisterUnterstützt ISO/IEC 27001:2022 Clauses 4.2 und 4.3, NIS2-Scoping, Abbildung von IKT-Abhängigkeiten nach DORA, Rechenschaftspflicht nach GDPR
ZugriffsrisikobeurteilungWarum IAM, MFA, PAM und Überprüfungen risikobasiert erforderlich sindRisikoregister, Bedrohungsszenarien, BehandlungsplanUnterstützt ISO/IEC 27001:2022 Clause 6.1, ISO/IEC 27005:2022, IKT-Risikomanagementrahmen nach DORA, Risikomaßnahmen nach NIS2
Richtlinien und StandardsWas die Organisation verlangtRichtlinie zur Zugriffskontrolle, Berechtigungsrichtlinie, Richtlinie für Onboarding und AustrittÜbersetzt regulatorische Erwartungen in verbindliche interne Regeln
IAM- und PAM-KonfigurationOb Kontrollen technisch umgesetzt sindIdP, HRIS, ITSM, PAM, Cloud-IAM, SaaS-AdministrationskonsolenBelegt Prinzip der minimalen Berechtigung, MFA, RBAC, Genehmigungs-Workflows und Kontrollen für privilegierte Sitzungen
Überprüfungs- und ÜberwachungsaufzeichnungenOb Zugriff im Zeitverlauf angemessen bleibtBerechtigungsrezertifizierungskampagnen, SIEM, PAM-Protokolle, Bestätigungen durch VorgesetzteBelegt laufenden Kontrollbetrieb, Überwachung nach DORA, Cyberhygiene nach NIS2, Datenminimierung nach GDPR
Offboarding- und AusnahmeaufzeichnungenOb Zugriff entzogen und Ausnahmen gesteuert werdenHR-Austrittsliste, Deaktivierungsprotokolle, AusnahmenregisterBelegt 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:

  1. Richtlinie zur Zugriffskontrolle und Richtlinie für Benutzerkonten
  2. Verfahren für Eintritts-, Wechsel- und Austrittsprozesse
  3. Rollenmatrix oder Zugriffskontrollmatrix
  4. Liste der Anwendungen, Plattformen und Datenablagen im Geltungsbereich
  5. MFA-Konfiguration des Identitätsanbieters
  6. Conditional-Access-Richtlinien und Ausnahmenliste
  7. Inventar privilegierter Konten
  8. PAM-Workflow-Nachweise, einschließlich Genehmigungen und Sitzungsprotokollen
  9. Aktuelle Ergebnisse von Berechtigungsrezertifizierungskampagnen
  10. Stichproben von Manager-Bestätigungen und Abhilfemaßnahmen
  11. HR-Austrittsbericht, abgeglichen mit Deaktivierungsprotokollen
  12. Inventar von Servicekonten, Verantwortliche, Rotationsaufzeichnungen und Nachweise aus Schlüsselablagen
  13. Verfahren für Break-Glass-Konten und Testprotokoll
  14. Nachweise zu Vorfällen oder Warnmeldungen im Zusammenhang mit fehlgeschlagenen Anmeldungen, Privilegieneskalation oder inaktiven Konten
  15. 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.

AuditthemaZugriffsnachweise nach ISO/IEC 27001:2022NIS2-ZuordnungDORA-ZuordnungGDPR-Zuordnung
IAM-LebenszyklusWorkflow für Eintritts-, Wechsel- und Austrittsprozesse, Zugriffsanfragen, Genehmigungen, Rollenvorlagen, DeaktivierungsprotokolleArticle 21 Maßnahmen zum Risikomanagement, Richtlinien zur Zugriffskontrolle und Richtlinien für Asset-ManagementArticles 5, 6 und 9 Governance, IKT-Rahmenwerk für Risikomanagement, logische Sicherheit und ZugriffskontrolleArticles 5, 25 und 32 Rechenschaftspflicht, Minimierung und Sicherheit
MFAIdP-Richtlinie, Conditional-Access-Screenshots, MFA-Registrierungsstatistiken, AusnahmegenehmigungenArticle 21(2)(j) MFA oder kontinuierliche Authentifizierung, soweit angemessenSicherer Zugriff auf kritische IKT-Systeme und IKT-RisikokontrollenGeeignete technische Maßnahmen gegen unbefugten Zugriff
PAMInventar privilegierter Konten, Genehmigungen, JIT-Rechteerweiterung, Sitzungsprotokolle, Rotation in SchlüsselablagenArticle 21(2)(i) risikobasierte Zugriffskontrolle und Richtlinien für Asset-ManagementSchutz von IKT-Systemen, operative Resilienz und ÜberwachungEinschränkung und Auditierung erhöhter Zugriffe auf personenbezogene Daten
BerechtigungsüberprüfungVierteljährliche oder halbjährliche Überprüfungsaufzeichnungen, Bestätigungen durch Vorgesetzte, AbhilfeticketsCyberhygiene, Richtlinien zur Zugriffskontrolle und Richtlinien für Asset-ManagementLaufende Überwachung, rollenbasierter Zugriff und WiderrufsprozesseDatenschutz durch datenschutzfreundliche Voreinstellungen und nachweisbare Rechenschaftspflicht
OffboardingHR-Austrittsliste, Nachweis zur Kontosperrung oder -löschung, Widerruf von TokenFristgerechte Entfernung nicht benötigter ZugriffeSteuerung des IKT-Zugriffs über den gesamten LebenszyklusVerhinderung 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:

  1. Einen neuen Mitarbeiter, der in den letzten 90 Tagen eingetreten ist
  2. Einen privilegierten Benutzer mit Administrationszugriff auf Cloud, Datenbank, Produktion oder IAM
  3. Einen ausgeschiedenen oder rollenveränderten Mitarbeiter aus den letzten 90 Tagen
StichprobeZu sammelnde NachweiseBestehenskriteriumHäufige Feststellung
Neuer MitarbeiterHR-Eintrittsaufzeichnung, Zugriffsanfrage, Genehmigung, Rollenzuweisung, MFA-Registrierung, erste AnmeldungZugriff wurde erst nach Genehmigung gewährt und entspricht der RolleZugriff wurde vor Genehmigung gewährt oder Rolle ist zu weit gefasst
Privilegierter BenutzerGeschäftliche Begründung, separates Administratorkonto, MFA-Nachweis, PAM-Genehmigung, Sitzungsprotokoll, vierteljährliche ÜberprüfungBerechtigung ist personenbezogen, begründet, soweit möglich zeitlich begrenzt, überwacht und überprüftGemeinsames Administratorkonto, fehlende MFA, kein Sitzungsnachweis
Austritt oder WechselHR-Ereignis, Austritts- oder Rollenänderungsticket, Deaktivierungsprotokolle, VPN-Entfernung, Widerruf von MFA- oder API-Token, Abschluss der ÜberprüfungZugriff wurde unverzüglich und vollständig entferntSaaS-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.

AuditorenperspektiveHauptfokusErwartete Nachweise
ISO/IEC 27001:2022-AuditorISMS-Prozess, Risikobehandlung und KontrollbetriebRisikobeurteilung, SoA, genehmigte Richtlinien, Zugriffsanfragen, Überprüfungsaufzeichnungen, Deaktivierungsprotokolle
Auditpraxis nach ISO/IEC 19011:2018Stichproben, Bestätigung durch mehrere Quellen und KonsistenzPassworteinstellungen, Sperrschwellen, Genehmigungszeitstempel, Ausführungsaufzeichnungen, Interviews
ISMS-Auditor nach ISO/IEC 27007:2020Durchführung und Wirksamkeit von ISMS-AuditsRollenbeschreibungen im Vergleich zu tatsächlichen Berechtigungen, Genehmigungspfad für privilegierten Zugriff, Widerrufsprotokolle
NIST-fokussierter AssessorTechnische Umsetzung und KontrolltestsNachweise 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-AuditorGovernance, Verantwortlichkeit und Verlässlichkeit der NachweiseProzessnachweise zu DSS05.04 und DSS06.03, Kennzahlen, Ausnahmen, Nachverfolgung von Abhilfemaßnahmen
DORA-PrüferIKT-Risiko, Resilienz und KritikalitätZugriffslisten kritischer Systeme, Überwachung privilegierter Zugriffe, Administrationskontrollen für Drittparteien, Verknüpfungen zu Resilienztests
NIS2-PrüferRechenschaftspflicht des Managements und RisikomaßnahmenAufsicht durch das Leitungsorgan, Maßnahmen zur Zugriffskontrolle nach Article 21, MFA-Abdeckung, Vorfallsbereitschaft
GDPR-PrüferVertraulichkeit personenbezogener Daten und RechenschaftspflichtZugriffsbeschrä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.

FeststellungWarum sie relevant istVorbeugung
Berechtigungsüberprüfung existiert, privilegierte Konten sind aber ausgeschlossenAdministrationsrechte erzeugen das höchste AuswirkungsrisikoKennzeichnung 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-AdministratorenAngreifer zielen auf AusnahmenMFA-Abdeckungsbericht und Ausnahmenregister mit Ablaufdaten pflegen
Eintrittsprozess ist dokumentiert, Wechsel werden aber nicht gesteuertSchleichende Rollenausweitung entsteht nach RollenwechselnBerechtigungsüberprüfung bei jedem Abteilungs- oder Rollenwechsel auslösen
Gemeinsame Administratorkonten existieren ohne kompensierende KontrollenRechenschaftspflicht ist schwachDurch personenbezogene Administratorkonten ersetzen oder Tresor-Auschecken und Sitzungsprotokollierung durchsetzen
Austritte sind im Verzeichnis deaktiviert, aber in SaaS-Plattformen aktivZugriff besteht außerhalb des zentralen IdP fortAnwendungsinventar und Offboarding-Checkliste für jedes System pflegen
Passwörter von Servicekonten sind unbekannt oder werden nie rotiertNicht-menschliche Identitäten werden zu versteckten HintertürenVerantwortliche zuweisen, Geheimnisse in Tresoren speichern, Zugangsdaten rotieren und Nutzungsprotokolle prüfen
Richtlinie verlangt vierteljährliche Überprüfung, Nachweise zeigen aber jährliche ÜberprüfungRichtlinie und Praxis weichen voneinander abZyklus risikobasiert anpassen oder dokumentierte Anforderung durchsetzen
Zugriffsgenehmigungen liegen in E-Mails ohne AufbewahrungsregelPrüfpfad ist fragilITSM-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:

  1. Systeme, Identitäten und Daten im Geltungsbereich definieren.
  2. NIS2-, DORA-, GDPR- und vertragliche Anforderungen in den ISMS-Kontext abbilden.
  3. Risikoszenarien im Stil von ISO/IEC 27005:2022 nutzen, um IAM, MFA, PAM und Berechtigungsüberprüfung zu priorisieren.
  4. Anwendbarkeitserklärung und Risikobehandlungsplan aktualisieren.
  5. Richtlinienklauseln mit tatsächlichen IAM- und PAM-Workflows abstimmen.
  6. Den Drei-Stichproben-Nachweissprint durchführen.
  7. Lücken schließen, bevor der Auditor sie findet.
  8. 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

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

Share this article

Related Articles

DORA-Vorfallmeldung und ISO 27001-Maßnahmen im Jahr 2026

DORA-Vorfallmeldung und ISO 27001-Maßnahmen im Jahr 2026

Ein praxisorientierter CISO-Leitfaden zur Zuordnung der Meldung schwerwiegender IKT-bezogener Vorfälle nach DORA zu ISO/IEC 27001:2022 Anhang A-Maßnahmen, Auditnachweisen, Richtlinienklauseln und Clarysec-Werkzeugen für die Umsetzung.

Cloud-Auditnachweise für ISO 27001, NIS2 und DORA

Cloud-Auditnachweise für ISO 27001, NIS2 und DORA

Cloud-Auditnachweise scheitern, wenn Organisationen geteilte Verantwortung, SaaS-Konfigurationen, IaaS-Kontrollen, Lieferantenaufsicht, Protokollierung, Resilienz und Vorfallsbereitschaft nicht nachweisen können. Dieser Leitfaden zeigt, wie Clarysec belastbare Nachweise für ISO 27001:2022, NIS2, DORA und GDPR strukturiert.