Conditional Access sperrt Admin-Portale für ungeprüfte Geräte

Wer einen Microsoft-365- oder Azure-Tenant verwaltet, weiß, dass Identitäten inzwischen Angriffsziel Nummer eins sind. In den vergangenen Monaten ist mir trotzdem immer wieder aufgefallen, wie oft privilegierte Zugriffe auf Admin-Portale wie Microsoft Entra, Microsoft 365, Exchange Online oder das Azure-Portal noch von beliebigen Geräten aus stattfinden. Häufig genügt dann ein gestohlenes Session-Token auf einem privaten Laptop, und ein Angreifer kann den Tenant lahmlegen oder sensible Daten abziehen. Dabei lässt sich dieses Risiko technisch längst sauber begrenzen. Mit Conditional Access, der Überwachung der Gerätecompliance und phishingsicherer Authentifizierung schränkt man den Zugriff auf die Admin-Portale gezielt ein.

Admin-Portale brauchen strengere Regeln als der restliche Tenant

Besonders bei Directory-Rollen mit weitreichenden Rechten kommt es auf den Schutz der Admin-Portale an. Angreifer suchen dort gezielt nach Lücken. Ein kompromittiertes Gerät, eine zu lasche MFA-Richtlinie oder ein schlecht geschützter Browser reicht ihnen schon als Sprungbrett in den Tenant. In vielen Tenants, die ich mir ansehe, gibt es zwar MFA-Richtlinien für alle Benutzer, für die Admin-Portale aber keine eigenen Regeln. Ausgerechnet diese Einstiegspunkte verlangen jedoch höhere Sicherheitsstandards. Microsoft rät inzwischen selbst dazu, Admin-Konten nur noch auf „compliant devices“ und mit phishingsicherer MFA zuzulassen. Wie das mit Conditional Access konkret aussieht, beschreibe ich in den folgenden Abschnitten.

Die Richtlinie richtet sich an Directory-Rollen statt an einzelne Benutzer

Grundlage ist eine eigene Conditional-Access-Richtlinie, die nur für Benutzer mit Directory-Rollen („Directory roles“) gilt und die Admin-Portale als Zielressource festlegt. Dazu gehören vor allem:

• „Microsoft Administrator Portals“ (alle zentralen Admin-Portale)
• „Windows Azure Service Management API“ (für Zugriffe auf das Azure-Portal)

Auf diese Weise sind auch Tools und PowerShell-Zugriffe sauber erfasst, die über das Azure-Portal laufen. Als Zielgruppe wählt man dabei nicht wie gewohnt „User“ aus, sondern verweist auf die Rollen, so wie es der Artikel auf Microsoft Learn beschreibt. Wer das einmal im eigenen Tenant aktiviert hat, wundert sich, wie viele Admins sofort betroffen sind, darunter auch die Rolle „Exchange Admin Center“ und weitere Spezialrollen.

Die Grant Controls verlangen ein konformes Gerät und phishingsichere MFA

Wie hoch das Sicherheitsniveau tatsächlich ausfällt, bestimmen die Grant Controls der Richtlinie. Ich empfehle „Require device to be marked as compliant“ zusammen mit „Require authentication strength: phishing-resistant MFA“. Die Compliance überwacht Intune. Zugriff bekommen nur Geräte, die sämtliche Compliance-Richtlinien erfüllen, in der Regel also Windows 11 mit BitLocker, aktuellem Patchstand und ohne Jailbreak. Bei der Anmeldung genügt dann nicht mehr ein beliebiger zweiter Faktor. Gefordert sind etwa FIDO2, Certificate-based Authentication oder die passwortlose Anmeldung per Authenticator. Ausführlicher gehe ich darauf in meinem Beitrag zu phishingsicherer MFA für Admins ein.

