Governance für Microsoft Entra Conditional Access im Jahr 2026

Es ist 09:12 Uhr an einem Dienstag, als Maria, CISO eines schnell wachsenden europäischen Fintechs, einen DORA-Vorbereitungsbericht öffnet, der eigentlich Routine sein sollte. Ihr Microsoft Entra Conditional Access-Dashboard wirkt solide. MFA wird für Administratoren durchgesetzt. Legacy-Authentifizierung ist blockiert. Anmeldungen mit hohem Risiko werden zusätzlich geprüft oder abgewiesen. Schutzbedürftige Finanzanwendungen verlangen konforme Geräte. Der Browserzugriff von nicht verwalteten Endpunkten ist eingeschränkt.

Dann liest sie die Feststellung des Auditors.

„Ihre Conditional-Access-Regeln sind technisch belastbar, aber sie stehen isoliert. Zeigen Sie uns die vom Leitungsorgan genehmigte Richtlinie, die diese Einstellungen vorschreibt. Zeigen Sie uns den Änderungsnachweis für die im letzten Monat geänderte Regel. Zeigen Sie uns, wie die Richtlinie für Anmeldungen mit hohem Risiko während des vermuteten Credential-Stuffing-Angriffs aktiv war. Zeigen Sie uns, wie diese Nachweise ISO 27001, DORA, NIS2 und GDPR unterstützen.“

Das Identitätsteam kann die Konfiguration exportieren. Das SOC kann Anmeldeprotokolle vorlegen. Der Compliance-Manager kann auf einen Richtlinienordner verweisen. Aber niemand kann eine durchgängig gesteuerte, auditfähige Nachweiskette vorlegen, die Risiko, Richtlinie, Genehmigung, Konfiguration, Ausnahmen, Überwachung, Incident Response, Datenschutzpflichten und Managementbewertung miteinander verbindet.

Das ist das Governance-Problem von Conditional Access im Jahr 2026.

Microsoft Entra Conditional Access ist nicht mehr nur eine Identitätseinstellung. Es ist ein Kontrollsystem auf Ebene des Leitungsorgans, das entscheidet, wer auf Cloud-Services zugreifen darf, unter welchen Bedingungen, von welchen Geräten, mit welcher Authentifizierungsstärke und mit welchen Sitzungsbeschränkungen. Für regulierte Organisationen müssen diese Entscheidungen nachvollziehbar, belastbar und den Verpflichtungen aus ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST und COBIT 2019 zugeordnet sein.

Conditional Access ist heute ein auditierbares Kontrollsystem

Conditional Access liegt an der Schnittstelle von Identität, Gerätezustand, Anwendungssensitivität, Standort, Anmelderisiko, Benutzerrisiko, Sitzungsverhalten und Protokollierung. Eine einzelne Richtlinie kann MFA verlangen, ein konformes Gerät voraussetzen, den Zugriff von einem risikobehafteten Standort blockieren, Downloads aus nicht verwalteten Browsern einschränken oder eine erneute Authentifizierung erzwingen, wenn sich das Risiko ändert.

Damit ist Conditional Access einer der wirksamsten Zero-Trust-Durchsetzungspunkte in Microsoft-Cloud-Umgebungen. Gleichzeitig ist er hochgradig auditierbar.

Nach ISO/IEC 27001:2022 ist eine Maßnahme nicht allein deshalb ausgereift, weil sie in einem Portal existiert. Die Organisation muss ihren Kontext verstehen, Informationssicherheitsrisiken beurteilen, Risikobehandlungen auswählen, die Erklärung zur Anwendbarkeit dokumentieren, Kontrollen betreiben, die Wirksamkeit überwachen und fortlaufend verbessern. Relevante Abschnitte sind Clause 6.1.2 für Risikobeurteilung, Clause 6.1.3 für Risikobehandlung, Clause 7.5 für dokumentierte Informationen, Clause 8.1 für operative Planung und Steuerung, Clause 9.1 für Überwachung und Clause 9.3 für Managementbewertung.

Anhang A, ausgerichtet an ISO/IEC 27002:2022, liefert die praktische Kontrollsprache, die Auditoren erwarten. Conditional Access unterstützt typischerweise:

• 5.15 Zugriffskontrolle
• 5.16 Identitätsmanagement
• 5.17 Authentifizierungsinformationen
• 5.18 Zugriffsrechte
• 8.1 Benutzer-Endgeräte
• 8.2 privilegierte Zugriffsrechte
• 8.3 Beschränkung des Informationszugriffs
• 8.5 sichere Authentifizierung
• 8.15 Protokollierung
• 8.16 Überwachungsaktivitäten

Für in der EU regulierte Organisationen ist die Governance-Anforderung noch eindeutiger. NIS2 Article 20 überträgt den Leitungsorganen die Verantwortung, Maßnahmen zum Management von Cybersicherheitsrisiken zu genehmigen und zu überwachen. NIS2 Article 21 verlangt geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen, einschließlich Zugriffskontrolle, Asset-Management, Cyberhygiene, Verfahren zum Umgang mit Informationssicherheitsvorfällen, Sicherheit der Lieferkette, Wirksamkeitsbewertung sowie Multi-Faktor- oder kontinuierliche Authentifizierung, soweit angemessen. NIS2 Article 23 führt eine gestufte Meldung erheblicher Vorfälle ein, einschließlich einer Frühwarnung innerhalb von 24 Stunden, einer Vorfallmeldung innerhalb von 72 Stunden und eines Abschlussberichts innerhalb eines Monats.

DORA formuliert ähnliche Erwartungen an Finanzunternehmen. Article 5 verlangt ein internes Governance- und Kontrollrahmenwerk. Article 6 verlangt ein Rahmenwerk für das Management von IKT-Risiken. Article 9 behandelt Schutz und Prävention, einschließlich Zugriffsbeschränkungen und Praktiken des Identitätsmanagements. Articles 10, 11, 17, 18 und 19 verknüpfen Erkennung, Reaktion, Wiederherstellung, IKT-Vorfallmanagement, Klassifizierung und Berichterstattung. Da DORA seit dem 17. Januar 2025 gilt, sollten Finanzunternehmen Conditional Access als Bestandteil von Nachweisen zur operativen Resilienz behandeln, nicht nur als Identitätshärtung.

GDPR ergänzt die Datenschutzperspektive. Wenn Conditional Access Systeme schützt, die personenbezogene Daten verarbeiten, unterstützt es die Rechenschaftspflicht nach Article 5, die Verantwortung des Verantwortlichen nach Article 24, Datenschutz durch Technikgestaltung nach Article 25 und Sicherheit der Verarbeitung nach Article 32. Bei Verdacht auf unbefugten Zugriff können Conditional-Access-Protokolle Teil der Bewertung und Meldung einer Datenschutzverletzung werden.

Der Fehler besteht darin, diese Anforderungen als getrennte Audit-Anfragen zu behandeln. Der ausgereifte Ansatz ist ein Governance-Modell für Conditional Access, das je nach Framework, Aufsichtsbehörde, Kunde oder Leitungsorgan aufbereitet werden kann.

Konfiguration ist keine Governance

Die meisten Organisationen können die Frage beantworten: „Was ist konfiguriert?“ Weniger Organisationen können die schwierigeren Fragen beantworten:

• Warum ist diese Conditional-Access-Richtlinie so konfiguriert?
• Welches Risikoszenario wird dadurch behandelt?
• Welche Richtlinienklausel verlangt dies?
• Wer hat die Änderung genehmigt?
• Welche Benutzer, Anwendungen und Geräte sind ausgeschlossen?
• Wie wird dies getestet?
• Welche Protokolle belegen die Wirksamkeit?
• Wie häufig erfolgt die Überprüfung?
• Was passiert, wenn die Kontrolle versagt?

An dieser Stelle entstehen typischerweise Audit-Feststellungen. Richtlinien existieren, sind aber nicht mit Microsoft Entra-Einstellungen verknüpft. Gerätekonformität liegt im IT-Betrieb, ist aber nicht dem Zugriffskontrollrisiko zugeordnet. Richtlinien für Anmelderisiken sind aktiviert, ohne dokumentierte Schwellenwerte oder Eskalationsregeln. Sitzungsbeschränkungen sind konfiguriert, werden aber nie von nicht verwalteten Geräten aus getestet. Protokolle werden aufbewahrt, aber nicht zu auditfähigen Nachweisen aufbereitet.

