ISO 27001 Zugriffskontrolle: Anforderungen, Controls und SaaS-Implementierung

Zugriffskontrolle ist die Praxis sicherzustellen, dass nur autorisierte Personen auf bestimmte Informationen, Systeme und Ressourcen zugreifen können — und nur in dem Umfang, den ihre Rolle erfordert. In ISO 27001 erstreckt sich die Zugriffskontrolle über mehrere Annex A Controls und berührt nahezu jeden Teil des Betriebs eines SaaS-Unternehmens, vom Mitarbeiter-Onboarding über die Verwaltung von Produktionsdatenbanken bis hin zur kundenseitigen API-Authentifizierung.

Für SaaS-Unternehmen ist die Zugriffskontrolle gleichzeitig der wichtigste und komplexeste Bereich, den es richtig umzusetzen gilt. Ihr Produkt läuft auf Cloud-Infrastruktur, die von verteilten Teams verwaltet wird. Entwickler benötigen Zugriff auf Produktionssysteme. Customer-Success-Teams benötigen Zugriff auf Kundendaten für den Support. Drittanbieter-Integrationen benötigen API-Anmeldeinformationen. CI/CD-Pipelines benötigen Deployment-Schlüssel. Jeder dieser Zugriffspfade muss gesteuert, überwacht und überprüft werden.

Dieser Leitfaden behandelt alle Anforderungen der ISO 27001 an die Zugriffskontrolle, die spezifischen Annex A Controls, die gelten, sowie praktische Implementierungshinweise für SaaS-Unternehmen, die auf modernen Cloud-Plattformen arbeiten.

Relevante Annex A Controls

ISO 27001:2022 hat seine Controls in vier Themenbereiche reorganisiert: Organisatorisch, Personell, Physisch und Technologisch. Die Zugriffskontrolle umfasst die organisatorischen und technologischen Themenbereiche. Das Verständnis, welche Controls gelten — und was jedes einzelne verlangt — ist die Grundlage Ihrer Zugriffskontrollrichtlinie.

Organisatorische Controls

A.5.15 — Zugriffskontrolle Das übergeordnete Control. Es verlangt, dass Regeln für den Zugriff auf Informationen und andere zugehörige Vermögenswerte auf der Grundlage geschäftlicher und informationssicherheitsbezogener Anforderungen festgelegt und implementiert werden. Dies ist Ihre Zugriffskontrollrichtlinie — das Dokument, das die Prinzipien (geringste Berechtigung, Need-to-know, RBAC) definiert, die alle anderen Zugriffskontrollen umsetzen.

A.5.16 — Identitätsmanagement Der vollständige Lebenszyklus von Benutzeridentitäten muss verwaltet werden. Dies umfasst die Erstellung, Pflege und Entfernung digitaler Identitäten. Für SaaS-Unternehmen bedeutet dies die Verwaltung von Identitäten über Ihren Identity Provider (Okta, Azure AD, Google Workspace), Cloud-Plattformen, SaaS-Tools und interne Anwendungen hinweg.

A.5.17 — Authentifizierungsinformationen Verwaltung von Authentifizierungsinformationen (Passwörter, Token, Zertifikate, Schlüssel) über ihren gesamten Lebenszyklus. Dies umfasst die erstmalige Zuweisung, sichere Speicherung, Rotation und den Widerruf. Das Control verlangt, dass Authentifizierungsinformationen nicht zwischen Personen geteilt werden und dass Standardanmeldeinformationen sofort nach der Bereitstellung geändert werden.

A.5.18 — Zugriffsrechte Zugriffsrechte müssen in Übereinstimmung mit der Zugriffskontrollrichtlinie bereitgestellt, überprüft, geändert und entzogen werden. Dies ist das operative Control, das Ihr RBAC-Modell umsetzt. Es erfordert einen definierten Prozess für die Gewährung von Zugriffen, einen Mechanismus zur Anpassung von Zugriffen bei Rollenwechseln und einen definierten Prozess zum Entzug von Zugriffen, wenn diese nicht mehr benötigt werden.

Technologische Controls

A.8.2 — Privilegierte Zugriffsrechte Privilegierter Zugriff (Administratorkonten, Root-Zugriff, Datenbank-Superuser) muss eingeschränkt und kontrolliert werden. Dieses Control erfordert eine explizite Autorisierung für privilegierten Zugriff, die Trennung von privilegierten und regulären Benutzerkonten, die Protokollierung privilegierter Aktionen und die regelmäßige Überprüfung privilegierter Zugriffsrechte.

A.8.3 — Einschränkung des Informationszugriffs Der Zugriff auf Informationen muss in Übereinstimmung mit der Zugriffskontrollrichtlinie eingeschränkt werden. Dies bedeutet technische Durchsetzung: Datenbankzugriffskontrollen, Autorisierungsregeln auf Anwendungsebene, Dateisystemberechtigungen, Netzwerksegmentierung, die unbefugte Zugriffspfade verhindert.

A.8.4 — Zugriff auf Quellcode Lese- und Schreibzugriff auf Quellcode, Entwicklungswerkzeuge und Softwarekonfigurationen muss kontrolliert werden. Für SaaS-Unternehmen bedeutet dies Repository-Zugriffsverwaltung, Branch-Protection-Regeln und Code-Review-Anforderungen.

A.8.5 — Sichere Authentifizierung Authentifizierungsmechanismen müssen der Sensibilität der Systeme und Daten, auf die zugegriffen wird, angemessen sein. Hier kommen Multi-Faktor-Authentifizierung (MFA), Single Sign-On (SSO), passwortlose Authentifizierung und Session-Management ins Spiel.

Aufbau Ihrer Zugriffskontrollrichtlinie

Ihre Zugriffskontrollrichtlinie ist das grundlegende Dokument, das Prinzipien definiert, Verantwortlichkeiten zuweist und die Anforderungen festlegt, die alle nachfolgenden Verfahren und technischen Controls umsetzen. Sie sollte prägnant, organisationsspezifisch und überprüfbar sein. Hinweise zur Richtlinienstruktur und -erstellung finden Sie in unserem ISO 27001 Richtlinien-Leitfaden.

Kernprinzipien

Jede Zugriffskontrollrichtlinie sollte diese Prinzipien festlegen:

Prinzip der geringsten Berechtigung. Benutzern werden die minimalen Zugriffsrechte gewährt, die zur Ausführung ihrer Aufgaben erforderlich sind. Zugriff wird nicht standardmäßig gewährt — er muss explizit angefordert, begründet und genehmigt werden.

