M365Con 2027 – die kostenlose Online-Konferenz · 11–22 Jan 2027 · 120 sessions→ m365con.net

Blog · Mirko Peters

Blinde Flecken in der Microsoft 365-Compliance mit Microsoft Graph aufdecken

Von ·

Willkommen zurück zu unserem Podcast und dem begleitenden technischen Blog! Wenn Sie je einem Standard-Compliance-Dashboard von Microsoft 365 vertraut und angenommen haben, alles sei w…

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

▶ BLOGUncovering M365Compliance Blindspots…M365.FM
Titelbild: Uncovering M365 Compliance Blindspots with Microsoft Graph

Willkommen zurück zu unserem Podcast und dem begleitenden technischen Blog! Wenn Sie einem Standard-Compliance-Dashboard von Microsoft 365 vertraut und angenommen haben, alles sei vollständig erfasst, könnten Sie sich in falscher Sicherheit wiegen. Standard-Compliance-Dashboards sind als Zusammenfassungen gedacht, nicht als absolute Wahrheit. Kritische Signale, etwa Treffer von Data Loss Prevention (DLP), eDiscovery-Aktionen und zugrunde liegende Sicherheitswarnungen, liegen oft hinter Microsoft Graph-Endpunkten. Diese erfordern separate Berechtigungen, erweiterte Abfrageparameter und eine saubere Datenzusammenführung. In diesem Deep Dive zeigen wir, warum Ihren nativen Berichten wichtige Informationen fehlen, welche Graph-Endpunkte Sie genau abfragen sollten, und wie Sie diese Rohdaten direkt in Microsoft Purview einspeisen, um klare und belastbare Berichte zu erstellen. Das vollständige Gespräch zu diesem Thema finden Sie in der zugehörigen Podcast-Episode: Find Missing Microsoft 365 Compliance Data with Graph.

Überblick

Standard-Compliance-Dashboards sind Zusammenfassungen, keine Wahrheit. Kritische Signale (DLP-Treffer, eDiscovery-Aktionen, Sicherheitswarnungen) liegen oft hinter Graph-Endpunkten mit eigenen Berechtigungen. Wir zeigen die genauen APIs, Berechtigungsbereiche und Skriptmuster, mit denen Sie vollständige Nachweise extrahieren und in Purview zentralisieren, für klare und belastbare Berichte.

Für wen dieser Beitrag hilfreich ist

  • Compliance-, Rechts- und Risikoverantwortliche, die prüfungsfähige Nachweise benötigen

  • Microsoft 365- und Entra-Administratoren, die Reporting und Automatisierung aufbauen

  • Sicherheitsteams, die DLP-, eDiscovery- und Warnungsdaten miteinander korrelieren

Die blinden Flecken (warum Standard-Dashboards wichtige Daten übersehen)

  • Aggregation und Verzögerung: Die UI-Zusammenfassungen lassen verschachtelte Vorfalldetails und aktuelle Aktivitäten aus

  • Lücken im Umfang: eDiscovery-Aktionen und DLP-Treffer liegen möglicherweise außerhalb der Standardexporte

  • Getrennte Berechtigungen: /security- und /compliance-Endpunkte erfordern unterschiedliche Berechtigungsbereiche

  • Keine Verknüpfungen: Dashboards korrelieren selten Vorfälle mit Benutzern, Custodians oder Schritten im Fall

Die wertvollsten Graph-Endpunkte (zum Kopieren)

  • Sicherheitswarnungen (Breite)

    • Endpunkt: /security/alerts oder /security/alerts_v2

    • App-Berechtigungen (Beispiele): SecurityEvents.Read.All (oder Alerts.Read.All in neueren Modellen)

    • Verwendung für: Zeitachsen von Warnungen, Schweregrad, Status, Zuweisungen

  • DLP-Richtlinien und Aktivitäten (Datenverlust)

    • Endpunkte (je nach Verfügbarkeit im Mandanten):

      • /security/dataLossPreventionPolicies (Inventar der Richtlinien)

      • /security/dlpIncidents oder erweiterte DLP-Vorfall-Endpunkte im Security-Namespace (mandantenabhängig)

    • App-Berechtigungen: SecurityEvents.Read.All (und/oder spezifische DLP-Leseberechtigungen, sofern verfügbar)

    • Verwendung für: Treffer, Speicherorte (Exchange/SharePoint/Teams), Disposition

  • eDiscovery (Fälle und Aktionen)

    • /compliance/ediscovery/cases

    • Untergeordnete Pfade: /custodians, /searches, /reviewSets, /noncustodialDataSources, /operations

    • App-Berechtigungen: eDiscovery.Read.All (und Schreibberechtigung, wenn Sie Fälle verwalten)

    • Verwendung für: Fallstatus, Aufbewahrungssperren (Holds), Custodians, Exporte, Aktionen von Prüfern

  • Audit- und Anmeldekontext (unterstützende Nachweise)

    • /auditLogs/directoryAudits, /auditLogs/signIns

    • App-Berechtigungen: AuditLog.Read.All, Directory.Read.All

    • Verwendung für: Wer hat wann was geändert, Sitzungskontext

Tipp: Viele Compliance-Payloads sind stark verschachtelt. Planen Sie den Einsatz von $expand, blättern Sie per @odata.nextLink durch die Ergebnisse und verknüpfen Sie die Daten mit /users/{id} für Anzeigenamen und Abteilungen.

