Ein Compliance-Ergebnis hat immer ein Alter
Geräte-Compliance beruht auf Evidenz, die zu einem bestimmten Zeitpunkt beobachtet wurde. Verschlüsselungsschutz, Agent-Heartbeat, Verwaltung, Gerätrisiko oder Patch-Evidenz können danach abweichen.
Geplantes Gerätemanagement bleibt nützlich, doch jede Entscheidung hat eine Aktualitätsgrenze. Teams müssen Quelle, Beobachtungszeit, Übertragungsweg und Durchsetzungszeit kennen.
Nahezu Echtzeit reduziert Verzögerungen für unterstützte Signale, beweist aber nie den buchstäblich aktuellen Zustand. Das belastbare Ziel ist die neueste vertrauenswürdige Evidenz mit expliziter Aktualität.
Das vollständige Expositionsfenster messen
Nicht ein einzelnes Check-in-Intervall, sondern die Zeit von einer relevanten Geräteänderung bis zum verifizierten Ergebnis beschreibt die Kontrolle.
Gesamtes Expositionsfenster =
Beobachtungslatenz
+ Übertragungslatenz
+ Richtlinienbewertungslatenz
+ Durchsetzungslatenz - Beobachtung. Zeit bis Endpoint, MDM, Security-Agent oder Attestierungsdienst die Änderung erkennt.
- Übertragung. Zeit bis die Evidenz den normalisierenden oder bewertenden Dienst erreicht.
- Bewertung. Zeit bis Compliance- oder Autorisierungsengine ein neues Ergebnis berechnet.
- Durchsetzung. Zeit bis Anwendung, Gateway, Sitzungsdienst oder Endpoint-Kontrolle reagiert und das Ergebnis bestätigt ist.
Was der Intune-Wartungsrhythmus bedeutet
Microsoft dokumentiert für Richtlinien und Profile einen geschätzten Wartungs-Check-in von etwa acht Stunden und häufigere Prüfungen bei neu registrierten Geräten. Außerdem gilt ein Wartungssync-Limit von einem Sync je 6,5 Stunden. Das ist relevant, wenn eine Kontrolle vom normalen MDM-Refresh abhängt.
Es gibt weitere Pfade: Benutzer und Administratoren können synchronisieren, Richtlinienänderungen einen Check-in anstoßen, App-Schutz beim Öffnen oder Fortsetzen bewerten und Microsoft Defender for Endpoint Gerätrisiko an Compliance und Conditional Access liefern.
Fragen Sie daher je Kontrolle nach Quelle, schnelleren Pfaden und der Restlatenz, wenn diese Pfade ausfallen.
Posture-Quellen haben unterschiedliche Zeit- und Vertrauenseigenschaften
| Quelle | Typische Evidenz | Zeitmodell | Wichtige Grenze |
|---|---|---|---|
| MDM-Inventar und Compliance | Registrierung, Konfiguration, Verschlüsselung, OS, Verwaltung | Wartungs-, angestoßener oder manueller Check-in | Evidenz bleibt offline oder zwischen Bewertungen unverändert |
| Endpoint Detection and Response | Detektionen, Agent-Gesundheit, Gerätrisiko | Ereignisse plus Heartbeats | Ein kompromittierter oder defekter Agent kann verstummen |
| Plattformattestierung | Boot- und hardwaregestützte Evidenz | Bei Registrierung, Zugriff oder Challenge | Beweist nur dargestellte Claims und Aktualität |
| App-Schutz | App-Integrität, OS und lokale Bedingungen | Bei Start, Fortsetzen oder Datenzugriff | Nur unterstützte Apps und Kontrollflächen |
| Patch- und Schwachstellenevidenz | Versionen, Exposition, Behebung | Inventar-, Scanner-, Agent- oder Service-Refresh | Neue Schwachstellen können Risiko ohne lokale Änderung erhöhen |
Ein hybrides Prüfmodell verwenden
- Ereignisgesteuerte Übergänge. Unterstützte Änderungen sofort melden, etwa erhöhtes Gerätrisiko, Verwaltungsentfernung oder Kontrollfehler.
- Liveness-Heartbeats. Kontinuierliche Quellen müssen ihre Funktion belegen; ein überfälliger Heartbeat wird veraltet oder unbekannt.
- Regelmäßiger Abgleich. Vollständigen Istzustand mit der Baseline vergleichen, um verlorene oder nicht unterstützte Ereignisse zu finden.
- Bedarfsgesteuerte Prüfung. Für sensible Zugriffe Evidenz innerhalb einer risikogerechten Aktualität verlangen.
- Begrenzt gecachter Zustand. Posture nur mit Quelle, Beobachtungszeit, Ablauf und Richtlinienversion cachen, nicht als unqualifiziertes compliant.
Schnelle Evidenz ist nicht automatisch vertrauenswürdig
- Telemetrie an authentifizierte Geräte- und Mandantenidentität binden.
- Manipulation und Replay durch authentifizierten Transport, Integritätsschutz, stabile IDs und Deduplizierung verhindern.
- Vertrauenswürdige Beobachtungszeit und zulässige Uhrabweichung definieren.
- Hardware- oder Plattformattestierung gezielt einsetzen und ihre tatsächliche Aussage dokumentieren.
- Unabhängige MDM-, EDR-, Identity- und Plattformsignale korrelieren; ein kompromittierter Agent kann eigenen Zustand fälschen.
- Quellenpriorität und Konfliktrichtlinie festlegen.
Veraltete, fehlende, unbekannte und widersprüchliche Zustände modellieren
Ein Gerät darf nicht unbegrenzt compliant bleiben, weil es gesund aufgehört hat zu melden. Legen Sie je Signal eine maximale Evidenzdauer fest.
Definieren Sie getrennte Ergebnisse für veraltet, fehlend, unbekannt, Fehler, widersprüchlich, nicht konform und wiederhergestellt. Je Ressource folgen Sperre, begrenzte Sitzung, Step-up, Grace Period, Hinweis, Behebung oder Analystenprüfung.
- Offline-Geräte. Sie können keine neuen Ereignisse senden. Vertrauen läuft anhand der letzten Evidenz ab.
- Ausgefallene Quellen. Unterscheiden Sie gesundes Gerät von ausgefallenem MDM- oder Security-Dienst.
- Wiederherstellung. Vollzugriff erst nach verifizierter, zeitlich neuerer und stabiler Evidenz zurückgeben.
Von Posture-Evidenz zur Zugriffsdurchsetzung
Ein neues Ergebnis verändert nicht automatisch aktive Sitzungen. Das Entscheidungssystem muss Gerät, Benutzer, Mandant, Ressourcen und Sitzungen korrelieren, Richtlinie bewerten und die Reaktion verifizieren.
SSF und CAEP können Zustandsänderungen übertragen. CAEP beschreibt das Ereignis; der Empfänger entscheidet über Sperre, Widerruf, Challenge, Einschränkung oder Beobachtung.
- Zum nachgelagerten Sitzungsweg siehe Kontinuierliche Zugriffsbewertung bei Änderungen des Gerätestatus.
Praxisbeispiel: Agent-Heartbeat wird veraltet
Um 09:00 meldet ein verwalteter Laptop gesunde Verschlüsselung, aktuellen Endpoint-Schutz und einen erfolgreichen Heartbeat. Um 09:07 verstummt der Agent; die Ursache ist zunächst unbekannt.
Am definierten Schwellenwert wechselt Posture von gesund zu veraltet. Das Ereignis wird authentifiziert, korreliert, dedupliziert und je Ressource bewertet. Geringes Risiko erhält begrenzten Zugriff, Quellcode- und Adminsysteme verlangen frische Evidenz.
Nach erneutem Heartbeat wird Zugriff nicht sofort wiederhergestellt. Das System gleicht relevante Kontrollen ab, prüft die zeitliche Reihenfolge und protokolliert die Recovery-Entscheidung.
Messgrößen für prüfbare Aktualität
- Latenz Beobachtung–Meldung, Meldung–Entscheidung und Entscheidung–Durchsetzung je Plattform und Signal messen.
- Anteil der Geräte innerhalb jedes Aktualitätsschwellenwerts verfolgen.
- Verlorene, doppelte und ungeordnete Ereignisse, Retry-Backlog, Dead Letters und Abgleichfunde messen.
- Fehlsperren, unsichere Freigaben, Recovery-Zeit, Ausnahmen und Wiederholungen erfassen.
- Normal-, Offline-, Netzdegradations-, Quellausfall-, Uhrabweichungs- und Konfliktszenarien testen.
Fragen an Anbieter
- Welche Signale sind ereignisgesteuert, periodisch, heartbeat-basiert oder bedarfsgesteuert?
- Welche gemessenen End-to-End-Latenzen gelten normal und bei Störungen?
- Wie erhält Richtlinie Quelle, Beobachtungszeit, Aktualität, Vertrauen und Version?
- Was geschieht offline oder bei Ausfall von MDM, EDR, Attestierung oder Streaming?
- Wie werden Identität, Mandantenbindung, Integrität, Replay, Reihenfolge, Deduplizierung und Rotation behandelt?
- Wie findet Abgleich verlorene oder nie ausgesendete Ereignisse?
- Welche Reaktionen betreffen nur neue Anmeldungen und welche aktive Sitzungen?
- Welche Evidenz bestätigt Konvergenz vor Wiederfreigabe?
Abbildung in einer Gideon-Evaluierung
Wählen Sie repräsentative Kontrollen und messen Sie den vollständigen Evidenzpfad in Gideon Endpoint Management. Bestätigen Sie Quelle, Aktualität, Umgang mit fehlenden Daten, Richtlinienwechsel, Aktion und verifiziertes Ergebnis. Behandeln Sie Latenzziele als Abnahmekriterien je Plattform und Signal, nicht als universelle Garantie.
Weiterführende Inhalte
- Nutzen Sie Zero-Touch Endpoint Management für Security-Teams für den gesamten Lifecycle.
- Vergleichen Sie Zuständigkeiten in MDM plus Native Agent Architecture.
- Definieren Sie Schwellenwerte mit dem Endpoint Posture Policy Starter Pack.
- Entdecken Sie Gideon Endpoint Management.
Primärquellen
- Microsoft dokumentiert Check-in-Zeiten in Fragen zu Richtlinien und Profilen in Microsoft Intune.
- Microsoft dokumentiert Compliance-Refresh und manuelle Synchronisierung in Gerätecompliancerichtlinien erstellen.
- Microsoft beschreibt Gerätrisiko und Conditional Access in Microsoft Defender for Endpoint mit Intune integrieren.
- Microsoft erklärt Status, Grace Period und Aktionen in Aktionen für nicht konforme Geräte konfigurieren.
So verwenden Sie diese Ressource
Wählen Sie ein folgenschweres Signal und ordnen Sie Beobachtung, Übertragung, Bewertung, Durchsetzung und Recovery zu. Definieren Sie Aktualität und Ergebnis, testen Sie Normal- und Störfälle und bewahren Sie die Messungen als Abnahmenachweis auf.