Clarysec behandelt dies als Problem der Nachvollziehbarkeit. Jede Conditional-Access-Entscheidung sollte Richtlinie, Risiko, Kontrolle, Konfiguration, Nachweis und Überprüfung verbinden.

Die KMU-Richtlinie zur Nutzung von Cloud-Diensten KMU-Richtlinie zur Nutzung von Cloud-Diensten legt fest:

Multi-Faktor-Authentifizierung (MFA) für Administrations- und Benutzerkonten

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

Diese Klausel ist die Vorgabe. Die Conditional-Access-Regel ist die Durchsetzung. Das Anmeldeprotokoll ist der Nachweis. Der Überprüfungsnachweis belegt die Aufsicht.

Die KMU-Netzwerksicherheitsrichtlinie KMU-Netzwerksicherheitsrichtlinie ergänzt die Anforderung an den Gerätezustand:

Systeme ohne aktuelle Antivirensoftware, Patches oder einen akzeptablen Gerätezustand müssen blockiert oder in Quarantäne versetzt werden

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

In Microsoft Entra kann daraus „konformes Gerät erforderlich“, „nicht unterstützte Plattformen blockieren“, „nicht verwaltete Browsersitzungen einschränken“ oder „Zugriff auf risikoreiche Anwendungen von unbekannten Geräten verweigern“ werden. Die Kontrolle ist jedoch erst vollständig, wenn die Organisation Geltungsbereich, Genehmigung, Tests, Ausnahmen und Überwachung nachweisen kann.

Governance-Grundlage vor dem Regelwerk schaffen

Ein belastbares Conditional-Access-Programm beginnt außerhalb des Entra-Portals. Es beginnt mit dem ISMS, dem Risikoregister, der Zugriffskontrollrichtlinie, der Richtlinie zur Nutzung von Cloud-Diensten, der SoA und dem Nachweismodell.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint bietet eine praktische Abfolge. In der Phase Risikomanagement, Schritt 13, Risikobehandlungsplanung und Erklärung zur Anwendbarkeit, weist er Organisationen an, Kontrollen mit Risiken und regulatorischen Treibern zu verbinden:

Vorschriften querverweisen: Wenn bestimmte Kontrollen speziell umgesetzt werden, um GDPR, NIS2 oder DORA einzuhalten, können Sie dies entweder im Risikoregister als Teil der Begründung der Risikoauswirkung oder in den SoA-Anmerkungen dokumentieren.

Für Conditional Access verändert dies die Nachweiskette. Statt „Wir haben MFA aktiviert“ kann die Organisation sagen:

• Risikoszenario: Kompromittierte Benutzerzugangsdaten ermöglichen unbefugten Zugriff auf Kundendaten in Microsoft 365 und Finanz-SaaS.
• Risikoverantwortlicher: Leiter IT-Sicherheit.
• Behandlung: Entra Conditional Access verlangt starke MFA für privilegierte Rollen, MFA für Benutzer, Blockierung bei Anmelderisiko, konforme Geräte für schutzbedürftige Anwendungen und Sitzungsbeschränkungen für nicht verwaltete Endpunkte.
• Zuordnung zu ISO/IEC 27002:2022: 5.15, 5.16, 5.17, 5.18, 8.1, 8.2, 8.3, 8.5, 8.15 und 8.16.
• Regulatorische Zuordnung: NIS2 Articles 20, 21 und 23, DORA Articles 5, 6, 9, 10, 17 und 18, GDPR Articles 24, 25, 32 und 33.
• Nachweise: Richtliniengenehmigung, Conditional-Access-Export, Änderungsticket, Testergebnisse, Anmeldeprotokolle, Berichte zur Gerätekonformität, Ausnahmenregister, SOC-Tickets und Protokolle der Managementbewertung.

Der Zenith Blueprint erläutert außerdem in der Phase „Controls in Action“, Schritt 19, warum der Gerätezustand Teil der Zugriffsentscheidung sein muss:

Der Zugriff auf Informationen über Endpunkte muss kontextbewusst erfolgen. Erfüllt das Gerät beispielsweise Mindestanforderungen an die Sicherheit, bevor es auf Unternehmensressourcen zugreift? Hat es kürzlich einen Schadsoftware-Scan bestanden? Verbindet es sich von einem ungewöhnlichen Standort oder Netzwerk? Integriert mit Zero-Trust-Grundsätzen kann der Gerätezustand in Conditional Access einfließen und den Zugriff verweigern, bis das Gerät nachweist, dass es sicher ist.

Das ist das zentrale Governance-Prinzip. Conditional Access sollte risikobasiert, kontextbewusst und nachweisfähig sein.

Conditional-Access-Entscheidungen Kontrollzielen zuordnen

Ein ausgereiftes Programm definiert standardisierte Zugriffsentscheidungen und ordnet jede Entscheidung Governance-Absicht und Nachweisen zu. Dadurch werden Richtlinienwildwuchs reduziert und Audit-Gespräche vereinfacht.

Die Enterprise-Richtlinie zur Nutzung von Cloud-Diensten Richtlinie zur Nutzung von Cloud-Diensten unterstützt die zentrale Identitätsintegration:

Die Integration von Single Sign-On (SSO) mit dem IdP der Organisation ist erforderlich, um eine konsistente Authentifizierung sicherzustellen.

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

Die Enterprise-Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen macht die Überwachung explizit:

Die Nutzung von Single Sign-On (SSO)-Systemen muss mit zentralen Identitätsanbietern integriert sein, z. B. Active Directory (AD), Azure AD, und auf anomale Anmeldeaktivitäten überwacht werden.

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

Zusammen verlangen diese Klauseln mehr als SSO. Sie verlangen eine zentrale Identitätsarchitektur, konsistente Authentifizierung, Überwachung anomaler Anmeldungen und Nachweise, dass Zugriffsentscheidungen überprüft werden.

Gerätekonformität: die Kontrolle, die Auditoren testen können

Gerätekonformität wird besonders häufig überschätzt. Ein Dashboard kann 92 Prozent konforme Geräte anzeigen, aber ein Auditor wird fragen, ob die Regel auf die tatsächlich relevanten Anwendungen angewendet wird, ob private Geräte erlaubt sind, ob nicht unterstützte Plattformen blockiert werden und ob Ausnahmen genehmigt sind.

Die Enterprise-Richtlinie für Remote-Arbeit Richtlinie für Remote-Arbeit setzt die Genehmigungsbasislinie:

BYOD-Geräte müssen ausdrücklich genehmigt sein und:

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.2.2.

Dieser kurze Satz ist wesentlich. BYOD ist nicht nur ein technischer Zustand. Es ist eine Governance-Entscheidung. In Conditional Access sollte sie in Regeln zur Geräteeigentümerschaft, Mindest-Baselines für Konformität, Verschlüsselungsanforderungen, Patch- und Malware-Schutzprüfungen, Schutz mobiler Apps, Behandlung von Auftragnehmern und Überprüfung von Ausnahmen umgesetzt werden.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls ordnet ISO/IEC 27002:2022-Maßnahme 5.15 Zugriffskontrolle als präventive Maßnahme ein, die Vertraulichkeit, Integrität und Verfügbarkeit in der operativen Fähigkeit für Identitäts- und Zugriffsmanagement schützt. Außerdem verbindet er Zugriffskontrolle mit Benutzer-Endgeräten, weil nicht verwaltete Laptops, mobile Geräte und Desktop-Computer die zentrale Zugriffsdurchsetzung unterlaufen können.

Ein praxistaugliches vierteljährliches Conditional-Access Device Evidence Pack sollte enthalten:

• Genehmigte Baseline für Gerätekonformität.
• Conditional-Access-Richtlinien, die konforme Geräte verlangen.
• Anwendungen, die durch diese Richtlinien geschützt werden.
• Export ausgeschlossener Benutzer, Gruppen, Anwendungen und Plattformen.
• Trendbericht zu nicht konformen Geräten.
• Stichproben blockierter Anmeldeprotokolle für nicht konforme Geräte.
• Ausnahmenregister mit Verantwortlichem, Begründung, Ablaufdatum und Risikoakzeptanz.
• Aufzeichnung der Managementbewertung.

