Sektion 30: Compliance Reporting: Analyse von Non-Compliant Devices

Willkommen zur 30. Sektion unseres Intune Masterkurses. Nachdem wir in den vorherigen Kapiteln gelernt haben, wie man Compliance-Richtlinien definiert und Geräte in einen gewünschten Zustand versetzt, kommen wir nun zum kritischsten Teil des gesamten Compliance-Frameworks: der Analyse. Eine Richtlinie, die zwar Geräte als „non-compliant“ markiert, aber keinen Pfad zur Lösung bietet, ist für die IT-Abteilung wertlos und für den Endanwender frustrierend.

Compliance Reporting ist in der Enterprise-Welt nicht nur eine Frage der Sicherheit, sondern auch der Audit-Fähigkeit. Wenn ein Auditor fragt: „Warum hatten 15 % Ihrer Flotte im letzten Quartal keinen aktuellen BitLocker-Status?“, müssen Sie in der Lage sein, dies nicht nur zu bestätigen, sondern die Ursachen (Root Cause Analysis) präzise zu benennen. In dieser Masterclass gehen wir tief in die Analyse von Non-Compliance, die Nutzung von Log-Daten und die strategische Behebung von Fehlern.

1. Die Anatomie der Non-Compliance: Warum schlagen Geräte fehl?

Bevor wir in die Reports eintauchen, müssen wir verstehen, was im Hintergrund passiert. Ein Gerät wird in Intune dann als non-compliant markiert, wenn eine oder mehrere Einstellungen einer zugewiesenen Compliance-Richtlinie nicht den definierten Anforderungen entsprechen. Dabei gibt es drei Hauptkategorien von Fehlern:

1.1. Echte Non-Compliance (User/System Error)

Hier ist die Richtlinie korrekt konfiguriert, aber das Gerät erfüllt die Bedingung schlichtweg nicht. Beispiele:

Der Benutzer hat den Passwort-Complexity-Check ignoriert.
Die Windows-Version ist veraltet, weil Updates durch den User aufgeschoben wurden.
BitLocker wurde manuell deaktiviert.

1.2. Konfigurationsfehler (Admin Error)

Das Gerät ist technisch in der Lage, die Anforderung zu erfüllen, aber die Richtlinie ist falsch definiert. Ein klassisches Beispiel ist die Anforderung eines TPM 2.0 Moduls in einer Flotte, die teilweise noch aus älteren Geräten mit TPM 1.2 besteht. Das Ergebnis: Massenhafte „Non-Compliant“ Meldungen, die eigentlich „Impossible“ bedeuten sollten.

1.3. Reporting- und Sync-Lag (Technical Error)

Das Gerät ist compliant, aber Intune weiß es noch nicht. Compliance-Daten werden nicht in Echtzeit gestreamt, sondern in Intervallen synchronisiert. Ein Gerät kann also compliant sein, aber im Portal noch als non-compliant gelistet werden, weil der letzte Sync-Zyklus fehlgeschlagen ist oder noch nicht stattgefunden hat.

2. Deep Dive: Analyse-Tools in Intune

Um Non-Compliance zu analysieren, stehen uns verschiedene Ebenen zur Verfügung. Wir bewegen uns hier vom Groben (Organisation) zum Feinen (einzelnes Gerät).

2.1. Das Compliance-Dashboard (The Big Picture)

Unter Devices -> Compliance erhalten wir die erste aggregierte Sicht. Hier ist der wichtigste Wert die Compliance-Rate. Ein plötzlicher Abfall dieser Rate ist ein Indikator für ein systemisches Problem (z.B. ein fehlerhaftes Windows-Update, das eine Sicherheitsfunktion deaktiviert hat).

2.2. Richtlinien-spezifische Analyse

Klickt man auf eine spezifische Compliance-Richtlinie, sieht man genau, welche Einstellung die meisten Fehler verursacht. Wenn beispielsweise 500 Geräte „Compliant“ sind, aber 200 bei der Einstellung „Minimum OS Version“ scheitern, wissen wir sofort, dass das Problem bei den Windows-Updates liegt und nicht bei der Firewall oder dem Antivirus.

