Azure Identity Protection: Risikorichtlinien-Leitfaden

Was Ist Azure Identity Protection?

Azure Identity Protection, heute Microsoft Entra ID Protection, ist die Risikoerkennungs- und Reaktionsschicht für Microsoft-Entra-Identitäten. Sie wertet Signale aus, die auf eine Kontokompromittierung hindeuten können, und stellt sie als Benutzerrisiko, Anmelderisiko, risikobehaftete Benutzer und Risikoerkennungen dar.

Der wichtige operative Punkt ist: Erkennung allein stoppt keinen Angriff. Ein Tenant kann im Portal risikobehaftete Benutzer und risikobehaftete Anmeldungen anzeigen und trotzdem zulassen, dass der Angreifer weitermacht, wenn keine Richtlinie eine Behebung, Multi-Faktor-Authentifizierung, erneute Authentifizierung, Passwortänderung oder Blockierung erzwingt. Dieser Artikel konzentriert sich genau auf diese Lücke: Das Risiko ist sichtbar, aber die Reaktion des Tenants fehlt, ist unvollständig oder zu eng abgegrenzt.

Microsofts aktuelle Empfehlung verlagert risikobasierte Kontrollen nach Conditional Access. Die alten Identity-Protection-Risikorichtlinien existieren in manchen Tenants noch, aber laut Microsoft-Dokumentation sollten die alten Benutzerrisiko- und Anmelderisikorichtlinien nach Conditional Access migriert werden; sie werden am 1. Oktober 2026 abgekündigt.

Wie Azure Identity Protection Funktioniert

Identity Protection nutzt zwei eng verwandte Risikokonzepte:

Anmelderisiko ist die Wahrscheinlichkeit, dass eine konkrete Authentifizierungsanfrage nicht vom legitimen Identitätsinhaber stammt. Es wird während der Anmeldung bewertet und kann als Conditional-Access-Bedingung verwendet werden.

Benutzerrisiko ist die Wahrscheinlichkeit, dass das Benutzerkonto selbst kompromittiert ist. Es kann über eine einzelne Anmeldung hinaus bestehen bleiben und eine Passwortänderung, einen Sitzungswiderruf, eine Administrator-Untersuchung oder eine Freigabe erfordern.

Microsoft dokumentiert Risikoerkennungen wie durchgesickerte Zugangsdaten, anonyme IP-Adresse, atypische Reise, unbekannte Anmeldeeigenschaften, bösartige IP-Adresse, verdächtige Posteingangsregeln, Password Spray, anomale Token und weitere Signale. Manche Erkennungen erfolgen in Echtzeit, andere werden offline berechnet und können erst später erscheinen. Dieses Timing ist operativ relevant: Ein Risikoereignis kann sichtbar werden, nachdem die ursprüngliche Authentifizierung bereits abgeschlossen ist.

Warum Risikorichtlinien In Der Praxis Scheitern

Identity Protection bleibt hinter ihrem Potenzial zurück, wenn Teams das Dashboard selbst als Kontrolle behandeln. Häufige Fehlerbilder sind:

keine Conditional-Access-Richtlinie nutzt Anmelderisiko- oder Benutzerrisiko-Bedingungen
Richtlinien bleiben nach dem Testen im Nur-Bericht-Modus
Risikorichtlinien decken Pilotbenutzer ab, aber nicht privilegierte Benutzer oder die Gesamtbelegschaft
Notfallkonten sind ohne kompensierendes Monitoring ausgeschlossen
Hybrid-Benutzer können die Selbstbehebung nicht abschließen, weil Password Writeback dort nicht verfügbar ist, wo es benötigt wird
Benachrichtigungen zu risikobehafteten Benutzern gehen an ein Postfach, das niemand prüft
Analysten können Risiken ohne dokumentierten Nachweisstandard verwerfen
Service Principals werden fälschlich als durch benutzerbezogene Conditional-Access-Abdeckung erfasst angenommen

Der letzte Punkt ist wichtig. Benutzerrisiko- und Anmelderisikorichtlinien zielen auf Benutzeranmeldungen ab. Workload-Identitäten und Service-Principal-Risiko benötigen ein anderes Kontrollmodell und sollten nicht als durch menschliche Benutzerrisikorichtlinien abgedeckt angenommen werden.

Die Angriffskette Ohne Risikoreaktion

Szenario 1 – Durchgesickerte Zugangsdaten

Die Zugangsdaten eines Benutzers tauchen in Breach-Daten auf oder werden anderweitig als riskant eingestuft. Identity Protection setzt das Benutzerrisiko hoch, aber keine Benutzerrisikorichtlinie erzwingt eine Behebung. Das Konto bleibt nutzbar, bis eine andere Kontrolle den Angreifer blockiert.

Szenario 2 – Riskante Anmeldung, Die Trotzdem Abgeschlossen Wird