Need-to-know-Prinzip. Der Zugriff auf Informationen ist auf Personen beschränkt, die diese für ihre spezifische Rolle benötigen. Eine Sicherheitsfreigabe oder Seniorität gewährt nicht automatisch Zugriff auf alle Informationen dieser Stufe.

Aufgabentrennung. Kritische Funktionen werden auf mehrere Personen verteilt, um zu verhindern, dass eine einzelne Person die End-to-End-Kontrolle über einen sensiblen Prozess hat. In SaaS-Begriffen: Die Person, die Code schreibt, sollte nicht der alleinige Genehmiger ihrer eigenen Deployments in die Produktion sein.

Standardmäßige Verweigerung. Zugriff wird standardmäßig verweigert und bei Bedarf explizit gewährt. Dies gilt für Netzwerkregeln, Anwendungsberechtigungen, Cloud-IAM-Richtlinien und Repository-Zugriff.

Richtlinienumfang

Definieren Sie genau, was die Zugriffskontrollrichtlinie abdeckt:

• Alle Produktionssysteme und -umgebungen
• Alle Cloud-Infrastruktur (AWS-, Azure-, GCP-Konten und -Ressourcen)
• Alle Unternehmensanwendungen (E-Mail, Kollaborationstools, HR-Systeme)
• Alle Quellcode-Repositories
• Alle Datenbanken mit Kunden- oder Organisationsdaten
• Alle Drittanbieter-SaaS-Tools im ISMS-Geltungsbereich
• Alle Dienstkonten, API-Schlüssel und Maschinenidentitäten
• Alle Mitarbeiter-, Auftragnehmer- und Drittanbieter-Benutzerkonten

Seien Sie explizit darüber, was außerhalb des Geltungsbereichs liegt. Wenn Sie Entwicklungs-Sandbox-Umgebungen haben, die absichtlich vom ISMS ausgenommen sind, geben Sie dies klar an.

Benutzerbereitstellung und -deprovisionierung

Der Zugriffslebenszyklus — von der Gewährung des Erstzugriffs bis zum Entzug, wenn er nicht mehr benötigt wird — ist der Punkt, an dem die Zugriffskontrolle entweder funktioniert oder scheitert. Auditoren testen dies gründlich, da Fehler bei der Bereitstellung und Deprovisionierung die häufigste Ursache für übermäßige Zugriffsrechte sind.

Bereitstellungsprozess

Ein gut definierter Bereitstellungsprozess umfasst:

1. Zugriffsanforderung. Jeder Zugriff muss formal angefordert werden. Die Anforderung sollte angeben, welcher Zugriff benötigt wird, warum und für wie lange. Für SaaS-Unternehmen bedeutet dies typischerweise ein Ticket in Ihrem Projektmanagement-Tool (Jira, Linear, Asana) oder eine Anfrage über Ihre Identitätsmanagement-Plattform.

2. Autorisierung. Die Anfrage muss von jemandem genehmigt werden, der befugt ist, diesen Zugriff zu gewähren — typischerweise der Vorgesetzte des Mitarbeiters und/oder der Systemverantwortliche. Die Genehmigung muss dokumentiert werden (kein mündliches „klar, mach mal”).

3. Implementierung. Der Zugriff wird gemäß der genehmigten Anfrage bereitgestellt, wobei vordefinierte Rollen verwendet werden, wo immer möglich, anstatt individuelle Berechtigungen. Die Person, die den Zugriff implementiert, sollte überprüfen, dass das Bereitgestellte dem Genehmigten entspricht.

4. Verifizierung. Nach der Bereitstellung ist zu überprüfen, dass der Benutzer den korrekten Zugriff hat — weder mehr noch weniger als genehmigt.

5. Dokumentation. Der vollständige Nachweis — Anfrage, Genehmigung, Implementierung und Verifizierung — muss für Prüfungszwecke aufbewahrt werden.

SaaS-Implementierung: Verwenden Sie Ihren Identity Provider (Okta, Azure AD, Google Workspace) als zentrale Zugriffsstelle. Definieren Sie gruppenbasierte Zugriffsrichtlinien, bei denen das Hinzufügen eines Benutzers zu einer Gruppe automatisch den korrekten Zugriff über verbundene Anwendungen hinweg bereitstellt. Das Onboarding neuer Mitarbeiter löst einen automatisierten Workflow aus: HR erstellt den Mitarbeiterdatensatz, der Identity Provider erstellt das Konto, und Gruppenmitgliedschaften stellen den Zugriff basierend auf Abteilung und Rolle bereit.

Rollenbasierte Zugriffskontrolle (RBAC)

RBAC ist das praktikabelste Zugriffsverwaltungsmodell für SaaS-Unternehmen. Anstatt Berechtigungen benutzerspezifisch zu verwalten, definieren Sie Rollen, die Arbeitsfunktionen zugeordnet sind, und weisen Benutzer Rollen zu.

Definieren Sie Rollen basierend auf Arbeitsfunktionen:

• Engineering — Entwickler: Lese-/Schreibzugriff auf zugewiesene Repositories, Lesezugriff auf Staging-Umgebungen, kein Produktionszugriff
• Engineering — Senior-Entwickler: Wie Entwickler plus Lesezugriff auf Produktionsprotokolle und -metriken
• Engineering — DevOps/SRE: Wie Senior-Entwickler plus Schreibzugriff auf Infrastructure-as-Code-Repositories und Produktionsdeployment-Fähigkeiten
• Customer Success: Lesezugriff auf Kundendaten im Support-Portal, kein direkter Datenbankzugriff
• Finanzen: Zugriff auf Abrechnungssysteme, kein Zugriff auf Engineering-Systeme
• Geschäftsleitung: Zugriff auf Dashboards und Berichte, kein direkter Systemzugriff

RBAC-Prinzipien für SaaS:

• Halten Sie Rollen granular genug, um das Prinzip der geringsten Berechtigung durchzusetzen, aber nicht so granular, dass Sie eine einzigartige Rolle pro Person haben
• Dokumentieren Sie die Zugriffsrechte jeder Rolle und überprüfen Sie diese, wenn sich Arbeitsfunktionen weiterentwickeln
• Verwenden Sie gruppenbasierten Zugriff in Ihrem Identity Provider, um RBAC technisch umzusetzen
• Wenn jemand die Rolle wechselt, entziehen Sie den Zugriff der alten Rolle und stellen Sie den Zugriff der neuen Rolle bereit — Berechtigungen dürfen sich nicht ansammeln