Dieses Nachweispaket unterstützt operative Kontrollen nach ISO/IEC 27001:2022, NIS2-Cyberhygiene, DORA-Schutz und Prävention sowie GDPR-Rechenschaftspflicht.

Anmelderisiko: Erkennung muss Entscheidungsnachweis werden

Risikobasierter Conditional Access ist der Punkt, an dem Identitätserkennung zu Zugriffsgovernance wird. Microsoft Entra kann Signale wie unbekannte Anmeldeeigenschaften, anonyme IP-Adressen, unmögliche Reisebewegungen und offengelegte Zugangsdaten bewerten. Auditoren akzeptieren „Risikorichtlinie aktiviert“ jedoch nicht als abschließende Antwort. Sie fragen, warum Schwellenwerte ausgewählt wurden, wer risikobehaftete Ereignisse überprüft und wann eine Anmeldung mit hohem Risiko zu einem Vorfall wird.

Die KMU-Richtlinie zur Protokollierung und Überwachung KMU-Richtlinie zur Protokollierung und Überwachung definiert eine Mindestanforderung an die Protokollierung:

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

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.4.2.

Die Enterprise-Richtlinie zur Protokollierung und Überwachung Richtlinie zur Protokollierung und Überwachung erweitert den erwarteten Ereignisumfang:

Zu erfassende Ereignistypen, z. B. Anmeldungen, Zugriffsausfälle, Konfigurationsänderungen, administrative Befehle, Erkennung von Schadsoftware

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.1.1.

Für Conditional Access sollten belastbare Nachweise erfolgreiche Anmeldungen, fehlgeschlagene Anmeldungen, Ergebnis der Conditional-Access-Richtlinie, MFA-Methode, Anmelderisiko, Benutzerrisiko, Gerätekonformitätsstatus, aufgerufene Anwendung, Standort, Client-Anwendung, Ergebnis der Sitzungskontrolle, Änderungsverlauf der Richtlinie und administrative Aktionen enthalten.

Zenith Controls ordnet ISO/IEC 27002:2022-Maßnahme 8.16 Überwachungsaktivitäten als aufdeckend und korrektiv ein und verknüpft sie mit Erkennungs- und Reaktionskonzepten. Er verbindet Überwachung mit Protokollierung, Ereignisbewertung, Bedrohungsinformationen, Lieferantenüberwachung und Vorfallmanagement. Zudem ordnet er Überwachungsaktivitäten GDPR Articles 32 und 33, NIS2-Vorfallsüberwachung und -meldung, DORA-IKT-Vorfallsnachverfolgung, kontinuierlicher Überwachung nach NIST und COBIT-Sicherheitsüberwachung zu.

Eine durch Conditional Access blockierte Anmeldung mit hohem Risiko ist daher nicht nur ein Sicherheitserfolg. Sie ist ein Nachweis dafür, dass präventive, aufdeckende und reaktive Prozesse verbunden sind.

Sitzungskontrollen: die Verbindung zwischen Zugriff und Datenschutz

Entscheidungen vor dem Zugriff reichen nicht aus. Sobald ein Benutzer authentifiziert ist, bestimmen Sitzungskontrollen, welche Restexposition verbleibt. Das ist besonders wichtig bei nicht verwalteten Geräten, Auftragnehmern, Remote-Arbeit, gemeinsam genutzten Terminals, risikobehafteten Standorten und Anwendungen, die personenbezogene Daten verarbeiten.

Die KMU-Richtlinie zu Anforderungen an die Anwendungssicherheit KMU-Richtlinie zu Anforderungen an die Anwendungssicherheit legt fest:

Sitzungsmanagement: Sitzungsdaten müssen nach 15 Minuten Inaktivität ablaufen und, soweit anwendbar, Warnhinweise vor dem Sitzungsablauf enthalten.

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

In der Microsoft Entra-Governance kann dies Anmeldehäufigkeit, Beschränkungen für persistente Browsersitzungen, Conditional Access App Control, durch Anwendungen erzwungene Einschränkungen, Download-Blockierung, erneute Authentifizierung nach Risikoänderungen und sensitivitätsbasierte Sitzungsbeschränkungen abbilden.

