Von Aaron Siller, Microsoft MVP
Wie schützt Compliant Network gegen Token-Replay?
Compliant Network in Entra ID kann die Einlösung gestohlener Refresh Tokens außerhalb Deines vorgesehenen Netzwerkpfads blockieren. Voraussetzung: Der Zugriff fällt unter eine aktive Conditional-Access-Policy, die das mandantenspezifische Signal von Microsoft Entra Global Secure Access verlangt. Ein bereits ausgestelltes Access Token wird dadurch nicht automatisch ungültig. Microsoft beschreibt diese Trennung in der Dokumentation zu Compliant Network.
Der praktische Nutzen: Ein Angreifer soll mit erbeuteten Anmeldedaten für eine Sitzung nicht einfach von seiner eigenen Infrastruktur aus neue Zugriffe aufbauen können. Du ergänzt Deine Identitätskontrollen um die Frage, ob die Anfrage tatsächlich über den vorgesehenen Zugang Deines Unternehmens kommt.
Den Anlass liefert das Entra.Chat-Interview mit Alexander Pavlovsky und Marilee Turscak, moderiert von Merill Fernando. Dort zeigen die Microsoft-Produktmanager eine Sperrregel außerhalb des konformen Netzwerks. Für Deinen Tenant zählt jedoch der überprüfte Geltungsbereich: Welche Benutzer, Ressourcen und Token-Anfragen deckt Deine Policy ab?
Die folgende Anleitung konzentriert sich deshalb auf einen kontrollierten Pilot. Die übergreifenden Schutzmaßnahmen findest Du im Beitrag zu Token-Diebstahl und Conditional Access bei Entra ID.
PRT, Refresh Token und Access Token: Wo greift die Kontrolle?
„Token“ bezeichnet unterschiedliche Artefakte. Für Deine Tests musst Du die Anforderung eines neuen Zugriffs von der Nutzung einer bestehenden Berechtigung unterscheiden.
| Artefakt | Aufgabe | Grenze beim Compliant-Network-Pilot |
|---|---|---|
| Primary Refresh Token, kurz PRT | Unterstützt Single Sign-on auf dem Gerät. | Conditional Access wird bei Ausstellung und Erneuerung des PRT nicht ausgewertet. |
| Refresh Token | Ermöglicht die Anforderung neuer Access Tokens. | Erfasste Token-Anfragen können außerhalb des vorgeschriebenen Netzwerkpfads scheitern. |
| Access Token | Berechtigt zum Zugriff auf eine Ressource. | Bereits ausgestellte Tokens können weiter funktionieren; die Ressource und ihre CAE-Unterstützung sind entscheidend. |
Die PRT-Grenze ist in Microsofts Beschreibung des Primary Refresh Token ausdrücklich dokumentiert. Eine Policy für eine einzelne Anwendung deckt daher auch nicht automatisch alle weiteren SSO- und Ressourcenpfade ab.
Bei Ressourcen ohne Continuous Access Evaluation, kurz CAE, können Access Tokens bis zum Ablauf gültig bleiben; die Standardlebensdauer liegt bei 60–90 Minuten. Compliant Network ist außerdem keine kryptografische Gerätebindung. Diese Grenzen beschreibt die oben verlinkte Compliant-Network-Dokumentation. Token Protection ist eine separate Kontrolle für unterstützte Szenarien.
Für Deine Bewertung bedeutet das: „Neue Anmeldung blockiert“ und „bestehende Sitzung beendet“ sind zwei verschiedene Testergebnisse. Halte beide getrennt fest. Sonst erscheint ein noch geöffnetes Browserfenster entweder als vermeintlicher Fehler oder als übersehene Schutzlücke.
Welche Voraussetzungen brauchst Du mit Entra ID P1?
Die Compliant-Network-Funktion und das Microsoft-Datenverkehrsprofil gehören zu Entra ID P1/P2. Daraus folgt keine Lizenzierung sämtlicher Funktionen von Microsoft Entra Internet Access oder Microsoft Entra Private Access. Microsoft führt die Unterschiede in der Global-Secure-Access-Übersicht auf.
Für diesen Pilot verwendest Du den Global Secure Access Client auf einem vorgesehenen Arbeitsgerät. Microsoft bietet Clients für Windows, macOS, Android und iOS an; prüfe die jeweilige Plattformunterstützung in der Client-Dokumentation. Stelle sicher, dass das Microsoft-Datenverkehrsprofil aktiviert und der Client verbunden ist.
Für die Einrichtung brauchst Du die Rollen Global Secure Access Administrator und Conditional Access Administrator. Öffne im Entra Admin Center Global Secure Access > Settings > Session management > Adaptive access und prüfe Enable Conditional Access Signaling for Microsoft Entra ID. Dieser Schalter aktiviert auch Source IP Restoration; dafür gibt es hier keinen zweiten Aktivierungsschritt. Bei neuen Tenants ist er standardmäßig aktiv. Wurde GSA vor Juni 2025 aktiviert, kann die manuelle Aktivierung nötig sein. Microsoft erläutert das im Tutorial zu Source IP Restoration. Das Compliant-Network-Pilottutorial nennt Source IP Restoration als Voraussetzung.
Kontrolliere anschließend, ob „All Compliant Network locations“ als besondere benannte Netzwerkadresse verfügbar ist. Sie steht für das GSA-Signal Deines Tenants, nicht für eine beliebige vertrauenswürdige öffentliche IP-Adresse. Ein konformes Gerät aus einem anderen Tenant erfüllt Deine Bedingung nicht automatisch.
Remote Networks sind eine alternative Anbindung, haben aber eine eigene Mindestanforderung von 50 anwendbaren Lizenzen laut der Microsoft-Übersicht. Diese Mindestmenge gilt nicht pauschal für den Client-Pilot. Vermische die beiden Bereitstellungswege deshalb weder bei der Kostenprüfung noch bei Deiner technischen Planung.
Lege außerdem fest, wer die GSA-Konfiguration und wer die Conditional-Access-Regel betreut. Für die Architektur dahinter genügt zunächst der Überblick zu Global Secure Access als SSE-Lösung.
Wie bereitest Du Pilot und Notfallzugang vor?
Wähle eine kleine Pilotgruppe, eine konkrete Testanwendung und ein Zeitfenster, in dem Du Unterstützung leisten kannst. Ein erfolgreich geöffneter Dienst ist noch kein ausreichender Pilot: Du willst auch den vorgesehenen Sperrfall verstehen und den Zugang zuverlässig wiederherstellen können.
Notfallkonto zuerst überprüfen
Nimm Deine Break-Glass-Konten ausdrücklich aus der neuen Sperrregel heraus. Prüfe vor dem Einschalten, ob der dokumentierte Notfallzugang funktioniert und ob Du damit die Policy deaktivieren kannst. Ein vorhandener Kontoname in einer Liste ersetzt diesen Test nicht.
Schreibe vorab auf, wer einen Abbruch entscheiden darf und wie diese Person bei einem Zugriffsproblem erreichbar bleibt. Plane einen Kommunikationsweg, der auch dann funktioniert, wenn die Testanwendung blockiert ist. Diese Vorbereitung verhindert, dass ein technischer Pilot zu einem unkoordinierten Ausfall wird.
Erfolgskriterien und Ausnahmen festhalten
Definiere drei erwartete Ergebnisse: Frische Anmeldung mit Client funktioniert, frische Anmeldung ohne vorgesehenen Pfad wird bei aktiver Pilotregel blockiert, Anmeldung nach Wiederherstellung funktioniert erneut. Notiere für Ausnahmen jeweils Zweck, Verantwortlichen und Prüfdatum.
Erfasse auch die üblichen Arbeitswege der Pilotpersonen: Büro, Homeoffice, mobile Nutzung und gegebenenfalls Gastzugriff. Du musst nicht alle Varianten am ersten Tag testen. Du musst aber wissen, welche davon vor einer Erweiterung noch offen sind.
Informiere die Pilotpersonen darüber, wann Du den Client-Pfad im Test unterbrichst und welche Anwendung vorübergehend nicht erreichbar sein soll. Vereinbare, dass sie unerwartete Auswirkungen mit Uhrzeit und betroffener Anwendung melden. Dadurch kannst Du geplante Sperren von Nebenwirkungen unterscheiden. Halte eine kurze Ausgangsbeschreibung bereit: Welche Verbindung und welche Anmeldeschritte funktionieren vor der Änderung? Dieser Vergleich hilft Dir später, die Wiederherstellung zu überprüfen, ohne Dich auf Erinnerungen zu verlassen.
Wie konfigurierst Du die Policy in Conditional Access?
Das Grundmuster aus dem Interview ist eine Sperrregel mit Netzwerkausnahme. Das Microsoft-Pilottutorial setzt dafür zunächst auf einen begrenzten Benutzer- und Ressourcenbereich. Übertrage dieses Muster im Entra Admin Center:
Die Logik lautet: Die Sperre gilt überall außerhalb des vorgesehenen konformen Netzwerks. Kontrolliere insbesondere, dass Du die benannte Netzwerkadresse tatsächlich ausgeschlossen hast. Eine vertauschte Auswahl würde ein anderes Verhalten erzeugen als beabsichtigt.
Report-only wertet die Policy aus und protokolliert das Ergebnis, erzwingt aber keine Sperre. Das erläutert Microsoft beim Report-only-Modus von Conditional Access. Nutze diese Phase, um betroffene Arbeitswege zu erkennen. Erst danach aktivierst Du die Regel für den begrenzten Pilot, um das tatsächliche Blockieren zu testen.
„All resources“ kommt als Erweiterung nach dem Pilot infrage. Eine einzelne Testressource liefert keinen Nachweis für tenantweite Abdeckung. Prüfe vor der Erweiterung zusätzliche Anwendungen, Benutzergruppen und Ausnahmen; die breite Auswahl aus der Interviewdemo ist kein Ersatz für diese Entscheidung.
Wie vermeidest Du die Intune-Enrollment-Sackgasse?
Ein neues Gerät braucht möglicherweise erst seine Registrierung und Konfiguration, bevor es den verlangten GSA-Pfad nutzen kann. Sperrst Du diesen Einstieg, verlangst Du eine Voraussetzung, deren Einrichtung Du gleichzeitig verhinderst.
Wenn Du Geräte über Intune einbindest, berücksichtige die dokumentierten Ressourcenausnahmen für Microsoft Intune Enrollment und Microsoft Intune. GSA-Ressourcen werden automatisch ausgenommen; mobile Defender-Szenarien haben zusätzliche Bootstrap-Anforderungen. Die Details stehen in der Compliant-Network-Dokumentation und den aktuellen GSA-Einschränkungen.
Teste deshalb zusätzlich zum eingerichteten Arbeitsgerät einen vorgesehenen Enrollment-Ablauf. Schreibe die Reihenfolge auf: Welche Anmeldung erfolgt zuerst, welche Komponente liefert anschließend die Konfiguration, und ab wann ist der Netzwerkpfad verfügbar? So erkennst Du zirkuläre Abhängigkeiten vor der breiten Aktivierung.
Eine Ressourcenausnahme und eine Benutzerausnahme haben unterschiedliche Reichweiten. Nimm nicht vorsorglich alle mobilen Benutzer aus der Regel. Begründe die benötigte Ausnahme am konkreten Einstieg und prüfe, welche weiteren Zugriffe damit möglich bleiben. Wiederhole diesen Test auch nach Änderungen an Deinem Onboarding.
Wie überprüfst Du Wirkung und Logs?
Arbeite mit einem vorgesehenen Testkonto und frischen Anmeldungen. Für den Funktionsnachweis brauchst Du keine echten gestohlenen Tokens. Ein reproduzierbarer Vergleich des Netzwerkpfads zeigt zunächst, ob Deine Policy im erwarteten Bereich greift.
Mit, ohne und wieder mit Client testen
Melde Dich zuerst mit verbundenem GSA-Client frisch an der ausgewählten Ressource an. Verwende für den nächsten Versuch eine neue Browsersitzung ohne den vorgesehenen Client-Pfad. Bei der aktivierten Pilotregel erwartest Du hier eine Sperre. Stelle danach den Client-Pfad wieder her und wiederhole die frische Anmeldung.
Halte Benutzer, Gerät, Ressource, Zeitpunkt und Policy-Modus für jeden Versuch fest. Verändere möglichst nur den Netzwerkpfad. Wenn Du zugleich Konto, Anwendung und Browser wechselst, kannst Du eine Abweichung kaum einer Ursache zuordnen.
Die konkrete Policy im Anmeldeereignis prüfen
Öffne die zugehörigen Sign-in-Logs und die Conditional-Access-Details. Vergleiche die angewendeten Policies, deren Ergebnis und die betroffene Ressource. Beziehe passende nicht interaktive Anmeldungen ein, wenn Du Token-Anfragen untersuchst. Microsoft erklärt die Ansicht unter angewendete Conditional-Access-Policies prüfen.
Eine Fehlermeldung allein zeigt nicht, welche Kontrolle blockiert hat. Umgekehrt beweist eine erfolgreiche Anmeldung nicht, dass Deine neue Regel beteiligt war. Ordne daher jede Beobachtung dem entsprechenden Ereignis zu und prüfe auch die Konfigurationsänderungen im Audit-Protokoll.
Teste bestehende Sitzungen separat. Notiere, ob Du eine frische Anmeldung, eine Token-Anfrage oder einen Ressourcenaufruf beobachtest. Diese Unterscheidung macht Deinen Pilotbericht für Kollegen nachvollziehbar und verhindert, dass unterschiedliche Vorgänge als widersprüchliche Ergebnisse zusammengefasst werden.
Wann stoppst Du den Rollout und wie rollst Du zurück?
Stoppe die Erweiterung, wenn unerklärte Sperren auftreten, der Enrollment-Test scheitert oder der Notfallzugang nicht verfügbar ist. „Die meisten Benutzer kommen hinein“ ist kein ausreichender Grund, offene Fehler auf weitere Gruppen auszuweiten.
Deaktiviere beim Rückbau zuerst die entsprechende blockierende Conditional-Access-Policy beziehungsweise entferne sie kontrolliert. Schalte erst danach die Signalisierung ab; Microsoft dokumentiert diese Reihenfolge für Compliant Network. Prüfe anschließend eine frische Anmeldung über den wieder vorgesehenen Zugang.
Bewahre die Testergebnisse und den Grund für den Abbruch auf. Teile Deinem Support mit, welche Gruppe betroffen war und welches Verhalten jetzt gilt. Ein Rückbau ist erst abgeschlossen, wenn der Zugang wieder überprüft wurde und die Beteiligten denselben Stand kennen.
Was bleibt außerhalb des Schutzes?
Compliant Network ergänzt Deine Schutzmaßnahmen um ein Netzwerksignal. Es prüft nicht allein den Sicherheitszustand des Endgeräts. Ein kompromittierter Rechner innerhalb des erlaubten Pfads bleibt daher ein eigenes Risiko. Phishingresistente Anmeldung, Gerätekontrollen und begrenzte Berechtigungen bleiben Teil Deiner Absicherung.
Gast- und BYOD-Zugriffe gehören auf die Liste der separat zu prüfenden Arbeitswege. Plane für sie einen unterstützten Zugang und überprüfe ihn gegen den Ressourcen-Tenant. Leite aus einem funktionierenden Client-Pilot keine Freigabe für sämtliche Browser- und Mobilvarianten ab.
Universal Continuous Access Evaluation braucht passende Policies
Universal CAE kann über GSA auch Netzwerkzugänge zu Anwendungen auf Identitätsänderungen reagieren lassen. Gerätebezogene Signale sind dabei Preview. Für die Durchsetzung braucht es die passende Conditional-Access-Policy, etwa eine Anforderung an Gerätekonformität oder eine entsprechende Risikoregel. Microsoft beschreibt die Voraussetzungen bei Universal Continuous Access Evaluation.
Die im Interview genannte Unterbrechung einer SSH-Sitzung ist damit keine pauschale Zusage für jede Sitzung in Deinem Tenant. Prüfe Datenverkehrspfad, Signal und Policy gemeinsam. Dokumentiere eine tatsächlich beobachtete Unterbrechung getrennt von einer konfigurierten Möglichkeit.
Häufige Fragen zu Compliant Network
Reicht Entra ID P1 für das gesamte GSA-Angebot?
Nein. P1/P2 umfasst Compliant Network und das Microsoft-Datenverkehrsprofil. Für weitergehende Funktionen von Microsoft Entra Internet Access und Microsoft Entra Private Access prüfst Du die jeweils benötigten Lizenzen.
Werden alle gestohlenen Tokens sofort ungültig?
Nein. Die Netzwerkbedingung begrenzt erfasste Token-Anfragen. Bereits ausgestellte Access Tokens können weiter gelten; ohne CAE bis zum Ablauf, standardmäßig 60–90 Minuten. Prüfe bestehende Sitzungen separat.
Bedeutet Compliant Network auch ein konformes Gerät?
Nein. Das Signal bestätigt den vorgesehenen GSA-Netzwerkpfad Deines Tenants. Gerätekonformität ist eine eigene Anforderung, die Du mit einer passenden Conditional-Access-Policy durchsetzt.
Blockiert eine Policy im Report-only-Modus?
Nein. Report-only protokolliert die Bewertung. Die tatsächliche Sperre testest Du erst mit einer aktivierten, begrenzten Pilotregel und vorbereitetem Notfallzugang.
Dein nächster Schritt: den Tenant gezielt härten
Starte mit einer kleinen Gruppe, einer Ressource und überprüfbarem Notfallzugang. Erweitere erst, wenn Anmeldung, Sperrfall, Enrollment und Rückbau nachvollziehbar funktionieren. So bekommst Du eine belastbare Grundlage für Deine Entscheidung statt eines pauschalen Versprechens gegen Token-Diebstahl.
Wenn Du die Netzwerkbedingung mit Deinen bestehenden Identitäts- und Gerätekontrollen abstimmen möchtest, ist der Microsoft 365 Hardening Check der passende nächste Schritt. Gemeinsam klären wir, welche Schutzlücken und Ausnahmen in Deinem Tenant zuerst bearbeitet werden sollten.
