Wie stoppen Conditional Access und PIM tatsächlich Angriffe?

Passwortrichtlinien stoppen Brute-Force-Angriffe. Sie helfen nichts gegen ein gestohlenes Session-Token, eine Phishing-MFA-Aufforderung oder ein permanentes Admin-Konto, das zwei Jahre lang mit Global Administrator-Rechten untätig herumliegt. Conditional Access und Privileged Identity Management (PIM) sind die zwei Azure AD / Entra ID-Steuerungen, die diese Lücken tatsächlich adressieren, und sie funktionieren am besten zusammen.

Was Conditional Access unter der Haube tut

Conditional Access ist ein If-This-Then-That-Motor, der zum Zeitpunkt der Anmeldung ausgewertet wird. Die "If"-Seite (Signale) umfasst Benutzer-/Gruppenmitgliedschaft, Gerätekompatibilitätsstatus, Netzwerkstandort, Anmeldungsrisiko (von Identity Protection), angehende Anwendung und Client-App-Typ (Browser vs. Legacy-Protokoll). Die "Then"-Seite (Steuerungen) umfasst: MFA erforderlich, konformes Gerät erforderlich, genehmigte Client-App erforderlich, Zugriff vollständig blockieren oder Akzeptanz von Nutzungsbedingungen erforderlich.

Eine Richtlinie, die in fast jedem Mandanten zählt: Legacy-Authentifizierung blockieren. Protokolle wie POP, IMAP und älteres SMTP unterstützen moderne MFA-Herausforderungen nicht, daher sind sie das Erste, das Credential-Stuffing-Tools versuchen. Überprüfen Sie Anmeldungsprotokolle gefiltert nach "Client App = Other clients", bevor Sie blockieren — Sie werden oft einen Legacy-Scanner oder einen alten Multifunktionsdrucker finden, der sich noch mit Basic Auth authentifiziert.

Eine zweite, die es von Tag eins geben sollte: MFA für alle Benutzer erforderlich, mit einer Ausschlussgruppe nur für Break-Glass-Konten. Begrenzen Sie MFA nicht auf "nur Admins". Kompromittierte Standard-Benutzerkonten sind der Weg, auf dem Angreifer ihren ersten Fuß in der Tür bekommen, bevor die Privilege Escalation überhaupt beginnt.

Anmeldungsrisiko vs. Benutzerrisiko — unterschiedliche Signale, unterschiedliche Reaktionen

Identity Protection (Teil von Entra ID P2) generiert zwei separate Risikobewertungen und es ist leicht, sie zu vermischen:

• Anmeldungsrisiko — dieser spezifische Authentifizierungsversuch sieht anomal aus (unmögliches Reisen, anonyme IP, unbekannte Anmeldeeigenschaften).
• Benutzerrisiko — dieses Konto wurde mit einem Grund gekennzeichnet, der mit der Identität selbst verbunden ist (geleakte Anmeldedaten in einem Breach-Corpus gefunden, bestätigte Kompromittierungsaktivität).

Eine Conditional Access-Richtlinie, die auf Anmeldungsrisiko reagiert, sollte typischerweise mit MFA herausfordern — wenn der echte Benutzer die Herausforderung bewältigen kann, lassen Sie ihn durch. Eine Richtlinie, die auf Benutzerrisiko reagiert, sollte einen Passwort-Reset erzwingen, da MFA allein nicht hilft, wenn die Anmeldedaten selbst bereits kompromittiert sind.

Warum permanente Admin-Zugänge das größere Problem sind

Selbst bei wasserdichtem Conditional Access ist ein Konto, das Global Administrator permanent hält, ein Ziel, das offen sichtbar im Verzeichnis sitzt. Jeder, der es kompromittiert, erbt die vollständige Mandantenkontrolle ohne erforderlichen zusätzlichen Schritt. PIM entfernt den "permanenten" Teil.

Mit PIM werden Admin-Rollen als berechtigt statt als aktiv zugewiesen. Der Benutzer muss die Rolle explizit aktivieren, was eine erforderliche Begründung, einen optionalen Genehmigungsworkflow, MFA-Neubestätigung und ein zeitgebundenes Fenster auslöst — üblicherweise 1 bis 8 Stunden — nach dem die Rolle automatisch deaktiviert wird. Niemand, auch nicht der Kontoinhaber, hat permanente Global Admin-Rechte, es sei denn, er verwendet sie gerade.

Eine minimale PIM-Konfiguration, die tatsächlich nutzbar ist

• Jede Rolle über Helpdesk Administrator: berechtigt, nicht permanent.
• Global Administrator und Privileged Role Administrator: Genehmigung von einem zweiten Admin erforderlich, nicht nur Selbstaktivierung.
• Aktivierungs-MFA erforderlich, ohne Ausnahmen.
• Maximale Aktivierungsdauer von 4 Stunden zwingt Menschen, für echte separate Arbeitssitzungen erneut zu aktivieren, was auch sauberere Audit-Trails erzeugt.
• Zugriffsüberprüfungen alle 90 Tage auf alle berechtigten Zuweisungen — Konten werden für ein Projekt hinzugefügt und sonst nie entfernt.

Wo Teams das falsch machen

Der häufigste Fehler ist nicht das Richtlinien-Design, es ist die Ausschlussliste. Eine Conditional Access-Richtlinie mit einer ständig wachsenden Gruppe "diese Benutzer ausschließen, weil die App MFA nicht unterstützt" schließt schließlich die Hälfte des Mandanten aus. Verfolgen Sie Ausschlüsse als ein Backlog-Element mit einem Besitzer und einem Entfernungsdatum, nicht als ein permanenter Behälter.

Der zweite Fehler sind Break-Glass-Konten, die nicht tatsächlich getestet werden. Zwei Notfall-Konten, ausgeschlossen von Conditional Access und PIM, mit langen zufälligen Passwörtern offline gespeichert und Alarmen bei jeder Anmeldung — und jemand sollte sich vierteljährlich in sie einloggen, um zu bestätigen, dass sie noch funktionieren.

Conditional Access und PIM sind kein Häkchen für ein Compliance-Audit. Sie sind der Unterschied zwischen einer Phishing-Anmeldedaten als Unannehmlichkeit und einer vollständigen Mandanten-Kompromittierung. Wenn Sie Identitätssteuerungen als Teil eines Blue Team-Aufbaus abbilden, behandeln Korra Studio's Cloud und Blue Team-Segmente die Erkennungsseite — wie Identity Protection-Risikointensive tatsächlich in Sentinel aussehen und wie man auf unmögliche PIM-Aktivierungsmuster alertet.