Sitzungskontrollen unterstützen ISO/IEC 27002:2022-Maßnahme 8.3 Beschränkung des Informationszugriffs und 8.5 sichere Authentifizierung. Außerdem unterstützen sie GDPR Article 32, indem sie unbefugtes Anzeigen, Herunterladen oder Fortbestehen des Zugriffs auf personenbezogene Daten reduzieren. Für DORA helfen Sitzungsbeschränkungen, die Exposition in IKT-Systemen zu begrenzen und Erkennung und Reaktion zu unterstützen. Für NIS2 sind sie verhältnismäßige Maßnahmen der Zugriffskontrolle und Cyberhygiene.

Die Nachweise sollten erklären, warum die Sitzungskontrolle existiert. Beispielsweise sollte „Download von nicht verwalteten Geräten für HR- und Finanzanwendungen blockieren“ auf Datenabfluss personenbezogener Daten, Endpoint-Kompromittierung und Verlust der Vertraulichkeit abgebildet werden. Nachweise sollten Konfiguration, Anwendungsumfang, Testanmeldungen von verwalteten und nicht verwalteten Geräten, Protokolle zu Einschränkungen und Genehmigungsaufzeichnungen umfassen.

Ein Conditional-Access-Kontrollregister erstellen

Ein Conditional-Access-Kontrollregister ist die operative Brücke zwischen Risikoregister, Erklärung zur Anwendbarkeit und Microsoft Entra-Konfiguration. Es ersetzt diese Dokumente nicht. Es macht sie nutzbar.

Nutzen Sie einen fünfstufigen Überprüfungszyklus:

1. Geltungsbereich bestätigen: Identifizieren Sie Cloud-Anwendungen, die regulierte, finanzielle, operative oder personenbezogene Daten verarbeiten.
2. Richtlinien Risiken zuordnen: Verknüpfen Sie jede Conditional-Access-Richtlinie mit mindestens einem Risikoszenario und einem Risikoverantwortlichen.
3. Ausschlüsse prüfen: Exportieren Sie ausgeschlossene Benutzer, Rollen, Apps, Gruppen, Standorte und Geräte. Jeder Ausschluss benötigt einen Verantwortlichen, eine Begründung, eine Genehmigung und ein Ablaufdatum.
4. Durchsetzung testen: Verwenden Sie Testkonten, um MFA, Gerätekonformität, Risikoblockierung, Blockierung von Legacy-Authentifizierung und Sitzungsbeschränkungen zu verifizieren.
5. Nachweise paketieren: Speichern Sie Exporte, Screenshots, Protokolle und Genehmigungen mit Metadaten.

Die KMU-Richtlinie zur Audit- und Compliance-Überwachung KMU-Richtlinie zur Audit- und Compliance-Überwachung ist entscheidend für die Integrität der Nachweise:

Metadaten, z. B. wer sie erhoben hat, wann und aus welchem System, müssen dokumentiert werden.

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

Screenshots ohne Quelle, Datum, erhebende Person und Systemkontext sind schwache Nachweise. Conditional-Access-Exporte, Anmeldeprotokolle und Überprüfungsberichte sollten als kontrollierte Audit-Aufzeichnungen behandelt werden.

Cross-Compliance-Zuordnung für Conditional-Access-Nachweise

Der Wert von Conditional Access liegt darin, dass ein Kontrollsatz bei sauberer Governance mehrere Audit-Perspektiven erfüllen kann.

Zenith Controls ordnet 5.15 Zugriffskontrolle außerdem GDPR Article 32, NIS2 Article 21(2)(i), DORA-Konzepten zur Zugriffsgovernance, NIST SP 800-53-Zugriffskontrollfamilien und COBIT 2019 DSS06.04 zu. Er ordnet 8.5 sichere Authentifizierung GDPR Articles 5, 24, 25 und 32, dem Management von Cybersicherheitsrisiken nach NIS2, dem Management von IKT-Risiken nach DORA, Identifikation und Authentifizierung nach NIST sowie COBIT-Identitäts- und logischem Zugriff zu.

Die Lehre ist einfach. Frameworks verwenden unterschiedliche Begriffe, erwarten aber dasselbe Sicherungsmuster: die richtigen Benutzer, aus akzeptablen Kontexten, mit starker Authentifizierung, über gesteuerte Sitzungen und mit Protokollen, die belegen, was geschehen ist.

