Die Anforderung höre ich immer wieder: Beim Browserzugriff von nicht verwalteten Geräten sollen Unternehmensdaten geschützt bleiben, ohne dass die Benutzer kaum noch arbeiten können. Besonders bei Gastzugriffen, BYOD und im Außendienst ist das ein Dauerthema. Conditional Access App Control mit Microsoft Defender for Cloud Apps (MDCA) löst das schon seit Jahren auf recht pragmatische Weise. Der Datenverkehr läuft über einen Reverse-Proxy und lässt sich dort sehr fein überwachen, protokollieren oder einschränken. Wer die Details sauber einrichtet und die Einschränkungen kennt, bekommt damit eine erstaunlich zuverlässige Lösung.

Ein Reverse-Proxy schaltet sich zwischen Benutzer und Cloud-App

Im Kern leitet Conditional Access App Control die Sitzungen bestimmter Benutzer und Geräte nicht direkt zur Anwendung, sondern über einen zwischengeschalteten Proxy. Dadurch kann MDCA in Echtzeit eingreifen und zum Beispiel Downloads blockieren oder überwachen. Gesteuert wird das Ganze in Entra ID. Eine Conditional-Access-Richtlinie legt dort fest, dass beim Zugriff auf z. B. Exchange Online oder SharePoint von nicht konformen oder nicht hybrid eingebundenen Geräten statt der normalen Anmeldung die Sitzungssteuerung „Use Conditional Access App Control“ greift. Von da an übernimmt der Reverse-Proxy.

Was dabei im Hintergrund passiert, ist auf den ersten Blick oft nicht klar. Ich habe das Prinzip deshalb in einem einfachen Diagramm skizziert:

flowchart TD
  user["Benutzer (unverwaltetes Gerät)"] --> ca_policy["Conditional Access Policy"]
  ca_policy --> proxy["MDCA Reverse Proxy"]
  proxy --> app["Cloud App (z.B. SharePoint)"]
  app --> proxy
  proxy --> user

Abbildung: Sitzungsfluss bei Conditional Access App Control für nicht verwaltete Geräte.

Solange der Benutzer im Browser arbeitet, merkt er von dem Umweg über den Proxy kaum etwas. Hier liegt allerdings auch die wichtigste Einschränkung: Native Clients wie Outlook, die Teams-App oder der OneDrive-Client werden nicht unterstützt. Das Verfahren funktioniert ausschließlich mit Web-Apps, und zwar in einem modernen, unterstützten Browser.

Die Konfiguration verteilt sich auf Entra ID und das Defender-Portal

Los geht es in Entra ID (Microsoft Entra Admin Center → Schutz → Conditional Access). Dort lege ich eine neue Richtlinie an, wähle die gewünschten Cloud-Apps aus (z. B. Exchange Online, SharePoint Online, Teams) und beschränke sie auf die Benutzer und Gruppen, für die das Verhalten gelten soll. Als Bedingung verwende ich in der Praxis fast immer Gerätefilter, entweder „nur nicht konforme Geräte“ oder Device Tags für hybrid eingebundene bzw. konforme Geräte. Zum Schluss aktiviere ich unter Sitzungssteuerung die Option „Use Conditional Access App Control“ und schalte die Richtlinie auf „On“.

Im nächsten Schritt wechsle ich ins Defender-Portal (defender.microsoft.com → Cloud Apps → Richtlinien → Sitzungsrichtlinie). Dort lässt sich beispielsweise eine Richtlinie anlegen, die Downloads aus SharePoint oder OneDrive blockiert, solange der Zugriff über den MDCA-Proxy läuft. Ebenso kann ich Downloads schützen, indem automatisch ein Sensitivity Label vergeben wird. Eine dritte Variante besteht darin, sämtliche Aktivitäten zu protokollieren und riskantes Verhalten per Alerts zu überwachen, was sich bei Gastzugriffen sehr bewährt hat. Einen guten Überblick über die Möglichkeiten bietet die Dokumentation zu Sitzungsrichtlinien.

Aus Erfahrung: Testet jede Kombination aus Sitzungsrichtlinien und Conditional-Access-Einstellungen gründlich im eigenen Tenant, vor allem dann, wenn mehrere Richtlinien auf dieselbe App wirken. Sonst rutschen unerwünschte Wechselwirkungen leicht durch.

App-enforced Restrictions setzen direkt in der Anwendung an

Der Proxy-Ansatz passt nicht in jedes Szenario. Gerade bei komplexen SharePoint-Anwendungen oder Integrationen kommt es mit Conditional Access App Control gelegentlich zu Kompatibilitätsproblemen. Für SharePoint Online und Exchange Online gibt es deshalb zusätzlich die App-enforced Restrictions. Hier wird kein Datenverkehr umgeleitet, die nativen Apps kommunizieren direkt mit den Microsoft-Diensten. SharePoint bzw. Exchange erkennen anhand von Claims, dass ein nicht konformes Gerät im Spiel ist, und schränken Download, Drucken oder Synchronisierung ein. Diese Variante ist etwas weniger flexibel, läuft aber deutlich stabiler und funktioniert auch im nativen Webclient.

Aus Gründen der Performance oder Kompatibilität kombinieren viele Admins beide Verfahren: Conditional Access App Control für die wichtigsten Apps, App-enforced Restrictions für die problematischen Fälle. Das verbessert das Nutzererlebnis, ohne den Schutz aufzuweichen. Weitere Informationen finden sich unter Conditional Access Session Controls.

Lizenzen und unterstützte Browser sorgen oft für Überraschungen

Für Conditional Access App Control braucht man Microsoft Defender for Cloud Apps, also für jeden betroffenen Benutzer mindestens eine Lizenz für Microsoft 365 E5, EMS E5 oder eine eigenständige MDCA-Lizenz. Wer sich auf App-enforced Restrictions beschränkt, kommt ohne MDCA aus. Nicht vergessen sollte man die Gäste: Auch für sie muss eine passende Lizenzierung eingeplant werden, wenn sie unter den Schutz fallen sollen. Im B2B-Umfeld führt genau das häufig zu Diskussionen.

In der Praxis sehe ich oft, dass die Liste der unterstützten Browser und Apps ignoriert wird. Nicht jede Web-App arbeitet von Haus aus mit dem Proxy zusammen, und manche Funktionen wie Co-Authoring in Office Online oder bestimmte SharePoint-Integrationen verhalten sich anders als gewohnt. Native Apps lassen sich ohnehin nicht steuern; mit Conditional-Access-Richtlinien bleibt dort nur die vollständige Blockierung. Wer sich mit den Grundlagen und bewährten Vorgehensweisen bei Conditional Access genauer beschäftigen möchte, findet mehr dazu in meinem Artikel Conditional Access in Microsoft Entra ID: Die ersten Richtlinien für jeden Tenant.

Das Werkzeug ist mächtig, solange man seine Grenzen kennt

Mit Conditional Access App Control lassen sich Unternehmensdaten beim Zugriff von nicht verwalteten Geräten sehr gezielt schützen, und die Nachvollziehbarkeit steigt deutlich. In vielen Tenants, die ich mir ansehe, bleibt davon allerdings einiges ungenutzt, meist weil die Details zu kurz gekommen sind oder niemand die Einschränkungen beachtet hat. Wer Proxy-Steuerung (MDCA) und App-enforced Restrictions sauber auseinanderhält, gründlich testet und die Lizenzierung nicht aus den Augen verliert, erreicht einen wirksamen Schutz, mit dem die Benutzer trotzdem gut arbeiten können.