Entra ID: Identitäten mit Conditional Access Policies schützen

Servus, liebe Admins und Heimlabor-Enthusiasten!

Heute tauchen wir in ein Thema ein, das mir persönlich sehr am Herzen liegt und in meiner täglichen Arbeit immer wichtiger wird: Der Schutz unserer Identitäten in der Cloud. Speziell geht es um Conditional Access Policies in Entra ID (wie Azure AD jetzt heißt). Wer von euch wie ich schon länger im Geschäft ist, weiß: Die Perimeter-Sicherheit, also das reine Absichern des Netzwerkrandes, ist ein Relikt vergangener Tage. Unsere Daten, unsere Anwendungen, unsere Nutzer – alles ist verteilt. Das Stichwort lautet Zero Trust, und Entra ID mit seinen Conditional Access Policies ist ein absoluter Game Changer, um dieses Konzept umzusetzen. Ich hab in den letzten Jahren unzählige Stunden damit verbracht, diese Policies zu planen, zu implementieren und zu optimieren, sowohl im Unternehmensumfeld als auch für meine eigenen Home-Lab-Szenarien. Meine Erfahrungen teile ich heute mit dir.

Egal, ob du eine kleine Firma absichern willst oder einfach nur dein eigenes Microsoft 365 Tenant im Home Lab auf Vordermann bringst – die Prinzipien sind die gleichen. Lass uns gemeinsam anschauen, wie du deine Identitäten effektiv vor unberechtigtem Zugriff schützt.

Was sind Conditional Access Policies in Entra ID?

Stell dir Conditional Access Policies (CAPs) als intelligente Wächter vor, die an jeder Tür zu deinen Cloud-Ressourcen stehen. Sie entscheiden dynamisch, ob ein Zugriff erlaubt, verweigert oder mit zusätzlichen Anforderungen versehen wird. Das Ganze basiert auf dem einfachen "If-Then"-Prinzip:

• IF (Bedingungen erfüllt sind) – zum Beispiel: Ein Nutzer versucht, sich von einem unbekannten Standort anzumelden und ist kein Administrator.
• THEN (führe diese Aktion aus) – zum Beispiel: Erzwinge Multi-Faktor-Authentifizierung (MFA) oder blockiere den Zugriff komplett.

Die "Signale", die diese Wächter auswerten, sind vielfältig und mächtig:

• Wer? (Benutzer oder Gruppen)
• Was? (Welche Cloud-App oder Aktion wird versucht?)
• Woher? (Standort – IP-Adresse, Länder)
• Womit? (Geräteplattform, Gerätezustand – ist das Gerät konform?)
• Wie? (Client-App – Browser, mobile App, Legacy-Authentifizierung)
• Wie riskant? (Anmelderisiko, Benutzerrisiko – basierend auf Entra ID Identity Protection)

In meiner Erfahrung ist die Flexibilität dieser Policies unschlagbar. Du kannst extrem granulare Regeln erstellen, die genau auf deine Bedürfnisse zugeschnitten sind.

Voraussetzungen für den Start

Bevor wir loslegen, hier ein paar Dinge, die du bereithalten solltest:

• Entra ID P1 oder P2 Lizenz: Conditional Access ist keine kostenlose Funktion. Du benötigst mindestens eine Azure AD Premium P1-Lizenz (jetzt Entra ID P1) für die Nutzer, die von den Policies betroffen sein sollen. Für fortgeschrittene Funktionen wie risikobasierte Policies benötigst du P2. Im Home Lab ist das oft der Knackpunkt, aber für produktive Umgebungen ist es eine Investition, die sich mehr als auszahlt.
• Administrator-Zugriff: Du brauchst mindestens die Rolle "Conditional Access Administrator" oder "Global Administrator" in deinem Entra ID Tenant.
• Grundlegendes Verständnis: Ein bisschen Ahnung von Identitätsmanagement, Netzwerkkonzepten (IP-Ranges!) und dem Entra ID Portal schadet nicht.
• Bereitschaft zur Planung: Nicht einfach drauflos konfigurieren! Eine gute Planung ist hier Gold wert.
• (Optional) Azure CLI oder PowerShell: Auch wenn die meisten Conditional Access Policies über das Portal konfiguriert werden, nutze ich oft die CLI oder PowerShell für begleitende Aufgaben, wie das Anlegen von Named Locations oder das Abfragen von Audit-Logs. Wer das im Home Lab automatisieren will, kommt um Skripte nicht herum.

Der Weg zum sicheren Zugriff: Schritt für Schritt mit Conditional Access

