Kontinuierliche Zugriffsbewertung bei Änderungen des Gerätestatus

Die Sitzungslücke nach der Anmeldung

Viele SSO-Umgebungen prüfen den Gerätestatus bei der Anmeldung und vertrauen danach der Sitzung oder dem Zugriffstoken bis zum Ablauf oder zur Aktualisierung. In dieser Zeit können Verschlüsselungsschutz, Agent-Heartbeat, Verwaltungsstatus oder Attestierung abweichen, ohne dass die Anwendung ihre Entscheidung automatisch ändert.

Diese Nachweise stammen aus MDM, Endpoint Security, Betriebssystem oder hardwaregestützter Attestierung. Kontinuierliche Zugriffsbewertung kann Änderungen vor dem regulären Token-Ablauf weitergeben, garantiert aber keine sofortige Erkennung, Zustellung oder Durchsetzung.

Warum kürzere Token-Laufzeiten nur ein Auffangnetz sind

Eine kürzere Laufzeit begrenzt, wie lange eine Ressource ein unverändertes Bearer-Token akzeptiert. Sie macht die Bewertung jedoch nicht kontinuierlich: Ohne Widerrufsprüfung, Introspection oder ein aktuelles Richtliniensignal bleibt das Token bis zum Ablauf gültig.

Begrenzte Laufzeiten bleiben sinnvoll, sollten aber durch ereignisgesteuerte Bewertung oder einen gleichwertigen Live-Kontrollpfad ergänzt werden.

SSF und CAEP: die Standardebene

Das OpenID Shared Signals Framework 1.0 definiert Ereignisstreams und den Austausch von Security Event Tokens. Ein SET nach RFC 8417 ist ein signiertes JWT für ein Sicherheitsereignis, keine Authentifizierungs-Assertion und keine API-Berechtigung.

Das Continuous Access Evaluation Profile 1.0 definiert Ereignisse für Änderungen, die laufenden Zugriff beeinflussen können. SSF und CAEP sind seit 2025 OpenID Final Specifications, doch Produktabdeckung und Interoperabilität unterscheiden sich.

CAEP beschreibt eine Änderung. Der Empfänger entscheidet per Richtlinie, ob er Zugriff verweigert, Sitzungen widerruft, erneute Authentifizierung verlangt, Rechte reduziert oder nur protokolliert.

CAEP-Ereignisse für laufenden Zugriff

• Device compliance change. Übermittelt eine Änderung des Compliance-Status. Der Empfänger muss Gerät, Benutzer, Sitzungen und Ressourcen korrekt korrelieren.
• Session revoked. Meldet den Widerruf einer Sitzung; jeder Enforcement Point benötigt weiterhin einen Mechanismus, sie abzulehnen.
• Credential change. Meldet eine relevante Credential-Änderung, die Sitzungsprüfung oder erneute Authentifizierung auslösen kann.
• Token claims change. Meldet geänderte Claims bereits ausgestellter Tokens.
• Assurance level change. Meldet ein geändertes Assurance-Niveau, das Step-up oder eingeschränkten Zugriff auslösen kann.

Ein belastbarer Durchsetzungspfad

• 1. Erkennen. Eine Posture-Quelle erkennt eine relevante Änderung und unterscheidet nicht konform, unbekannt, veraltet und Fehler.
• 2. Normalisieren. Die Evidenz wird einer definierten Zustandsänderung und stabilen Subject-ID zugeordnet; Quelle, Zeit und Richtlinienversion bleiben erhalten.
• 3. Übermitteln. Ein signiertes SET wird per autorisiertem Push- oder Poll-Stream mit minimal erforderlichem Subject-Kontext gesendet.
• 4. Validieren und korrelieren. Der Empfänger prüft das Ereignis und löst Gerät, Benutzer, aktive Sitzungen und Ressourcen eindeutig auf.
• 5. Entscheiden. Lokale Richtlinie bewertet Ereignis, Ressourcensensitivität, Aktualität, Ausnahmen und Sitzungskontext.
• 6. Durchsetzen. Die Entscheidung erreicht Gateway, Anwendung, Resource Server oder Sitzungsdienst und wird dort verifiziert.
• 7. Erklären und protokollieren. Benutzer erhalten einen verständlichen Grund und Wiederherstellungsweg; Erkennung, Entscheidung und Ergebnis bleiben nachweisbar.

Mehr als die JWT-Signatur validieren

• Nur konfigurierte Issuer und Stream-Beziehungen akzeptieren; Algorithmus und Schlüssel gegen vertrauenswürdige Metadaten prüfen.
• Audience, Ereignistyp, Pflicht-Claims, Subject-Format und Zeitbedingungen validieren.
• SET-ID wie jti für Replay-Schutz und idempotente Verarbeitung verwenden.
• Schlüsselrotation und Metadatenaktualisierung sicher behandeln.
• Mandanten-, Geräte- und Sitzungskorrelation gegen Verwechslung schützen; Mehrdeutigkeit als Fehler behandeln.

Verspätete, doppelte und ungeordnete Signale einplanen

