Conditional Access Richtlinien Beispiele für Entra ID

Definition

Conditional Access (Conditional Access Policies) ist eine Richtlinienlogik in Microsoft Entra ID, die Zugriffe auf Cloud-Apps anhand von Bedingungen und Signalen steuert und daraus Zugriffskontrollen ableitet. Es ist kein einzelnes Feature wie „MFA an“, sondern ein Regelwerk zur Entscheidung „zulassen, erzwingen, blockieren“ pro Zugriff.

Conditional Access ist nicht der Betrieb von Endpoints oder Netzwerken und ersetzt weder Helpdesk noch Microsoft Intune-Management oder eine vollständige Security-Architektur.

Einleitung

conditional access richtlinien beispiele sind vor allem dann hilfreich, wenn MFA zwar existiert, aber Angreifer trotzdem über schwache Ausnahmen, Admin-Konten oder unbeaufsichtigte Loginversuche durchkommen. Mit ein paar sauberen Policies bekommst du Zugriff klar geregelt, Risiken sinken und dein internes Team spart Zeit bei Störungen und Ausnahmefällen.

Inhaltsverzeichnis

• Welche Signale und Kontrollen du brauchst
• Leitfaden: Richtlinien Schritt für Schritt bauen
• Empfohlene Richtlinien (Beispiele)
• Evaluierung: Report-only, What If, Sign-in Logs
• Lizenzen, Berechtigungen, Fallstricke

Welche Signale und Zugriffskontrollen wirklich zählen

Gute Access Policies nutzen wenige, aber aussagekräftige Bedingungen: Benutzergruppe (inkl. Admins), Ziel-App, Gerätestatus und Risikosignale. Der Nutzen ist direkt: Du blockierst nicht „alle“, sondern nur die riskanten Zugriffe, was Support-Tickets reduziert und trotzdem Sicherheit erhöht.

Typische Zugriffskontrollen in Conditional Access sind: MFA erzwingen, phishing-resistente MFA verlangen, nur compliant devices zulassen oder Zugriff komplett blockieren. Wichtig: Bedingungen und Kontrollen sind nicht „alleinige Sicherheitsmaßnahme“, sondern müssen zusammenpassen (Identität, Gerät, Risiko).

Leitfaden: Richtlinien Schritt für Schritt aufsetzen

Ein pragmatischer Ablauf verhindert Überraschungen im Betrieb und macht die Wirkung messbar.

• Scope festlegen: zuerst Pilotgruppen, dann breiter Rollout.
• Ziel-Apps definieren: z. B. Microsoft 365, Admin-Portale, sensible SaaS.
• Bedingungen wählen: Standort, Gerät, Client-App, Risiko, Plattformfilter.

Dann die Kontrolle festlegen (z. B. MFA) und die Policy zunächst in Report-only betreiben. Erst wenn klar ist, welche Konten betroffen sind, wird produktiv geschaltet. So sparst du Zeit, weil du nicht im Notfall nachträglich Ausnahmen bauen musst.

Conditional Access Richtlinien Beispiele (empfohlenes Start-Set)

Beispiel 1: MFA für alle Benutzer auf alle Cloud-Apps

Ziel: Basisschutz gegen Phishing. Kontrolle: Multi-Factor Authentication (MFA) erzwingen. Nutzen: Angreifer scheitern häufiger, ohne dass du jede App einzeln härten musst.

Beispiel 2: Admin-Zugriffe nur mit phishing-resistenter MFA und strikterem Kontext

Ziel: Admins sind das Hauptziel. Kontrolle: phishing-resistente MFA (z. B. passkey/FIDO2 oder Windows Hello for Business) verlangen und riskante Anmeldearten einschränken. Nutzen: Weniger „Admin übernommen“-Vorfälle und weniger Cleanup-Aufwand.

Beispiel 3: Block für Legacy Authentication und riskante Clients

Ziel: Schutz vor Umgehungen. Kontrolle: Legacy Auth blockieren und Client-Apps klar definieren. Nutzen: Weniger unerklärliche Sonderfälle in den Logs und weniger Angriffsfläche.