Vor dem Rollout muss getestet werden, gerade in größeren Umgebungen. Mit dem Modus „Report-only“ vermeidet man Kollateralschäden, weil sich in Ruhe auswerten lässt, welche Admins und Geräte betroffen wären, bevor die Richtlinie greift. „Report-only“ und das klassische What-If-Tool in Conditional Access haben jeweils eigene Stärken, und beide haben mir schon oft geholfen, Fehlschläge zu verhindern (weitere Tipps).

Break-Glass-Konten bleiben von jeder Admin-Richtlinie ausgenommen

Ohne Notzugang ist kein Sicherheitskonzept vollständig. Mindestens ein Break-Glass-Konto, besser zwei, gehört aus allen Conditional-Access-Richtlinien herausgenommen, die Compliance oder starke Authentifizierung voraussetzen. So sperrt man sich bei einem Konfigurationsfehler nicht komplett aus. Bewährt hat sich bei mir eine eigene Gruppe für die Break-Glass-Konten, die ich in jeder neuen Admin-Richtlinie ausdrücklich ausschließe. Auch bei späteren Änderungen darf dieser Ausschluss nicht verloren gehen. Wie man Break-Glass-Konten sicher und alltagstauglich einrichtet, habe ich in diesem Beitrag ausführlich beschrieben.

Aus der Praxis: Sobald eine Richtlinie produktiv läuft, sollte man die Break-Glass-Konten mindestens einmal im Monat auf Erreichbarkeit und Funktion prüfen. Andernfalls ist im Ernstfall genau dieses Konto gesperrt. Bei Mandanten habe ich das leider schon erlebt.

Ein konformes Gerät ist noch keine Privileged Access Workstation

Viele halten ein „Compliant Device“ irrtümlich für eine vollwertige Privileged Access Workstation (PAW). Häufig sehe ich, dass Admins ihr normales Arbeitsgerät compliant bekommen und es anschließend auch privat und für E-Mails verwenden. Eine echte PAW dient dagegen ausschließlich privilegierten Aufgaben. Sie ist abgeschottet und gehärtet, Office-Mails und Browser-Add-ons haben darauf nichts verloren. Die Compliance-Richtlinie in Intune kann dazu beitragen, ein durchdachtes Betriebskonzept ersetzt sie aber nicht. Wer das Thema ernst nimmt, betreibt PAWs als dedizierte Hardware mit restriktiven Richtlinien und getrenntem Netzwerk.

Ein Diagramm zeigt den Ablauf der Zugriffsprüfung

Um zu veranschaulichen, wie Conditional Access den Zugriff auf Admin-Portale steuert, habe ich ein kleines Diagramm erstellt:

graph TD
    Admin["Admin (mit Directory-Rolle)"] --> Device["Gerät (Compliance geprüft)"]
    Device --> MFA["Phishingsichere Authentifizierung"]
    MFA --> Portal["Admin-Portal (CA Policy)"]
    BreakGlass["Break-Glass-Konto"] --> Portal
    Portal --> Zugriff["Zugriff gewährt"]

Abbildung: Zugriff auf Admin-Portale erst nach Compliance- und MFA-Prüfung, mit dem Break-Glass-Konto als Ausnahme.

Ins Admin-Portal gelangt man also nur, wenn das Gerät compliant ist und die Anmeldung phishingsicher erfolgt. Davon ausgenommen ist allein das Break-Glass-Konto.

Ich sichere Admin-Portale heute in jedem Projekt von Anfang an ab

Bei jedem neuen Projekt sorge ich dafür, dass die Admin-Portale abgesichert sind und sich tatsächlich nur von geprüften, restriktiv konfigurierten Geräten aus erreichen lassen. Saubere Conditional-Access-Richtlinien mit Compliance-Prüfung und phishingsicherer Authentifizierung kosten wenig Aufwand und bringen viel Sicherheit. Die meisten Stolpersteine liegen woanders, nämlich bei der konsequenten Trennung von PAWs und Alltagsgeräten und beim regelmäßigen Test der Break-Glass-Konten. Wer seine Admin-Portale bisher nicht auf diese Weise schützt, sollte das laut aktueller Ankündigung bald nachholen. Die Angreifer warten nicht.