Deprovisionierungsprozess

Die Deprovisionierung ist der risikoreichste Bereich der Zugriffskontrolle. Ein ehemaliger Mitarbeiter oder Auftragnehmer mit aktiven Anmeldedaten stellt ein ernsthaftes Sicherheitsrisiko dar und ist ein garantiertes Audit-Finding.

Sofortige Auslöser für die Deprovisionierung:

• Kündigung des Arbeitsverhältnisses (freiwillig oder unfreiwillig)
• Ende eines Auftragnehmerverhältnisses
• Beendigung einer Drittanbieterbeziehung
• Wechsel eines Mitarbeiters in eine Rolle, die den aktuellen Zugriff nicht erfordert

Erforderlicher Deprovisionierungszeitraum: Ihre Richtlinie muss einen maximalen Zeitraum zwischen dem auslösenden Ereignis und der Zugriffsentfernung festlegen. Für SaaS-Unternehmen ist die Standarderwartung:

• Unfreiwillige Kündigung: Zugriff wird vor oder zum Zeitpunkt der Benachrichtigung des Mitarbeiters entzogen, innerhalb desselben Geschäftstages
• Freiwillige Kündigung: Zugriff wird bis zum Ende des letzten Arbeitstages des Mitarbeiters entzogen
• Rollenwechsel: Zugriff der vorherigen Rolle wird innerhalb von 5 Geschäftstagen nach dem Wirksamkeitsdatum des Rollenwechsels entzogen
• Auftragnehmerende: Zugriff wird am letzten Tag des Auftrags entzogen

SaaS-Implementierung: Integrieren Sie Ihr HR-System mit Ihrem Identity Provider. Wenn HR eine Kündigung verarbeitet, deaktiviert der Identity Provider automatisch das Konto und entzieht den Zugriff auf alle verbundenen Anwendungen. Für Systeme, die nicht mit dem Identity Provider verbunden sind (Legacy-Tools, kundenspezifische Umgebungen), führen Sie eine Deprovisionierungscheckliste und überprüfen Sie die Vollständigkeit.

Häufig übersehener Schritt: Dienstkonten, gemeinsam genutzte Anmeldedaten und SSH-Schlüssel, die mit der ausscheidenden Person verbunden sind. Wenn ein ehemaliger Entwickler Zugriff auf Produktions-SSH-Schlüssel hatte, sollten diese Schlüssel rotiert werden. Wenn er zu gemeinsamen Dienstkonto-Anmeldedaten beigetragen hat, sollten diese Anmeldedaten geändert werden. Dokumentieren Sie dies in Ihrem Deprovisionierungsverfahren.

Zugriff bei Rollenwechseln

Rollenwechsel sind eine bedeutende Quelle für Zugriffsakkumulation — die allmähliche Ansammlung von Berechtigungen, wenn Mitarbeiter zwischen Teams wechseln, ohne dass alte Berechtigungen entzogen werden. Im Laufe der Zeit könnte eine Person, die im Engineering-Support begonnen und über QA ins Produktmanagement gewechselt hat, Zugriffsrechte aus allen drei Rollen behalten.

Verhindern Sie Zugriffsakkumulation durch:

• Behandeln Sie interne Wechsel als Deprovisionierungs-/Reprovisionierungsereignis
• Vergleichen Sie den aktuellen Zugriff des Benutzers mit den definierten Zugriffsrechten der Zielrolle
• Entfernen Sie Zugriff, der für die neue Rolle nicht erforderlich ist
• Dokumentieren Sie die Zugriffsänderung mit der gleichen Sorgfalt wie die Erstbereitstellung

Verwaltung privilegierter Zugriffe

Privilegierter Zugriff — administrative Konten mit erhöhten Berechtigungen — ist die sensibelste Zugriffskategorie und wird bei ISO 27001 Audits am intensivsten geprüft. Control A.8.2 zielt speziell auf privilegierten Zugriff ab.

Was als privilegierter Zugriff in SaaS gilt

• Cloud-Plattform-Administratoren: AWS-Root-Konto, IAM-Administratoren, Azure Global Administrators, GCP Organization Administrators
• Datenbankadministratoren: Produktionsdatenbank-Superuser, Benutzer mit Datenexportfähigkeiten
• Infrastrukturmanagement: Kubernetes-Cluster-Administratoren, Netzwerkadministratoren
• Identity-Provider-Administratoren: Okta Super Admins, Azure AD Global Admins
• Anwendungsadministratoren: Admin-Rollen in SaaS-Tools, die alle Daten einsehen oder Sicherheitseinstellungen ändern können
• CI/CD-Pipeline-Zugriff: Konten, die in die Produktion deployen, Pipeline-Konfigurationen ändern oder auf Deployment-Secrets zugreifen können

Controls für privilegierten Zugriff

Trennen Sie privilegierte und reguläre Konten. Administratoren sollten ein Standardkonto für die tägliche Arbeit (E-Mail, Slack, Dokumente) und ein separates privilegiertes Konto für administrative Aufgaben haben. Dies reduziert den Schadensradius, wenn das Alltagskonto kompromittiert wird.

Fordern Sie stärkere Authentifizierung für privilegierten Zugriff. Wenn MFA für den Standardzugriff erforderlich ist, sollte privilegierter Zugriff Hardware-Sicherheitsschlüssel (FIDO2/WebAuthn) anstelle von SMS oder TOTP erfordern. Erwägen Sie, eine erneute Authentifizierung für sensible Operationen auch innerhalb einer authentifizierten Sitzung zu verlangen.

Implementieren Sie Just-in-Time (JIT)-Zugriff. Anstatt dauerhaften privilegierten Zugriff zu gewähren, erteilen Sie temporäre erhöhte Berechtigungen bei Bedarf für eine bestimmte Aufgabe, mit automatischem Widerruf nach einem definierten Zeitraum.

SaaS-Implementierung: Verwenden Sie Tools wie AWS IAM Identity Center (ehemals SSO) mit Sitzungsdauerbegrenzungen, HashiCorp Vault für dynamische Secrets oder dedizierte PAM-Lösungen. Wenn ein Entwickler Produktionsdatenbankzugriff für eine Debugging-Sitzung benötigt, fordert er JIT-Zugriff über einen Workflow an, der temporäre Anmeldedaten für 2-4 Stunden bereitstellt und alle Aktivitäten während dieses Zeitfensters protokolliert.