Beispiel 4: Zugriff nur mit compliantem Gerät für sensible Apps

Ziel: Datenabfluss reduzieren. Bedingung: Gerät muss compliant sein (typisch mit Microsoft Intune). Nutzen: Unverwaltete Geräte werden ausgesperrt, ohne alle Nutzer global zu stören.

Beispiel 5: Risiko-basierte Policies (Benutzerrisiko/Anmelderisiko)

Ziel: dynamisch reagieren. Bedingung: Benutzerrisiko oder Anmelderisiko hoch. Kontrolle: Zugriff blockieren oder Step-up MFA erzwingen. Nutzen: Weniger manuelle Bewertung von auffälligen Loginversuchen.

Praxis: Richtlinien testen und sauber evaluieren

Die wichtigste Frage ist nicht „kann ich das konfigurieren“, sondern „wirkt die Policy wie gedacht“. Dafür gibt es drei Pflichtwerkzeuge: Report-only, What If (Conditional Access What If) und die Sign-in Logs.

• Report-only: zeigt Wirkung, ohne Zugriffe zu brechen.
• What If: simuliert einen Loginversuch (z. B. browser iPhone, Safari Browser, bestimmte Plattformfilter).
• Sign-in Logs: dort erscheint, welche Policy gegriffen hat und warum ein Zugriff erlaubt oder blockiert wurde.

Wenn im Log „loginversuch Safari“ unerwartet durchkommt, liegt es oft an falschem App-Scope, einer zu breiten Ausnahme oder einer nicht abgedeckten Client-App.

Lizenz- und Berechtigungsbedarf (damit du nicht ins Leere läufst)

Conditional Access erfordert typischerweise Entra ID P1. Für Risiko-Signale (Entra Identity Protection) und erweiterte Steuerung rund um privilegierte Konten (Privileged Identity Management, PIM) wird häufig Entra ID P2 benötigt. Plane das früh, sonst baust du Policies, die später nicht ausgerollt werden können.

Auf Rollenebene sollten nur wenige Admins Policies ändern dürfen. Zusätzlich brauchen Notfallaccounts (Emergency Access Accounts) eine klare, dokumentierte Behandlung, damit du im Notfall Zugriff behältst.

Häufige Fallstricke und wie du sie vermeidest

• Zu viele Ausnahmen: jede Ausnahme ist ein Einfallstor und erschwert interne Nachvollziehbarkeit.
• Notfallaccounts vergessen: ohne getestete Notfallkonten riskierst du Lockout im Incident.
• Policies ohne Messpunkt: ohne Logs-Review und Namensschema fehlt dir die Kontrolle im Betrieb.

Kurzer Reality-Check: Conditional Access ist kein „einmal einstellen“. Policies müssen gepflegt werden, weil Apps, Geräte, Benutzergruppen und Angriffswege sich ändern (z. B. Device Code Flow als Umgehungsversuch in bestimmten Szenarien).

Mini-Story aus der Praxis

Ein Unternehmen erzwingt MFA, wundert sich aber über wiederkehrende verdächtige Zugriffe. In den Sign-in Logs erscheint, dass Admin-Logins über eine Ausnahmegruppe nicht erfasst wurden. Nach Aufteilung in „User“, „Admins“ und separate Notfallaccounts plus Report-only-Test sinkt die Zahl kritischer Anmeldeereignisse und der interne Aufwand für Nacharbeiten deutlich.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn Policies nicht nur eingerichtet, sondern laufend überwacht, bewertet und angepasst werden müssen. Typische Trigger sind mehrere Mandanten/Apps, häufige Changes, oder wenn das interne Team Richtlinien „nebenbei“ betreibt und dadurch Risiko und Zeitaufwand steigen.

Gerade bei Admin-Policies, Risikosteuerung und Notfallkonzepten zählt saubere Dokumentation: Sie reduziert Betriebsrisiko, macht Entscheidungen auditierbar und spart im Incident wertvolle Stunden.