Wer hat Identity Settings geaendert? Audit Logs pruefen

In Identity hat sich etwas geaendert.

Ein Benutzer wurde aktualisiert.

Eine Gruppenmitgliedschaft wurde geaendert.

Eine App Permission ist aufgetaucht.

Eine Conditional-Access-Policy wurde bearbeitet.

Die Frage ist:

Wer hat es geaendert?

Microsoft Entra Audit Logs sind der erste Ort, an dem du nachsiehst.

In diesem Beispiel:

• CloudTrips Identity Admin muss eine Identity-Aenderung untersuchen
• Audit Logs zeigen Activity, Actor, Target, Result und Modified Properties
• Correlation Details helfen, wenn das Event eskaliert werden muss

Was Audit Logs beantworten

Audit Logs helfen bei diesen Fragen:

Wer hat die Aenderung ausgefuehrt?
Welche Activity wurde ausgefuehrt?
Welches Objekt wurde geaendert?
Wann ist es passiert?
War es erfolgreich oder fehlgeschlagen?
Welche Properties wurden geaendert?
Wurde die Aenderung von einem User, einer App oder einem Service Principal gemacht?

Nutze Audit Logs, wenn es um Konfigurations- oder Directory-Aenderungen geht.

Nutze Sign-in Logs, wenn es um Login-Versuche geht.

Audit Logs oeffnen

Gehe zu:

Entra ID > Monitoring & health > Audit logs

Diese Seite listet Directory- und Identity-Management-Aktivitaeten.

Nach Zeit und Activity filtern

Starte mit dem Zeitfenster.

Fuege dann Filter hinzu wie:

Correlation ID
Status
Target
Initiated by
User agent

Wenn du zum Beispiel eine Conditional-Access-Aenderung untersuchst, filtere nach dem Target Policy Name oder nach dem Admin unter Initiated by.

Audit Event oeffnen

Waehle die Audit-Log-Zeile aus, die zur Aenderung passt.

Das Details Panel ist der Ort, an dem du das Event bestaetigst.

Achte zuerst auf:

Activity
Target(s)
Modified properties

Erkennen, wer die Aenderung gemacht hat

Pruefe:

Activity

Der Activity Abschnitt zeigt Werte wie:

Activity type
Correlation ID
Category
Status
Initiated by (actor)

Activity type zeigt dir, welche Operation passiert ist.

Verwende Initiated by (actor), um zu erkennen, wer oder was die Aenderung gestartet hat.

Der Actor kann eine Person, App, Service Principal, Managed Identity oder ein Microsoft Service sein.

Erkennen, was geaendert wurde

Pruefe:

Target(s)

Das zeigt das Objekt, das geaendert wurde.

Beispiele:

User
Group
Application
Service principal
Conditional Access policy
Administrative unit
Role assignment

Wenn mehrere Targets erscheinen, pruefe jedes davon, bevor du entscheidest, was passiert ist.

Modified Properties pruefen

Oeffne:

Modified properties

Das ist oft der wichtigste Teil.

Achte auf:

Property name
Old value
New value

Das zeigt dir, was wirklich geaendert wurde.

Zum Beispiel:

Account enabled: true -> false
Group membership: user added
Policy state: report-only -> on
App permission: permission added

Correlation Details speichern

Kopiere:

Correlation ID
Date
Initiated by

Diese Werte sind nuetzlich, wenn du an einen anderen Admin, das Security Team, den Application Owner oder Microsoft Support eskalierst.

Naechste Aktion entscheiden

Verwende die Audit-Log-Details, um die Reaktion zu waehlen:

Unexpected user change -> Actor kontaktieren oder Setting wiederherstellen
Unexpected group membership -> Member entfernen und Access pruefen
Unexpected app permission -> Consent und API Permissions pruefen
Unexpected policy change -> alte/neue Werte vergleichen und bei Bedarf zuruecksetzen
Unexpected role assignment -> Privileged Access und PIM pruefen
Automated change -> Service Principal oder Managed Identity untersuchen

Das Audit Log sollte dir zeigen, ob es erwartete Administration, Automation oder etwas Verdaechtiges war.

Enterprise-Hinweis

Audit Logs sind nicht nur fuer Security Incidents.

Sie sind auch fuer Change Control nuetzlich.

Empfohlener Workflow:

• zuerst nach Zeit filtern
• nach Activity, Target oder Actor eingrenzen
• Event Details oeffnen
• erkennen, wer die Aenderung initiiert hat
• Target Object erkennen
• Modified Properties pruefen
• Correlation Details speichern
• dokumentieren, ob die Aenderung erwartet war