Authentifizierung und Berechtigungen (unkomplizierter Weg)

  • Verwenden Sie Anwendungsberechtigungen (Dienstprinzipal) für unbeaufsichtigte Hintergrundjobs

  • Registrieren Sie separate Apps für Sicherheit und den Kern-Graph, wenn Ihre Organisation eine getrennte Rechtevergabe verlangt

  • Erteilen Sie nur Berechtigungen mit minimalen Rechten und speichern Sie Geheimnisse und Zertifikate in Key Vault

  • Implementieren Sie exponentielles Backoff für 429- und 503-Fehler und protokollieren Sie x-ms-request-id

Skriptmuster (PowerShell oder Python)

  • Select und Expand: Fordern Sie nur die benötigten Felder an, $select=…, $expand=… für verschachtelte Entitäten

  • Filtern & Zeitfenster begrenzen: $filter=createdDateTime ge {ISO8601} für Deltas

  • Paginieren: in einer Schleife @odata.nextLink verfolgen; nie von einseitigen Ergebnissen ausgehen

  • Normalisieren: Benutzer- und Objekt-IDs vorab Namen und Abteilungen zuordnen, damit die Ausgaben lesbar sind

  • Für Kontext zusammenführen: Vorfälle vor dem Export um Benutzer-, Website-, Team- oder Fallmetadaten ergänzen

Einbindung in Purview (Daten in Entscheidungen verwandeln)

  1. Ausgabe vereinheitlichen: CSV/JSON mit einheitlichen Feldnamen (tenant, incidentId, workload, userId, userUPN, severity, status, created, lastAction, caseId)

  2. Einlesen: Dateien an einem gesicherten Speicherort ablegen, den Purview lesen kann (z. B. ADLS Gen2)

  3. Taggen & kennzeichnen: vertraulichkeitsbezeichnungen oder benutzerdefinierte Tags (z. B. „DLP-PII-High“) für die Weiterleitung anwenden

  4. Dashboards: Purview (oder Power BI auf Basis von Purview-Daten) für Trends, Verantwortliche und SLA-Alterung

  5. Automatisierungen: Regeln, die Fallverantwortliche bei Wiederholungen oder Eskalationen benachrichtigen; wöchentliche PDF-Zusammenfassungen

30-Minuten-Pilotprojekt (Schritt für Schritt)

  • 0–10 Min.: App-Registrierung + SecurityEvents.Read.All / eDiscovery.Read.All; Secret bzw. Zertifikat erstellen

  • 10–20 Min.: Einen Endpunkt (Warnungen oder Fälle) mit Paginierung und $filter für die letzten 7 Tage skripten

  • 20–30 Min.: Mit /users anreichern, als CSV exportieren, in den ADLS-Pfad ablegen und ein einfaches Diagramm visualisieren

KPIs, die den Nutzen belegen

  • Anteil der Incidents mit ausgefülltem Verantwortlichen und Disposition (in %)

  • Mittlere Zeit von Incident bis Fall (oder Prüfer)

  • Wiederholungstäter (Konten/Standorte) pro 30 Tage

  • Abweichung zu den Anzahlen im OOTB-Dashboard (Schließung von Lücken)

  • Dauer des Audit-Zyklus (eingesparte Stunden für die Nachweiserstellung)

Häufige Fallstricke (und Lösungen)

  • Leere Ergebnisse → falsche Bereiche oder Delegated statt der erforderlichen Application-Berechtigung

  • Fehlende Details → $expand vergessen / verschachtelte Sammlungen nicht ausgewertet

  • Unvollständige Daten → keine Paginierung; nur die erste Seite erfasst

  • Namensabweichungen → keine Anreicherung per Join mit /users oder HR-Daten

  • Veraltete Dashboards → keine geplanten Läufe; Job und Alarmierung bei Fehlern ergänzen

Quick Wins für diese Woche

  • Ziehen Sie die Daten der letzten 7 Tage aus /security/alerts und vergleichen Sie die Anzahl mit dem Portal

  • Offene eDiscovery-Fälle und Auskunftspersonen exportieren; zur Validierung an die Rechtsabteilung weitergeben

  • Einen DLP-Incident-Durchlauf starten, Wiederholungen taggen und Folgeaufgaben in Purview anlegen

  • Ein wöchentliches Nachweispaket (CSV + PDF) an ein Compliance-Postfach planen

Häufige Fragen

  • Muss ich Entwickler sein? Nein – PowerShell oder kurze Python-Skripte reichen aus.

  • Warum App-Berechtigungen? Die meisten /security- und /compliance-Endpunkte erfordern einen headless Zugriff mit hohem Vertrauensniveau.

  • Kann ich bei PowerShell bleiben? Ja – nutzen Sie das Microsoft Graph PowerShell SDK und behandeln Sie $top, $filter, $expand und die Paginierung.

  • Ist Purview erforderlich? Nicht zwingend – aber es verwandelt rohes JSON in prüfbare Workflows und Dashboards.

Fazit

Dashboards fassen zusammen; Graph erzählt die ganze Geschichte. Rufen Sie die richtigen Endpunkte auf, korrigieren Sie die Authentifizierung, paginieren und erweitern Sie die Abfragen und bündeln Sie die Daten anschließend in Purview. So wechseln Sie von reiner Checkbox-Compliance zu nachweisbarer Transparenz in Echtzeit – ohne im manuellen Export zu versinken. Für ein ausführliches Gespräch und Expertentipps zu diesen blinden Flecken hören Sie unbedingt unsere Podcast-Episode Find Missing Microsoft 365 Compliance Data with Graph. Verfeinern Sie Ihre Skripte weiter, sichern Sie Ihre Anwendungsberechtigungen ab und machen Sie die Daten sichtbar, die Ihre Dashboards bisher verborgen haben!

Entitäten in diesem Artikel

eDiscovery Compliance Dashboards Microsoft Graph Microsoft Purview Data loss prevention (DLP) PowerShell Microsoft 365 Exchange Online JSON

Verwandte Artikel

RSS