Lass uns das Ganze in die Praxis umsetzen. Ich zeige dir, wie ich typischerweise vorgehe.

1. Planung ist alles – Dein Sicherheitskonzept

Bevor du auch nur einen Klick im Portal machst, nimm dir einen Kaffee und einen Block Papier (oder OneNote, Notion, was auch immer du nutzt). Überlege dir:

• Welche Ressourcen sind kritisch? (z.B. Admin-Portale, Finanz-Apps, SharePoint mit sensiblen Daten)
• Wer sind deine Nutzergruppen? (Admins, normale Nutzer, externe Partner, Dienst-Accounts)
• Welche Zugriffe sollen unter welchen Bedingungen erlaubt sein? (z.B. Admins nur von konformen Geräten und vertrauenswürdigen Standorten; normale Nutzer immer MFA, egal woher)
• Welche Risiken möchtest du mindern? (z.B. Brute-Force-Angriffe, gestohlene Anmeldeinformationen, Zugriff von unsicheren Geräten)
• Gibt es Ausnahmen? (z.B. Break-Glass-Accounts, bestimmte Legacy-Anwendungen)

Mein Tipp: Fang klein an. Definiere ein oder zwei Kern-Policies und erweitere sie schrittweise.

2. Zugriff auf das Entra ID Portal

Das ist der einfache Teil. Öffne deinen Browser und navigiere zu entra.microsoft.com. Melde dich mit einem Administrator-Konto an. Im linken Navigationsbereich findest du unter "Protection" den Punkt "Conditional Access".

3. Erstellen der ersten Conditional Access Policy

Klicke auf "New policy". Jetzt beginnt die eigentliche Arbeit.

a) Benenne deine Policy

Gib deiner Policy einen aussagekräftigen Namen, damit du später weißt, was sie tut. Ich nutze gerne ein Präfix wie "CA-" und dann eine klare Beschreibung, z.B. "CA-Admins-MFA-von-ueberall".

b) Zuweisungen (Assignments)

• Users or workload identities:

  Hier wählst du aus, wer von dieser Policy betroffen sein soll. Ich rate dringend davon ab, hier "All users" zu wählen, es sei denn, du hast eine sehr spezifische Block-Policy und bist dir der Konsequenzen bewusst. Wähle lieber "Select users and groups" und dann spezifische Gruppen. Wichtig: Schließe immer mindestens ein Notfall- oder "Break-Glass"-Administratorkonto aus, das nicht von dieser Policy betroffen ist. Das ist deine Lebensversicherung, falls du dich versehentlich aussperrst!

• Cloud apps or actions:

  Welche Anwendungen sollen geschützt werden? "All cloud apps" ist wieder sehr weitreichend. Für kritische Anwendungen wie Azure Management, Microsoft 365 Exchange Online oder SharePoint wähle "Select apps".

c) Bedingungen (Conditions)

Hier definierst du die "If"-Teile deiner Regel. Dies sind die Signale, die der Wächter prüft.

• Device platforms:

  Sollen nur bestimmte Geräteplattformen (z.B. Windows, macOS) erlaubt sein? Oder alle?

• Locations:

  Der Klassiker. Hier kannst du festlegen, ob der Zugriff nur von "Trusted locations" erlaubt ist (z.B. deine Büro-IP-Adressen oder dein Home Lab VPN-Gateway) oder von "Any location". Du musst zuerst "Named locations" unter "Protection" -> "Conditional Access" -> "Named locations" definieren. Das sind IP-Ranges, die du als vertrauenswürdig einstufst. Mein Tipp: Denk daran, auch dein Home Lab als Named Location zu definieren, wenn du von dort aus adminstrierst!

• Client apps:

  Sollen auch "Other clients" (die oft für Legacy-Authentifizierung wie POP3, IMAP, alte Skype for Business-Clients stehen) zugelassen werden? Meine Empfehlung: Versuche, Legacy-Authentifizierung so weit wie möglich zu blockieren, da sie oft keine MFA unterstützt und ein großes Sicherheitsrisiko darstellt.

• Device state:

  Soll nur Zugriff von Geräten erlaubt sein, die "Hybrid Azure AD joined" oder "Azure AD joined" sind? Oder sogar "Require device to be marked as compliant" (was Intune oder Microsoft Endpoint Manager voraussetzt)?

• Sign-in risk (Requires Entra ID Identity Protection P2):

  Wenn du P2-Lizenzen hast, kannst du hier das Risiko einer Anmeldung bewerten lassen. Bei "High" oder "Medium" Risk kannst du dann z.B. MFA erzwingen oder den Zugriff blockieren.

