Freigeben über

Microsoft Entra ID Protection-Szenario: Beherrschen der Risikoanalyse für effektive Schadensbehebung

Der Leitfaden für die Machbarkeitsprüfung (PoC) in dieser Artikelreihe hilft Ihnen, Microsoft Entra ID Protection zu erlernen, bereitzustellen und zu testen, um identitätsbasierte Risiken zu erkennen, zu untersuchen und zu beheben.

Eine Übersicht über die Anleitung beginnt mit Einleitung in die Anleitung zum Proof-of-Concept von Microsoft Entra ID Protection.

Detaillierte Anleitungen werden mit diesen Szenarien fortgesetzt:

Dieser Artikel hilft Identitätsadministratoren, die Risikoanalyse für effektive Korrekturen mit Azure Monitor-Protokollen zu meistern. In der folgenden Liste werden Analysebereiche hervorgehoben:

In den folgenden Abschnitten erfahren Sie, wie Sie allgemeine Risikoereignistypen, gekennzeichnete Benutzer und Muster auf Risikoebene mit Azure Monitor-Protokollen und Microsoft Entra ID Protection verwalten.

Aktivieren der Risikoanalyse mit der Tabelle "AADUserRiskEvents"

Identitätsrisiken wachsen jedes Jahr in Geschwindigkeit und Komplexität. Sie können Risikoeinblicke verwenden, um die Menge und Details potenzieller Identitätsangriffe und Kompromittierungen zu erfassen. Ermöglichen Sie Azure Monitor Logs-Referenztabellen, um Risikoeinblicke mit Microsoft Entra ID Protection zu analysieren, die Identitätsrisiken erkennt, untersucht und korrigiert. Risikodaten werden an Tools für Zugriffsentscheidungen oder an Tools zur Untersuchung und Korrelation gesendet. Microsoft Entra ID Protection wird kontinuierlich aktualisiert, um Organisationen dabei zu helfen, sich vor neuen Bedrohungen zu halten. Das Identitätsrisikomanagement wird proaktiver, skalierbarer und effektiver.

Mit Einblicken, Referenztabellen und mehr können Sie Identitätsrisiken mit bedingtem Zugriff untersuchen und beheben und gezielte Richtlinien erstellen, um die Risiken Ihrer Organisation zu beheben.

Weitere Informationen finden Sie in der Übersicht über Azure Monitor-Protokolle.

In Microsoft Entra ID Protection gibt es vier Risikotabellen zum Abfragen von Risikoereignissen, riskanten Benutzern und riskanten Dienstprinzipalen.

  • AADUserRiskEvents
  • AADRiskyUsers
  • AADServicePrincipalRiskEvents
  • AADRiskyServicePrincipals

In diesem Artikel liegt der Fokus auf der Tabelle AADUserRiskEvents. Weitere Informationen zum Erkennen von Risiken für Ihre Organisation finden Sie im folgenden Video.

Risikoanalyse meistern mit Microsoft Entra ID Protection

Sicherstellen, dass voraussetzungen erfüllt sind

Um Azure Monitor zu verwenden, stellen Sie sicher, dass die folgenden Voraussetzungen erfüllt sind.

Erstellen eines Log Analytics-Arbeitsbereichs

Ein Log Analytics-Arbeitsbereich ist ein Datenspeicher zum Sammeln von Protokolldatentypen aus Azure und Nicht-Azure-Ressourcen und -Anwendungen. Es wird empfohlen, alle Protokolldaten an einen Log Analytics-Arbeitsbereich zu senden.

  1. Erstellen Sie einen Log Analytics-Arbeitsbereich.
  2. Um die zu analysierenden Daten zu integrieren, fügen Sie Diagnoseeinstellungen hinzu. Weitere Informationen finden Sie in der folgenden Liste:
  • AuditLogs
  • SignInLogs
  • Protokolle der nicht interaktiven Benutzeranmeldungen
  • Anmeldeprotokolle des Dienstprinzipals
  • ManagedIdentitySignInLogs
  • RiskyUsers
  • BenutzerRisikoEreignisse
  • RiskyServicePrincipals
  • ServicePrincipalRiskEvents
  1. Um den Abfragehub anzuzeigen, wechseln Sie zum Log Analytics-Arbeitsbereich.
  2. Wählen Sie Protokolle aus.
  3. Suchen Sie nach Risiko.
  4. Suchen Sie die Abfrage Aktuelle Benutzerrisikoereignisse.
  5. Klicken Sie auf Ausführen.
  6. Ändern Sie im Dropdownmodus den einfachen Modus in den Kusto Query Language-Modus (KQL-Modus).

Screenshot der Option 'KQL-Modus'.

Screenshot der KQL-Modusoption im Dropdownmenü.

Identifizieren riskanter Benutzer

In diesem Abschnitt und den folgenden Abschnitten wird veranschaulicht, wie Risiken mit Azure Monitor analysiert werden. Riskante Benutzer haben mindestens eine riskante Anmeldung oder andere riskante Aktionen.

  1. Führen Sie die Abfrage aus, um die Anzahl von UserDisplayName zu ermitteln.
  2. Fügen Sie einen Zeitbereich in DetectedDateTime < ago()hinzu.