Protokollieren Sie alle privilegierten Aktionen. Jede Aktion, die mit privilegierten Anmeldedaten durchgeführt wird, muss protokolliert werden, und diese Protokolle müssen vor Änderungen durch die privilegierten Benutzer selbst geschützt werden. Senden Sie Protokolle an ein zentralisiertes SIEM oder Log-Management-System, wo sie überprüft werden können.

Überprüfen Sie privilegierten Zugriff vierteljährlich. Privilegierter Zugriff sollte häufiger überprüft werden als Standardzugriff. Vierteljährliche Überprüfungen sind die Mindesterwartung. Überprüfen Sie bei jeder Überprüfung, dass jedes privilegierte Konto noch benötigt wird, das Zugriffsniveau noch angemessen ist und der Kontoinhaber noch beschäftigt und in einer Rolle ist, die privilegierten Zugriff erfordert.

Das AWS-Root-Konto-Problem

Jedes AWS-Konto hat einen Root-Benutzer mit uneingeschränktem Zugriff. Dies ist ein häufiges Audit-Anliegen.

Best Practices:

• Aktivieren Sie MFA auf dem Root-Konto mit einem Hardware-Sicherheitsschlüssel
• Verwenden Sie das Root-Konto nicht für den täglichen Betrieb
• Bewahren Sie Root-Konto-Anmeldedaten an einem sicheren, physischen Ort auf (Tresor oder sicherer Aufbewahrungsort)
• Protokollieren und alarmieren Sie bei jeder Root-Konto-Nutzung über CloudTrail
• Dokumentieren Sie die Umstände, unter denen der Zugriff auf das Root-Konto zulässig ist (typischerweise beschränkt auf Aktionen auf Kontoebene, die nur Root ausführen kann)

Multi-Faktor-Authentifizierung und Single Sign-On

MFA-Anforderungen

Control A.8.5 erfordert eine sichere Authentifizierung, die der Sensibilität des zugegriffenen Systems angemessen ist. Für SaaS-Unternehmen bedeutet dies MFA-Anforderungen in der gesamten Umgebung.

Wo MFA durchgesetzt werden sollte:

• Jeder Identity-Provider-Zugriff (nicht verhandelbar)
• Jeder Cloud-Plattform-Konsolenzugriff (AWS, Azure, GCP)
• Jeder Zugriff auf Produktionsumgebungen
• Alle VPN-Verbindungen
• Jeder Code-Repository-Zugriff
• Jeder privilegierte Kontozugriff
• Jeder administrative Zugriff auf SaaS-Tools

MFA-Stärkehierarchie:

1. Hardware-Sicherheitsschlüssel (FIDO2/WebAuthn): Am widerstandsfähigsten gegen Phishing. Erforderlich für privilegierten Zugriff.
2. Authenticator-Apps (TOTP): Akzeptabel für Standardzugriff. Beispiele: Google Authenticator, Authy, 1Password.
3. Push-Benachrichtigungen: Akzeptabel, aber anfällig für MFA-Fatigue-Angriffe. Verwenden Sie Nummernabgleich, wenn verfügbar.
4. SMS-Codes: Schwächste Form. Anfällig für SIM-Swapping. Vermeiden Sie dies für den Zugriff auf Produktionssysteme.

Richtlinienempfehlung: Fordern Sie Authenticator-App-MFA als Minimum für jeden Zugriff. Fordern Sie Hardware-Sicherheitsschlüssel für privilegierten Zugriff und den Zugriff auf Systeme, die Kundendaten enthalten.

Single Sign-On (SSO)

SSO zentralisiert die Authentifizierung über Ihren Identity Provider und ist der effektivste Weg, konsistente Zugriffskontrollrichtlinien über Ihr SaaS-Tool-Ökosystem hinweg durchzusetzen.

Vorteile für die ISO 27001-Konformität:

• Zentralisierte Authentifizierungsprotokolle für alle verbundenen Anwendungen
• Konsistente MFA-Durchsetzung über alle Systeme hinweg
• Vereinfachte Deprovisionierung — deaktivieren Sie das IdP-Konto und der gesamte verbundene Zugriff wird entzogen
• Reduzierte Passwortmüdigkeit und die damit verbundenen Sicherheitsrisiken

SSO-Implementierungsprioritäten für SaaS-Unternehmen:

1. Zuerst: Cloud-Plattform-Zugriff (AWS IAM Identity Center, Azure AD, GCP Cloud Identity)
2. Zweitens: Code-Repositories (GitHub, GitLab, Bitbucket)
3. Drittens: CI/CD-Tools (Jenkins, CircleCI, GitHub Actions)
4. Viertens: Kommunikationstools (Slack, Microsoft Teams)
5. Fünftens: Alle verbleibenden SaaS-Tools, die SSO unterstützen

Die Realität der „SSO-Steuer”: Viele SaaS-Anbieter berechnen Premium-Preise für die SSO-Integration. Planen Sie dies bei Ihrer ISO 27001-Implementierungsplanung ein. Die Kosten für SSO sind durch die Compliance-Vorteile und die betriebliche Effizienz der zentralisierten Zugriffsverwaltung gerechtfertigt.

Anwendungen, die kein SSO unterstützen: Führen Sie ein dokumentiertes Inventar der Anwendungen, die nicht mit SSO verbunden werden können. Diese erfordern individuelle Kontoverwaltung, separate MFA-Durchsetzung und sollten bei Deprovisionierungschecklisten priorisiert werden, da sie nicht automatisch widerrufen werden, wenn das IdP-Konto deaktiviert wird.

Zugriffsüberprüfungen

Control A.5.18 erfordert, dass Zugriffsrechte in definierten Intervallen überprüft werden. Zugriffsüberprüfungen sind ein zentraler Audit-Prüfpunkt — Auditoren fordern den Nachweis, dass Überprüfungen planmäßig durchgeführt wurden und dass Feststellungen behoben wurden.

Überprüfungshäufigkeit

Vierteljährlich: Privilegierter Zugriff, Produktionsumgebungszugriff und Zugriff auf Systeme, die sensible Kundendaten enthalten. Dies ist die Mindestkadenz, die Auditoren für risikoreichen Zugriff erwarten.

Halbjährlich: Standardanwendungszugriff, Code-Repository-Zugriff und Zugriff auf Unternehmenstools.

Jährlich: Zugriff mit geringem Risiko, Informationssysteme und interne Dokumentationsplattformen.

Ihre Zugriffskontrollrichtlinie muss die Überprüfungshäufigkeit für jede Kategorie festlegen. Setzen Sie keine Häufigkeit fest, die Sie nicht aufrechterhalten können — ein versäumter Überprüfungszyklus ist ein Audit-Finding.

