Perimeter-Sicherheit ist tot. Das Modell „alles hinter der Firewall ist sicher” funktioniert in einer Welt mit Remote Work, Cloud-Apps und BYOD nicht mehr. Zero Trust ist der Ersatz – und Microsofts Conditional Access ist das zentrale Werkzeug, um es in M365-Umgebungen umzusetzen.

Dieser Post zeigt, wie du Conditional Access strukturiert aufbaust: von der ersten Richtlinie bis zum lückenlosen Monitoring.

Was ist Conditional Access?

Conditional Access (CA) ist eine Policy-Engine in Microsoft Entra ID (ehemals Azure AD). Sie trifft Zugangsentscheidungen nach dem Prinzip:

Signal → Entscheidung → Durchsetzung

Jede Anmeldung wird anhand von Signalen bewertet:

Das Ergebnis: Zugriff gewähren, blockieren oder Bedingung erzwingen (z. B. MFA, Passwortänderung).

Voraussetzungen & Lizenzen

Conditional Access erfordert mindestens Entra ID P1 – in M365 Business Premium, E3 oder E5 enthalten. Risikobasierte Policies (Sign-in Risk, User Risk) brauchen Entra ID P2 bzw. M365 E5.

# Lizenzübersicht für alle User prüfen
Connect-MgGraph -Scopes "User.Read.All", "Directory.Read.All"

Get-MgUser -All -Property DisplayName, UserPrincipalName, AssignedLicenses |
    Select-Object DisplayName, UserPrincipalName,
        @{N="Lizenzen"; E={ $_.AssignedLicenses.Count }} |
    Where-Object { $_.Lizenzen -gt 0 }

Wichtig: Notfallkonten („Break Glass Accounts”) müssen immer von CA-Richtlinien ausgenommen sein. Sonst sperrst du dich im Fehlerfall selbst aus.

Die Basis-Richtlinien

Hier die sechs Policies, die ich in jeder Umgebung als Minimum konfiguriere – in der Reihenfolge, wie ich sie einführe:

CA001 – MFA für alle Benutzer

Die wichtigste Richtlinie überhaupt. Kein Benutzer sollte sich ohne zweiten Faktor anmelden können.

Einstellungen:

# Bestehende CA-Richtlinien auflesen
Get-MgIdentityConditionalAccessPolicy |
    Select-Object DisplayName, State, CreatedDateTime |
    Sort-Object CreatedDateTime

CA002 – Legacy-Authentifizierung blockieren

Legacy-Protokolle wie SMTP AUTH, IMAP, POP3 und ältere Exchange ActiveSync-Versionen unterstützen kein MFA. Angreifer nutzen das gezielt aus.

Einstellungen:

Dieser eine Policy-Block eliminiert einen der häufigsten Angriffsvektoren in M365-Umgebungen.

CA003 – Admin-MFA immer erzwingen

Privilegierte Rollen brauchen besondere Behandlung – unabhängig davon, ob sie von CA001 erfasst werden.

Einstellungen:

CA004 – Compliant Device für produktive Apps

Gerätecompliance über Intune ist der nächste Zero-Trust-Schritt: Nur verwaltete Geräte dürfen auf sensible Apps zugreifen.

Einstellungen:

Starte hier mit Report-Only (dazu weiter unten). Ein zu aggressiver Roll-out blockiert reale Nutzer.

CA005 – Hochrisiko-Anmeldungen blockieren (P2)

Entra ID Identity Protection bewertet jede Anmeldung auf Anomalien: unbekannte Standorte, Credential Leaks, Tor-Browser, etc.

Einstellungen:

CA006 – Named Locations filtern

Nicht jede Umgebung braucht globalen Zugriff. Wenn deine Nutzer ausschließlich aus Deutschland arbeiten, kannst du alle anderen Länder blockieren.

Einstellungen:

Named Locations konfigurieren

Named Locations sind IP-Bereiche oder Länderlisten, auf die du in Policies referenzieren kannst.

Im Portal: Entra Admin Center → Sicherheit → Conditional Access → Named Locations

# Named Locations per Graph API anlegen
$body = @{
    "@odata.type" = "#microsoft.graph.countryNamedLocation"
    displayName   = "Deutschland"
    countriesAndRegions = @("DE")
    includeUnknownCountriesAndRegions = $false
} | ConvertTo-Json