Push- und Poll-Zustellung kann fehlschlagen, erneut versuchen oder Ereignisse ungeordnet liefern. Erforderlich sind begrenzte Retries, Bestätigungen, Deduplizierung, Backlog-Überwachung, Dead-Letter-Verarbeitung und eine Ordnungsregel auf Basis vertrauenswürdiger Zeitdaten.

Ein veraltetes Recovery-Ereignis darf keinen neueren Sperrzustand überschreiben. Definieren Sie autoritative Quellen, Evidenzgültigkeit und Verhalten bei widersprüchlichen oder ausgefallenen Sendern.

Ein zur Sitzungsarchitektur passendes Enforcement-Muster wählen

• Zentraler Sitzungszustand. Ein gemeinsamer Sitzungsdienst markiert Sitzungen als gesperrt oder eingeschränkt.
• Widerrufs- oder Richtliniencache. Gateways verwenden kompakte Zustände wie Sicherheitsversion, revoked-after-Zeitpunkt oder gezielten Deny-Eintrag.
• Token Introspection. Ressourcen fragen einen Autorisierungs- oder Richtliniendienst, benötigen dafür aber eine belastbare Live-Abhängigkeit.
• Direkte Invalidierung. Ein Prozessor verteilt Sitzungs- oder Richtlinienupdates mit Bestätigung und Abgleich an Enforcement Points.
• Gestaffeltes Auffangnetz. Begrenzte Token- und Sitzungslaufzeiten verhindern unbegrenzt gültigen Zugriff bei Ausfall des Signalpfads.

Was heutige Produktunterstützung belegt

• Microsoft Entra. Microsoft dokumentiert CAE für unterstützte Dienste, Clients, kritische Benutzerereignisse und Standortänderungen. Die Abdeckung ist nicht universell; Microsoft nennt nahezu Echtzeit, mögliche Verzögerungen bis 15 Minuten und weitere Einschränkungen.
• Jamf Security Cloud. Jamf dokumentiert einen SSF Transmitter für CAEP device-compliance-change bei Änderungen des Apple-Gerätemanagementstatus. Korrelation und Durchsetzung bleiben Aufgabe des Empfängers.
• Keycloak. Stand Juli 2026 ist SSF-Transmitter-Unterstützung experimentell, standardmäßig deaktiviert und nicht für Produktion empfohlen. Keycloak ist dabei kein allgemeiner Empfänger für Geräte-Posture-Ereignisse.

Fragen für Anbieterprüfungen

• Welche Posture-Änderungen erzeugen ein Signal, wie werden sie erkannt und wie hoch ist die End-to-End-Latenz?
• Welche SSF-/CAEP-Versionen, Ereignisse, Subject-Formate und Zustellmethoden werden unterstützt?
• Welche Aktion löst jedes Ereignis je Ressourcenklasse aus?
• Wie werden Signale authentifiziert, dedupliziert, geordnet, erneut zugestellt, überwacht und nach Ausfällen abgeglichen?
• Wie werden Gerät, Benutzer, Mandant und Sitzung ohne mandantenübergreifende Fehlzuordnung korreliert?
• Was geschieht bei veralteter, fehlender, widersprüchlicher oder wiederhergestellter Posture?
• Welche Anwendungen, APIs, Hintergrundkanäle und kollaborativen Sitzungen setzen die Entscheidung vor Token-Ablauf um?

Abbildung in einer Gideon-Evaluierung

Prüfen Sie Gideon Identity und Endpoint Management als durchgängigen Signal-zu-Enforcement-Pfad. Verifizieren Sie beobachtete Bedingungen, Aktualität, Subject-Korrelation, Richtlinienentscheidung, Durchsetzung und Wiederherstellung. Fordern Sie Messwerte je Plattform und Signal statt eines universellen Echtzeitversprechens.

Weiterführende Inhalte

• Trennen Sie Credential-, Geräte- und Sitzungskontrollen mit Gerätegebundene Authentifizierung vs. konventionelle MFA.
• Prüfen Sie Aktualität und Lifecycle-Durchsetzung in Zero-Touch Endpoint Management für Security-Teams.
• Entdecken Sie Gideon Identity.

Primärquellen

• Die OpenID Foundation definiert Streams, Sender, Empfänger und Zustellung in der OpenID Shared Signals Framework 1.0 Final Specification.
• CAEP-Ereignistypen stehen in der OpenID Continuous Access Evaluation Profile 1.0 Final Specification.
• Die IETF definiert SETs in RFC 8417.
• Microsoft dokumentiert CAE unter Kontinuierliche Zugriffsbewertung in Microsoft Entra.
• Jamf dokumentiert seinen Ereignispfad in Shared Signals Framework und CAEP.
• Keycloak beschreibt Umfang und Warnhinweis der experimentellen SSF-Unterstützung.

So verwenden Sie diese Ressource

Ordnen Sie eine folgenschwere Posture-Änderung von Erkennung bis Wiederherstellung zu. Messen Sie jede Übergabe, testen Sie doppelte und ungeordnete Zustellung sowie Sperren und Recovery in repräsentativen Anwendungen und bewahren Sie die Ergebnisse als Abnahmenachweis auf.