Eine Anmeldung hat aufgrund von Signalen wie anonymer Infrastruktur, unbekannten Anmeldeeigenschaften oder atypischer Reise ein mittleres oder hohes Risiko. Greift keine Anmelderisikorichtlinie, kann die Sitzung trotzdem zustande kommen. Ein Protokolleintrag existiert zwar, aber der Angreifer hat bereits Zugriff erlangt.

Szenario 3 – Password Spray Gegen Cloud-Konten

Eine Password-Spray-Kampagne erzeugt breites Authentifizierungsrauschen und kann riskante Erkennungen auslösen. Werden erfolgreiche Anmeldungen nicht per Richtlinie zu einer Step-up-Authentifizierung gezwungen oder blockiert, behält der Angreifer die erfolgreichen Sitzungen.

Szenario 4 – Risiko Ohne Untersuchung Verworfen

Ein risikobehafteter Benutzer wird verworfen, weil der Alarm unbequem oder störend ist. Verlangt der Verwerfungsprozess keine Nachweise, kann der Tenant echte Kompromittierung normalisieren und genau das Signal entfernen, das Verteidiger benötigt hätten.

Erkennung

Zu Überwachende Risikosignale

Signal	Was Es Anzeigt	Operativer Einsatz
Durchgesickerte Zugangsdaten	Zum Konto gehörende Zugangsdaten wurden in bekanntem kompromittiertem Material gefunden	Bis zur Überprüfung als Nachweis für eine Kontokompromittierung behandeln
Anonyme IP-Adresse	Die Anmeldung kam aus Anonymisierungs-Infrastruktur	Mit Gerät, Standort und Benutzerhistorie korrelieren
Atypische Reise	Die Anmeldegeografie passt nicht zur jüngsten Aktivität	Auf unmögliche oder verdächtige Reisemuster prüfen
Unbekannte Anmeldeeigenschaften	Die Anmeldung weicht vom normalen Benutzerverhalten ab	Nützlich in Kombination mit Geräte- und Standortkontext
Bösartige IP-Adresse	Die Quellinfrastruktur ist mit bösartiger Aktivität assoziiert	Höhere Dringlichkeit bei privilegierten Benutzern
Password Spray	Breit angelegtes Passwort-Rateverhalten wird erkannt	Mit Sperrungen, Fehlversuchen und erfolgreichen Anmeldungen korrelieren
Anomaler Token	Das Token-Verhalten wirkt verdächtig	Sitzungsaktivität prüfen und ggf. widerrufen

Zu Prüfende Ereignisse Und Berichte

Die Erkennung sollte umfassen:

Bericht zu risikobehafteten Benutzern
Bericht zu Risikoerkennungen
Anmeldeprotokolle mit Risikostufe und Risikodetails
Conditional-Access-Ergebnisse für riskante Anmeldungen
Audit-Protokolle für Risiko-Verwerfungen, Passwort-Zurücksetzungen, Richtlinienänderungen und Admin-Aktionen
Kontext zu privilegierten Rollen für betroffene Identitäten

Eine Hochrisiko-Anmeldung eines globalen Administrators hat nicht dieselbe operative Priorität wie ein Niedrigrisiko-Ereignis bei einem ruhenden Testkonto. Der Alarm sollte Rolle, Gerät, Standort, App, Richtlinienergebnis und Sitzungsausgang enthalten.

Behebung

Identity Protection wird erst dann nützlich, wenn Risiko eine Reaktion auslöst. Ein Dashboard ohne durchgesetzte Conditional-Access-Richtlinien ist nur Sichtbarkeit.

1. Separate Risikorichtlinien Konfigurieren

Microsoft rät davon ab, Benutzerrisiko- und Anmelderisiko-Bedingungen in derselben Conditional-Access-Richtlinie zu kombinieren. Erstellen Sie separate Richtlinien, damit jede Risikobedingung einen klaren Reaktionspfad hat.

Für Anmelderisiko empfiehlt Microsoft, bei mittlerem und hohem Anmelderisiko Multi-Faktor-Authentifizierung zu erzwingen. Für Benutzerrisiko empfiehlt Microsoft, bei hohem Benutzerrisiko eine Risikobehebung zu erzwingen. Organisationen können strengere Schwellenwerte wählen, müssen dabei aber Sicherheit, Falsch-Positive und Benutzerunterbrechung abwägen.

2. Zunächst Nur-Bericht-Modus Nutzen, Dann Durchsetzen

Der Nur-Bericht-Modus eignet sich für den Rollout. Er ist kein Endzustand. Prüfen Sie, welche Benutzer, Apps und Szenarien betroffen wären, beheben Sie erwartete Beeinträchtigungen und stellen Sie die Richtlinie dann auf Ein. Führen Sie eine datierte Rollout-Dokumentation, damit Nur-Bericht-Richtlinien nicht dauerhaft liegen bleiben.

