User Risk muss remediated werden? User Risk Policy konfigurieren

Manchmal ist das Problem nicht nur ein einzelner verdaechtiger Login-Versuch.

Das Konto selbst kann ueber Zeit riskant sein.

Das ist User risk.

Das Microsoft-Entra-Muster ist:

Benutzerkonto sieht kompromittiert aus -> Conditional Access User Risk Policy -> Remediation verlangen

In diesem Beispiel:

• CloudTrips will kompromittierte Konten automatisch remediaten
• User risk beschreibt die Wahrscheinlichkeit, dass das Konto kompromittiert ist
• Conditional Access verlangt Remediation fuer High-Risk Users

Dieser Trip behandelt das Konto.

Der separate Sign-in-Risk-Trip behandelt den aktuellen Login-Versuch.

User Risk vs Sign-In Risk

User risk beantwortet:

Ist dieses Benutzerkonto wahrscheinlich kompromittiert?

Sign-in risk beantwortet:

Sieht dieser konkrete Login-Versuch riskant aus?

Halte die Policies getrennt.

Fuer User risk ist die normale Reaktion:

Secure password change oder Risk Remediation verlangen

Fuer Sign-in risk ist die normale Reaktion:

MFA oder Authentication Strength verlangen

Risky Users pruefen

Gehe zu:

Entra ID > Identity Secure Score > Risky users

Du brauchst keinen vorhandenen risky user, um die Policy zu konfigurieren.

Auf dieser Seite erscheinen riskante Konten, wenn Microsoft genug Account-Level-Risk erkennt.

Achte auf Spalten wie:

User
Risk state
Risk level
Last updated

Conditional-Access-Policy erstellen

Gehe zu:

Entra ID > Conditional Access > Policies

Erstelle eine neue Policy.

Beispielname:

CA-Require-Remediation-For-High-User-Risk

Benutzer zuweisen

Unter:

Users and groups

Starte mit einer Pilotgruppe.

Beispiel:

Include: GRP-CloudTrips-Risk-Policy-Pilot
Exclude: Emergency access accounts, if your tenant has them

Nach dem Testen kannst du die Policy auf alle Benutzer erweitern.

Ressourcen targetieren

Unter:

Target resources

Fuer Account-Risk-Remediation verwende:

All resources

Damit gilt die Remediation-Anforderung, wenn der risky user auf Cloud-Ressourcen zugreift.

User Risk konfigurieren

Unter:

Conditions > User risk

Waehle:

High

High user risk ist der normale Startpunkt fuer Remediation Policies, weil Microsoft dann staerkere Hinweise hat, dass das Konto kompromittiert ist.

Risk Remediation verlangen

Unter:

Access controls > Grant

Waehle:

Grant access
Require password change

Je nach Portal-Erfahrung kann das als Risk Remediation oder Password-Change Grant Control erscheinen.

Der Punkt ist:

Der risky user muss das Konto remediaten, bevor er fortfahren kann.

Mit Report-Only Mode starten

Setze:

Enable policy: Report-only

Report-only laesst dich die Policy-Konfiguration pruefen, ohne sofort Remediation zu erzwingen.

Wenn dein Lab noch keine risky users hat, ist das in Ordnung.

Ohne risky user validieren

Du musst keinen risky user erzeugen, um diesen Trip abzuschliessen.

Bestaetige, dass die Policy-Zusammenfassung Folgendes zeigt:

Users and groups: pilot group
Target resources: All resources
Conditions: User risk = High
Grant: Require password change or risk remediation
Enable policy: Report-only

Wenn spaeter echte risky users erscheinen, pruefe sie in:

Entra ID > Identity Secure Score > Risky users

und pruefe, ob der User Risk State nach der erforderlichen Aktion remediated ist.

Policy aktivieren

Nach dem Testen aendere:

Enable policy: On

Jetzt muessen High-Risk Users das Konto remediaten, bevor sie fortfahren.

Enterprise-Hinweis

User Risk Policy behandelt Account Compromise ueber Zeit.

Sie ist nicht dasselbe wie Sign-in Risk Policy.

Empfohlener Rollout:

• mit einer Pilotgruppe starten
• zuerst Report-only Mode verwenden
• Emergency Access Accounts ausschliessen, wenn dein Tenant welche hat
• High als erstes User-Risk-Level verwenden
• Sign-in-Risk-Challenges in einer separaten Policy halten
• sicherstellen, dass Benutzer Self-Service Password Reset nutzen koennen, wenn Password Change verlangt wird