Durchführung von Zugriffsüberprüfungen

Schritt 1: Zugriffsberichte generieren. Exportieren Sie aktuelle Benutzerlisten und deren Berechtigungen aus jedem zu überprüfenden System. Die meisten Identity Provider können konsolidierte Berichte über verbundene Anwendungen hinweg generieren.

Schritt 2: An Prüfer verteilen. Jedes System oder jede Anwendung sollte einen benannten Verantwortlichen haben, der den Zugriff für dieses System überprüft. In der Praxis bedeutet dies oft:

• Engineering-Leads überprüfen den Zugriff auf Produktionsinfrastruktur
• Teamleiter überprüfen den Anwendungszugriff ihres Teams
• Das Sicherheitsteam überprüft privilegierten Zugriff über alle Systeme hinweg

Schritt 3: Jeden Eintrag überprüfen. Für jede Benutzer-Zugriffs-Kombination bestimmt der Prüfer:

• Ist diese Person noch beschäftigt? (Abgleich mit HR-Daten)
• Erfordert ihre aktuelle Rolle diesen Zugriff?
• Ist das Zugriffsniveau angemessen (nicht übermäßig)?
• Ist das Konto aktiv (wurde es kürzlich verwendet)?

Schritt 4: Feststellungen beheben. Entfernen Sie nicht mehr benötigten Zugriff. Stufen Sie übermäßige Berechtigungen herab. Deaktivieren Sie inaktive Konten. Dokumentieren Sie jede Behebungsmaßnahme.

Schritt 5: Überprüfung dokumentieren. Bewahren Sie den Zugriffsbericht, Prüferkommentare, Behebungsmaßnahmen und das Abschlussdatum auf. Dies ist der Nachweis, den Auditoren anfordern werden.

SaaS-Implementierung: Erstellen Sie einen automatisierten Zugriffsüberprüfungs-Workflow. Exportieren Sie Benutzerlisten aus Ihrem Identity Provider und verbundenen Systemen per API. Präsentieren Sie diese in einem strukturierten Format (Tabelle, GRC-Plattform oder benutzerdefiniertes Tool), in dem Prüfer jeden Zugriffseintrag genehmigen, markieren oder widerrufen können. Verfolgen Sie den Abschlussgrad und senden Sie Erinnerungen an Prüfer, die ihre Überprüfungen nicht bis zum Stichtag abgeschlossen haben.

Häufige Feststellungen bei Zugriffsüberprüfungen

• Verwaiste Konten: Konten ehemaliger Mitarbeiter oder Auftragnehmer, die nicht ordnungsgemäß deprovisioniert wurden
• Übermäßige Berechtigungen: Benutzer mit Zugriff über das hinaus, was ihre Rolle erfordert, oft durch Rollenwechsel ohne Zugriffsbereinigung
• Inaktive Konten: Aktive Konten, die seit 60-90+ Tagen nicht verwendet wurden, was darauf hindeutet, dass der Zugriff unnötig ist
• Gemeinsam genutzte Konten: Mehrere Personen nutzen dieselben Anmeldedaten, was Rechenschaftspflicht und Audit-Trail-Anforderungen verletzt
• Fehlende MFA: Konten, bei denen MFA durchgesetzt werden sollte, dies aber nicht der Fall ist

SaaS-spezifische Überlegungen zur Zugriffskontrolle

SaaS-Unternehmen stehen vor Herausforderungen bei der Zugriffskontrolle, die in traditionellen IT-Umgebungen nicht existieren. Ihre Richtlinien und Verfahren müssen diese explizit adressieren.

Mandantenfähigkeit

Wenn Ihr Produkt mandantenfähig ist, muss die Zugriffskontrolle eine strikte Isolation zwischen Mandanten sicherstellen. Dies ist sowohl eine Sicherheitsanforderung als auch eine Frage des Kundenvertrauens.

Umzusetzende Controls:

• Mandantenisolation auf Anwendungs-, Datenbank- und Netzwerkebene
• Zugriff auf Kundendaten beschränkt durch Mandantenkontext (ein Entwickler, der ein Problem eines Kunden debuggt, sollte nicht auf die Daten eines anderen Kunden zugreifen können)
• Audit-Protokollierung aller mandantenübergreifenden Zugriffe
• Regelmäßiges Testen der Mandantenisolationsgrenzen (in den Umfang der Penetrationstests einbeziehen)

API-Schlüssel und Service-zu-Service-Authentifizierung

SaaS-Produkte bieten typischerweise APIs an, gegen die sich Kunden und Partner authentifizieren. Die Verwaltung dieser Anmeldedaten ist eine Zugriffskontrollverantwortung.

API-Schlüssel-Management:

• Generieren Sie eindeutige API-Schlüssel pro Kunde oder Integration, keine gemeinsamen Schlüssel
• Unterstützen Sie Schlüsselrotation ohne Dienstunterbrechung
• Implementieren Sie Richtlinien zum Schlüsselablauf
• Protokollieren Sie jede API-Schlüssel-Nutzung und überwachen Sie auf anomale Muster
• Bieten Sie Kunden die Möglichkeit, ihre eigenen Schlüssel zu widerrufen und neu zu generieren
• Betten Sie API-Schlüssel niemals in Quellcode oder clientseitige Anwendungen ein

Service-zu-Service-Authentifizierung:

• Verwenden Sie kurzlebige Token (OAuth 2.0, JWT) anstelle von langlebigen Anmeldedaten, wo möglich
• Implementieren Sie Mutual TLS (mTLS) für interne Dienstkommunikation in hochsicheren Kontexten
• Rotieren Sie Dienstanmeldedaten nach einem definierten Zeitplan
• Speichern Sie Dienstanmeldedaten in einem Secrets Manager (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), nicht in Umgebungsvariablen oder Konfigurationsdateien

CI/CD-Pipeline-Zugriff

Ihre Deployment-Pipeline hat konstruktionsbedingt Produktionszugriff — sie deployt Code, führt Migrationen aus und verwaltet Infrastruktur. Dies macht sie zu einem hochwertigen Angriffsziel und einem kritischen Zugriffskontrollbereich.

CI/CD-Zugriffskontrollen:

• Beschränken Sie, wer Pipeline-Konfigurationen ändern kann (behandeln Sie Pipeline-as-Code mit denselben Controls wie Anwendungscode)
• Verwenden Sie kurzlebige, begrenzte Anmeldedaten für Deployments (OIDC-Federation mit AWS, temporäre Token anstelle langlebiger Secrets)
• Fordern Sie Genehmigungsstufen für Produktionsdeployments (mindestens Code-Review; idealerweise eine explizite Deployment-Genehmigung)
• Protokollieren Sie alle Pipeline-Ausführungen mit vollständigen Audit-Trails
• Implementieren Sie Branch-Protection-Regeln, sodass nur der Hauptbranch Produktionsdeployments auslösen kann
• Trennen Sie Pipeline-Anmeldedaten nach Umgebung (die Staging-Pipeline sollte keine Produktionsanmeldedaten haben)

Kundendatenzugriff für den Support

Support-Ingenieure und Customer-Success-Teams müssen möglicherweise auf Kundendaten zugreifen, um Probleme zu lösen. Dieser Zugriff muss kontrolliert, begründet und protokolliert werden.

Break-Glass-Zugriffsmodell:

• Definieren Sie klare Kriterien, wann der Zugriff auf Kundendaten zulässig ist (z. B. aktives Support-Ticket des Kunden)
• Fordern Sie eine explizite Genehmigung für jedes Zugriffsereignis (von einem Teamleiter oder über einen automatisierten Workflow)
• Gewähren Sie zeitlich begrenzten Zugriff (automatisch nach der Support-Sitzung widerrufen)
• Protokollieren Sie jeden Datenzugriff während der Sitzung
• Anonymisieren oder pseudonymisieren Sie Daten in Nicht-Produktionsumgebungen, damit der Support Fehler beheben kann, ohne echte Kundendaten einzusehen

Cloud-IAM-Implementierung

Für SaaS-Unternehmen, die auf großen Cloud-Plattformen laufen, ist Cloud-IAM der primäre Mechanismus zur Implementierung der Zugriffskontrolle auf Infrastrukturebene.

AWS IAM

Kontostruktur: Verwenden Sie AWS Organizations mit separaten Konten für Produktion, Staging, Entwicklung und Sicherheit/Audit. Dies bietet harte Kontogrenzen, die versehentlichen umgebungsübergreifenden Zugriff verhindern.

IAM-Best-Practices für ISO 27001:

• Verwenden Sie niemals das Root-Konto für den Betrieb. Aktivieren Sie MFA und beschränken Sie dessen Nutzung.
• Verwenden Sie IAM Identity Center (ehemals SSO), um den Zugriff von Ihrem Identity Provider zu föderieren
• Definieren Sie IAM-Richtlinien nach dem Prinzip der geringsten Berechtigung — beginnen Sie ohne Berechtigungen und fügen Sie nur das Nötige hinzu
• Verwenden Sie IAM-Rollen für Anwendungen und Dienste, keine IAM-Benutzer mit langlebigen Zugriffsschlüsseln
• Aktivieren Sie CloudTrail in allen Regionen für umfassende Audit-Protokollierung
• Verwenden Sie Service Control Policies (SCPs), um organisationsweite Leitplanken durchzusetzen
• Implementieren Sie Berechtigungsgrenzen, um die maximalen Berechtigungen einer IAM-Entität zu begrenzen

Häufige AWS-Audit-Feststellungen:

• IAM-Benutzer mit Inline-Richtlinien anstelle angehängter verwalteter Richtlinien
• Zugriffsschlüssel, die seit 90+ Tagen nicht rotiert wurden
• IAM-Benutzer mit Konsolenzugriff, aber ohne MFA
• Übermäßig permissive Richtlinien mit Wildcards (z. B. "Action": "*", "Resource": "*")
• CloudTrail nicht in allen Regionen aktiviert

Azure IAM

Mandanten- und Abonnementstruktur: Verwenden Sie Azure-Verwaltungsgruppen und -Abonnements, um Umgebungen zu trennen. Azure AD (jetzt Entra ID) dient als Identity Provider.

Wichtige Controls:

• Verwenden Sie Azure AD Privileged Identity Management (PIM) für JIT-privilegierten Zugriff
• Implementieren Sie Conditional-Access-Richtlinien für risikobasierte Authentifizierung
• Aktivieren Sie Azure AD Identity Protection für automatisierte Risikoerkennung
• Verwenden Sie verwaltete Identitäten für Azure-Ressourcen (eliminiert Anmeldedatenverwaltung für Service-zu-Service-Zugriff)
• Konfigurieren Sie Diagnoseeinstellungen, um Azure-AD-Protokolle an Ihr SIEM zu streamen

GCP IAM

Ressourcenhierarchie: Verwenden Sie GCP-Organisationen, -Ordner und -Projekte, um Umgebungen zu trennen. Cloud Identity oder Google Workspace dient als Identity Provider.

Wichtige Controls:

• Verwenden Sie Workload Identity Federation, um Dienstkontoschlüssel für externe Workloads zu vermeiden
• Implementieren Sie Organisationsrichtlinien, um Beschränkungen projektübergreifend durchzusetzen
• Verwenden Sie IAM Conditions für kontextbezogene Zugriffsentscheidungen
• Aktivieren Sie Admin-Activity-Audit-Protokolle (immer aktiv) und Data-Access-Audit-Protokolle für sensible Ressourcen
• Überprüfen Sie IAM-Recommender-Vorschläge zur Reduzierung übermäßiger Berechtigungen

Protokollierung und Überwachung von Zugriffsereignissen

Zugriffskontrolle ist ohne Sichtbarkeit unvollständig. Die Controls A.8.15 (Protokollierung) und A.8.16 (Überwachungsaktivitäten) erfordern, dass Zugriffsereignisse protokolliert und auf Anomalien überwacht werden.

Was protokolliert werden muss

Authentifizierungsereignisse:

• Erfolgreiche und fehlgeschlagene Anmeldeversuche
• MFA-Herausforderungen und -Ergebnisse
• Passwortänderungen und -zurücksetzungen
• Kontosperrungen
• SSO-Token-Ausstellung und -Erneuerung

Autorisierungsereignisse:

• Zugriffsgewährungen und -widerrufe
• Berechtigungsänderungen
• Rollenzuweisungen und -entfernungen
• Privilegien-Eskalationsereignisse

Administrative Ereignisse:

• IAM-Richtlinienänderungen
• Sicherheitsgruppenänderungen
• Netzwerk-ACL-Änderungen
• Erstellung oder Änderung von Dienstkonten

Datenzugriffsereignisse:

• Datenbankabfragen auf sensiblen Tabellen
• Dateizugriffe an sensiblen Speicherorten
• API-Aufrufe, die Kundendaten zurückgeben
• Massen-Datenexporte oder -downloads