2.3. Geräte-Level Analyse

Auf dem Gerät-Objekt selbst unter Device Compliance sehen wir die detaillierte Liste. Intune zeigt uns hier genau an: „Setting: Secure Boot -> Status: Non-compliant“. Dies ist der Startpunkt für jedes Troubleshooting-Ticket.

3. Praxis-Implementierung: Root Cause Analysis (RCA)

Wenn ein Gerät als non-compliant markiert wird, folgen wir einem strikten Analyse-Pfad. Wir nutzen hierfür eine Kombination aus dem Intune Portal und lokalen Diagnosetools.

Schritt 1: Validierung des Sync-Status

Bevor wir an den Einstellungen schrauben, prüfen wir, ob das Gerät überhaupt „spricht“. Ein Gerät, das seit 14 Tagen nicht synchronisiert hat, kann nicht compliant sein.

# In Intune: Device -> Overview -> Last sync
# Lokal auf dem Gerät: Einstellungen -> Konten -> Zugriff auf Arbeit oder Schule -> Info -> Synchronisieren

Schritt 2: Lokale Verifizierung via PowerShell

Wir vertrauen dem Portal nicht blind. Wir prüfen die Einstellung direkt auf dem Client. Angenommen, Intune meldet, dass BitLocker non-compliant ist. Wir führen lokal folgendes aus:

# Prüfen des BitLocker Status für alle Laufwerke
Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, EncryptionMethod, ProtectionStatus

Wenn PowerShell ProtectionStatus = On meldet, das Portal aber Non-compliant anzeigt, haben wir ein Reporting-Problem. Wenn PowerShell Off meldet, haben wir ein echtes Konfigurationsproblem.

Schritt 3: Analyse der Registry-Keys

Viele Compliance-Einstellungen basieren auf Registry-Werten. Für Experten ist es oft schneller, direkt in die Registry zu schauen, anstatt auf den nächsten Sync zu warten. Viele Compliance-Checks prüfen Pfade unter:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\...

4. Advanced Reporting mit Log Analytics und KQL

Für große Umgebungen (1.000+ Geräte) ist das Klicken durch einzelne Geräte unmöglich. Hier implementieren wir ein professionelles Monitoring via Azure Log Analytics. Wir verbinden Intune mit einem Log Analytics Workspace, um Compliance-Daten in SQL-ähnlicher Sprache (Kusto Query Language – KQL) auszuwerten.

Ein mächtiges Beispiel-Query, um alle Geräte zu finden, die aufgrund einer bestimmten Einstellung non-compliant sind, sieht so aus:

// KQL Query für Log Analytics
IntuneDeviceComplianceDevices
| where ComplianceState == "noncompliant"
| summarize DeviceCount = count() by SettingName
| order by DeviceCount desc

Mit diesem Report können wir dem Management belegen: „Wir haben 5 % Non-Compliance, aber 90 % davon betreffen nur die alte Hardware-Serie X, die kein TPM 2.0 unterstützt. Das Risiko ist somit kalkuliert und gering.“

5. Strategien zur Behebung (Remediation)

Compliance-Reporting ohne Behebungsstrategie ist nur Statistik. Es gibt drei Wege, Non-Compliance zu lösen:

5.1. Self-Healing via Conditional Access (Der sanfte Weg)

Wir koppeln die Compliance-Richtlinie an den Conditional Access (CA). Das Gerät wird nicht sofort gesperrt, sondern der User erhält eine Meldung: „Ihr Gerät entspricht nicht den Sicherheitsrichtlinien. Bitte aktualisieren Sie Windows, um weiterhin auf Outlook zuzugreifen.“ Das verschiebt die Last der Behebung vom Admin zum User.

5.2. Proaktive Remediation via Intune Remediation Scripts

Für technische Fehler (z.B. ein deaktivierter Dienst) nutzen wir Devices -> Scripts -> Remediations. Wir erstellen ein Detektions-Skript und ein Remediation-Skript.

