Conditional Access: der ultimative Einsteiger-Leitfaden
Einleitung
Heute arbeiten Teams verteilter, und die Sicherheitslage entwickelt sich ständig weiter. Für IT-Security, Identitäten und Access Management bringt das Herausforderungen mit sich. Eine Anmeldung von einem entfernten Standort, Gerät oder einer App kann verdächtig sein oder von einem Angreifer stammen. Wir müssen aber zwischen legitimem und unberechtigtem Zugriff unterscheiden: Die Guten lassen wir rein, die Bösen halten wir draussen.
In diesem Post geht es um Identity & Access Management, sicher und kontrolliert, mit Microsoft-Security-Technologien. Mein Ziel 🎯:
- 💭 Die verschiedenen Entra-Security-Produkte und ihre Beziehung erklären
- ✅ Den Post einfach und verständlich halten, auch für Leute, die Microsoft Security nicht kennen
- 💡 Ideen und technische Umsetzungsanleitungen mit Hinweisen aus der Praxis liefern, um den Zugriff auf Entra ID abzusichern
Kurz und knapp
- Was kannst du schützen? Identitäten: Benutzer oder Workloads, Apps (Enterprise Applications oder App Registrations) oder mit Entra IdP föderierte Anwendungen in Authentifizierungs- und Autorisierungsprozessen.
- Wie schützt du? Wir nutzen Signale 🚦 Signale sind Informationen, die bei jeder Anmeldung mitgeliefert werden. Zum Beispiel: Standorte (Geo oder IP), Geräteplattform, Client Apps, Gerätezustand und Trust Type sowie durch Machine Learning bewertete Risiken.
- Was ist Access Control? Anhand der Signale steuern wir den Zugriff. Der Zugriff kann blockiert oder erlaubt werden, oder er wird mit Bedingungen erlaubt.
- Was kannst du mit Session Control tun? Damit steuern wir die Session-Ebene und wenden eine feinere Kontrolle an.
Komponenten
- Entra ID: Microsofts Identity-&-Access-Management-Lösung, ein zentraler cloudbasierter Identity Provider. Alle Authentifizierungen auf die Ressourcen einer Organisation (wie Microsoft 365 oder SaaS mit föderierten IdPs) werden gegen Entra ID ausgewertet. Entra ID prüft die Authentifizierung (darf jemand zugreifen) und die Autorisierung (darf jemand etwas tun). Mehr dazu
- Conditional Access: Teil von Entra ID und das wichtigste Feature, um den Zugriff anhand verschiedener Bedingungen und Signale zu steuern. Conditional Access ist ein regelbasiertes Feature, das ein IT-Admin konfiguriert. Jede Organisation mit einem Microsoft-365-Abonnement oder mit Azure sollte Conditional Access aktivieren, um mindestens MFA durchzusetzen. Mehr dazu
- Identity Protection: Feature von Entra ID Premium Plan 2, um den Zugriff anhand von Signalen und Machine-Learning-Bewertung zu erlauben oder zu blockieren.
- Authentication Methods: Technologien und Typen, um Multi-Faktor-Authentifizierung nachzuweisen. Beispiele: Microsoft Authenticator, FIDO2 Security Keys und Passkeys, Temporary Access Pass usw.
Lies die Ansätze unten, um zu verstehen, wie diese Komponenten zusammenspielen.
Möglichkeiten einer Conditional Access Policy
| Konfigurationsaspekt | Beschreibung |
|---|---|
| Users | Benutzer, Gruppen, Rollen und andere Identitäten ein- oder ausschliessen |
| Target resources | Cloud Apps, die mit Entra als IdP föderiert sind, ein- oder ausschliessen |
| Network | Netzwerk oder Named Location ein- oder ausschliessen |
| Conditions | Verschiedene Bedingungen und Signale ein- oder ausschliessen: -User risk -Sign-in risk -Insider risk -Device platforms -Locations -Client apps -Filter for devices -Authentication flows |
| Grant | Zugriff blockieren oder erlauben, oder Bedingungen verlangen: -Require multifactor authentication -Require authentication strength -Require device to be marked as compliant -Require Microsoft Entra hybrid joined device -Require approved client app -Require app protection policy -Require password change -Require Terms of Use. Auswählen, ob alle oder eine der gewählten Kontrollen erforderlich sind |
| Session | Session Controls anwenden, um eingeschränkte Nutzung in bestimmten Cloud Apps zu ermöglichen: -Use app enforced restrictions -Use Conditional Access App Control -Sign-in frequency -Persistent browser session -Customize continuous access evaluation -Disable resilience defaults -Require token protection for sign-in sessions -Use Global Secure Access security profile |
Ansätze und Bedingungen
Das sind die Bedingungen und Signale, mit denen wir arbeiten können. Sie werden alle bei jeder (nicht) interaktiven Anmeldeanfrage übermittelt.
- Geografische Standorte erlauben/blockieren: Zugriff aus verschiedenen Ländern mit Conditional Access einschränken, über Named Locations (Zuordnung von IP zu Land)
💡 Empfehlung: Erstelle eine Liste der Länder, aus denen deine Mitarbeitenden auf Daten der Organisation zugreifen dürfen.
- Netzwerkstandorte erlauben/blockieren: bestimmte IP-Adressen oder vertrauenswürdige Netzwerkstandorte von Global Secure Access einschränken
💡 Empfehlung: Erstelle Conditional Access Named Locations mit deinen Breakout- und anderen speziell behandelten IP-Bereichen.
- User-/Sign-in-Risiko: durch Machine Learning bewertete Signale, die Risiken klassifizieren
💡 Empfehlung: Blockiere hohes User-Risiko und mittleres bis hohes Sign-in-Risiko.
- Device Trust Level verlangen (Hybrid Joined oder als compliant markiertes Gerät): unternehmenseigene Geräte, entweder Hybrid Joined oder von Intune als compliant markiert
💡 Empfehlung: Setze Intune Device Compliance ein und erzwinge sie.
Empfohlene Policies
Es ist kein Geheimnis, dass Microsoft dir Conditional Access Templates bereitstellt, die du mit wenigen Klicks aktivieren kannst. Sie sind für jede Organisation ein guter Startpunkt und sollten geprüft werden. Damit dir der Entscheid leichter fällt, habe ich unten eine Tabelle mit einigen Fakten vorbereitet.
| Policy name | Beschreibung | Impact | Security posture benefit | Technical implementation effort |
|---|---|---|---|---|
| Require multifactor authentication for admins | Alle Admins (Rollen) brauchen MFA | 🟩 Low | 🟥 High | 🟩 Low |
| Securing security info registration | Die Registrierung von Security-Infos für MFA ist an Bedingungen geknüpft | 🟧 Medium | 🟧 Medium | 🟩 Low |
| Block legacy authentication | Blockiert Legacy Authentication (Benutzername + Passwort) | 🟧 Medium - 🟥 High | 🟥 High | 🟧 Medium |
| Require multifactor authentication for all users | Alle Benutzer müssen für den Zugriff auf Dienste MFA durchführen | 🟧 Medium | 🟥 High | 🟩 Low |
| Require multifactor authentication for guest access | Alle Gäste müssen für den Zugriff auf Ressourcen MFA durchführen | 🟧 Medium | 🟧 Medium | 🟩 Low |
| Require multifactor authentication for Azure management | Der Portalzugriff auf Azure erfordert MFA | 🟩 Low | 🟥 High | 🟩 Low |
| Require multifactor authentication for risky sign-ins | Von Entra Identity Protection als riskant eingestufte Anmeldungen müssen MFA durchführen | 🟩 Low | 🟧 Medium | 🟩 Low |
| Require password change for high-risk users | Von Entra Identity Protection als riskant eingestufte Benutzer müssen ihr Passwort ändern | 🟩 Low | 🟧 Medium | 🟩 Low |
| Require compliant or Microsoft Entra hybrid joined device for admins | Für Admins ein Intune-compliant oder Hybrid-Joined-Gerät verlangen | 🟧 Medium | 🟧 Medium | 🟧 Medium |
| Block access for unknown or unsupported device platform | Zugriff für bestimmte Geräte-Betriebssysteme blockieren | 🟧 Medium | 🟩 Low | 🟩 Low |
| No persistent browser session | Browserzugriff ist nie persistent | 🟧 Medium | 🟧 Medium | 🟩 Low |
| Require approved client apps or app protection policies | Mobile Application Management gilt für Apps auf nicht verwalteten Geräten | 🟧 Medium | 🟧 Medium | 🟥 High |
| Require compliant or Microsoft Entra hybrid joined device or multifactor authentication for all users | Für alle Benutzer ein Intune-compliant oder Hybrid-Joined-Gerät verlangen | 🟧 Medium | 🟧 Medium | 🟧 Medium |
| Use application enforced restrictions for unmanaged devices | App Enforced Restrictions über Session Controls schränken die Nutzung ein | 🟧 Medium | 🟧 Medium | 🟥 High |
| Require phishing-resistant multifactor authentication for administrators | Admins brauchen eine phishing-resistant MFA-Methode wie FIDO2 oder WHfB | 🟧 Medium | 🟧 Medium | 🟧 Medium |
| Block access for users with insider risk | Insider-Risk-Kontrollen | 🟧 Medium | 🟧 Medium | 🟧 Medium |
*persönliche Einstufung
Weitere Policies
Natürlich lassen sich noch viele weitere Policies umsetzen. Wenn du die empfohlenen Policies live gesetzt hast, kannst du über weitere nachdenken. Sie können organisationsspezifisch sein, für bestimmte Identitäten oder Apps.
Monitoring
Nachdem du Conditional Access Policies umgesetzt hast, ist es entscheidend, ihre Auswirkungen zu überwachen. Dafür stehen dir in Entra ID mehrere Features zur Verfügung.
What if
Wenn du die Auswirkungen einer oder aller Policies besser verstehen willst, nutze den integrierten What if-Analyzer. Du kannst beliebige Signale eingeben, die simuliert und gegen deine Policies ausgewertet werden.
Sign-in logs
Wenn ein Benutzer an einer Conditional Access Anmeldung scheitert, schaue ich als Erstes in die Sign-in logs. Eine von Conditional Access blockierte Anmeldung sieht für den Benutzer so aus:
Die Sign-in logs lassen sich auf Tenant-Ebene oder pro Benutzer prüfen. Du kannst auch nach dem Status «Conditional Access failed» filtern.
Log Analytics Workspace
Ein Log Analytics Workspace ist eine Pay-as-you-go-Ressource, die in Azure gehostet wird. Sie braucht ein Azure-Abonnement. Du kannst Entra und den Log Analytics Workspace verbinden, um deine Sign-in-Daten länger als 30 Tage zu speichern, eigene KQL-Abfragen zu erstellen und Entra Workbooks zu nutzen.
Mehr zu Log Analytics Workspace:
Entra Monitoring Workbooks
Entra Monitoring Workbooks sind übersichtliche Dashboards, die Einblick in Nutzung und Auswirkungen von Conditional Access geben. Du findest sie unter Entra > Monitoring & health > Workbooks. Zu Conditional Access gehören:
- Conditional Access insights and reporting
- Continuous access evaluation token insights
- Conditional Access Gaps and Recommendations
Mehr...
Entra Authentication Methods Activity
Um herauszufinden, welche Authentication Methods Benutzer für MFA nutzen, schau unter Entra > Authentication methods. Unter «Activity» und «User registration details» findest du alle nötigen Informationen und Berichte dazu, welche Methoden genutzt und registriert sind.
Hinweise aus der Praxis 📝
In einer Organisation mit der Durchsetzung starten
Conditional Access sollte das Herzstück jeder identitätsbezogenen Sicherheit in jeder Organisation sein, die Microsoft 365 oder Azure-Dienste nutzt. Wenn du mit einem frischen Tenant starten kannst, solltest du gleich mit allen Policies starten.
Hat deine Organisation Microsoft-Dienste bereits im Einsatz, brauchst du ein Projekt, das den Übergang reibungslos gestaltet und Sicherheit und Produktivität bei der Umsetzung der Policies ausbalanciert. Setz dich mit den Security-Verantwortlichen zusammen, um die anstehenden Änderungen festzulegen und die nötigen Schritte einzuleiten. Auch Adoption und Kommunikation bei den Benutzern sind wichtiger Teil des Prozesses. Das ist ein Beispiel für die Schritte auf dem Weg zu Conditional Access:
- Den Einsatzfall oder die Verbesserung der Security Posture definieren
- Die Policy im Report-only-Modus erstellen
- Impact überwachen
- Freigabe für die Umsetzung der Policy einholen
- Mit Pilotbenutzern testen (Policy aktivieren)
- Feedback einholen, anpassen oder entscheiden
- Policy auf alle anwenden
Sobald deine Baseline aus Policies steht, kannst du sie auf weitere Einsatzfälle ausweiten. Bleib auch auf dem Laufenden: Wie jeder Microsoft-Clouddienst erhält Conditional Access regelmässig Updates und neue Features. Diese solltest du laufend prüfen und, wenn möglich, übernehmen.
Integrität wahren
Ein weiteres wichtiges Thema ist die Integrität deines CA-Policy-Frameworks. Sobald die Policy-Definition und die Sicherheitsanforderungen festgelegt sind, sollte niemand die produktiven Policies ohne Genehmigung oder Begründung «anfassen» oder ändern.
Dazu gehört die Dokumentation der Policies. Ob du dafür ein Tool einsetzt oder sie von Hand in einem Dokument oder einer App führst, spielt keine Rolle, aber sie sollte dokumentiert sein!
Auf dem Laufenden bleiben
Microsoft veröffentlicht neue Features für seine Cloud-Produkte, auch für Conditional Access. Prüfe sie anhand deiner Einsatzfälle und überlege, wie du deine Security Posture verbessern oder den Endbenutzern das Leben erleichtern kannst. Bleib mit dem Microsoft Entra Blog auf dem Laufenden
Was heisst das für Schweizer Firmen?
- Das revDSG verlangt angemessene technische und organisatorische Massnahmen für die Datensicherheit. MFA für alle Benutzer und für Admins sowie das Blockieren von Legacy Authentication sind dafür typische, gut belegbare Massnahmen
- Mit Named Locations kannst du den Zugriff auf Länder beschränken, aus denen deine Mitarbeitenden tatsächlich arbeiten. Für viele Schweizer KMU ist das eine kurze Liste
- Identity Protection (Risk-Policies) braucht Entra ID Premium Plan 2: Prüfe die Lizenz, bevor du diese Policies einplanst
- Plane in KMU und bei IT-Dienstleistern pro Tenant mindestens zwei Break Glass Admins ein und dokumentiere die Ausnahmen in den Policies. So bleibt der Zugriff im Notfall möglich
powered by Oceanleaf
Verwandte Beiträge
