Vom Gatekeeper zum Watcher: Pre-Auth- und Post-Auth-Sicherheit verbinden

Von Mirko Peters · 2026-08-11

Willkommen zurück zum Podcast und zu unserem begleitenden technischen Deep Dive! Wenn Sie schon einmal den Eindruck hatten, dass Ihre Strategie für Identitätssicherheit direkt nach der Anmeldung eines Benutzers einen blinden Fleck hat…

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück zum Podcast und zu unserem begleitenden technischen Deep Dive! Wenn Sie schon einmal das Gefühl hatten, dass Ihre Strategie zur Identitätssicherheit direkt nach der erfolgreichen Anmeldung eines Benutzers einen blinden Fleck hat, sind Sie damit nicht allein. Jahrelang haben sich Organisationen stark auf Pre-Auth-Kontrollen verlassen, um Angreifer fernzuhalten, und die Eingangstür als letzte Verteidigungslinie behandelt. Doch was passiert, wenn ein Angreifer mit einem gültigen Token oder einem gestohlenen Satz an Anmeldeinformationen an dieser Tür vorbeikommt? Genau dieses Dilemma stand im Mittelpunkt unserer jüngsten Episode, Conditional Access with Defender for Identity Signals. In diesem Beitrag vertiefen wir diese Konzepte und zeigen, wie Sie Ihren Pre-Auth-Gatekeeper mit Ihrem Post-Auth-Watcher verbinden, um eine wirklich widerstandsfähige Identitätsarchitektur aufzubauen.

Das Wichtigste in Kürze (TL;DR)

Um moderne Identitätsabsicherung wirklich zu verstehen, sollten Sie Ihre Werkzeuge als spezialisierte Rollen betrachten, die in Echtzeit zusammenarbeiten:

• Conditional Access (CA) ist Ihr Türsteher. Er trifft Pre-Auth-Entscheidungen außergewöhnlich gut, und zwar auf Basis dessen, wer sich anmeldet, woher die Anmeldung kommt und wie es um den Zustand des Geräts steht.
• Defender for Identity (DfI) ist Ihre Videoüberwachung, kombiniert mit der Sicherheit vor Ort. Die Stärke liegt in der Überwachung des Post-Auth-Verhaltens, seitlicher Bewegungen und interner Auffälligkeiten.
• Echte Resilienz entsteht erst dann, wenn Post-Auth-Risiko die Pre-Auth-Hürden automatisch und dynamisch erhöht, und zwar genau dort, während der Sitzung.

Mentales Modell

Schauen wir uns genauer an, wie diese Komponenten in Ihrer Umgebung zusammenwirken:

• Gatekeeper (CA): Prüft, wer sich anmeldet, von wo aus, den Gerätezustand und das Anmelderisiko und erzwingt sofortige Sitzungskontrollen.
• Watcher (DfI + M365 Defender): Sucht nach seitlichen Bewegungen, ungewöhnlichen Zugriffsmustern auf Ressourcen, Kerberoasting, NTLM-Missbrauch und unerwarteten Rechteausweitungen.
• Feedback-Schleife: Der Watcher markiert verdächtiges Verhalten, was wiederum den Score für das Benutzerrisiko oder Sitzungsrisiko erhöht. Dadurch muss der Gatekeeper die Kontrollen sofort verschärfen, indem er eine stärkere MFA-Authentifizierung verlangt, den Zugriff vollständig blockiert oder die aktive Sitzung einschränkt.

Integrationsplan (was in welcher Reihenfolge zu aktivieren ist)

Damit diese Systeme miteinander kommunizieren, braucht es eine strukturierte Einführung. Dieser Plan gibt Ihnen die Schritte vor:

1. Risikobasiertes CA (Basis)
   • Entra ID Protection: Aktivieren Sie die Auswertung von Benutzerrisiko und Anmelderisiko.
   • CA-Richtlinien erstellen:
     • Blockieren, wenn das Benutzerrisiko = Hoch ist (oder eine Kennwortänderung verlangen, sofern Ihre Helpdesk-Prozesse das unterstützen).
     • MFA erforderlich, wenn das Anmelderisiko ≥ Mittel ist.
     • Konformes Gerät erforderlich für Apps mit mittlerer bis hoher Vertraulichkeit. Für nicht verwaltete Endgeräte nutzen Sie Geräte-Filter, um sie direkt in eingeschränkte Sitzungskontrollen zu leiten.
