Conditional Access richtig gedacht: Device Compliance ist nicht genug

Viele Unternehmen glauben, sie hätten Conditional Access „richtig" umgesetzt, sobald eine Policy aktiv ist wie:

Require compliant device

Das Problem: Diese Konfiguration fühlt sich sicher an, ist es aber nicht.

Sie ist ein einzelner Kontrollpunkt in einem System, das eigentlich aus mehreren Ebenen bestehen muss. In diesem Beitrag zeige ich dir, warum Device Compliance alleine nicht ausreicht und wie du Conditional Access wirklich sinnvoll aufbaust.

Das Grundproblem: Ein Signal ist kein Sicherheitsmodell

Ein compliant device bedeutet:

• Intune sagt: Gerät ist ok
• BitLocker aktiv
• Defender läuft
• OS-Version passt

Je nachdem wie die Compliance in Intune konfiguriert wurde.

Das ist gut, aber es beantwortet nicht:

• Ist der Benutzer legitim?
• Ist das Risiko gerade erhöht?
• Wird von einem ungewöhnlichen Ort zugegriffen?
• Ist der Token kompromittiert?

Du prüfst also nur das Gerät, nicht den Kontext.

Wie Conditional Access wirklich funktioniert

Conditional Access ist kein „Feature", sondern eine Entscheidungsengine.

Sie bewertet mehrere Signale gleichzeitig und trifft dann eine Zugriffsentscheidung:

Je nach Kombination dieser Signale wird entschieden:

• Allow – Zugriff gewährt
• Block – Zugriff verweigert
• Require MFA – Zusätzliche Verifikation nötig
• Require compliant device – Geräteprüfung erzwingen
• Require Hybrid Join – AD-Bindung voraussetzen
• Oder Kombinationen daraus

Der klassische Fehler: Single-Control Policies

Viele bauen Policies so:

IF User = All Users
THEN Require compliant device

Das Problem dabei:

Das ist kein Zero Trust. Das ist „ein bisschen Vertrauen".

Besserer Ansatz: Mehrere Kontrollen kombinieren

Eine saubere Baseline kombiniert mindestens drei Dinge:

1. Device State – Ist das Gerät compliant und verwaltet?
2. MFA – Ist der Benutzer verifiziert?
3. Risk Evaluation – Gibt es aktuell Anzeichen für Kompromittierung?
4. Context – Unter welchen Bedingungen erfolgt der Zugriff (Location, App, Session, Device Type)?

Beispiel: Moderne Baseline Policy

Die Policy-Architektur auf einen Blick

Am Ende sollte dein Conditional Access Setup mindestens diese drei Ebenen abdecken:

Erst mit diesen drei Policies zusammen entsteht ein Sicherheitsmodell, das nicht nur das Gerät, sondern auch den Benutzer, das Risiko und den Kontext berücksichtigt.

Wenn du Fragen oder anregungen hast zu diesem Konzept, lass gerne ein Kommentar da!