Conditional Access Rezepte

Wie CA funktioniert Richtlinien-Rezepte Reihenfolge & Ausrollen

Wie Conditional Access funktioniert

Das „Wenn-Dann" der Zugriffssteuerung: Signale werden ausgewertet, Kontrollen erzwungen.

Signale → Bedingungen → Kontrollen

Conditional Access (CA) ist die Richtlinien-Engine von Entra ID (ab Lizenz P1). Bei jeder Anmeldung wertet sie Signale aus und entscheidet, ob und unter welchen Auflagen Zugriff gewährt wird. Aufbau jeder Richtlinie:

Zuweisungen (Wer/Was): Nutzer & Gruppen, Zielressourcen (Cloud-Apps), plus Bedingungen wie Standort, Gerätestatus, Client-App, Anmelderisiko.
Zugriffssteuerung (Dann): Blockieren oder Gewähren mit Auflagen — MFA verlangen, konformes Gerät fordern, App-Schutzrichtlinie, Passwortänderung.

Beispiel in einem Satz: „Wenn Nutzer aus Gruppe X von außerhalb des Firmennetzes auf Exchange Online zugreifen (Signal), dann MFA erzwingen (Kontrolle)."

Wichtig: mehrere Richtlinien wirken additiv

Alle passenden Richtlinien werden ausgewertet und kombiniert. Eine einzige „Blockieren"-Richtlinie sticht jede „Gewähren"-Richtlinie — Block gewinnt immer. Deshalb sind Ausschlüsse (Exclusions) so kritisch.

Report-only-Modus

Jede Richtlinie hat drei Zustände: Ein, Aus und Nur Bericht (Report-only). Im Report-only-Modus wird die Richtlinie ausgewertet und protokolliert, aber nicht durchgesetzt. In den Anmeldeprotokollen (Tab „Nur-Bericht") sieht man exakt, welche Anmeldungen betroffen wären — ohne jemanden auszusperren. Pflicht-Schritt vor jeder Aktivierung.

Fertige Richtlinien-Rezepte

Sechs bewährte Basis-Policies. Immer Report-only starten und Break-Glass ausnehmen.

1 · MFA für alle Nutzer erzwingen

Das Fundament jeder Absicherung — Multi-Faktor bei jedem Cloud-Zugriff.

Zweck: Kennwort allein reicht nicht mehr; kompromittierte Passwörter werden wertlos.
Nutzer: Alle Nutzer außer Break-Glass
Ziel: Alle Cloud-Apps
Bedingung: Alle Anmeldungen (optional: nur außerhalb vertrauenswürdiger Standorte)
Aktion: Zugriff gewähren → Multi-Faktor-Authentifizierung erforderlich

2 · Administratoren immer MFA

Privilegierte Rollen sind das lohnendste Angriffsziel — hier keine Ausnahmen bei Standort oder Gerät.

Zweck: Admin-Konten strikt absichern, unabhängig von Standort.
Nutzer: Verzeichnisrollen: Global Admin, Privileged Role Admin, User Admin, Exchange/Intune/SharePoint Admin, Helpdesk, Security Admin außer Break-Glass
Ziel: Alle Cloud-Apps
Bedingung: Alle Standorte, alle Geräte
Aktion: Zugriff gewähren → MFA erforderlich (ideal: phishing-resistente MFA erzwingen)

3 · Legacy-Authentifizierung blockieren

Alte Protokolle (POP, IMAP, SMTP AUTH, ältere Office-Clients) unterstützen keine moderne Authentifizierung und umgehen damit MFA komplett.

Zweck: Das größte MFA-Schlupfloch schließen.
Nutzer: Alle Nutzer außer Break-Glass
Ziel: Alle Cloud-Apps
Bedingung: Client-Apps: „Andere Clients" / Exchange ActiveSync-Clients (= Legacy)
Aktion: Zugriff blockieren

4 · Zugriff nur aus DE/EU (Länder-Sperre)

Wenn niemand aus dem Ausland arbeitet, lässt sich die Angriffsfläche drastisch verkleinern.

Zweck: Anmeldungen aus nicht benötigten Ländern von vornherein abweisen.
Vorbereitung: Benannten Standort anlegen: „Erlaubte Länder" = Deutschland (+ ggf. EU-Nachbarn)
Nutzer: Alle Nutzer außer Break-Glass
Bedingung: Standort: Beliebiger Standort, ausgeschlossen: „Erlaubte Länder"
Aktion: Zugriff blockieren (greift für alles, was NICHT aus den erlaubten Ländern kommt)

💡

GPS-basierte Standorte lassen sich per VPN umgehen — als harte Grenze, nicht als alleinigen Schutz betrachten. Reisende und Roaming-IPs vorher bedenken.

5 · Geräte-Compliance verlangen

Nur von Intune als konform bewerteten Geräten Zugriff geben — verknüpft CA mit dem Endpoint-Management.

Zweck: Zugriff nur von verwalteten, richtlinienkonformen Geräten (BitLocker, Firewall, aktuelles OS).
Voraussetzung: Intune mit Compliance-Richtlinien (siehe Intune-Referenz)
Nutzer: Alle Nutzer außer Break-Glass
Ziel: Office 365 / sensible Apps
Aktion: Zugriff gewähren → „Als konform markiertes Gerät erforderlich" (oder Entra-Hybrid-Join)

6 · Session-Limits für nicht verwaltete Geräte

Auf privaten/unverwalteten Geräten Zugriff erlauben, aber einschränken — kein „Angemeldet bleiben", kürzere Sitzung, ggf. nur Browser ohne Download.

Zweck: Produktivität auf BYOD ermöglichen, Datenabfluss begrenzen.
Nutzer: Alle Nutzer außer Break-Glass
Ziel: Exchange Online, SharePoint Online
Bedingung: Gerätestatus: nicht als konform/Hybrid markiert
Aktion: Sitzung → Anmeldehäufigkeit (z. B. 8 h) + persistente Browsersitzung: nie; für SharePoint/Exchange „App-erzwungene Einschränkungen" (nur Web, kein Download)

Reihenfolge & Ausrollen

Struktur schlägt Aktionismus — so kommt man ohne Aussperrung ans Ziel.

Empfohlene Schritt-für-Schritt-Reihenfolge

Break-Glass-Konten anlegen und aus jeder künftigen Richtlinie ausschließen.
Jede neue Richtlinie zuerst im Report-only-Modus aktivieren.
Ein bis zwei Wochen die Anmeldeprotokolle (Tab „Nur-Bericht") auswerten — wer wäre blockiert/zu MFA gezwungen worden?
Mit einer Pilotgruppe scharf schalten, Feedback einsammeln.
Schrittweise auf alle Nutzer ausrollen.
Reihenfolge der Inhalte: erst Legacy-Auth blockieren und Admin-MFA, dann MFA für alle, danach Geräte-/Standort-/Session-Policies.

Benennung & Dokumentation

Klare Namenskonvention hilft im Betrieb, z. B. CA01-Alle-MFA, CA02-Admins-MFA, CA03-Block-LegacyAuth. Jede Richtlinie mit Zweck, Ausschlüssen und Ausrolldatum dokumentieren.

⚠️

Wichtigste Regel: In jeder Richtlinie das Break-Glass-Konto (bzw. eine „CA-Ausnahme"-Gruppe mit den Notfallkonten) ausschließen. Sonst kann eine fehlerhafte Bedingung alle Administratoren gleichzeitig aussperren — inklusive Ihnen selbst. Zusätzlich: Vor dem Aktivieren immer in einem privaten Browserfenster gegentesten.