Überwachung und Alarmierung

Protokollierung ist notwendig, aber nicht ausreichend. Sie müssen Protokolle aktiv auf verdächtige Muster überwachen und auf Alarme reagieren.

Alarmierungswürdige Ereignisse:

• Mehrere fehlgeschlagene Anmeldeversuche vom selben Konto oder derselben IP-Adresse
• Erfolgreiche Anmeldung von einem ungewöhnlichen geografischen Standort
• Nutzung privilegierter Konten außerhalb der Geschäftszeiten
• Zugriff auf sensible Daten durch Konten, die normalerweise nicht darauf zugreifen
• Erstellung neuer privilegierter Konten
• Deaktivierung von MFA auf einem beliebigen Konto
• Zugriff von IP-Adressen, die nicht in Ihren Unternehmens- oder VPN-Bereichen liegen

SaaS-Implementierung: Leiten Sie alle Zugriffsprotokolle an ein zentralisiertes SIEM weiter (Datadog, Splunk, Elastic oder eine cloud-native Lösung wie AWS Security Hub, Azure Sentinel oder GCP Chronicle). Definieren Sie Alarmierungsregeln für die oben genannten Ereignisse. Etablieren Sie einen Prozess zur Bewertung und Untersuchung von Alarmen mit Eskalation an Ihren Incident-Response-Prozess bei bestätigter verdächtiger Aktivität.

Protokollschutz

Zugriffsprotokolle müssen vor Manipulation geschützt werden. Wenn ein kompromittiertes privilegiertes Konto seine eigenen Zugriffsprotokolle ändern kann, verlieren die Protokolle ihren Beweiswert.

Schutzmaßnahmen:

• Speichern Sie Protokolle in einem separaten Konto oder System als die überwachten Systeme
• Wenden Sie Write-Once-Read-Many (WORM) oder Append-Only-Richtlinien auf die Protokollspeicherung an
• Beschränken Sie die Löschung und Änderung von Protokollen auf eine sehr kleine Anzahl von Konten (oder verhindern Sie dies vollständig)
• Überwachen Sie Protokollmanipulation oder -löschung als hochprioritären Alarm

Häufige Audit-Feststellungen bei der Zugriffskontrolle

Das Verständnis, was Auditoren typischerweise finden, hilft Ihnen, Lücken proaktiv zu schließen. Dies sind die häufigsten Zugriffskontrollfeststellungen bei ISO 27001-Zertifizierungsaudits.

Feststellung 1: Unvollständige Deprovisionierung

Was Auditoren testen: Sie fordern Ihre Liste gekündigter Mitarbeiter für den Prüfzeitraum an und gleichen diese mit Benutzerkonten in kritischen Systemen ab.

Was sie finden: Ehemalige Mitarbeiter mit aktiven Konten in Systemen, die nicht mit dem Identity Provider verbunden sind — oft Legacy-Anwendungen, Entwicklertools oder Cloud-Plattform-Konten mit lokalen Anmeldedaten.

Wie Sie es verhindern: Pflegen Sie eine umfassende Deprovisionierungscheckliste, die jedes System im Geltungsbereich abdeckt. Automatisieren Sie, wo möglich. Für Systeme, die nicht automatisiert werden können, überprüfen Sie die Deprovisionierungsvollständigkeit manuell und dokumentieren Sie die Verifizierung.

Feststellung 2: Übermäßiger privilegierter Zugriff

Was Auditoren testen: Sie überprüfen die Liste der Benutzer mit privilegiertem Zugriff und vergleichen diese mit dem Organigramm und den Rollendefinitionen.

Was sie finden: Entwickler, denen vor Monaten Admin-Zugriff für ein bestimmtes Projekt gewährt wurde und die ihn noch haben. Gründer, die Root-Zugriff auf alles haben, obwohl sie in nicht-technische Rollen gewechselt sind. Dienstkonten mit Admin-Berechtigungen, weil die Einrichtung „einfacher” war.

Wie Sie es verhindern: Implementieren Sie vierteljährliche Überprüfungen privilegierter Zugriffe mit dokumentierter Behebung. Verwenden Sie JIT-Zugriff für privilegierte Operationen, sodass dauerhafter Admin-Zugriff die Ausnahme ist, nicht die Regel.

Feststellung 3: Fehlende oder unvollständige Zugriffsüberprüfungen

Was Auditoren testen: Sie fordern Nachweise abgeschlossener Zugriffsüberprüfungen für den Prüfzeitraum an, die der in Ihrer Zugriffskontrollrichtlinie festgelegten Häufigkeit entsprechen.

Was sie finden: Überprüfungen, die vierteljährlich hätten stattfinden sollen, aber nur zweimal stattfanden. Überprüfungen, die durchgeführt wurden, aber keine Dokumentation von Feststellungen und Behebungen enthielten. Überprüfungen, die einige Systeme abdeckten, aber nicht alle Systeme im Geltungsbereich.

Wie Sie es verhindern: Automatisieren Sie die Planung von Zugriffsüberprüfungen. Setzen Sie Kalendererinnerungen mit ausreichend Vorlaufzeit, um die Überprüfung vor dem Stichtag abzuschließen. Verwenden Sie eine strukturierte Überprüfungsvorlage, die Datum, Prüfer, überprüfte Systeme, Feststellungen und Behebungsmaßnahmen erfasst. Siehe unsere ISO 27001-Zertifizierungscheckliste für einen vollständigen Zeitplan wiederkehrender Aktivitäten.

Feststellung 4: Gemeinsam genutzte Konten

Was Auditoren testen: Sie suchen nach Konten, die von mehreren Personen genutzt werden, was Rechenschaftspflicht und Audit-Trail-Anforderungen verletzt.

Was sie finden: Gemeinsam genutzte „Admin”-Konten für SaaS-Tools, die SSO nicht unterstützen. Gemeinsame Anmeldedaten für Legacy-Systeme. Generische „Deploy”-Konten, die von mehreren Entwicklern genutzt werden.

Wie Sie es verhindern: Eliminieren Sie gemeinsam genutzte Konten, wo immer möglich. Wo gemeinsam genutzte Konten technisch unvermeidbar sind (einige Legacy-Systeme), implementieren Sie kompensierende Controls: Ein-/Auschecken-Verfahren, Sitzungsaufzeichnung und Nutzungsprotokollierung, die identifiziert, wer das gemeinsam genutzte Konto zu einem bestimmten Zeitpunkt verwendet hat.