2. Den Watcher mit dem Gatekeeper sprechen lassen
   • Stellen Sie sicher, dass DfI Warnungen aktiv an Microsoft 365 Defender und Sentinel streamt (sofern Sie Sentinel als SIEM/SOAR nutzen).
   • Automatisieren Sie die Aktion "Als kompromittiert bestätigen" für Benutzer bei DfI-Warnungen mit hohem Schweregrad. Dadurch wird in Entra ID Protection das Benutzerrisiko = Hoch gesetzt, und Ihre CA-Richtlinien reagieren sofort.
   • Automatisierungspfad: M365-Defender-Vorfall → Logic App oder Power Automate → Graph Security/Identity Protection API (/riskDetections, /riskyUsers:confirmCompromised) → optional Abmeldung erzwingen.
   • Aktivieren Sie Continuous Access Evaluation (CAE) für alle unterstützten Apps (Exchange, SharePoint, Graph), damit Richtlinienänderungen auch laufende Tokens tatsächlich beenden.
3. Sitzungskontrolle zur Eindämmung
   • Für nicht verwaltete oder riskante Sitzungen setzen Sie Defender for Cloud Apps (Session-Proxy) direkt aus CA heraus ein:
     • CA → Conditional Access App Control verwenden (zuerst überwachen, dann Datenabfluss wie Downloads, Kopieren und Einfügen, Drucken und Synchronisieren blockieren).
   • Kombinieren Sie das mit MDE-Gerätrisiko → Intune-Compliance → CA „Require compliant device“ für alle sensiblen Anwendungen.
4. Schutzvorkehrungen für privilegierte Identitäten
   • PIM muss Just-in-Time-Zugriff erzwingen. Vor einer Erhöhung der Rechte verlangen Sie MFA + konformes Gerät + keinen riskanten Benutzerstatus.
   • Richten Sie eine CA-Richtlinie ein, die privilegierte Rollen blockiert, wenn das Benutzerrisiko mindestens Niedrig ist (ja, auch bei niedrigem Risiko). So erzwingen Sie eine sofortige Prüfung, bevor eine administrative Rolle übernommen werden kann.

„Wenn das, dann jenes“: DfI-Signale auf CA-Aktionen abbilden

Wenn Sie bestimmte Erkennungssignale von Defender for Identity auf automatisierte Aktionen für bedingten Zugriff und Reaktionsmaßnahmen abbilden, schließen Sie die Lücke zwischen passiver Beobachtung und aktiver Abwehr:

Betreiben Sie diese Regeln zunächst für 1 bis 2 Wochen im Modus Audit/Überwachung und stellen Sie die Reaktionen pro Warnungsklasse auf den Modus Erzwingen um, sobald Ihr Vertrauen wächst.

Beispielrichtlinien (praxisnah, minimal)

Um diese Strategien produktiv umzusetzen, sollten Sie vier grundlegende Richtlinien konfigurieren:

1. Blockieren, wenn das Benutzerrisiko = Hoch ist
   • Zuweisen: Alle Benutzer (Notfallzugriffskonten ausschließen), alle Cloud-Apps
   • Bedingungen: Benutzerrisiko = Hoch
   • Zugriffskontrolle: Zugriff blockieren
2. Step-up bei Anmelderisiko
   • Zuweisen: Alle Benutzer, Anwendungen mit hohem Wert (Admin-Portale, Exchange, SharePoint, Entra Admin Center)
   • Bedingungen: Anmelderisiko ≥ Mittel
   • Zugriffskontrolle: MFA + konformes Gerät (oder verwaltetes Gerät) erforderlich
3. Sitzung bei nicht verwalteten Geräten einschränken
   • Zuweisen: Alle Benutzer, SharePoint/OneDrive/Teams
   • Gerätestatus: Hybrid/konform = umgehen; nicht verwaltet = erzwingen
   • Sitzung: Conditional Access App Control verwenden (Downloads blockieren)
4. Schutz vor Rechteerhöhung für privilegierte Rollen
   • Zuweisen: Verzeichnisrollen = privilegierte Administratorrollen
   • Bedingungen: Benutzerrisiko ≥ Niedrig ODER Anmelderisiko ≥ Mittel
   • Zugriffskontrolle: MFA + konformes Gerät erforderlich; blockieren, wenn das Risiko ≥ Hoch ist

Automatisierungs-Playbooks (sofort einsetzbar)

Automatisierung ist das Geheimrezept, mit dem Sie Ihre mittlere Zeit bis zur Eindämmung (MTTC) senken. Hier sind zwei Playbooks, die Sie heute schon aufbauen können:

Playbook A: DfI-Warnung mit hohem Schweregrad → Identität eindämmen