In der folgenden Beispielabfrage ist 30d der Datumsbereich.

// Recent user risk events 
// Gets list of the top 100 active user risk events. 
AADUserRiskEvents 
| where DetectedDateTime > ago(30d) 
| where RiskState == "atRisk" 
| take 100 
| summarize count()by UserDisplayName

Verwenden Sie die vorherige Abfrage, um allgemeine Benutzermuster zu identifizieren, z. B. Dienstkonten oder kleine Benutzeruntergruppen, die große Risikomengen generieren. Im Beispiel-Screenshot ist ein Benutzer für deutlich mehr Risikoereignisse verantwortlich als andere. Wenn ein einzelner Benutzer für ein unverhältnismäßiges Risiko in Ihrem Mandanten verantwortlich ist, empfehlen wir, dass eine sichere Kennwortänderung erforderlich ist.

Screenshot der riskanten Benutzerdaten aus der Abfrage.

Erkennen von Risikoereignistypen

Nachdem wir Muster von bestimmten Benutzern untersucht haben, empfehlen wir, die Ergebnisse selbst zu überprüfen und sie nach Erkennungstypen zusammenzufassen.

  1. Verwenden Sie die Tabelle "AADUserRiskEvents ".
  2. Zusammenfassen mit RiskEventType.

Beispielabfrage

// Recent user risk events 
// Gets list of the top 100 active user risk events. 
AADUserRiskEvents 
| where DetectedDateTime > ago(30d) 
| where RiskState == "atRisk" 
| take 100  
| summarize count()by RiskEventType

Achten Sie beim Überprüfen der Risikotypen auf große Mengen. Im folgenden Beispiel gibt es mehrere gekennzeichnete Risikoereignisse. Die meisten beziehen sich auf:

  • nicht vertraute Features – Erkennen unbekannter Anmeldeeigenschaften für einen Benutzer
    • Sitzungssteuerung erzwingen, wie z.B. Anmeldehäufigkeit, Anwendungseinschränkungen und persistente Browsersteuerung.
  • anomalousToken – Richtlinien für bedingten Zugriff einrichten, um einen Kennwortzurücksetzung zu fordern und eine Mehrfaktor-Authentifizierung (MFA) durchzuführen.
    • Blockieren des Zugriffs für Anmeldungen mit hohem Risiko
  • unlikelyTravel – Benannte Standorte als vertrauenswürdige IPs hinzufügen
    • Aktivieren vertrauenswürdiger Speicherorte für Benutzer, die häufig reisen

Sehen Sie sich den folgenden Screenshot der Ergebnisse der Abfrage für aktive Benutzerrisikoereignisse an.

Screenshot der Ergebnisse aus der Abfrage

Untersuchen von Risikostufen

Nachdem wir das Benutzerverhalten und die Risikoereignistypen untersucht haben, empfiehlt es sich, die Tabelle "AADUserRiskEvents" erneut zu untersuchen, um die drei Risikostufen zu überprüfen: niedrig, mittel und hoch. Fassen Sie das Risiko nach Ebene zusammen, und analysieren Sie die Gesamtanzahl der einzelnen Risikostufen.

Beispielabfrage

// Recent user risk events 
// Gets list of the top 100 active user risk events. 
AADUserRiskEvents 
| where DetectedDateTime > ago(30d) 
| where RiskState == "atRisk" 
| take 100 
| summarize count()by RiskLevel

Im folgenden Screenshot gibt es viele Erkennungen insgesamt, aber nur drei werden als hochriskant eingestuft. Das Filtern nach Empfindlichkeit – niedrig, mittel oder hoch – hilft dabei, die wichtigsten Probleme zu isolieren. Die Priorisierung von Erkennungen mit hohem Risiko reduziert zuerst das Rauschen und stellt sicher, dass Sie die wichtigsten Bedrohungen behandeln. In diesen Fällen wird empfohlen, eine grundlegende Richtlinie für bedingten Zugriff zu implementieren, die eine sichere Kennwortänderung für Benutzer mit hohem Risiko erzwingt.

Screenshot der Abfrageergebnisse, die drei Benutzer mit hohem Risiko anzeigen.

Erfahren Sie mehr über Zugriffssteuerungsentscheidungen: Was ist der bedingte Zugriff?

Erste Schritte mit Referenztabellen zu Azure Monitor Logs

Erkunden Sie zunächst die Azure Monitor-Protokollreferenztabellen für Microsoft Entra ID Protection. Die folgenden Links bieten eine Liste von Tabellen nach Namen. Diese Protokolle erfassen wichtige Erkenntnisse, einschließlich Benutzerrisikoereignisse, riskante Benutzer, Dienstprinzipal-Risikoereignisse und riskante Dienstprinzipale unter anderem.

Nächste Schritte

  • Last updated on