Entra ID Security Audit: Logs, Setup und Best Practices
Ein Entra ID Security Audit bringt Struktur in Identitäts- und Zugriffsereignisse: Audit Logs, Sign-in-Logs und Änderungen an Rollen, Anwendungen und Berechtigungen werden nachvollziehbar ausgewertet. Das senkt Suchzeiten bei Vorfällen, reduziert das Risiko von Privilege Escalation und liefert saubere Nachweise für Compliance.
- Transparenz: Wer hat was wann im Directory verändert?
- Kontrolle: Rollen, Consent und Application Permissions werden überprüfbar.
- Nachweis: Dokumentation für Audits und interne Richtlinien wird einfacher.
Entscheidend ist nicht das Sammeln der Logs, sondern eine Auswertung, die zu Maßnahmen führt.
Du sorgst dafür, dass M365 läuft. Wir sorgen dafür, dass niemand unbemerkt eindringt, heimlich mitliest und Schaden anrichtet.
Definition
Ein Entra ID Security Audit ist die strukturierte Prüfung von Identitäten, Zugriff und Administrator-Aktivitäten in Microsoft Entra ID anhand von Audit Logs und Sign-in-Logs. Es ist kein Penetrationstest und kein allgemeines IT-Reporting, sondern ein prüfbarer Nachweis- und Steuerungsprozess für Identity Security und Compliance.
Einleitung
Wenn Entra ID „einfach läuft“, werden Änderungen oft nur im Portal geklickt und später nicht mehr sauber nachvollzogen. Ein entra id security audit verhindert genau das: Du bekommst Klarheit über Admin-Aktionen, riskante Berechtigungen und auffällige Anmeldungen, bevor daraus ein Vorfall oder ein teurer Stillstand wird.
Audit-Logs: Was wird erfasst (und warum ist das wichtig)?
Die Entra ID Audit Logs erfassen Änderungen im Directory: Nutzer, Gruppen, Rollen, Geräte, Policies, Application Registration (AppRegistration) und Service Principals. Dazu kommen Details wie „wer“ (Initiator/Administrator), „was“ (Operation), „womit“ (z. B. Application/Principal) und „wann“ (Zeitpunkt) sowie häufig ein Zielobjekt-Name.
Die Sign-in-Logs ergänzen das Bild: Authentication, Conditional Access, Multi-Factor Authentication (MFA), Standort/Client-Signal und Fehlercodes. Genau diese Kombination macht Investigations schneller: Erst sehen, dass ein Admin etwas geändert hat, dann prüfen, ob kurz davor ein verdächtiger Sign-in oder ein Policy-Bypass passiert ist.
Setup: Diagnoseeinstellungen, Event Hub und Aufbewahrung
Ein belastbares Audit-Setup beginnt nicht bei Dashboards, sondern bei Datenfluss und Retention. In der Entra Admin Center-/Azure-Portal-Welt werden Diagnoseeinstellungen so gesetzt, dass Audit Logs und Sign-in-Logs kontinuierlich in ein Zielsystem geschrieben werden (und nicht nur im Portal „nachgeschaut“).
- Azure Event Hub: sinnvoll, wenn Logs in Near-Realtime in ein zentrales Monitoring (z. B. SIEM) gestreamt werden sollen.
- Azure Storage Account (z. B. Azure Blob Storage): sinnvoll als kosteneffizientes Archiv für Compliance und spätere Auditing-Fragen.
- Azure Monitor/Log Analytics als Auswertungsbasis: sinnvoll für Abfragen, Alerts und Dashboards.
Wichtig für Budget und Aufwand: Der Nutzen steigt, wenn die Aufbewahrung zu den eigenen Nachweispflichten passt und die Daten nicht doppelt gesammelt werden. Zu kurze Retention macht Forensik teuer, zu lange ohne Filter macht Betrieb teuer.
Datenquellen & Integrationen: APIs, Endpunkte und „blinde Flecken“
Für ein „full“ Bild werden neben Portal-Ansichten auch API-Zugänge genutzt. Die Microsoft Graph API ist der zentrale Endpunkt, wenn Reports, Custom Checks oder regelmäßige Kontrollen automatisiert laufen sollen (z. B. risky Application Permissions, neu erteiltes Consent, Änderungen an credentials eines Service Principal). Zusätzlich kann Azure Resource Manager (ARM) relevant sein, wenn Identity-Änderungen mit Azure-Ressourcen-Zugriff verknüpft werden.
Typische Integrationen sind: Export in Event Hub, Abfragen per Graph, und Korrelation mit Identity Protection/PIM-Signalen. Der Nutzen ist konkret: Weniger manuelle Portal-Klickerei, schnellere Detect-Zeiten und eine kleinere Blast Radius, weil kritische Änderungen früh auffallen.
Berichte, Dashboards und Kennzahlen: Was du wirklich messen solltest
Ein Audit liefert erst Wert, wenn er in Kennzahlen und Entscheidungen mündet. Gute Dashboards trennen Tagesbetrieb (Monitoring) von Audit-Nachweis (Compliance) und zeigen Trends statt Roh-Logs. Microsoft Secure Score kann als Orientierung dienen, ersetzt aber keine Auswertung von tatsächlichen Änderungen und Sign-ins.
- Privilegien: Anzahl neuer Role-Assignments, PIM-Aktivierungen, Admin/Administrator-Aktivität pro Zeitraum.
- Anwendungen: neue Service Principals, neue/erhöhte Application Permissions, auffällige Consent-Vorgänge (Consent phishing/Illicit consent grants).
- Zugriff: fehlgeschlagene Sign-ins, MFA-Bypass-Signale, Conditional-Access-Block/Allow-Rate.
Prüfpfade: Sicherheit, Privilegien, Compliance
Ein entra id security audit sollte konkrete Prüfpfade definieren, damit Auditing nicht zur Ad-hoc-Suche wird. Drei Pfade reichen zum Start: Privilege Escalation (Rollen, PIM, Break-Glass), Application/Consent (AppRegistration, Service Principal, credentials, API-Rechte) und Zugriffsschutz (Conditional Access, MFA, ungewöhnliche Sign-ins). Für Compliance (z. B. DSGVO (GDPR), SOX, HIPAA, PCI DSS) ist der wichtigste Punkt nicht das Framework, sondern die Nachvollziehbarkeit von Änderungen und die Dokumentation von Maßnahmen.
Häufige Stolpersteine
- Logs werden gesammelt, aber niemand hat einen run-bookartigen Prozess zum Lesen, Bewerten und Dokumentieren.
- Zu breite Admin-Rechte ohne PIM; Rollen wachsen über inheritance/„hat sich so ergeben“.
- App- und Consent-Themen werden unterschätzt: ein granted Consent kann mehr Schaden machen als ein einzelnes Passwortleck.
Checkliste: Best Practices zur Implementierung
- Scope festlegen: Welche Rollen, welche Apps, welche Ressource/Directory-Objekte sind kritisch?
- Datenfluss fixieren: Diagnoseeinstellungen aktivieren und Export nach Event Hub oder Storage sauber testen.
- Auswertung operationalisieren: Queries/Alerts, Verantwortlichkeiten, Ticketing und monatliches Reporting definieren.
Wann externe Unterstützung sinnvoll wird
Externe Unterstützung lohnt sich, wenn intern zwar Microsoft Entra administriert wird, aber kein Team die Kapazität für kontinuierliches Monitoring, Auditing und Dokumentation hat. Spätestens wenn PIM, Conditional Access, App-/Consent-Prüfungen und Log-Export zusammenkommen, entscheidet nicht Technik, sondern Betriebsdisziplin: Wer prüft was, wie schnell, und wie werden Maßnahmen nachweisbar umgesetzt?
CTA
Wenn du willst, dass Entra ID nicht nur administriert, sondern im Alltag sicher betrieben wird, buch ein kostenloses Erstgespräch (30 Minuten, remote, kein Verkaufsgespräch, kein Angebot ohne dein OK, Rückmeldung innerhalb von 24h).
Fazit
Ein Entra ID Security Audit schafft Nachvollziehbarkeit für Admin-Änderungen, Zugriffe und App-Berechtigungen. Der größte Effekt entsteht, wenn Log-Setup, Integrationen und Reporting als wiederholbarer Prozess betrieben werden: weniger Suchzeit, weniger Risiko durch Privilegienfehler, bessere Compliance-Nachweise. Starte klein mit klaren Prüfpfaden und baue dann Auswertung und Automatisierung aus.
Häufige Fragen
Welche Voraussetzungen brauche ich für ein Entra ID Security Audit?
Du brauchst Zugriff auf Microsoft Entra Admin Center, aktivierte Audit- und Sign-in-Logs im Tenant und ein Ziel für den Export (z. B. Azure Event Hub oder Azure Storage Account). Zusätzlich helfen klare Rollen: wer darf konfigurieren, wer darf auswerten, wer dokumentiert.
Lohnt sich das auch ohne eigenes Security-Team?
Ja, gerade dann. Ein Audit reduziert den Aufwand im Ernstfall, weil Änderungen und Zugriffe schneller nachvollziehbar sind. Ohne Prozess bleibt es aber bei Daten: der Nutzen entsteht durch regelmäßige Reviews, Alerts und dokumentierte Maßnahmen.
Wie lange dauert die Implementierung typischerweise?
Ein Basissetup (Diagnoseeinstellungen, Export-Ziel, erste Dashboards) ist oft schnell möglich. Der echte Zeitfaktor ist die Betriebsreife: Prüfpfade, Verantwortlichkeiten, Retention, Queries und ein Report-Rhythmus, der wirklich gelebt wird.
Wie messe ich den Erfolg (Messbarkeit der Ergebnisse)?
Miss die Zeit bis zur Klärung von „wer hat was geändert“, die Anzahl kritischer Role-/App-Änderungen pro Monat, MFA- und Conditional-Access-Wirkung sowie die Qualität der Nachweise (vollständige Änderungs- und Maßnahmenkette). Zusätzlich sind weniger Eskalationen und kleinere Blast Radius bei Vorfällen starke Indikatoren.
