Zurück zum Blog

CA Deep Dive (2/3) — Die richtige Trainingsplan-Logik

Wie du eine CA-Policy-Landschaft aufbaust, die schützt ohne zu blockieren. Mit konkreten Beispiel-Policies.

EntraIDSecurity
CA Deep Dive (2/3) — Die richtige Trainingsplan-Logik

Ein guter Trainingsplan hat Struktur. Du machst nicht einfach “irgendwas” — du hast einen Plan, jede Übung hat ein Ziel, und alles baut aufeinander auf. Genau so sollte deine CA-Policy-Landschaft aussehen.

Was gute von schlechter CA-Architektur unterscheidet

Eine gute CA-Architektur ist:

  • Lesbar — jeder Admin versteht auf einen Blick, was eine Policy tut
  • Erweiterbar — neue Anforderungen lassen sich sauber integrieren
  • Eine Aufgabe pro Policy — nicht alles in eine Mammut-Policy packen

Die häufigsten Fehler

Ich sehe diese Fehler immer wieder:

  • Mammut-Policies — eine Policy, die alles abdecken soll und am Ende nichts richtig macht
  • Keine Break-Glass-Ausnahmen — und dann sperrt sich der Admin selbst aus
  • Kein Namenskonzept — “Policy 1”, “Test”, “Neu 2” — viel Spaß beim Troubleshooting
  • Kein Report-Only — Policies werden direkt scharfgeschaltet und legen den halben Tenant lahm
  • Fehlende Dokumentation — niemand weiß, warum eine Policy existiert

Drei Fragen vor jeder Policy

Bevor du eine Policy erstellst, beantworte diese drei Fragen:

  1. Wer braucht welchen Zugriff? — Zielgruppe klar definieren
  2. Was ist das Schutzziel? — Was genau soll verhindert oder erzwungen werden?
  3. Was ist die Ausnahme? — Wer oder was muss explizit ausgenommen werden (Break Glass, Service Accounts)?

Wenn du diese drei Fragen nicht beantworten kannst, ist die Policy nicht durchdacht.

Namensschema — Ordnung im Trainingsplan

Verwende ein konsistentes Namensschema. Meine Empfehlung:

  • CA001 — Block Legacy Authentication
  • CA002 — MFA for all users
  • CA003 — Phishing-resistant MFA for admins
  • usw.

Die Nummer gibt die Reihenfolge und Priorität vor. Der Name beschreibt die Funktion. Kein Rätselraten, kein “was macht diese Policy nochmal?”

Die 7 Basis-Policies für jeden Tenant

Hier sind die sieben Policies, die in jedem Tenant als Grundlage existieren sollten:

CA001: Block Legacy Authentication

  • Ziel: Alle Legacy-Protokolle blockieren (IMAP, POP3, SMTP Auth, etc.)
  • Zuordnung: Alle User
  • Cloud Apps: Alle
  • Bedingung: Client Apps → Legacy Authentication Clients
  • Zugriffskontrolle: Block
  • Ausnahme: Break Glass Accounts

Legacy Authentication unterstützt kein MFA. Das ist eine offene Tür — schließ sie.

CA002: MFA für alle User

  • Ziel: Jeder Login erfordert MFA
  • Zuordnung: Alle User
  • Cloud Apps: Alle
  • Zugriffskontrolle: Require Authentication Strength → Standard MFA
  • Ausnahme: Break Glass Accounts, ggf. Service Accounts mit Managed Identity

CA003: Phishing-resistente MFA für Admins

  • Ziel: Admins nutzen ausschließlich Phishing-resistente Methoden
  • Zuordnung: Administrative Rollen (Global Admin, Exchange Admin, Security Admin, etc.)
  • Cloud Apps: Alle
  • Zugriffskontrolle: Require Authentication Strength → Phishing-resistant MFA
  • Ausnahme: Break Glass Accounts

CA004: Compliant Device für sensible Ressourcen

  • Ziel: Zugriff auf sensible Apps nur von compliant Geräten
  • Zuordnung: Alle User
  • Cloud Apps: Exchange Online, SharePoint Online, Teams
  • Zugriffskontrolle: Require device to be marked as compliant
  • Ausnahme: Break Glass Accounts, ggf. bestimmte Gruppen in Übergangsphase

CA005: Risikobasierter Zugriff

  • Ziel: Bei erhöhtem Risiko zusätzliche Maßnahmen erzwingen
  • Zuordnung: Alle User
  • Cloud Apps: Alle
  • Bedingung: Sign-In Risk → Medium und High
  • Zugriffskontrolle: Require Authentication Strength → Phishing-resistant MFA
  • Zusätzlich: Bei User Risk High → Passwortänderung erzwingen
  • Ausnahme: Break Glass Accounts

CA006: Geografische Einschränkung

  • Ziel: Zugriff nur aus DACH-Region (Deutschland, Österreich, Schweiz)
  • Zuordnung: Alle User
  • Cloud Apps: Alle
  • Bedingung: Location → Alle Standorte außer Named Location “DACH”
  • Zugriffskontrolle: Block
  • Ausnahme: Break Glass Accounts, Reisende (temporäre Ausnahmegruppe)

CA007: Nicht unterstützte Geräteplattformen blockieren

  • Ziel: Zugriff nur von definierten Plattformen
  • Zuordnung: Alle User
  • Cloud Apps: Alle
  • Bedingung: Device Platform → Linux, Windows Phone, etc. (je nach Anforderung)
  • Zugriffskontrolle: Block
  • Ausnahme: Break Glass Accounts

Authentication Strengths

Conditional Access arbeitet mit Authentication Strengths — abgestuften Sicherheitslevel:

  • Standard MFA — Microsoft Authenticator Push, Telefon, SMS (Minimum für alle User)
  • Passwordless MFA — Microsoft Authenticator Passwordless, FIDO2 (kein Passwort mehr nötig)
  • Phishing-resistant MFA — ausschließlich FIDO2 oder Windows Hello for Business (höchstes Level, Pflicht für Admins)

Wähle die passende Stärke für jede Policy und Zielgruppe.

Policy-Auswertung verstehen

Wichtig zu wissen, wie Conditional Access Policies ausgewertet werden:

  • Block gewinnt immer — wenn eine Policy blockiert und eine andere erlaubt, wird blockiert
  • Alle Policies werden ausgewertet — nicht nur die erste passende
  • Ausnahmen müssen konsistent sein — wenn du Break Glass in einer Policy vergisst, sperrst du dich aus
  • Grant Controls werden kombiniert — “Require MFA” UND “Require compliant device” bedeutet: beides muss erfüllt sein

👉 Denk daran: Eine vergessene Ausnahme in einer einzigen Policy kann den gesamten Notfallzugang zerstören.

Gruß Micha