3. Selbstbehebung Funktionsfähig Machen

Selbstbehebung hängt von Voraussetzungen ab. Benutzer müssen für Microsoft Entra Multi-Faktor-Authentifizierung registriert sein, bevor sie eine MFA-basierte Behebung durchführen können. Hybrid-Benutzer benötigen unter Umständen Password Writeback für sichere Passwortänderungsszenarien. Fehlen diese Voraussetzungen, können Benutzer blockiert werden und einen Administrator-Eingriff benötigen.

4. Den Analysten-Workflow Definieren

Eine Risikorichtlinie ersetzt keine Untersuchung. Definieren Sie, wer:

eine Benutzerkompromittierung bestätigen darf
Benutzerrisiko verwerfen darf
Passwörter zurücksetzen darf
Sitzungen widerrufen darf
Benutzer entsperren darf
Ausnahmen genehmigen darf
Conditional-Access-Risikoschwellenwerte aktualisieren darf

Jede Aktion sollte einem Nachweisstandard folgen. Ein Risiko zu verwerfen, weil der Benutzer angibt, gereist zu sein, ist nicht dasselbe wie Gerät, IP, Authentifizierungsmethode und Sitzungsaktivität zu validieren.

5. Ausnahmen Und Servicekonten Überprüfen

Notfallzugriffskonten benötigen unter Umständen eine Sonderbehandlung, aber Ausnahmen sollten wenige und stark überwacht sein. Servicekonten und Workload-Identitäten sollten nicht stillschweigend aus der Risikobetrachtung ausgeschlossen werden; sie benötigen möglicherweise Workload-Identity-Conditional-Access, Managed Identities, Credential-Rotation oder ein anderes Monitoring.

Sicherer Rollout-Ablauf

Ein sicherer Rollout beginnt nicht damit, den gesamten Tenant ohne Evidenz zu blockieren. Starten Sie mit Nur-Bericht-Richtlinien für die vorgesehene Zielgruppe, prüfen Sie die Richtlinienauswirkung, beheben Sie Voraussetzungen bei Registrierung und Password Writeback, und setzen Sie die Richtlinie dann stufenweise durch. Privilegierte Identitäten sollten priorisiert werden, weil eine erfolgreiche riskante Anmeldung eines Administrators einen deutlich größeren Blast Radius hat als dasselbe Ereignis bei einem gering privilegierten Konto.

Halten Sie den Rollout messbar. Verfolgen Sie, wie viele riskante Anmeldungen blockiert oder herausgefordert worden wären, wie viele Benutzer eine Selbstbehebung durchführen konnten, welche Konten ausgeschlossen sind und welche Vorfälle einen Administrator-Eingriff erforderten. Diese Kennzahlen helfen, ein funktionierendes Schutzprogramm von einer Richtlinie zu unterscheiden, die zwar existiert, aber nicht sicher durchgesetzt werden kann.

Validierung Nach Aktivierung Der Risikoreaktion

Validieren Sie die Kontrolle sowohl aus Portal- als auch aus Angreiferperspektive:

bestätigen, dass Anmelderisiko- und Benutzerrisikorichtlinien aktiviert und nicht nur konfiguriert sind
bestätigen, dass die Zielbenutzer privilegierte Identitäten und normale Benutzer im Geltungsbereich einschließen
bestätigen, dass ausgeschlossene Benutzer dokumentiert und überwacht werden
aktuelle riskante Anmeldungen prüfen und bestätigen, dass das vorgesehene Richtlinienergebnis angewendet wurde
bestätigen, dass erfolgreiche Hochrisiko-Anmeldungen selten, erklärbar und untersucht sind
bestätigen, dass Administratoren Kompromittierung bestätigen, Risiko verwerfen, Sitzungen widerrufen und Zugangsdaten anhand dokumentierter Workflows zurücksetzen können
das Alarm-Routing testen, damit Benachrichtigungen zu risikobehafteten Benutzern das Response-Team erreichen
prüfen, ob Workload-Identitäten separate Conditional-Access-Richtlinien oder Monitoring benötigen

Erkennt der Tenant zwar Risiko, lässt aber risikobehaftete Benutzer ohne Behebung weitermachen, ist die Kontrolle unvollständig.

Wie EtcSec Dies Erkennt

EtcSec prüft, ob Risikoerkennungen an einen durchgesetzten Reaktionspfad gebunden sind.

Die Kategorie Risk Protection hebt eine fehlende Anmelderisikorichtlinie, eine fehlende Benutzerrisikorichtlinie und eine schwache Tenant-Reaktion hervor, bei der riskante Aktivität sichtbar, die Durchsetzung aber abwesend oder unvollständig ist.

Das ist genau die operative Lücke, um die es in diesem Artikel geht: Risikoerkennungen ohne Eindämmung.

Azure Identity Protection: Geleakte Zugangsdaten Blockieren