Identity Protection und risikobasierte Policies richtig einsetzen

Identity Protection ist kein Knopf, den du einschaltest und dann ruhig schlaefst. Es ist ein Risiko-Radar, das dir sagt, welche Anmeldungen und Konten verdaechtig sind – reagieren musst du selbst. Und die ehrliche Wahrheit: Ohne Entra ID P2 siehst du zwar Risiken, kannst aber nichts automatisch dagegen tun. Wer das verwechselt, wiegt sich in falscher Sicherheit.

Identity Protection bewertet Signale zu einem Risiko und loest – mit P2 – automatisch eine Reaktion aus.

Was Identity Protection eigentlich macht (und was nicht)

Identity Protection ist die Risiko-Engine von Entra ID (früher Azure AD). Sie sammelt Signale rund um jede Anmeldung und jedes Konto, jagt sie durch Microsofts Machine-Learning-Modelle und spuckt zwei Risikobewertungen aus: das Sign-in-Risiko (ist diese eine Anmeldung verdächtig?) und das User-Risiko (ist dieses Konto vermutlich kompromittiert?).

Der entscheidende Punkt, den viele übersehen: Identity Protection erkennt, aber es handelt nicht von allein. Reagieren tust du über risikobasierte Conditional-Access-Policies. Erkennung und Reaktion sind zwei getrennte Bausteine – und genau dazwischen verläuft die Lizenzgrenze.

Sign-in-Risk vs. User-Risk: zwei Hebel, zwei Zwecke

Die beiden Policy-Typen werden ständig verwechselt, dabei lösen sie unterschiedliche Probleme. Die Sign-in-Risk-Policy fragt: 'Ist diese Anmeldung hier und jetzt verdächtig?' – etwa weil sie von einer anonymen IP oder nach einem unmöglichen Ortswechsel kommt. Die User-Risk-Policy fragt: 'Ist dieses Konto insgesamt vermutlich übernommen?' – etwa weil die Zugangsdaten im Darknet aufgetaucht sind.

Sign-in-Risk reagiert pro Anmeldung in Echtzeit, User-Risk auf den akkumulierten Zustand des Kontos.

Faustregel aus der Praxis: Sign-in-Risk-Policy erzwingt MFA, User-Risk-Policy erzwingt einen sicheren Passwortwechsel. Beide solltest du ab der Stufe 'Mittel' greifen lassen – 'Hoch' allein lässt zu viel durch.

Die Reaktionskette – und wo sie teuer kippt

Im Idealfall heilt sich ein Risiko selbst: Die Policy zwingt den User zu MFA und Passwortwechsel, das Risiko gilt als bereinigt, fertig. Das funktioniert aber nur, wenn der User überhaupt MFA-fähig registriert ist. Ist er das nicht, landet jeder Vorfall manuell beim Admin – und in einem 800-Mann-Tenant ist das kein Spaß.

Self-Healing klappt nur bei MFA-fähigen Usern – sonst staut sich alles beim Admin.

Umsetzung: Risiken sichtbar machen und gezielt bereinigen

Bevor du Policies scharf schaltest, willst du wissen, wer aktuell als riskant gilt. Microsoft Graph PowerShell liefert dir die Liste der riskanten User – ideal für einen schnellen Audit oder ein Reporting an die Geschäftsführung.

Wichtig: 'Confirm compromised' und 'Dismiss' sind keine Kosmetik. Sie trainieren Microsofts Modell mit. Wer wahllos Risiken wegklickt, macht die Engine für den eigenen Tenant dumm – also nur dismissen, wenn du wirklich geprüft hast, dass die Anmeldung legitim war.

Beispiel aus der Praxis

Die Trendforge Digital GmbH, ein Cloud-first-Startup mit rund 90 Leuten, schaltet voller Tatendrang eine User-Risk-Policy auf 'Hoch – Zugriff blockieren'. Zwei Wochen später taucht ein altes Mitarbeiter-Passwort in einem fremden Datenleck auf. Die Engine stuft drei Konten als 'hoch' ein und blockt sie komplett – darunter den CTO mitten in einer Kundendemo.

Das Problem: 'Blockieren' beendet den Zugriff, löst das Risiko aber nicht auf. Der CTO kann sich nicht selbst befreien, weil 'Block' keinen Self-Service-Pfad lässt. Die saubere Lösung wäre eine User-Risk-Policy mit 'Sicheren Passwortwechsel erzwingen' gewesen – das hätte den CTO durch MFA plus neues Passwort geschleust und das Risiko automatisch bereinigt. Trendforge baut die Policy um, erzwingt vorab die kombinierte MFA-Registrierung und hat seitdem Ruhe. Lehre: 'Blockieren' ist die Notbremse, nicht der Normalbetrieb.

Verwandte Artikel

Häufige Fragen (FAQ)

Frage 1: Brauche ich für Identity Protection zwingend Entra ID P2?

Antwort: Für die volle Funktion ja. Risikobasierte Sign-in- und User-Policies, die detaillierten Risiko-Reports und die automatische Reaktion sind P2-Features. Mit Free oder P1 siehst du allenfalls grundlegende Erkennungen, kannst aber nicht risikobasiert reagieren – was den eigentlichen Sinn ausmacht.

Frage 2: Was ist der Unterschied zwischen Sign-in-Risk und User-Risk?

Antwort: Sign-in-Risk bewertet eine einzelne Anmeldung in Echtzeit (verdächtige IP, unmöglicher Ortswechsel). User-Risk bewertet den Gesamtzustand eines Kontos über die Zeit (z. B. geleakte Zugangsdaten). Sign-in-Risk erzwingt typischerweise MFA, User-Risk einen sicheren Passwortwechsel.

Frage 3: Auf welche Risikostufe sollte ich meine Policies einstellen?

Antwort: In der Praxis bewährt sich 'Mittel und höher'. Wer nur auf 'Hoch' reagiert, lässt zu viele echte Vorfälle durch, weil die Engine neue Angriffsmuster anfangs konservativ als 'Mittel' einstuft. 'Niedrig' wiederum erzeugt Alarm-Müdigkeit.

Frage 4: Warum sperrt sich nach Aktivierung der Policy plötzlich die halbe Belegschaft aus?

Antwort: Fast immer, weil die User keine MFA-Methoden registriert haben und die Policy 'Passwort ändern' oder 'Blockieren' erzwingt. Ohne registrierte MFA gibt es keinen Self-Service-Pfad zurück. Lösung: erst MFA-Registrierung sicherstellen, dann die risikobasierte Policy aktivieren.

Frage 5: Was bedeutet es, einen Risiko-Eintrag zu bestätigen oder zu verwerfen?

Antwort: 'Confirm compromised' und 'Dismiss' trainieren Microsofts ML-Modell für deinen Tenant mit. Sie sind also kein bloßes Aufräumen. Verwirf Risiken nur, wenn du geprüft hast, dass die Anmeldung legitim war – sonst verschlechterst du die Erkennungsqualität.

Frage 6: Ersetzt Identity Protection meine Conditional-Access-Policies?

Antwort: Nein, es ergänzt sie. Identity Protection liefert das Risiko-Signal, Conditional Access trifft die Entscheidung. Du baust risikobasierte CA-Policies, die das Risiko als Bedingung nutzen. Ohne Conditional Access bleibt das Risiko nur eine Zahl im Report.

Wie geht es weiter?