Feststellung 5: Unzureichende MFA-Abdeckung

Was Auditoren testen: Sie überprüfen, ob MFA auf allen Systemen durchgesetzt wird, auf denen Ihre Richtlinie dies erfordert.

Was sie finden: MFA-Richtlinien, die im Identity Provider konfiguriert sind, aber mit Ausnahmen für bestimmte Benutzer oder Anwendungen. Cloud-Plattform-Konten mit MFA auf der Konsole, aber nicht für den CLI-Zugriff. Anwendungen, die MFA unterstützen, bei denen es aber nie aktiviert wurde.

Wie Sie es verhindern: Prüfen Sie die MFA-Durchsetzung über alle Systeme im Geltungsbereich. Schließen Sie Ausnahmelücken. Für Systeme, die MFA nicht unterstützen, dokumentieren Sie die Einschränkung und implementieren Sie kompensierende Controls (IP-Beschränkungen, VPN-Anforderungen, erweiterte Protokollierung).

Häufig gestellte Fragen

Was ist der Unterschied zwischen Zugriffskontrolle in ISO 27001 und SOC 2?

Die zugrundeliegenden Anforderungen sind nahezu identisch — beide Frameworks erwarten geringste Berechtigung, MFA, Zugriffsüberprüfungen, Bereitstellungs-/Deprovisionierungskontrollen und Verwaltung privilegierter Zugriffe. Der Unterschied liegt in der Framework-Struktur. ISO 27001 organisiert Zugriffskontrollanforderungen über spezifische Annex A Controls. SOC 2 adressiert die Zugriffskontrolle über Common Criteria (hauptsächlich CC6.1 bis CC6.8). Ein SaaS-Unternehmen, das Zugriffskontrollen für ein Framework implementiert, wird die meisten Anforderungen des anderen Frameworks mit minimalem Zusatzaufwand erfüllen.

Wie oft müssen Zugriffsüberprüfungen durchgeführt werden?

ISO 27001 schreibt keine bestimmte Häufigkeit vor — es verlangt Überprüfungen in „geplanten Intervallen”. Sie definieren die Häufigkeit in Ihrer Zugriffskontrollrichtlinie. Der Branchenstandard für Zertifizierungsaudits ist vierteljährliche Überprüfungen für privilegierten und sensiblen Zugriff sowie halbjährliche oder jährliche Überprüfungen für Standardzugriff. Welche Häufigkeit Sie auch festlegen, Sie müssen eine konsistente Durchführung nachweisen.

Benötigen wir ein separates Privileged-Access-Management (PAM)-Tool?

Nicht unbedingt. Die Anforderung besteht darin, privilegierten Zugriff zu kontrollieren — wie Sie diese Kontrolle implementieren, liegt bei Ihnen. Kleine SaaS-Unternehmen können privilegierten Zugriff durch IAM-Richtlinien, JIT-Zugriffsskripte und dokumentierte manuelle Prozesse verwalten. Mit zunehmender Skalierung wird ein dediziertes PAM-Tool (CyberArk, BeyondTrust, HashiCorp Vault) zunehmend wertvoll für die Zentralisierung der Verwaltung privilegierter Anmeldedaten, die Implementierung von Sitzungsaufzeichnungen und die Automatisierung der Anmeldedatenrotation.

Wie sollten wir die Zugriffskontrolle für Kundendaten in einem mandantenfähigen SaaS-Produkt handhaben?

Mandantenisolation muss auf technischer Ebene durchgesetzt werden — Anwendungslogik, Datenbankabfragen (Row-Level-Security oder Schema/Datenbank pro Mandant) und Netzwerksegmentierung. Der interne Zugriff auf Kundendaten sollte eine explizite Begründung erfordern (aktives Support-Ticket), zeitlich begrenzte Zugriffsgewährungen und umfassende Protokollierung. Erwägen Sie die Implementierung einer Kundendatenzugriffsrichtlinie, die aufgrund ihrer Sensibilität und der zusätzlichen erforderlichen Controls von Ihrer allgemeinen Zugriffskontrollrichtlinie getrennt ist.

Welche Beziehung besteht zwischen unserer Zugriffskontrollrichtlinie und unserer Risikobewertung?

Ihre Risikobewertung identifiziert Risiken im Zusammenhang mit unbefugtem Zugriff, übermäßigen Berechtigungen und Zugriffskontrollfehlern. Die Zugriffskontrollrichtlinie definiert die Controls, die diese Risiken behandeln. Beide sollten explizit verknüpft sein — jede Zugriffskontrollanforderung in Ihrer Richtlinie sollte auf ein Risiko zurückzuführen sein, das sie adressiert, und jedes zugriffsbezogene Risiko in Ihrem Risikoregister sollte auf das Control zurückzuführen sein, das es mindert. Diese Nachverfolgbarkeit ist etwas, nach dem Auditoren suchen, und wird in Ihrer Erklärung zur Anwendbarkeit dokumentiert.

Wie GRCTrail hilft

GRCTrail vereinfacht die Implementierung und laufende Konformität der ISO 27001 Zugriffskontrolle für SaaS-Unternehmen:

• Automatisierte Zugriffsüberprüfungen, die Benutzerlisten aus Ihrem Identity Provider und verbundenen Systemen abrufen, an die entsprechenden Prüfer weiterleiten, den Abschluss verfolgen und Nachweise aufbewahren — und damit den tabellenbasierten Überprüfungsprozess eliminieren, der zu versäumten Fristen führt
• Zugriffskontrollrichtlinien-Vorlagen, die auf SaaS-Unternehmen zugeschnitten sind und jedes relevante Annex A Control mit praxisorientierter Sprache für Cloud-Umgebungen, CI/CD-Pipelines und mandantenfähige Architekturen abdecken
• Dashboards zur kontinuierlichen Überwachung, die die MFA-Durchsetzung, inaktive Konten und privilegierten Zugriff über Ihre Umgebung hinweg verfolgen und Sie auf Abweichungen aufmerksam machen, bevor Ihr Auditor sie findet

Starten Sie mit GRCTrail

Verwandte Leitfäden

• Was ist ISO 27001? Ein praktischer Leitfaden für SaaS-Unternehmen
• ISO 27001 Annex A Controls: Der vollständige Leitfaden
• ISO 27001 Richtlinien: Welche Richtlinien Sie benötigen und wie Sie sie schreiben
• ISO 27001 Zertifizierungscheckliste
• ISO 27001 Risikobewertung: Leitfaden