Microsoft Entra-SecOps für Consumerkonten
Benutzeridentität ist einer der wichtigsten Aspekte beim Schutz Ihrer Organisation und Daten. Dieser Artikel bietet einen Leitfaden zum Überwachen der Erstellung, Löschung und Nutzung von Konten. Im ersten Teil wird die Überwachung auf ungewöhnliche Kontoerstellung und -löschung behandelt. Der zweite Teil befasst sich mit der Überwachung ungewöhnlicher Kontonutzung.
Wenn Sie die Übersicht über Microsoft Entra-Sicherheitsvorgänge noch nicht gelesen haben, sollten Sie dies tun, ehe Sie fortfahren.
In diesem Artikel werden allgemeine Benutzerkonten behandelt. Informationen zu privilegierten Konten finden Sie unter „Sicherheitsvorgänge: privilegierte Konten“.
Definieren einer Baseline
Um anomales Verhalten zu ermitteln, müssen Sie zunächst definieren, wie normales und erwartetes Verhalten aussieht. Das Definieren des erwarteten Verhaltens für Ihre Organisation hilft Ihnen bei der Ermittlung, sobald unerwartetes Verhalten auftritt. Die Definition trägt auch dazu bei, die Menge falsch positiver Ergebnisse bei der Überwachungs- und Warnungsaktivität zu verringern.
Nachdem Sie definiert haben, was Sie erwarten, führen Sie eine Baselineüberwachung durch, um Ihre Erwartungen zu überprüfen. Mit diesen Informationen können Sie die Protokolle auf alles überwachen, was außerhalb der von Ihnen festgelegten Toleranzen liegt.
Verwenden Sie die Microsoft Entra-Überwachungsprotokolle, Microsoft Entra-Anmeldeprotokolle und Verzeichnisattribute als Datenquellen für Konten, die außerhalb normaler Prozesse erstellt wurden. Die folgenden Vorschläge sollen Ihnen eine Hilfestellung bei der Definition von „normal“ für Ihre Organisation geben.
Erstellung eines Benutzerkontos: Prüfen Sie Folgendes:
Strategie und Prinzipien für Tools und Prozesse, die zum Erstellen und Verwalten von Benutzerkonten verwendet werden. Gibt es beispielsweise Standardattribute, d. h. Formate, die auf Benutzerkontenattribute angewendet werden?
Genehmigte Quellen für die Kontoerstellung. Beispielsweise in Active Directory (AD), Microsoft Entra ID oder Personalmanagementsystemen wie Workday.
Warnungsstrategie für Konten, die außerhalb genehmigter Quellen erstellt wurden. Gibt es eine kontrollierte Liste der Organisationen, mit denen Ihre Organisation zusammenarbeitet?
Bereitstellung von Gastkonten und Warnungsparametern für Konten, die außerhalb der Berechtigungsverwaltung oder anderer normaler Prozesse erstellt wurden.
Strategie- und Warnungsparameter für Konten, die von einem Konto erstellt, geändert oder deaktiviert wurden, das keinem genehmigten Benutzeradministrator gehört.
Überwachungs- und Warnungsstrategie für Konten ohne Standardattribute, z. B. Mitarbeiter-ID oder Nichtbefolgung der Benennungskonventionen der Organisation.
Strategie, Prinzipien und Prozess zum Löschen und Aufbewahren von Konten.
Lokale Benutzerkonten: Prüfen Sie Folgendes für Konten, die mit Microsoft Entra Connect synchronisiert wurden:
Die Gesamtstrukturen, Domänen und Organisationseinheiten im Geltungsbereich der Synchronisierung. Wer sind die genehmigten Administratoren, die diese Einstellungen ändern können, und wie oft wird der Geltungsbereich überprüft?
Die Typen synchronisierter Konten. Beispiel: Benutzerkonten und/oder Dienstkonten.
Der Prozess zum Erstellen privilegierter lokaler Konten und zum Steuern der Synchronisierung dieses Kontotyps.
Der Prozess zum Erstellen lokaler Konten und zum Verwalten der Synchronisierung dieses Kontotyps.
Weitere Informationen zum Absichern und Überwachen lokaler Konten finden Sie unter Schützen von Microsoft 365 vor lokalen Angriffen.
Cloudbenutzerkonten: Prüfen Sie Folgendes:
Prozess zum Bereitstellen und Verwalten von Cloudkonten direkt in Microsoft Entra ID.
Prozess zum Bestimmen der Benutzertypen, für die Microsoft Entra-Cloudkonten bereitgestellt werden. Lassen Sie beispielsweise nur privilegierte Konten oder auch Benutzerkonten zu?
Prozess zum Erstellen und Verwalten einer Liste vertrauenswürdiger Personen und Prozesse, von denen das Erstellen und Verwalten von Cloudbenutzerkonten erwartet wird.
Prozess zum Erstellen und Verwalten einer Warnungsstrategie für nicht genehmigte Cloudkonten.
Zu untersuchende Protokolle
Zur Untersuchung und Überwachung verwenden Sie die folgenden Protokolldateien:
Im Azure-Portal können Sie die Microsoft Entra-Überwachungsprotokolle anzeigen und als CSV-Datei (Comma Separated Value) oder JSON-Datei (JavaScript Object Notation) herunterladen. Das Azure-Portal bietet mehrere Möglichkeiten zur Integration von Microsoft Entra-Protokollen in andere Tools, die eine umfassendere Automatisierung von Überwachung und Benachrichtigungen ermöglichen:
Microsoft Sentinel : Ermöglicht intelligente Sicherheitsanalysen auf Unternehmensebene, indem SIEM-Funktionen (Security Information and Event Management) zur Verfügung gestellt werden.
Sigma-Regeln: Sigma ist ein sich in Entwicklung befindender offener Standard zum Schreiben von Regeln und Vorlagen, die automatisierte Verwaltungstools zum Parsen von Protokolldateien verwenden können. Wenn Sigma-Vorlagen für unsere empfohlenen Suchkriterien vorhanden sind, verweist ein Link zum Sigma-Repository. Sigma-Vorlagen werden von Microsoft weder geschrieben, noch getestet und verwaltet. Das Repository und die Vorlagen werden von der weltweiten IT-Sicherheitscommunity erstellt und gesammelt.
Azure Monitor : ermöglicht die automatisierte Überwachung verschiedener Bedingungen und entsprechende Warnungen. Mit dem Tool können Arbeitsmappen erstellt werden, die sich zum Kombinieren von Daten aus verschiedenen Quellen eignen.
Azure Event Hubs mit Integration in ein SIEM-System: Microsoft Entra-Protokolle können über die Azure Event Hub-Integration in andere SIEM-Systeme integriert werden, z. B. in Splunk, ArcSight, QRadar und Sumo Logic.
Microsoft Defender-für-Cloud-Apps : Ermöglichen Ihnen die Erkennung und Verwaltung von Apps, die Steuerung von Apps und Ressourcen sowie die Überprüfung der Konformität Ihrer Cloud-Apps.
Sichern von Workloadidentitäten mit Identity Protection (Preview): Wird verwendet, um Risiken für Workloadidentitäten über das Anmeldeverhalten und Offlineindikatoren für eine Gefährdung zu erkennen.
Ein Großteil der Überwachung und zugehörigen Warnungen hängt von den Auswirkungen Ihrer Richtlinien für bedingten Zugriff ab. Sie können die Arbeitsmappe Erkenntnisse und Berichterstellung zum bedingten Zugriff verwenden, um die Auswirkungen einer oder mehrere Richtlinien für bedingten Zugriff auf Ihre Anmeldungen sowie die Ergebnisse von Richtlinien, einschließlich Gerätestatus, zu untersuchen. Diese Arbeitsmappe bietet Ihnen die Möglichkeit, eine Zusammenfassung anzuzeigen und die Auswirkungen über einen bestimmten Zeitraum zu ermitteln. Sie können mithilfe der Arbeitsmappe auch die Anmeldungen eines bestimmten Benutzers untersuchen.
Im restlichen Teil dieses Artikels wird beschrieben, was wir Ihnen zur Überwachung und für zugehörige Warnungen empfehlen, und zwar gegliedert nach der Art der Bedrohung. Wo es spezielle vordefinierte Lösungen gibt, verweisen wir auf diese oder stellen Beispiele im Anschluss an die Tabelle zur Verfügung. Andernfalls können Sie Warnungen mithilfe der oben genannten Tools erstellen.
Kontoerstellung
Eine anomale Kontoerstellung kann auf ein Sicherheitsproblem hinweisen. Kurzlebige, nicht den Benennungsstandards entsprechende und außerhalb normaler Prozesse erstellte Konten müssen untersucht werden.
Kurzlebige Konten
Das Erstellen und Löschen von Konten außerhalb der normalen Identitätsverwaltungsprozesse muss in Microsoft Entra ID überwacht werden. Kurzlebige Konten sind Konten, die innerhalb einer kurzen Zeitspanne erstellt und gelöscht werden. Diese Art der Kontoerstellung und des schnellen Löschens kann bedeuten, dass ein böswilliger Akteur versucht, die Erkennung zu vermeiden, indem er Konten erstellt, einsetzt und dann löscht.
Muster kurzlebiger Konten können darauf hindeuten, dass nicht genehmigte Personen oder Prozesse das Recht haben, Konten zu erstellen und zu löschen, die nicht den festgelegten Prozessen und Richtlinien entsprechen. Bei dieser Art von Verhalten werden sichtbare Marker aus dem Verzeichnis entfernt.
Wenn der Datenpfad der Kontoerstellung und -löschung nicht schnell ermittelt wird, sind die für die Untersuchung eines Incidents erforderlichen Informationen möglicherweise nicht mehr vorhanden. Beispielsweise können Konten erst gelöscht und dann endgültig aus dem Papierkorb gelöscht werden. Aktivitätsprotokolle werden 30 Tage aufbewahrt. Sie können Ihre Protokolle jedoch zur längerfristigen Aufbewahrung in Azure Monitor oder eine SIEM-Lösung (Security Information and Event Management) exportieren.
| Zu überwachende Elemente | Risikostufe | Hierbei gilt: | Filter/Unterfilter | Notizen |
|---|---|---|---|---|
| Ereignisse zur Erstellung und Löschung von Konten innerhalb eines engen Zeitrahmens. | Hoch | Microsoft Entra-Überwachungsprotokolle | Aktivität: Benutzer hinzufügen Status = Erfolg - und - Aktivität: Benutzer löschen Status = Erfolg |
Suchen Sie nach UPN-bezogenen Ereignissen (User Principal Name, Benutzerprinzipalname). Achten Sie auf Konten, die in weniger als 24 Stunden erstellt und dann gelöscht werden. Microsoft Sentinel-Vorlage |
| Konten, die von nicht genehmigten Benutzern oder Prozessen erstellt und gelöscht wurden. | Medium | Microsoft Entra-Überwachungsprotokolle | Von (Akteur) initiiert: BENUTZERPRINZIPALNAME - und - Aktivität: Benutzer hinzufügen Status = Erfolg und/oder Aktivität: Benutzer löschen Status = Erfolg |
Wenn es sich bei den Akteuren um nicht genehmigte Benutzer handelt, konfigurieren Sie das Senden einer Warnung. Microsoft Sentinel-Vorlage |
| Konten aus nicht genehmigten Quellen. | Medium | Microsoft Entra-Überwachungsprotokolle | Aktivität: Benutzer hinzufügen Status = Erfolg Ziele = BENUTZERPRINZIPALNAME |
Wenn der Eintrag nicht aus einer genehmigten Domäne stammt oder zu einer bekannten blockierten Domäne gehört, konfigurieren Sie das Senden einer Warnung. Microsoft Sentinel-Vorlage |
| Konten, die einer privilegierten Rolle zugewiesen sind. | Hoch | Microsoft Entra-Überwachungsprotokolle | Aktivität: Benutzer hinzufügen Status = Erfolg - und - Aktivität: Benutzer löschen Status = Erfolg - und - Aktivität: Mitglied zu Rolle hinzufügen Status = Erfolg |
Wenn das Konto einer Microsoft Entra-Rolle, einer Azure-Rolle oder einer privilegierten Gruppe zugewiesen ist, geben Sie eine Warnung aus, und priorisieren Sie die Untersuchung. Microsoft Sentinel-Vorlage Sigma-Regeln |
Sowohl privilegierte als auch nicht privilegierte Konten müssen überwacht und mit entsprechenden Warnungen versehen werden. Da privilegierte Konten jedoch über administrative Berechtigungen verfügen, müssen sie in Ihren Überwachungs-, Warn- und Reaktionsprozessen höhere Priorität haben.
Konten, die Benennungsrichtlinien nicht befolgen
Benutzerkonten, die Benennungsrichtlinien nicht befolgen, wurden möglicherweise unter Umgehung von Organisationsrichtlinien erstellt.
Eine bewährte Methode ist eine Benennungsrichtlinie für Benutzerobjekte. Eine Benennungsrichtlinie erleichtert die Verwaltung und sorgt für Konsistenz. Die Richtlinie kann auch helfen zu ermitteln, wann Benutzer außerhalb genehmigter Prozesse erstellt wurden. Ein böswilliger Akteur ist sich möglicherweise nicht über Ihre Namensstandards im Klaren, was die Erkennung eines Kontos, das außerhalb Ihrer Organisationsprozesse bereitgestellt wurde, erleichtern kann.
In Organisationen gibt es in der Regel bestimmte Formate und Attribute, die für die Erstellung von Benutzer- oder privilegierten Konten verwendet werden. Zum Beispiel:
UPN von Administratorkonten = ADM_firstname.lastname@tenant.onmicrosoft.com
UPN von Benutzerkonten = Firstname.Lastname@contoso.com
Benutzerkonten verfügen häufig über ein Attribut, das einen realen Benutzer identifiziert. Beispiel: EMPID = XXXNNN. Verwenden Sie die folgenden Vorschläge zum Definieren, was normal für Ihre Organisation ist, und beim Festlegen einer Baseline für Protokolleinträge, wenn Konten nicht die Namenskonvention befolgen:
Konten, die nicht der Benennungskonvention entsprechen. Beispielsweise
nnnnnnn@contoso.comim Vergleich zufirstname.lastname@contoso.com.Konten, deren Standardattribute nicht ausgefüllt sind oder die nicht das richtige Format haben. Beispielsweise fehlende gültige Mitarbeiter-ID.
| Zu überwachende Elemente | Risikostufe | Hierbei gilt: | Filter/Unterfilter | Notizen |
|---|---|---|---|---|
| Benutzerkonten, bei denen erwartete Attribute nicht definiert sind. | Niedrig | Microsoft Entra-Überwachungsprotokolle | Aktivität: Benutzer hinzufügen Status = Erfolg |
Suchen Sie nach Konten, bei denen Ihre Standardattribute entweder NULL sind oder das falsche Format haben. Beispiel: EmployeeID Microsoft Sentinel-Vorlage |
| Benutzerkonten, die mit einem falschen Benennungsformat erstellt wurden. | Niedrig | Microsoft Entra-Überwachungsprotokolle | Aktivität: Benutzer hinzufügen Status = Erfolg |
Suchen Sie nach Konten mit einem UPN, der nicht Ihrer Benennungsrichtlinie entspricht. Microsoft Sentinel-Vorlage |
| Privilegierte Konten, die nicht der Benennungsrichtlinie entsprechen. | Hoch | Azure-Abonnement | Auflisten von Azure-Rollenzuweisungen mithilfe des Azure-Portals – Azure RBAC | Listen Sie Rollenzuweisungen für Abonnements auf, und warnen Sie, wenn der Anmeldename nicht dem Format Ihrer Organisation entspricht. Beispiel: ADM_ als Präfix. |
| Privilegierte Konten, die nicht der Benennungsrichtlinie entsprechen. | Hoch | Microsoft Entra Verzeichnis | Auflisten von Microsoft Entra-Rollenzuweisungen | Listen Sie Rollenzuweisungen für Microsoft Entra-Rollen auf, und geben Sie eine Warnung aus, wenn der UPN nicht dem Format Ihrer Organisation entspricht. Beispiel: ADM_ als Präfix. |
Weitere Informationen zur Analyse finden Sie unter:
Microsoft Entra-Überwachungsprotokolle: Analysieren von Textdaten in Azure Monitor-Protokollen
Azure-Abonnements: Auflisten von Azure-Rollenzuweisungen mit Azure PowerShell
Microsoft Entra ID: Auflisten von Microsoft Entra Rollenzuweisungen
Außerhalb normaler Prozesse erstellte Konten
Standardprozesse zum Erstellen von Benutzern und privilegierten Konten sind wichtig, damit Sie den Lebenszyklus von Identitäten sicher steuern können. Wenn Benutzer außerhalb eingerichteter Prozesse bereitgestellt werden bzw. ihre Bereitstellung aufgehoben wird, kann dies zu Sicherheitsrisiken führen. Ein Betrieb außerhalb etablierter Prozesse kann auch Probleme bei der Identitätsverwaltung verursachen. Mögliche Risiken:
Benutzer- und privilegierte Konten unterliegen möglicherweise nicht den Richtlinien der Organisation. Dies kann zu einer größeren Angriffsfläche für Konten führen, die nicht ordnungsgemäß verwaltet werden.
Es wird schwieriger zu erkennen, wenn böswillige Akteure Konten für böswillige Zwecke erstellen. Wenn gültige Konten außerhalb etablierter Verfahren erstellt werden, wird es schwieriger zu erkennen, wann für böswillige Zwecke Konten erstellt oder Berechtigungen geändert werden.
Es wird empfohlen, Benutzer- und privilegierte Konten nur gemäß Ihren Organisationsrichtlinien zu erstellen. Beispielsweise sollte ein Konto gemäß den ordnungsgemäßen Benennungsstandards, Organisationsinformationen und im Rahmen der entsprechenden Identitätsgovernance erstellt werden. Organisationen sollten streng kontrollieren, wer Rechte zum Erstellen, Verwalten und Löschen von Identitäten hat. Rollen zur Erstellung dieser Konten sollten streng geregelt werden, und die Rechte sollten nur unter Befolgung eines festgelegten Workflows zur Genehmigung und zum Bezug dieser Berechtigungen verfügbar sein.
| Zu überwachende Elemente | Risikostufe | Hierbei gilt: | Filter/Unterfilter | Notizen |
|---|---|---|---|---|
| Benutzerkonten, die von nicht genehmigten Benutzern oder Prozessen erstellt und gelöscht wurden. | Medium | Microsoft Entra-Überwachungsprotokolle | Aktivität: Benutzer hinzufügen Status = Erfolg und/oder Aktivität: Benutzer löschen Status = Erfolg - und - Von (Akteur) initiiert: BENUTZERPRINZIPALNAME |
Warnung bei Konten, die von nicht genehmigten Benutzern oder Prozessen erstellt wurden. Priorisieren Sie Konten, die mit erhöhten Berechtigungen erstellt wurden. Microsoft Sentinel-Vorlage |
| Benutzerkonten, die von nicht genehmigten Quellen erstellt oder gelöscht wurden. | Medium | Microsoft Entra-Überwachungsprotokolle | Aktivität: Benutzer hinzufügen Status = Erfolg Oder Aktivität: Benutzer löschen Status = Erfolg - und - Ziele = BENUTZERPRINZIPALNAME |
Warnung, wenn die Domäne nicht genehmigt oder als blockierte Domäne bekannt ist. |
Ungewöhnliche Anmeldungen
Fehler bei der Benutzerauthentifizierung sind normal. Aber das Erkennen von Mustern oder Häufungen von Fehlern kann ein Hinweis darauf sein, dass mit der Identität eines Benutzers etwas nicht stimmt. Dies kann beispielsweise bei Kennwortspray- oder Brute-Force-Angriffen oder kompromittierten Benutzerkonten der Fall sein. Eine entsprechende Überwachung und Warnung ist bei Auftreten von Mustern unbedingt erforderlich. Dadurch wird sichergestellt, dass Sie die Benutzer und Daten in Ihrer Organisation schützen können.
Eine Erfolgsmeldung scheint zu bedeuten, dass alles in Ordnung ist. Sie kann jedoch auch bedeuten, dass ein böswilliger Akteur erfolgreich auf einen Dienst zugegriffen hat. Die Überwachung erfolgreicher Anmeldungen hilft Ihnen dabei, Benutzerkonten aufzuspüren, die zwar Zugriff erhalten, aber eigentlich keinen Zugriff haben sollten. Erfolgreiche Benutzerauthentifizierungen sind normale Einträge in Microsoft Entra-Anmeldeprotokollen. Wir empfehlen eine Überwachung auf und Warnung bei auftretenden Mustern. Dadurch wird sichergestellt, dass Sie die Benutzerkonten und Daten in Ihrer Organisation schützen können.
Sobald Sie eine Protokollüberwachungs- und Warnstrategie entwerfen und umsetzen möchten, sollten Sie die Tools im Azure-Portal berücksichtigen. Mit Azure AD Identity Protection können Sie Erkennung, Schutz und Korrektur identitätsbasierter Risiken automatisieren. Identity Protection nutzt mit Daten gefütterte Machine Learning- und heuristische Systeme, um Risiken zu erkennen und Benutzern und Anmeldungen einen Risikopunktwert zuzuweisen. Kunden können Richtlinien auf Grundlage einer Risikostufe konfigurieren, um Zugriff zuzulassen oder zu verweigern oder dem Benutzer die Möglichkeit zu geben, ein Risiko auf sichere Weise selbst zu beseitigen. Die folgenden Identity Protection-Risikoerkennungen informieren derzeit über Risikostufen:
| Zu überwachende Elemente | Risikostufe | Hierbei gilt: | Filter/Unterfilter | Notizen |
|---|---|---|---|---|
| Erkennung von Benutzerrisiken: kompromittierte Anmeldeinformationen | Hoch | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: kompromittierte Anmeldeinformationen API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Microsoft Entra Threat Intelligence-Benutzerrisikoerkennung | Hoch | Microsoft Entra-Risikoerkennungsprotokolle | UX: Microsoft Entra Threat Intelligence API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Risikoerkennung: Anmeldung mit anonymer IP-Adresse | Varies | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: anonyme IP-Adresse API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Risikoerkennung: ungewöhnlicher Ortswechsel bei der Anmeldung | Varies | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: ungewöhnlicher Ortswechsel API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Anomales Token | Varies | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: anomales Token API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Risikoerkennung: mit Schadsoftware verknüpfte IP-Adresse für Anmeldung | Varies | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: mit Schadsoftware verknüpfte IP-Adresse API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Risikoerkennung: Anmeldung bei verdächtigem Browser | Varies | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: verdächtiger Browser API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Risikoerkennung: ungewöhnliche Anmeldeeigenschaften bei der Anmeldung | Varies | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: ungewöhnliche Anmeldeeigenschaften API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Risikoerkennung: Anmeldung mit schädlicher IP-Adresse | Varies | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: schädliche IP-Adresse API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Risikoerkennung: verdächtige Regeln zur Posteingangsänderung | Varies | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: verdächtige Regeln zur Posteingangsänderung API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Risikoerkennung: Kennwort-Spray-Anmeldung | Hoch | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: Kennwortspray API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Risikoerkennung: unmöglicher Ortswechsel bei der Anmeldung | Varies | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: unmöglicher Ortswechsel API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Neue Anmelderisikoerkennung für Land/Region | Varies | Microsoft Entra-Risikoerkennungsprotokolle | UX: Neues Land/Neue Region API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Risikoerkennung: Aktivität über anonyme IP-Adresse | Varies | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: Aktivität über anonyme IP-Adresse API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Risikoerkennung: verdächtige Weiterleitung des Posteingangs | Varies | Microsoft Entra-Risikoerkennungsprotokolle | Benutzererfahrung: verdächtige Weiterleitung des Posteingangs API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
| Microsoft Entra Threat Intelligence-Bedrohungserkennung für Anmeldungen | Hoch | Microsoft Entra-Risikoerkennungsprotokolle | UX: Microsoft Entra Threat Intelligence API: Weitere Informationen finden Sie unter riskDetection-Ressourcentyp: Microsoft Graph |
Weitere Informationen finden Sie unter Was bedeutet Risiko? Microsoft Entra ID Protection Sigma-Regeln |
Weitere Informationen finden Sie unter Was ist Identity Protection?.
Suchschwerpunkte
Konfigurieren Sie die Überwachung der Daten in den Microsoft Entra-Anmeldeprotokollen, um sicherzustellen, dass Warnungen ausgegeben und die Sicherheitsrichtlinien Ihrer Organisation eingehalten werden. Einige Beispiele:
Fehlgeschlagene Authentifizierungen: Wie alle Menschen machen wir auch einmal Fehler bei der Kennworteingabe. Viele fehlgeschlagene Authentifizierungen können jedoch darauf hindeuten, dass ein böswilliger Akteur versucht, sich Zugriff zu verschaffen. Angriffe sind unterschiedlich intensiv und können von wenigen Versuchen pro Stunde bis hin zu einer deutlich höheren Rate reichen. Bei einem Kennwort-Spray-Angriff wird versucht, sich mit den meistverwendeten Kennwörtern bei vielen verschiedenen Konten anzumelden, während bei einem Brute-Force-Angriff sehr viele Kennwörter für gezielt ausgewählte Konten ausprobiert werden.
Unterbrochene Authentifizierungen: Eine Unterbrechung stellt in Microsoft Entra ID eine Einschaltung eines Prozesses zur Erfüllung der Authentifizierungsanforderungen dar, z. B. beim Erzwingen einer Steuerung in einer Richtlinie für bedingten Zugriff. Dies ist ein normales Ereignis und kann vorkommen, wenn Anwendungen nicht ordnungsgemäß konfiguriert sind. Wenn jedoch viele Unterbrechungen für ein Benutzerkonto erkennbar werden, kann dies darauf hindeuten, dass mit diesem Konto etwas nicht stimmt.
- Wenn Sie beispielsweise in den Anmeldeprotokollen nach einem Benutzer gefiltert haben und eine große Anzahl von Anmeldungen mit „Status = Unterbrochen“ und „Bedingter Zugriff = Fehler“ sehen. Bei genauerer Betrachtung könnten die Authentifizierungsdetails zeigen, dass das Kennwort zwar stimmt, aber eine strenge Authentifizierung erforderlich ist. Dies kann bedeuten, dass der Benutzer die Multi-Faktor-Authentifizierung (MFA) nicht abschließt, was wiederum bedeuten könnte, dass das Kennwort des Benutzers kompromittiert ist und der böswillige Akteur nicht in der Lage ist, die MFA abzuschließen.
Intelligente Sperrung: Microsoft Entra ID bietet einen intelligenten Sperrdienst, mit dem das Konzept vertrauter und nicht vertrauter Orte in den Authentifizierungsprozess eingeführt wurde. Ein Benutzerkonto, das einen vertrauten Ort besucht, kann sich erfolgreich authentifizieren, während ein böswilliger Akteur, der am selben Ort nicht vertraut ist, nach mehreren Versuchen gesperrt wird. Suchen Sie nach Konten, die gesperrt wurden, und untersuchen Sie sie weiter.
Änderungen an IP-Adressen: Es ist normal, dass Benutzeraktivitäten von unterschiedlichen IP-Adressen stammen. Der Zero-Trust-Ansatz steht jedoch unter dem Motto „Niemals vertrauen, immer überprüfen“. Das Erkennen einer großen Anzahl von IP-Adressen und fehlgeschlagener Anmeldungen kann ein Hinweis auf einen Eindringversuch sein. Suchen Sie nach einem Muster vieler fehlgeschlagener Authentifizierungen, die von mehreren IP-Adressen stammen. Beachten Sie, dass VPN-Verbindungen (virtuelles privates Netzwerk) falsch positive Ergebnisse verursachen können. Unabhängig von den Herausforderungen wird empfohlen, auf Änderungen an IP-Adressen zu achten und nach Möglichkeit Microsoft Entra ID Protection einzusetzen, um diese Risiken automatisch zu erkennen und zu entschärfen.
Orte: Im Allgemeinen erwarten Sie, dass sich ein Benutzerkonto am gleichen geografischen Ort befindet. Sie erwarten auch Anmeldungen von Orten, an denen Sie Mitarbeiter oder Geschäftsbeziehungen haben. Wenn die Anmeldung des Benutzerkontos von einem anderen internationalen Ort aus in kürzerer Zeit erfolgt, als für die Reise dorthin erforderlich wäre, kann dies ein Hinweis auf Missbrauch des Benutzerkontos sein. Beachten Sie, dass VPNs False Positives verursachen können. Es wird empfohlen, die Anmeldung von Benutzerkonten von geografisch entfernten Orten aus zu überwachen und nach Möglichkeit Microsoft Entra ID Protection einzusetzen, um diese Risiken automatisch zu erkennen und zu entschärfen.
Für diesen Risikobereich empfehlen wir, Standardbenutzerkonten und privilegierte Konten zu überwachen, wobei die Untersuchung privilegierter Konten Vorrang hat. Privilegierte Konten sind die wichtigsten Konten in jedem Microsoft Entra-Mandanten. Einen spezifischen Leitfaden für privilegierte Konten finden Sie unter „Sicherheitsvorgänge: privilegierte Konten“.
Vorgehensweise zum Erkennen eines Ausfalls von Azure Storage
Sie nutzen Microsoft Entra ID Protection und die Microsoft Entra-Anmeldeprotokolle, um Bedrohungen zu erkennen, die durch ungewöhnliche Anmeldungsmerkmale gekennzeichnet sind. Informationen zu Identity Protection finden Sie unter Was ist Identity Protection?. Sie können die Daten auch zu Überwachungs- und Warnungszwecken in Azure Monitor oder ein SIEM-System replizieren. Um den Normalzustand für Ihre Umgebung zu definieren und eine Baseline festzulegen, bestimmen Sie Folgendes:
die Parameter, die Sie für Ihren Benutzerstamm als normal betrachten.
die durchschnittliche Anzahl von Versuchen der Kennworteingabe über einen Zeitraum, bevor der Benutzer sich an den Helpdesk wendet oder eine Self-Service-Kennwortzurücksetzung durchführt.
die Anzahl fehlgeschlagener Versuche, die Sie vor einer Warnung zulassen möchten, und ob diese für Benutzerkonten und privilegierte Konten unterschiedlich sein soll.
die Anzahl von MFA-Versuchen, die Sie vor einer Warnung zulassen möchten, und ob diese für Benutzerkonten und privilegierte Konten unterschiedlich sein soll.
ob eine Legacyauthentifizierung aktiviert ist und Ihre Roadmap für die Einstellung ihrer Nutzung.
ob die bekannten ausgehenden IP-Adressen zu Ihrer Organisation gehören.
die Länder/Regionen, in denen Ihre Benutzer arbeiten.
ob es Gruppen von Benutzern gibt, die innerhalb eines Netzstandorts oder in einem Land/einer Region stationär bleiben.
Geben Sie alle anderen Indikatoren für ungewöhnliche Anmeldungen an, die für Ihre Organisation spezifisch sind. Beispiele hierfür sind Tage oder Zeiten der Woche oder des Jahres, an denen der Betrieb in Ihrer Organisation ruht.
Wenn Sie festgelegt haben, was für die Konten in Ihrer Umgebung normal ist, sollten Sie die folgende Liste berücksichtigen, um zu bestimmen, welche Szenarien Sie überwachen und für welche Sie eine Warnung ausgeben möchten, und um Ihre Warnungen zu optimieren.
Ist eine Überwachung und Warnung erforderlich, wenn Identity Protection konfiguriert ist?
Gelten strengere Bedingungen für privilegierte Konten, die Sie zur Überwachung und Warnung nutzen können? Beispielsweise kann die Anforderung privilegierter Konten nur von vertrauenswürdigen IP-Adressen erfolgen.
Sind die von Ihnen festgelegten Baselines zu aggressiv? Zu viele Warnungen können dazu führen, dass Warnungen ignoriert oder übersehen werden.
Konfigurieren Sie Identity Protection, um sicherzustellen, dass Schutz so besteht, dass die Richtlinien Ihrer Sicherheitsbaseline erfüllt werden. Beispiel: Blockieren von Benutzern, wenn das Risiko hoch ist. Diese Risikostufe gibt mit einem hohen Maß an Konfidenz an, dass ein Benutzerkonto kompromittiert ist. Weitere Informationen zum Einrichten von Richtlinien für Anmelde- und Benutzerrisiken finden Sie unter Identity Protection-Richtlinien. Weitere Informationen zum Einrichten des bedingten Zugriffs finden Sie unter Bedingter Zugriff: Risikobasierter bedingter Zugriff beim Anmelden.
Die folgenden Einträge sind nach Auswirkung und Schweregrad in der Reihenfolge ihrer Bedeutung aufgeführt.
Überwachen externer Benutzeranmeldungen
| Zu überwachende Elemente | Risikostufe | Hierbei gilt: | Filter/Unterfilter | Hinweise |
|---|---|---|---|---|
| Benutzer*innen authentifizieren sich bei anderen Microsoft Entra-Mandanten. | Niedrig | Microsoft Entra-Anmeldeprotokoll | Status = Erfolg Ressourcenmandanten-ID != Basismandanten-ID |
Erkennt, wenn sich Benutzer*innen erfolgreich bei einem anderen Microsoft Entra-Mandanten mit einer Identität im Mandanten Ihrer Organisation authentifiziert haben. Warnung, wenn die Ressourcenmandanten-ID nicht mit der Basismandanten-ID identisch ist Microsoft Sentinel-Vorlage Sigma-Regeln |
| Benutzerstatus von „Gast“ in „Mitglied“ geändert | Medium | Microsoft Entra-Überwachungsprotokolle | Aktivität: Benutzer aktualisieren Kategorie: Benutzerverwaltung Benutzertyp (UserType) von „Gast“ in „Mitglied“ geändert |
Überwachen von und Warnen bei Änderung des Benutzertyps von „Gast“ in „Mitglied“ Wurde dieses Verhalten erwartet? Microsoft Sentinel-Vorlage Sigma-Regeln |
| Gastbenutzer, die von nicht genehmigten Einladenden zum Mandanten eingeladen wurden | Medium | Microsoft Entra-Überwachungsprotokolle | Aktivität: Externe Benutzer einladen Kategorie: Benutzerverwaltung Initiiert von (Akteur): Benutzerprinzipalname |
Überwachen von und Warnen bei nicht genehmigten Akteuren, die externe Benutzer einladen Microsoft Sentinel-Vorlage Sigma-Regeln |
Überwachung auf fehlgeschlagene ungewöhnliche Anmeldungen
| Zu überwachende Elemente | Risikostufe | Hierbei gilt: | Filter/Unterfilter | Notizen |
|---|---|---|---|---|
| Fehlgeschlagene Anmeldeversuche. | Mittel, falls isolierter Incident Hoch, wenn zahlreiche Konten das gleiche Muster oder eine VIP aufweisen |
Microsoft Entra-Anmeldeprotokoll | Status = fehlgeschlagen -und- Anmeldefehlercode 50126: Fehler beim Überprüfen der Anmeldeinformationen aufgrund eines ungültigen Benutzernamens oder Kennworts. |
Legen Sie einen Basisschwellenwert fest, den Sie dann überwachen und entsprechend dem Verhalten Ihres Unternehmens anpassen können, um zu verhindern, dass Fehlwarnungen generiert werden. Microsoft Sentinel-Vorlage Sigma-Regeln |
| Intelligente Sperrereignisse. | Mittel, falls isolierter Incident Hoch, wenn zahlreiche Konten das gleiche Muster oder eine VIP aufweisen |
Microsoft Entra-Anmeldeprotokoll | Status = fehlgeschlagen - und - Anmeldefehlercode = 50053: IdsLocked |
Legen Sie einen Basisschwellenwert fest, den Sie dann überwachen und entsprechend dem Verhalten Ihres Unternehmens anpassen können, um zu verhindern, dass Fehlwarnungen generiert werden. Microsoft Sentinel-Vorlage Sigma-Regeln |
| Interrupts | Mittel, falls isolierter Incident Hoch, wenn zahlreiche Konten das gleiche Muster oder eine VIP aufweisen |
Microsoft Entra-Anmeldeprotokoll | 500121, Fehler bei der Authentifizierung während Anforderung einer strengen Authentifizierung. Oder 50097, Geräteauthentifizierung erforderlich, oder 50074, Strenge Authentifizierung erforderlich. Oder 50155, DeviceAuthenticationFailed Oder 50158, ExternalSecurityChallenge:Externe Sicherheitsabfrage nicht erfüllt Oder 53003 und Fehlerursache = Durch bedingten Zugriff blockiert |
Überwachen und Senden von Warnungen bei Unterbrechungen Legen Sie einen Basisschwellenwert fest, den Sie dann überwachen und entsprechend dem Verhalten Ihres Unternehmens anpassen können, um zu verhindern, dass Fehlwarnungen generiert werden. Microsoft Sentinel-Vorlage Sigma-Regeln |
Die folgenden Einträge sind nach Auswirkung und Schweregrad in der Reihenfolge ihrer Bedeutung aufgeführt.
| Zu überwachende Elemente | Risikostufe | Hierbei gilt: | Filter/Unterfilter | Notizen |
|---|---|---|---|---|
| Betrugswarnungen bei mehrstufiger Authentifizierung (Multi-Factor Authentication, MFA). | Hoch | Microsoft Entra-Anmeldeprotokoll | Status = fehlgeschlagen - und - Details = MFA verweigert |
Überwachen und bei jedem Eintrag warnen. Microsoft Sentinel-Vorlage Sigma-Regeln |
| Fehlgeschlagene Authentifizierungen aus Ländern/Regionen, in denen Sie nicht tätig sind. | Medium | Microsoft Entra-Anmeldeprotokoll | Standort = <Nicht genehmigter Standort> | Überwachen und bei jedem Eintrag warnen. Microsoft Sentinel-Vorlage Sigma-Regeln |
| Fehlgeschlagene Authentifizierungen für Legacy- oder nicht verwendete Protokolle | Medium | Microsoft Entra-Anmeldeprotokoll | Status = Fehler - und - Client-App = andere Clients, POP, IMAP, MAPI, SMTP, ActiveSync |
Überwachen und bei jedem Eintrag warnen. Microsoft Sentinel-Vorlage Sigma-Regeln |
| Durch bedingten Zugriff blockierte Fehler. | Medium | Microsoft Entra-Anmeldeprotokoll | Fehlercode = 53003 -und- Fehlerursache = Durch bedingten Zugriff blockiert |
Überwachen und bei jedem Eintrag warnen. Microsoft Sentinel-Vorlage Sigma-Regeln |
| Vermehrte fehlgeschlagene Authentifizierungen beliebiger Art. | Medium | Microsoft Entra-Anmeldeprotokoll | Erfassen Sie die Zunahme von Fehlern in allen Bereichen. Beispiel: Die Gesamtanzahl der Fehler heute ist >10 % als am gleichen Tag der Vorwoche. | Wenn Sie keinen Schwellenwert festgelegt haben, überwachen und warnen Sie, wenn Fehler um 10 % oder mehr zunehmen. Microsoft Sentinel-Vorlage |
| Die Authentifizierung erfolgt zu Zeiten und Tagen in der Woche, wenn in Ländern/Regionen kein normaler Geschäftsbetrieb herrscht. | Niedrig | Microsoft Entra-Anmeldeprotokoll | Erfassen Sie die interaktive Authentifizierung, die außerhalb der normalen Geschäftstage/-zeiten erfolgt. Status = Erfolg - und - Standort = <Standort> - und - Tag/Uhrzeit = <außerhalb der normalen Arbeitszeiten> |
Überwachen und bei jedem Eintrag warnen. Microsoft Sentinel-Vorlage |
| Konto für Anmeldungen deaktiviert/blockiert | Niedrig | Microsoft Entra-Anmeldeprotokoll | Status = Fehler - und - Fehlercode = 50057, Das Benutzerkonto ist deaktiviert. |
Dies kann darauf hindeuten, dass jemand versucht, sich Zugriff auf ein Konto zu verschaffen, nachdem er eine Organisation verlassen hat. Obwohl das Konto blockiert ist, ist es wichtig, diese Aktivität zu protokollieren und eine Warnung auszugeben. Microsoft Sentinel-Vorlage Sigma-Regeln |
Überwachung auf erfolgreiche ungewöhnliche Anmeldungen
| Zu überwachende Elemente | Risikostufe | Hierbei gilt: | Filter/Unterfilter | Notizen |
|---|---|---|---|---|
| Authentifizierungen privilegierter Konten außerhalb der erwarteten Kontrollmechanismen. | Hoch | Microsoft Entra-Anmeldeprotokoll | Status = Erfolg - und - UserPricipalName = <Administratorkonto> - und - Standort = <Nicht genehmigter Standort> - und - IP-Adresse = <Nicht genehmigte IP-Adresse> Geräteinformationen = <Nicht genehmigter Browser, nicht genehmigtes Betriebssystem> |
Überwachen und warnen Sie bei erfolgreicher Authentifizierung für privilegierte Konten außerhalb der erwarteten Kontrollmechanismen. Drei allgemeine Kontrollmechanismen sind aufgeführt. Microsoft Sentinel-Vorlage Sigma-Regeln |
| Wenn nur eine einstufige Authentifizierung erforderlich ist. | Niedrig | Microsoft Entra-Anmeldeprotokoll | Status = Erfolg Authentifizierungsanforderung = einstufige Authentifizierung |
Führen Sie in regelmäßigen Abständen eine Überwachung aus, und stellen Sie sicher, dass das erwartete Verhalten auftritt. Sigma-Regeln |
| Ermitteln Sie privilegierte Konten, die nicht für MFA registriert sind. | Hoch | Azure Graph-API | Abfrage von IsMFARegistered ist für Administratorkonten FALSE. CredentialUserRegistrationDetails auflisten – Microsoft Graph-Betaversion |
Überwachen und untersuchen Sie, um zu ermitteln, ob Absicht oder ein Versehen vorliegt. |
| Erfolgreiche Authentifizierungen aus Ländern/Regionen, in denen Ihre Organisation nicht tätig ist. | Medium | Microsoft Entra-Anmeldeprotokoll | Status = Erfolg Standort = <Nicht genehmigtes Land/nicht genehmigte Region> |
Überwachen und warnen Sie bei Einträgen, die nicht den von Ihnen angegebenen Ortsnamen entsprechen. Sigma-Regeln |
| Erfolgreiche Authentifizierung, Sitzung durch bedingten Zugriff blockiert. | Medium | Microsoft Entra-Anmeldeprotokoll | Status = Erfolg -und- Fehlercode 53003 – Fehlerursache: Durch bedingten Zugriff blockiert |
Überwachen und untersuchen Sie, wenn die Authentifizierung zwar erfolgreich ist, die Sitzung aber durch den bedingten Zugriff blockiert wird. Microsoft Sentinel-Vorlage Sigma-Regeln |
| Erfolgreiche Authentifizierung, nachdem Sie die Legacyauthentifizierung deaktiviert haben. | Medium | Microsoft Entra-Anmeldeprotokoll | Status = Erfolg -und- Client-App = andere Clients, POP, IMAP, MAPI, SMTP, ActiveSync |
Wenn Ihre Organisation die Legacyauthentifizierung deaktiviert hat, überwachen und warnen Sie, wenn eine erfolgreiche Legacyauthentifizierung erfolgt ist. Microsoft Sentinel-Vorlage Sigma-Regeln |
Wir empfehlen Ihnen, regelmäßig die Authentifizierungen für Anwendungen mit mittleren (MBI) und erheblichen Geschäftsauswirkungen (HBI) zu überprüfen, bei denen nur eine einstufige Authentifizierung erforderlich ist. Stellen Sie jeweils fest, ob eine einstufige Authentifizierung erwartet wurde oder nicht. Überprüfen Sie außerdem basierend auf dem Ort, ob die Authentifizierung erfolgreich oder zu unerwarteten Zeiten erfolgreich war.
| Zu überwachende Elemente | Risikostufe | Hierbei gilt: | Filter/Unterfilter | Notizen |
|---|---|---|---|---|
| Authentifizierungen bei MBI- und HBI-Anwendungen mit einstufiger Authentifizierung. | Niedrig | Microsoft Entra-Anmeldeprotokoll | Status = Erfolg - und - Anwendungs-ID = <HBI-App> - und - Authentifizierungsanforderung = einstufige Authentifizierung. |
Überprüfen Sie, ob diese Konfiguration beabsichtigt ist. Sigma-Regeln |
| Authentifizierung zu Zeiten und Tagen der Woche oder des Jahres, wenn in Ländern/Regionen kein normaler Geschäftsbetrieb herrscht. | Niedrig | Microsoft Entra-Anmeldeprotokoll | Erfassen Sie die interaktive Authentifizierung, die außerhalb der normalen Geschäftstage/-zeiten erfolgt. Status = Erfolg Standort = <Standort> Datum/Uhrzeit = <außerhalb der normalen Arbeitszeiten> |
Überwachen und benachrichtigen Sie bei Authentifizierungen zu Zeiten und Tagen der Woche oder des Jahres, wenn in Ländern/Regionen kein normaler Geschäftsbetrieb herrscht. Sigma-Regeln |
| Messbarer Anstieg erfolgreicher Anmeldungen. | Niedrig | Microsoft Entra-Anmeldeprotokoll | Erfassen Sie eine Zunahme der erfolgreichen Authentifizierung in allen Bereichen. Beispiel: Die Gesamtanzahl erfolgreicher Authentifizierungen heute ist >10 % als am gleichen Tag der Vorwoche. | Wenn Sie keinen Schwellenwert festgelegt haben, überwachen und warnen Sie, wenn erfolgreiche Authentifizierungen um 10 % oder mehr zunehmen. Microsoft Sentinel-Vorlage Sigma-Regeln |
Nächste Schritte
Weitere Informationen finden Sie in den folgenden Artikeln im Leitfaden zu Sicherheitsvorgängen:
Übersicht zu Microsoft Entra-SecOps
Sicherheitsvorgänge für Consumerkonten
Sicherheitsvorgänge für privilegierte Konten
Sicherheitsvorgänge für Privileged Identity Management
Sicherheitsvorgänge für Anwendungen