Wie Auditoren Conditional Access prüfen werden

Ein ISO/IEC 27001:2022-Auditor beginnt beim ISMS. Er wird fragen, ob Conditional Access im Geltungsbereich liegt, welche Risiken behandelt werden, wie Conditional Access in der SoA erscheint, wie Richtlinien genehmigt werden, wie Änderungen gesteuert werden und ob Nachweise die operative Wirksamkeit belegen. Rechnen Sie mit Stichproben zu privilegierten Benutzern, schutzbedürftigen Anwendungen, Ausschlüssen und aktuellen Richtlinienänderungen.

Ein DORA- oder NIS2-Auditor wird operative Resilienz, Managementverantwortung und Risiko in den Mittelpunkt stellen. Er kann fragen, wie Zugriffskontrollen kritische oder wichtige Funktionen schützen, wie das Leitungsorgan Identitätsrisiken überwacht, wie Anmeldungen mit hohem Risiko triagiert werden und ob Zugriffsausfälle in Vorfallklassifizierung oder Meldeentscheidungen einfließen.

Ein GDPR-orientierter Auditor wird auf personenbezogene Daten fokussieren. Er kann fragen, wie HR-, Finanz- oder Kundendaten vor nicht verwalteten Geräten geschützt werden, wie Sitzungskontrollen unbefugtes Anzeigen reduzieren, wie der Zugriff auf autorisierte Benutzer begrenzt wird und wie Protokolle die Bewertung von Datenschutzverletzungen unterstützen.

Ein COBIT 2019-Prüfer wird nach Governance-Praktiken, Verantwortlichkeit, Kennzahlen, Wiederholbarkeit, Leistungsüberwachung und Verbesserung suchen. Ein NIST-orientierter Prüfer wird Ergebnisse zu Identität, Authentifizierung, Autorisierung, Überwachung und Reaktion mit technischen Nachweisen abgleichen.

Die Enterprise-Richtlinie zur Zugriffskontrolle Richtlinie zur Zugriffskontrolle setzt den Maßstab für privilegierten Zugriff:

Administrativer Zugriff muss strikt kontrolliert werden durch:

Aus dem Abschnitt „Governance-Anforderungen“, Richtlinienklausel 5.4.1.

Ihre Microsoft Entra-Nachweise müssen diesen Satz operativ vervollständigen. Welche Rollen sind privilegiert? Welche erfordern phishingresistente oder starke MFA? Welche sind über Privileged Identity Management berechtigt? Welche Konten sind Break-Glass-Konten? Welche sind von Richtlinien ausgeschlossen? Wer überprüft sie? Wohin werden Warnmeldungen gesendet?

Kennzahlen für das Leitungsorgan zur Conditional-Access-Governance

Da NIS2 und DORA die Verantwortung des Managements betonen, sollte die Conditional-Access-Berichterstattung für das Leitungsorgan verständlich sein. Berichten Sie nicht nur Richtliniennamen. Berichten Sie Risikoprofil und Kontrollleistung.

Nützliche Kennzahlen sind:

• Anteil privilegierter Konten, die durch starke MFA geschützt sind.
• Anzahl der Conditional-Access-Ausschlüsse nach Risikostufe.
• Anzahl blockierter, angeforderter oder zugelassener Anmeldungen mit hohem Risiko.
• Anteil der Zugriffe auf schutzbedürftige Anwendungen, die konforme Geräte erfordern.
• Anzahl der Sitzungen von nicht verwalteten Geräten zu regulierten Anwendungen.
• Zeit bis zur Triage von Anmeldeereignissen mit hohem Risiko.
• Anzahl der Änderungen an Conditional-Access-Richtlinien im Quartal.
• Anzahl abgelaufener, erneuerter und überfälliger Ausnahmen.
• Abdeckung der Protokollierung von Authentifizierung, Sitzungen und Richtlinienänderungen.
• Fehlgeschlagene Testfälle aus der vierteljährlichen Conditional-Access-Validierung.

