Conditional Access Baseline für KMU: Die ersten Richtlinien

Von · Veröffentlicht

Conditional Access ist das zentrale Steuerungswerkzeug für Identitätssicherheit in Microsoft Entra ID. Es entscheidet bei jeder Anmeldung anhand von Signalen wie Benutzer, Anwendung, Gerät, Standort und Risiko, ob Zugriff gewährt, zusätzlich abgesichert oder blockiert wird.

Viele Tenants starten mit den Sicherheitsstandards (Security Defaults) oder mit einzelnen, historisch gewachsenen Richtlinien. Dieser Artikel beschreibt eine schlanke Baseline, die sich für kleine und mittlere Unternehmen bewährt, und wie Sie sie ohne Betriebsunterbrechung einführen.

Voraussetzungen: Lizenz und Sicherheitsstandards

Conditional Access setzt Microsoft Entra ID P1 voraus. P1 ist unter anderem in Microsoft 365 Business Premium, E3 und E5 enthalten. Risikobasierte Richtlinien (Anmelde- und Benutzerrisiko) benötigen Entra ID P2.

Sicherheitsstandards und Conditional Access schließen sich gegenseitig aus. Bevor Sie eigene Richtlinien aktivieren, müssen die Sicherheitsstandards deaktiviert werden – idealerweise erst dann, wenn die Ersatzrichtlinien bereits im Berichtsmodus geprüft wurden, damit keine Schutzlücke entsteht.

Zuerst: Notfallkonten (Break-Glass-Accounts)

Bevor Sie die erste blockierende Richtlinie aktivieren, legen Sie mindestens zwei reine Cloud-Konten mit der Rolle Globaler Administrator an, die ausschließlich für Notfälle gedacht sind. Microsoft empfiehlt, diese Konten mit starker, idealerweise phishing-resistenter Authentifizierung (zum Beispiel FIDO2-Sicherheitsschlüssel) zu schützen und ihre Anmeldungen zu überwachen.

Die Notfallkonten werden aus den meisten Conditional-Access-Richtlinien ausgeschlossen. So bleibt der Tenant erreichbar, falls eine fehlerhafte Richtlinie oder ein Ausfall des MFA-Dienstes alle anderen Administratoren aussperrt.

Die Baseline-Richtlinien

Die folgenden Richtlinien decken die häufigsten Angriffswege ab und bilden eine solide Grundlage. Jede Richtlinie sollte klar benannt werden (zum Beispiel mit Präfix und Nummer), damit die Wirkung später nachvollziehbar bleibt.

  • MFA für alle Administratorrollen – idealerweise mit Authentifizierungsstärke „phishing-resistente MFA“.
  • MFA für alle Benutzer bei allen Cloud-Apps, mit Ausnahme der Notfallkonten.
  • Legacy Authentication blockieren (Client-Apps „Exchange ActiveSync“ und „Andere Clients“), da diese Protokolle MFA nicht unterstützen.
  • MFA für den Zugriff auf Azure-Verwaltung (Azure-Portal, CLI, PowerShell).
  • Geräteanforderungen für den Zugriff auf Unternehmensdaten: konformes Gerät (Intune) oder App-Schutzrichtlinie auf mobilen Geräten.
  • Mit Entra ID P2: MFA oder Kennwortänderung bei erhöhtem Anmelde- bzw. Benutzerrisiko.

Ausrollen ohne Aussperren: der Berichtsmodus

Jede neue Richtlinie wird zunächst im Modus „Nur Bericht“ aktiviert. In diesem Modus wird die Richtlinie bei jeder Anmeldung ausgewertet, aber nicht erzwungen. In den Anmeldeprotokollen und im Arbeitsbuch „Conditional Access Insights and Reporting“ sehen Sie, welche Anmeldungen blockiert oder zusätzlich abgefragt würden.

Erst wenn die Auswertung über einige Tage keine unerwarteten Treffer zeigt – etwa Dienstkonten, Scanner oder Schnittstellen –, wird die Richtlinie aktiviert. Ausnahmen sollten die Ausnahme bleiben, dokumentiert und regelmäßig überprüft werden.

Typische Fehler

  • Keine oder nur ein Notfallkonto – oder Notfallkonten, die selbst an MFA eines einzelnen Mitarbeiters hängen.
  • Richtlinien direkt aktiviert statt im Berichtsmodus getestet.
  • Großzügige Ausschlussgruppen, die mit der Zeit wachsen und nie überprüft werden.
  • Standortbasierte Ausnahmen („im Büronetz kein MFA“), die bei kompromittierten Konten keinen Schutz bieten.

Fazit

Eine gute Conditional-Access-Baseline besteht aus wenigen, klar benannten Richtlinien, abgesicherten Notfallkonten und einem disziplinierten Rollout über den Berichtsmodus. Danach lohnt sich eine regelmäßige Überprüfung von Ausnahmen und Anmeldeprotokollen.

Quellen