• Auslöser: M365-Defender-Vorfall mit dem Tag IdentityThreatHigh
• Aktionen:
  1. Graph API – Kompromittierung des Benutzers bestätigen (setzt Benutzerrisiko auf Hoch)
  2. Entra ID – Aktualisierungstoken sofort widerrufen
  3. Intune/MDE – Gerät isolieren (falls ein einzelnes primäres Gerät zugeordnet ist)
  4. ServiceNow/JSM – Incident-Ticket mit Zeitleiste und gesammelten Artefakten erstellen
  5. SOC und Benutzerverantwortliche per adaptiver Teams-Karte benachrichtigen, mit einer Ein-Klick-Schaltfläche zum Zurücksetzen bei Fehlalarmen

Playbook B: Anomaler Zugriffsstoß auf SharePoint

• Auslöser: Defender-Warnung „Ungewöhnlicher Dateidownload“
• Aktionen:
  1. Benutzer mit UnderInvestigation über AAD-Erweiterungsattribute kennzeichnen
  2. Benutzer in eine CA-Richtlinie überführen, die sie zu App Control leitet (Downloads und Drucken blockieren)
  3. eDiscovery-Sperre für betroffene SharePoint-Websites einrichten (optional, abhängig von den Compliance-Anforderungen)
  4. Eindämmung nach 72 Stunden automatisch ablaufen lassen, sofern das SOC sie nicht manuell verlängert

Hunting & nützliche Abfragen

Proaktives Hunting hilft Ihnen, Lücken zu erkennen, bevor Angreifer sie ausnutzen. Verwenden Sie diese Abfragen im erweiterten Hunting von M365 Defender:

Anstieg der SharePoint-Websitezugriffe eines Benutzers im Vergleich zu seiner 30-Tage-Basislinie:

let lookback=30d;
let recent=1h;
let baseline = CloudAppEvents
    | where Timestamp between (ago(lookback) .. ago(recent))
    | where Application == "SharePoint" and ActionType == "FileAccessed"
    | summarize uniqSites=dcount(SiteUrl) by AccountUpn;
CloudAppEvents
| where Timestamp >= ago(recent)
| where Application == "SharePoint" and ActionType in ("FileDownloaded","FileAccessed")
| summarize curSites=dcount(SiteUrl), dls=sumif(1, ActionType=="FileDownloaded") by AccountUpn
| join kind=leftouter baseline on AccountUpn
| where curSites > 3 * coalesce(uniqSites,1) or dls > 500

Anstiege des Anmelderisikos, die eng mit späteren DfI-Warnungen zusammenhängen:

let riskySignIns = IdentityLogonEvents
| where RiskLevelDuringSignIn in ("medium","high")
| project AccountUpn, Timestamp, RiskLevelDuringSignIn;
let dfiAlerts = IdentityDirectoryEvents
| where EventType startswith "DefenderForIdentity"
| project AccountUpn, DfiTime=Timestamp, AlertType=EventType;
riskySignIns
| join kind=inner dfiAlerts on AccountUpn
| where DfiTime between (Timestamp .. Timestamp + 4h)

Kennzahlen, die den Erfolg belegen

Wenn Sie der Geschäftsleitung berichten, brauchen Sie Kennzahlen, die einen greifbaren Rückgang des Risikos belegen. Verfolgen Sie diese Leistungskennzahlen (KPIs):

• Mean Time To Contain (MTTC) bei Identitätsvorfällen (Zeit von der Warnungserstellung bis zur Durchsetzung der Bedingten Zugriffsrichtlinie) ↓
• Verweildauer des Angreifers (Zeit von der ersten verdächtigen Aktion bis zur vollständigen Behebung) ↓
• Blockierte riskante Sitzungen (durch Richtlinien ausgelöste Ereignisse) ↑, während die Rate falsch positiver Ergebnisse ↓
• Alter des Rückstaus riskanter Benutzer (offene Fälle älter als 24 Stunden) ↓
• Latenz beim Widerruf von Token (gemessen in Sekunden) ↓
• Fehlgeschlagene Rechteerhöhungen privilegierter Konten aufgrund von Risiko (frühzeitig abgefangen, bevor Schaden entsteht) ↑, danach im Zeitverlauf Normalisierung
• Secure Score über Identität, Geräte und Apps ↑, ohne entsprechenden Anstieg der Helpdesk-Tickets

30/60/90-Tage-Rollout-Strategie

Versuchen Sie nicht, über Nacht alles zu ändern. Nutzen Sie diesen gestaffelten Zeitplan:

Tag 0–30 (Grundlagen)