d) Zugriffssteuerung (Access controls)

Dies ist der "Then"-Teil der Policy – die Aktion, die ausgeführt wird, wenn die Bedingungen erfüllt sind.

• Grant:
  • Block access: Harte Sperre.
  • Require multi-factor authentication: Erzwingt MFA. Mein absoluter Favorit für fast alle Policies.
  • Require device to be marked as compliant: Gerät muss als konform in Intune markiert sein.
  • Require Hybrid Azure AD joined device: Gerät muss Hybrid AD joined sein.

  Du kannst auch "Require one of the selected controls" oder "Require all of the selected controls" wählen.

• Session:

  Hier kannst du Feinheiten wie Anmeldehäufigkeit, Persistenz der Browser-Sitzung oder die Nutzung von Conditional Access App Control (CAAC) konfigurieren.

e) Policy aktivieren

Ganz unten findest du den Schalter "Enable policy".

• Report-only: Das ist dein bester Freund! Aktiviere Policies IMMER zuerst im "Report-only"-Modus. So siehst du in den Anmelde-Logs, welche Auswirkungen die Policy hätte, ohne dass sie tatsächlich greift. Du kannst so Fehler erkennen und beheben, bevor du jemanden aussperrst.
• On: Die Policy ist aktiv.
• Off: Die Policy ist deaktiviert.

Beispiel-Szenarien und Code-Blöcke

Lass uns ein paar klassische Szenarien durchgehen, wie ich sie oft im Home Lab oder bei Kunden umsetze. Auch wenn die Konfiguration hauptsächlich im Portal stattfindet, zeige ich dir, wie du mit der Azure CLI oder PowerShell unterstützende Tasks erledigen kannst oder Konzepte abbildest.

Szenario 1: MFA für Administratoren und kritische Apps von überall erzwingen

Das ist die absolute Baseline-Policy, die jeder haben sollte. Admins sind das Hauptziel von Angreifern. Egal, woher sie sich anmelden, MFA muss her.

• Assignments:
  • Users: "Select users and groups", wähle deine "Entra ID Admins"-Gruppe aus (und schließe dein Break-Glass-Konto aus!).
  • Cloud apps: "Select apps", wähle "Azure Management", "Microsoft 365 Exchange Online", "Microsoft 365 SharePoint Online" etc.
• Conditions:
  • Locations: "Any location".
  • Client apps: "All client apps".
• Access controls:
  • Grant: "Require multi-factor authentication".
• Enable policy: "Report-only", dann "On".

Um dir einen Überblick über deine bestehenden Conditional Access Policies zu verschaffen, kannst du die Azure CLI nutzen. Das ist zwar keine direkte Konfiguration, aber super zur Dokumentation oder für Audit-Zwecke.

# Sicherstellen, dass du angemeldet bist
az login

# Alle Conditional Access Policies auflisten (erfordert die Rolle 'Conditional Access Administrator')
az rest --method GET --url "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies" | jq .value[]

# Oder spezifischer nach dem Status filtern
az rest --method GET --url "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies?\$filter=state eq 'enabled'" | jq .value[]

Mein Tipp: `jq` ist dein Freund, um die JSON-Ausgaben lesbarer zu machen!

Szenario 2: Blockieren von Legacy Authentication

Legacy-Authentifizierungsprotokolle (wie POP3, IMAP, ältere Exchange ActiveSync-Versionen) unterstützen oft keine MFA und sind ein Einfallstor für Angreifer. Ich blockiere sie, wo immer es geht.

• Assignments:
  • Users: "All users" (oder spezifische Gruppen, die keine Legacy Auth benötigen).
  • Cloud apps: "All cloud apps" (oder spezifisch z.B. "Microsoft 365 Exchange Online").
• Conditions:
  • Client apps: "Configure Yes", wähle "Other clients".
• Access controls:
  • Grant: "Block access".
• Enable policy: "Report-only", dann "On".

Oft ist es hilfreich zu wissen, ob überhaupt noch Legacy Auth genutzt wird, bevor man es blockiert. Hier ein konzeptionelles PowerShell-Beispiel, das dir helfen könnte, die Nutzung zu analysieren. Dies ist kein direkter CA-Befehl, sondern ein Pre-Check.

# Installiere das MSOnline Modul, falls noch nicht geschehen
# Install-Module MSOnline

# Verbinde dich mit MSOnline
# Connect-MsolService