Beispiel: Sicherstellen, dass der „Windows Defender“ Dienst läuft

Detektions-Skript (Detection):

$service = Get-Service -Name "WinDefend"
if ($service.Status -ne 'Running') {
    Write-Output "Non-Compliant"
    exit 1 # Signalisiert Intune: Fehler gefunden
} else {
    Write-Output "Compliant"
    exit 0
}

Remediation-Skript (Fix):

Start-Service -Name "WinDefend"
Set-Service -Name "WinDefend" -StartupType Automatic

5.3. Hardware-Lifecycle-Management (Der harte Weg)

Wenn die Analyse ergibt, dass Geräte aufgrund von Hardware-Limitierungen (TPM, CPU-Generation) non-compliant bleiben, ist dies ein Signal für den Einkauf. Compliance Reporting dient hier als Business Case für den Hardware-Austausch.

6. Troubleshooting-Matrix für hartnäckige Fälle

Manchmal zeigt Intune „Non-compliant“ an, obwohl lokal alles perfekt aussieht. Hier ist die Experten-Checkliste für solche „Ghost-Errors“:

Zertifikatsprüfung: Ist das Gerät korrekt in Azure AD (Entra ID) registriert? Wenn das Gerät-Objekt im Entra ID deaktiviert ist, schlägt jede Compliance-Prüfung fehl.
Policy-Konflikte: Sind zwei verschiedene Compliance-Richtlinien zugewiesen, die sich widersprechen? Intune wählt in der Regel die strengste Einstellung.
Management Extension (IME): Ist die Intune Management Extension aktuell? Viele Advanced-Checks laufen über die IME. Ein Absturz dieses Agenten führt zu veralteten Reports.
Windows Update for Business (WUfB): Wenn die „Minimum OS Version“ nicht erreicht wird, prüfen Sie, ob die Update-Ringe korrekt zugewiesen sind oder ob der User Updates über „Pause Updates“ blockiert hat.

7. Best Practices für das Enterprise Reporting

Um Compliance Reporting produktiv zu nutzen, sollten Sie folgende Regeln befolgen:

Keine „Alles-oder-Nichts“ Richtlinien: Erstellen Sie lieber mehrere kleine, spezifische Richtlinien als eine gigantische. So sehen Sie im Report sofort, ob es ein „Virenscanner-Problem“ oder ein „OS-Versions-Problem“ ist.
Grace Periods nutzen: Geben Sie Usern eine Zeitspanne (z.B. 3 Tage), bevor das Gerät als non-compliant markiert wird und der Zugriff gesperrt wird. Das verhindert einen Ticket-Sturm am Montagmorgen nach einem Update-Release.
Regelmäßige Audits: Überprüfen Sie monatlich, ob Ihre Compliance-Anforderungen noch zeitgemäß sind. Eine Anforderung an Windows 10 21H2 ist heute obsolet und führt nur zu unnötigem Rauschen im Report.
Kombination mit Azure Monitor: Bauen Sie sich ein Workbook in Azure, das die Compliance-Daten visualisiert. Dashboards werden von Management-Ebenen besser verstanden als Tabellen in Intune.

Fazit

Die Analyse von Non-Compliant Devices ist das Herzstück des Security-Managements in Intune. Es geht nicht darum, 100 % Compliance zu erreichen – das ist in einer dynamischen IT-Umwelt fast unmöglich. Es geht darum, die Sichtbarkeit zu haben, um zu wissen, welche Geräte gefährdet sind, warum sie es sind und wie man sie effizient zurück in den compliant Zustand bringt.

Indem Sie vom einfachen Portal-Check über lokale PowerShell-Validierungen bis hin zu KQL-Queries in Log Analytics vorstoßen, transformieren Sie Compliance von einem „lästigen Warnlicht“ in ein strategisches Werkzeug zur Risikominimierung. In der nächsten Sektion werden wir uns ansehen, wie wir diese Compliance-Daten nutzen, um den Zugriff auf Unternehmensressourcen über Conditional Access absolut wasserdicht zu machen.