• Aktivieren Sie die Einstellungen für Benutzerrisiko und Anmelderisiko in Entra und stellen Sie die Basisrichtlinien für Bedingten Zugriff zunächst im Überwachungsmodus bereit. Wechseln Sie anschließend in den Erzwingungsmodus.
• Binden Sie Defender for Identity in Microsoft 365 Defender ein, und prüfen Sie Warnungen sowie die zentralen Entitätszuordnungen.
• Aktivieren Sie Continuous Access Evaluation (CAE) für unterstützte Apps und integrieren Sie das Gerätrisiko aus MDE mit der Intune-Compliance.

Tag 31–60 (Feedback und Eindämmung)

• Erstellen Sie die Playbooks A und B in Logic Apps und testen Sie diese ausgiebig im Dry-Run-Modus.
• Pilotieren Sie App Control für nicht verwaltete Sitzungen mit zwei bis drei kollaborativen Geschäftsteams.
• Implementieren Sie die Richtlinie zur Schutzschiene für die PIM-Rechteerhöhung.

Tag 61–90 (Erzwingen und Messen)

• Schalten Sie Ihre automatisierten Playbooks für Warnungen mit hoher Zuverlässigkeit in den vollständigen Erzwingungsmodus.
• Richten Sie eine Identity-Security-Arbeitsmappe (in Sentinel oder Power BI) ein, die die oben genannten Kennzahlen verfolgt.
• Führen Sie quartalsweise eine Purple-Team-Übung durch, um MTTC, Geschwindigkeit des Token-Widerrufs und das Umschalten der Bedingten-Zugriff-Richtlinien in einem Live-Fire-Szenario zu validieren.

Häufige Fallstricke (und sicherere Standardeinstellungen)

Achten Sie während der Implementierung auf diese typischen Fehler:

• Fallstrick: Ausschließliches Verlassen auf das Anmelderisiko von CA → Lösung: Reagieren Sie zusätzlich auf Benutzerrisiko und Warnungen von DfI nach der Authentifizierung.
• Fallstrick: Keine CAE konfiguriert, sodass veraltete Token kompromittierte Sitzungen am Leben halten → Lösung: Aktivieren Sie CAE und integrieren Sie den Widerruf von Token direkt in Ihre automatisierten Playbooks.
• Fallstrick: Unternehmensweites, pauschales Blockieren von Dateidownloads, was zu Widerstand bei den Benutzern führt → Lösung: Wenden Sie App Control gezielt nur dann an, wenn Sitzungen nicht verwaltet oder riskant sind.
• Fallstrick: Warnungsfluten und Fehlalarme durch aggressive automatische Kompromittierungs-Workflows → Lösung: Knüpfen Sie Ihre Automatisierungen an eine Verifizierung über mehrere Signale (z. B. hohe DfI-Warnung + ungewöhnliches Download-Volumen + Zugriff außerhalb der Geschäftszeiten).
• Fallstrick: Notfallzugriffskonten werden durch automatisierte Risikorichtlinien versehentlich ausgesperrt → Lösung: Schließen Sie zwei stark überwachte Notfallzugriffskonten aus und rotieren Sie deren Anmeldedaten vierteljährlich.

Kopiervorlagen

Um diese Änderungen im gesamten Unternehmen zu kommunizieren, verwenden Sie diese fertigen Textbausteine:

CAB-Kurzfassung für die Geschäftsleitung:

Wir haben das Nutzerverhalten nach der Anmeldung erfolgreich mit unseren Zugriffskontrollentscheidungen verknüpft. Wenn sich ein Konto ungewöhnlich verhält, erhöhen wir die Sicherheitshürden oder blockieren den Zugriff während der laufenden Sitzung. Dadurch verkürzt sich die Verweildauer von Angreifern deutlich, ohne die normale tägliche Arbeit zu verlangsamen.

Änderungshinweis für Administratoren:

• Neue Richtlinien für Bedingten Zugriff können eine zusätzliche MFA-Abfrage auslösen oder den Zugriff blockieren, wenn ein ungewöhnliches Risiko erkannt wird. Aktive Authentifizierungstoken können nun auf Basis von Telemetriedaten während einer Sitzung widerrufen werden. Notfallzugriffskonten bleiben ausdrücklich ausgeschlossen. Bitte beobachten Sie die Arbeitsmappe Identity Resilience zur Analyse der Auswirkungen.

Benachrichtigungskarte für Eigentümer in Teams (automatisiert):

• „Uns ist ungewöhnliche Dateiaktivität von Ihrem Konto aufgefallen. Wir haben vorübergehende Schutzmaßnahmen angewendet (z. B. das Deaktivieren von Downloads auf nicht verwalteten Geräten). Waren Sie es selbst, klicken Sie einfach auf Bestätigen. Falls nicht, klicken Sie bitte sofort auf Melden.“