Invoke-MgGraphRequest -Method POST `
    -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/namedLocations" `
    -Body $body `
    -ContentType "application/json"

Report-Only Modus – immer zuerst

Bevor du eine neue Richtlinie aktivierst, schalte sie auf Report-Only. Die Policy wird ausgewertet, aber nicht durchgesetzt. Du siehst im Anmeldeprotokoll, welche Anmeldungen betroffen wären – ohne Produktionsauswirkungen.

Mindestens 3–5 Tage im Report-Only-Modus, bevor du auf enabled wechselst.

Anmeldeprotokolle auswerten:

Connect-MgGraph -Scopes "AuditLog.Read.All"

# Anmeldungen der letzten 24h mit CA-Auswertung
$since = (Get-Date).AddHours(-24).ToString("yyyy-MM-ddTHH:mm:ssZ")

Get-MgAuditLogSignIn -Filter "createdDateTime ge $since" -Top 100 |
    Select-Object UserDisplayName, AppDisplayName, CreatedDateTime,
        @{N="CA-Ergebnis"; E={
            $_.AppliedConditionalAccessPolicies |
            ForEach-Object { "$($_.DisplayName): $($_.Result)" }
        }}

Monitoring: Sign-in Logs richtig lesen

Das Entra-Anmeldeprotokoll zeigt für jede Anmeldung:

SpalteBedeutung
CA-RichtliniennameWelche Policy wurde angewendet?
Ergebnissuccess, failure, notApplied, reportOnlySuccess
MFA-ErgebnisOb MFA angefordert / abgeschlossen wurde
Gerätecompliancecompliant, notCompliant, unknown
Risikostufenone, low, medium, high

Für einen strukturierten Export:

$since = (Get-Date).AddDays(-7).ToString("yyyy-MM-ddTHH:mm:ssZ")

Get-MgAuditLogSignIn -Filter "createdDateTime ge $since" -Top 500 |
    Where-Object { $_.Status.ErrorCode -ne 0 } |
    Select-Object UserDisplayName, UserPrincipalName,
        AppDisplayName, CreatedDateTime,
        @{N="Fehlercode"; E={ $_.Status.ErrorCode }},
        @{N="Fehlertext"; E={ $_.Status.FailureReason }} |
    Export-Csv "C:\Reports\ca_failures_$(Get-Date -Format 'yyyyMMdd').csv" `
        -NoTypeInformation -Encoding UTF8

Häufige Fehler und wie du sie vermeidest

1. Break-Glass-Konto nicht ausgenommen Das passiert öfter als man denkt. Jedes Break-Glass-Konto muss in einer eigenen Gruppe sein, die von allen CA-Policies ausgenommen ist.

2. Alle Policies auf einmal aktiviert Roll-out Policy für Policy. Immer erst Report-Only, dann einzeln scharf schalten.

3. Service Accounts vergessen Service Accounts für automatisierte Prozesse (z. B. Sync, Monitoring) schlagen bei MFA-Policies fehl. Entweder ausschließen oder auf Managed Identities / Workload Identities umstellen – diese haben eigene CA-Policies.

4. Keine Notfall-Benachrichtigung Richte Entra ID Alerts ein, damit du sofort informiert wirst, wenn sich ein Break-Glass-Konto anmeldet. Das signalisiert, dass irgendetwas schiefgelaufen ist.

# Alert-Regel per Graph (vereinfacht)
# Empfehlung: Im Entra Portal unter Monitoring → Alerts konfigurieren

5. „Alle Cloud-Apps” vs. gezielte Apps „Alle Cloud-Apps” ist mächtig, kann aber Office-Add-ins oder Legacy-Integrationen brechen. Starte mit den kritischen Apps (Exchange, SharePoint, Teams) und erweitere dann.

Best Practices Checkliste

Bevor du eine CA-Konfiguration für produktiv erklärst:

Fazit

Conditional Access ist kein Einmal-Klick-Feature. Es ist eine Architektur. Wer es sauber aufbaut – mit Struktur, Report-Only-Tests und regelmäßigem Monitoring – hat eine der effektivsten Sicherheitsmaßnahmen, die M365 zu bieten hat.

Der häufigste Fehler ist, es entweder gar nicht einzusetzen oder mit einer einzigen übermächtigen Policy alles auf einmal zu blockieren. Der richtige Weg liegt dazwischen: schrittweise, dokumentiert, und immer mit einem Auge auf den Logs.

Einstieg heute:

# Ersten Überblick verschaffen – was läuft aktuell in deiner Umgebung?
Connect-MgGraph -Scopes "Policy.Read.All", "AuditLog.Read.All"
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State | Format-Table -AutoSize

Schau was dir zurückkommt. Dann weißt du, wo du anfangen musst.

Fragen oder eigene CA-Setups? Schreib mir: info@westmeier.cloud