# Suche nach Benutzern, die noch Legacy Auth nutzen (dies ist eine vereinfachte, konzeptionelle Abfrage)
# Get-MsolUser -All | Where-Object {$_.StrongAuthenticationRequirements.Count -eq 0} | Select-Object UserPrincipalName,DisplayName
#
# Für detailliertere Infos müsstest du die Azure AD Sign-in Logs analysieren und nach "Client app" filtern, der "Other clients" anzeigt.
# Dies kann auch über die Graph API erfolgen. Hier ein CLI-Beispiel, um Anmeldeereignisse zu filtern:

az monitor activity-log list --query "[?contains(operationName.value, 'Sign-in') && contains(properties.clientAppUsed, 'Other clients')].{Time:eventTimestamp, User:claims.upn, IpAddress:callerIpAddress, Status:status.value}" --output table

Wichtig zu wissen: Die direkte Analyse von Legacy Auth im großen Stil erfordert oft das Durchforsten der Entra ID Sign-in Logs, die sehr detailliert sind und auch via Graph API abgefragt werden können.

Szenario 3: Zugriff nur von vertrauenswürdigen Standorten (IP-Ranges)

Ein Klassiker im Unternehmensumfeld: Zugriff auf bestimmte Apps nur aus dem Büro oder via VPN. Im Home Lab könnte das bedeuten: Zugriff auf dein privates Azure-Abonnement nur, wenn du in deinem Heimnetzwerk bist oder dein VPN nutzt.

• Assignments:
  • Users: "All users" (oder spezifische Gruppen).
  • Cloud apps: "Select apps", z.B. "Azure Management".
• Conditions:
  • Locations: "Configure Yes", "Include: Any location", "Exclude: All trusted locations" (oder nur "Selected locations" und deine spezifische Named Location).
• Access controls:
  • Grant: "Block access".
• Enable policy: "Report-only", dann "On".

Das Erstellen und Verwalten von Named Locations ist ein wichtiger Schritt. Auch wenn du es im Portal machst, hier ein Beispiel, wie eine Definition für eine "vertrauenswürdige IP-Range" aussehen könnte – sei es in einer Firewall-Konfig oder im Kontext der Azure CLI, um eine Named Location zu erstellen.

# Beispiel einer Named Location Definition (Konzeptionell, für Azure CLI/Graph API)
# Dies würde man normalerweise über das Entra ID Portal konfigurieren,
# aber für Automatisierungszwecke könnte es so über die Graph API erstellt werden.

# Erstellen einer Named Location über Azure CLI (Graph API Call)
# IP-Ranges müssen im CIDR-Format sein.

# Beispiel: Erstelle eine Named Location "MyHomeLabIPRange"
# Ersetze die IP-Adresse und den Namen entsprechend
az rest --method POST \
  --uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations" \
  --body '{
    "displayName": "MyHomeLabIPRange",
    "isTrusted": true,
    "@odata.type": "#microsoft.graph.ipNamedLocation",
    "ipRanges": [
      {
        "cidrAddress": "192.168.1.0/24"
      },
      {
        "cidrAddress": "203.0.113.42/32"
      }
    ]
  }'

Hinweis: Die CIDR-Adresse `192.168.1.0/24` wäre eine private IP-Range. Für öffentliche Named Locations musst du natürlich deine öffentliche IP-Adresse oder die deines VPN-Gateways verwenden.

Szenario 4: Gerätekonformität erzwingen

Für Unternehmen ist das ein Muss: Nur Geräte, die den Sicherheitsrichtlinien entsprechen (z.B. verschlüsselte Festplatte, aktuelle Updates, Antivirus installiert), dürfen auf sensible Daten zugreifen. Dies erfordert in der Regel die Integration mit Microsoft Intune (Teil von Microsoft Endpoint Manager).

• Assignments:
  • Users: "All users" (oder spezifische Gruppen).
  • Cloud apps: "Select apps", z.B. "Microsoft 365 SharePoint Online".
• Conditions:
  • Device platforms: "All device platforms" (oder spezifische).
• Access controls:
  • Grant: "Require device to be marked as compliant".
• Enable policy: "Report-only", dann "On".

Auch wenn die Konformität primär in Intune definiert und überwacht wird, kann man sich im Home Lab vorstellen, wie ein Skript auf einem Client prüfen könnte, ob grundlegende Sicherheitsstandards erfüllt sind. Dies ist ein Konzept, das die Idee der Gerätekonformität verdeutlicht, nicht direkt eine Entra ID CAP Konfiguration.

#!/bin/bash
# Konzeptionelles Skript zur Überprüfung einfacher Gerätesicherheitsmerkmale
# NICHT für produktive Entra ID/Intune-Integration gedacht, sondern zur Veranschaulichung