Diese Kennzahlen machen aus Identitätskonfiguration Nachweise für Aufsicht. Sie helfen den Leitungsorganen außerdem, Genehmigung, Überprüfung, Ressourcenzuweisung und kontinuierliche Verbesserung nachzuweisen.

Häufige Feststellungen vor dem Audit beseitigen

Conditional-Access-Feststellungen entstehen meist durch Governance-Schwächen, nicht durch technisches Versagen. Zu den häufigsten Problemen gehören:

• Break-Glass-Konten sind ausgeschlossen, werden aber nicht überwacht.
• Richtlinien sind uneinheitlich benannt und haben keine Verantwortlichen.
• Schutzbedürftige Anwendungen fehlen in Regeln zur Gerätekonformität.
• Gastbenutzer und externe Mitwirkende umgehen Standardkontrollen.
• Servicekonten und Workload-Identitäten werden nicht gesondert gesteuert.
• Erkennungen von Anmelderisiken werden nicht triagiert oder mit Vorfällen verknüpft.
• Sitzungskontrollen werden nie von nicht verwalteten Geräten aus getestet.
• Richtlinienänderungen erfolgen direkt in der Produktion ohne Änderungsnachweise.
• Ausschlüsse sind dauerhaft, nicht dokumentiert oder nur mündlich genehmigt.
• Protokolle werden aufbewahrt, aber nicht überprüft.
• Nachweisen fehlen Metadaten, Quellkontext oder Übertragungskette.

Ein für 2026 geeigneter Zielzustand umfasst vom Leitungsorgan genehmigte Zugriffsgovernance, risikobasiertes Conditional-Access-Design, explizite Zuordnung zu ISO/IEC 27001:2022 und ISO/IEC 27002:2022, dokumentierte Unterstützung von NIS2, DORA und GDPR, starke MFA nach Rolle und Risiko, Gerätekonformität für schutzbedürftige Zugriffe, Sitzungsbeschränkungen für nicht verwaltete Kontexte, überwachte Authentifizierungs- und Richtlinienänderungen, einen Ausnahmenlebenszyklus, vierteljährliche Tests und Managementberichterstattung.

Microsoft Entra in auditbereite Nachweise überführen

Ihre Conditional-Access-Richtlinien treffen bereits jede Minute Sicherheitsentscheidungen. Die Frage ist, ob diese Entscheidungen gesteuert, risikobasiert, überwacht und den Verpflichtungen zugeordnet sind, die für Ihre Auditoren und Aufsichtsbehörden relevant sind.

Beginnen Sie mit Zenith Blueprint Zenith Blueprint, insbesondere Schritt 13, um Conditional-Access-Richtlinien mit Risiken, Behandlungen, der Erklärung zur Anwendbarkeit und regulatorischen Anmerkungen zu verbinden. Verwenden Sie Zenith Controls Zenith Controls, um Zugriffskontrolle, sichere Authentifizierung, Gerätezustand, Protokollierung und Überwachung über ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST und COBIT 2019 hinweg zuzuordnen.

Richten Sie anschließend Ihre internen Anforderungen an den Clarysec-Richtlinien aus, einschließlich KMU-Richtlinie zur Nutzung von Cloud-Diensten, KMU-Netzwerksicherheitsrichtlinie, KMU-Richtlinie zur Protokollierung und Überwachung, KMU-Richtlinie zur Audit- und Compliance-Überwachung, KMU-Richtlinie zu Anforderungen an die Anwendungssicherheit, Richtlinie zur Nutzung von Cloud-Diensten, Richtlinie zur Verwaltung von Benutzerkonten und Berechtigungen, Richtlinie für Remote-Arbeit, Richtlinie zur Zugriffskontrolle und Richtlinie zur Protokollierung und Überwachung.

Clarysec unterstützt Sie dabei, Microsoft Entra Conditional Access von einer Sammlung von Einstellungen in ein durchsetzbares, messbares und auditbereites Kontrollsystem zu überführen. Laden Sie die relevanten Clarysec-Toolkits herunter, fordern Sie eine Überprüfung der Richtlinienzuordnung an oder buchen Sie ein Assessment, um zu prüfen, ob Ihre Conditional-Access-Nachweise einer Prüfung nach ISO 27001, NIS2, DORA und GDPR standhalten.