Conditional Access: Gerätekonformität als Zugriffsbedingung

„Nur konforme Geräte erhalten Zugriff“ ist ein Satz, der in jeder Zero-Trust-Präsentation steht. Als Richtlinie ist er in etwa fünf Minuten geklickt. Die Arbeit liegt an einer anderen Stelle, als die meisten erwarten.

Die Richtlinie ist nur die halbe Aussage

Die Grant-Control „Require device to be marked as compliant“ prüft genau ein Ja/Nein-Flag am Geräteobjekt in Entra ID. Dieses Flag setzt Intune, und zwar auf Basis der Compliance-Richtlinien, die dort definiert sind.

Daraus folgt der Punkt, an dem es in der Praxis hängt: Die Conditional-Access-Richtlinie ist exakt so streng wie die Compliance-Definition dahinter. Ist dort nichts Substanzielles hinterlegt, ist jedes eingeschriebene Gerät konform, und die Richtlinie prüft im Ergebnis nur noch, ob das Gerät überhaupt verwaltet wird. Das ist nicht wertlos, aber es ist etwas anderes als das, was draufsteht.

Genau deshalb halte ich Identity und Endpoint Management nicht für zwei Themen. Die Zugriffsentscheidung fällt in der Identitätsebene, aber die Tatsache, auf die sie sich stützt, entsteht auf dem Gerät.

Die Kette, die stimmen muss

Damit ein Gerät als konform in das Token kommt, muss eine ganze Reihe zusammenpassen:

1. 1.Das Gerät ist in Entra ID registriert, eingebunden oder hybrid eingebunden
2. 2.Es ist in Intune eingeschrieben und meldet sich regelmäßig zurück
3. 3.Ihm ist eine Compliance-Richtlinie zugewiesen, nicht nur eine, die irgendwo existiert
4. 4.Es hat die Auswertung bestanden
5. 5.Der Client meldet die Geräteidentität beim Anmelden überhaupt mit

Der letzte Punkt ist der, der die überraschenden Fehlschläge produziert. Nicht jeder Client übermittelt seine Geräteidentität. Bricht die Kette an dieser Stelle, wird nicht „nicht konform“ gemeldet. Es kommt schlicht keine Information an, und die Richtlinie blockiert.

Report-only ist kein Zwischenschritt

Jede Zugriffsrichtlinie geht bei mir zuerst in den Report-only-Modus. Sie wird dann vollständig ausgewertet und protokolliert, greift aber noch nicht.

Nach ein paar Tagen zeigen die Anmeldeprotokolle pro Anmeldung, wie die Richtlinie entschieden hätte. Interessant ist dabei weniger, wer bestanden hätte, sondern wer durchgefallen wäre und warum: der Dienstleister mit dem nicht verwalteten Notebook, der Linux-Client in der Entwicklung, das Konferenzraum-Gerät, an das niemand mehr gedacht hat.

Diese Liste ist der eigentliche Wert der Übung. Sie ist in der Regel länger als erwartet, und jeder Eintrag darauf ist eine Entscheidung, die vor dem Scharfschalten getroffen werden muss: Ausnahme, Migration oder bewusstes Blockieren.

Break-Glass zuerst, nicht zuletzt

Eine Conditional-Access-Richtlinie kann alle Administratoren gleichzeitig aussperren, sich selbst eingeschlossen. Der Fall ist nicht theoretisch: Es reicht eine Richtlinie, die ein Gerät fordert, das der Administrator gerade nicht zur Hand hat.

Deshalb existieren Break-Glass-Konten. Sie sind reine Notfallkonten, an keine Person gebunden, mit sehr langen Zufallspasswörtern und phishing-resistenter Authentifizierung. Wichtig sind vor allem drei Dinge: Es sind zwei, nicht eines. Sie sind von den Richtlinien ausgenommen, die sie aussperren könnten. Und ihre Anmeldungen lösen eine Warnung aus, weil eine Anmeldung mit einem solchen Konto entweder ein Notfall ist oder ein Vorfall.

Ein Notfallzugang, der nie getestet wurde, ist kein Notfallzugang. Es lohnt sich, das einmal im Quartal auszuprobieren, bevor man es zum ersten Mal wirklich braucht.