echo "Starte Gerätesicherheits-Check..."

# Prüfe, ob Firewall aktiv ist (Linux-Beispiel)
if systemctl is-active --quiet ufw; then
    echo "[OK] Firewall (UFW) ist aktiv."
else
    echo "[FEHLER] Firewall (UFW) ist inaktiv."
    exit 1 # Gerät ist nicht "konform"
fi

# Prüfe, ob ein Antivirus-Prozess läuft (Konzept: z.B. ClamAV)
if pgrep -x "clamd" > /dev/null; then
    echo "[OK] Antivirus (ClamAV) läuft."
else
    echo "[WARNUNG] Antivirus (ClamAV) läuft nicht."
    # Könnte hier trotzdem als "konform" durchgehen, je nach Richtlinie
fi

# Prüfe, ob das Dateisystem verschlüsselt ist (sehr vereinfachtes Beispiel)
if mount | grep -q 'type ext4.*encrypted'; then
    echo "[OK] Dateisystem ist (teilweise) verschlüsselt."
else
    echo "[WARNUNG] Dateisystem möglicherweise nicht verschlüsselt."
fi

echo "Geräte-Check abgeschlossen. Status: Konform."
exit 0

Dieses Skript ist ein stark vereinfachtes Beispiel, um die *Idee* der Gerätekonformität zu verdeutlichen. In der realen Welt übernimmt Intune diese Checks und meldet den Status an Entra ID.

Häufige Fehler und Lösungen

In meiner Laufbahn bin ich über so ziemlich jeden Stolperstein gestolpert, den Conditional Access zu bieten hat. Hier sind die Top 3, die du unbedingt vermeiden solltest:

1. Der Klassiker: Sich selbst aussperren

Problem: Du erstellst eine Policy, die "All users" betrifft und "Block access" erteilt, oder eine, die MFA erzwingt, aber dein Admin-Konto hat noch kein MFA eingerichtet. Plötzlich kommst du nicht mehr ins Entra ID Portal, weil du die Policy aktiviert hast, die dich blockiert.

Lösung: Immer, wirklich IMMER eine Gruppe von "Break-Glass"-Administratorkonten (am besten Cloud-Only-Konten, die nie synchronisiert werden und keine Lizenzen zugewiesen bekommen) von allen Conditional Access Policies ausschließen. Diese Konten sollten extrem sicher aufbewahrt werden (z.B. in einem physischen Safe) und nur im Notfall verwendet werden. Außerdem: Starte JEDE neue Policy im "Report-only"-Modus und analysiere die Anmelde-Logs.

2. Zu restriktive Policies am Anfang

Problem: Du willst es perfekt machen und erstellst gleich mehrere sehr restriktive Policies. Das führt oft dazu, dass legitime Workflows blockiert werden, Nutzer frustriert sind und der Helpdesk überlastet wird.

Lösung: Gehe inkrementell vor. Implementiere zuerst die wichtigsten Policies (z.B. MFA für Admins). Nutze den "Report-only"-Modus intensiv. Sammle Feedback von den Nutzern und analysiere die Anmelde-Logs, um die Auswirkungen zu verstehen, bevor du eine Policy scharf schaltest. Iteriere und optimiere. Lieber fünf gut funktionierende Policies als zwanzig, die ständig Probleme verursachen.

3. Übersehen von Legacy-Authentifizierung

Problem: Du blockierst Legacy-Authentifizierung, aber ein Teil deiner Nutzer oder Anwendungen (z.B. alte Drucker, die per SMTP E-Mails senden, oder ältere mobile Clients) nutzt diese noch. Plötzlich funktioniert etwas nicht mehr, und du musst auf Fehlersuche gehen.

Lösung: Bevor du Legacy-Authentifizierung blockierst, analysiere die Anmelde-Logs, um zu sehen, welche Nutzer oder Apps diese noch verwenden. Informiere die betroffenen Nutzer im Voraus und biete Alternativen an (z.B. aktualisierte Clients, App-Passwörter für bestimmte Szenarien – wobei App-Passwörter selbst ein Kompromiss sind und vermieden werden sollten). Setze eine separate Policy auf, die nur Legacy-Authentifizierung blockiert, und aktiviere sie schrittweise oder für spezifische Gruppen.

Mein Tipp für den Heimlabor-Enthusiasten

Als jemand, der sein Home Lab liebt: Nutze Conditional Access auch hier! Auch wenn du vielleicht kein ganzes Unternehmen absichern musst, die Prinzipien sind die gleichen.