Conditional Access einführen, ohne Mitarbeitende auszusperren

Viele Geschäftsführungen haben MFA beschlossen und gehen davon aus, dass das Thema damit erledigt ist. In der Praxis entscheidet aber erst Conditional Access, ob MFA tatsächlich bei jeder Anmeldung verlangt wird, ob alte Protokolle ohne MFA noch funktionieren und ob ein Administrator sich von einem privaten Laptop aus anmelden darf. Dieser Beitrag zeigt, wie Sie Conditional Access einführen, ohne dass am Montagmorgen die Geschäftsführung, der einzige Administrator oder eine Produktionslinie vor einer Fehlermeldung steht.

Warum braucht ein Unternehmen Conditional Access, wenn MFA schon aktiv ist?

Weil MFA ohne Regeln nur dort greift, wo sie zufällig verlangt wird. Conditional Access ist die Richtlinien-Engine von Microsoft Entra ID: Sie verknüpft Signale wie Benutzer, Gerät, Standort und Anwendung mit einer Entscheidung, etwa „MFA verlangen“, „nur mit verwaltetem Gerät“ oder „blockieren“. Das Prinzip ist eine einfache Wenn-dann-Logik. Für die Geschäftsführung heißt das: Ohne Conditional Access können Sie gegenüber Prüfern, Cyberversicherern und Kunden nicht belegen, dass jede Anmeldung abgesichert ist.

Für die IT: Conditional Access benötigt Microsoft Entra ID P1, das auch in Microsoft 365 Business Premium enthalten ist. Risikobasierte Richtlinien setzen Entra ID P2 voraus. Wichtig ist außerdem, dass Conditional Access erst nach der ersten Anmeldestufe ausgewertet wird. Es ersetzt also keine starken Anmeldemethoden, sondern erzwingt sie.

Wovor haben Unternehmen bei der Einführung Angst?

Vor dem Aussperren, und das zu Recht. Eine falsch zugeschnittene Blockier-Richtlinie kann alle Administratoren gleichzeitig aussperren. Typische Szenarien, die wir in Gesprächen hören: Die Geschäftsführerin ist auf Reisen und kommt nicht mehr ins Postfach. Der einzige Administrator hat sein Telefon verloren. Ein Scanner oder eine Maschinensteuerung verschickt Mails über ein altes Protokoll und fällt plötzlich aus.

Alle drei Szenarien sind vermeidbar. Vor jeder Richtlinie stehen vier Schritte: Notfallkonten ausnehmen, mit einer Pilotgruppe testen, sicherstellen, dass Benutzer ihre Anmeldemethoden registriert haben, und die Änderung ankündigen.

In welcher Reihenfolge führt man Conditional Access sicher ein?

Die sichere Reihenfolge lautet: erst wissen, was angebunden ist, dann den Notausgang bauen, dann beobachten und erst danach durchsetzen.

1. Bestandsaufnahme von Anwendungen, Benutzern, Standorten und Geräten

Klären Sie, welche Anwendungen über Entra ID angemeldet werden, welche Benutzergruppen es gibt (Mitarbeitende, Administratoren, Gäste, Dienstkonten), von welchen Standorten aus gearbeitet wird und welche Geräte in Microsoft Intune verwaltet sind. Die Anmeldeprotokolle in Entra ID zeigen, welche Clients und Protokolle tatsächlich genutzt werden. Dort fallen auch Geräte auf, die noch Legacy-Authentifizierung verwenden, also alte Anmeldeverfahren ohne MFA-Unterstützung.

2. Zwei Notfallkonten einrichten

Notfallkonten, auch Break-Glass-Konten genannt, sind reine Cloud-Konten mit der Rolle Global Administrator, die nur im Notfall verwendet werden. Es sollten mindestens zwei sein, mit phishing-resistenter Anmeldung (zum Beispiel FIDO2-Sicherheitsschlüssel), ausgenommen von allen blockierenden oder einschränkenden Richtlinien und mit einer Alarmierung bei jeder Anmeldung. Prüfen Sie ihre Funktion mindestens alle 90 Tage. Legen Sie die Konten in eine eigene Gruppe und nehmen Sie diese Gruppe in jeder Richtlinie aus.

3. Report-only-Modus und Insights-Arbeitsmappe

Jede neue Richtlinie startet im Report-only-Modus. Sie wird dann bei jeder Anmeldung ausgewertet, aber nicht durchgesetzt. Das Ergebnis steht im Anmeldeprotokoll im Reiter „Report-only“. Die Arbeitsmappe „Conditional Access insights and reporting“ fasst die Wirkung über alle Anmeldungen zusammen. Sie setzt voraus, dass die Anmeldeprotokolle in einen Log Analytics Workspace gestreamt werden. Lassen Sie jede Richtlinie mindestens zwei Wochen im Report-only-Modus laufen.

4. What-If-Tool für Sonderfälle

Mit dem What-If-Tool simulieren Sie eine Anmeldung, etwa „Geschäftsführerin, iPhone, aus dem Ausland, Outlook“, und sehen, welche Richtlinien greifen würden. Das ist besonders hilfreich für seltene Konstellationen, die im Report-only-Zeitraum nicht vorkommen.

5. Pilotgruppe, dann Richtlinie für Richtlinie

Starten Sie mit einer Pilotgruppe aus der IT und einigen technikaffinen Mitarbeitenden aus den Fachbereichen. Erweitern Sie danach Richtlinie für Richtlinie. Eine bewährte Reihenfolge:

1. Legacy-Authentifizierung blockieren. Alte Protokolle unterstützen kein MFA und umgehen sie damit.
2. MFA für alle Benutzer. Mit Ausnahme der Notfallkonten.
3. Konformes Gerät für Administratoren. Administrative Portale nur von Geräten, die Intune als konform meldet.
4. Phishing-resistente MFA für Administratoren. Über die Authentifizierungsstärke „Phishing-resistant MFA“. Warum klassische Codes und Push-Bestätigungen nicht ausreichen, zeigt unsere Webinar-Aufzeichnung. Die Umstellung beschreiben wir im Beitrag Conditional Access und Passkeys.

Wie geht man mit Ausnahmen um?

Ausnahmen sind normal, sie brauchen aber einen Prozess. Legen Sie für jede Richtlinie eine benannte Ausnahmegruppe an, dokumentieren Sie für jedes Mitglied Grund, Verantwortlichen und Ablaufdatum, und prüfen Sie die Gruppe regelmäßig. Mit Microsoft Entra Access Reviews lässt sich diese Prüfung automatisieren und für den Prüfer belegen. Dafür ist Entra ID P2 oder Entra ID Governance nötig.

Für Dienstkonten gilt: Prüfen Sie, ob sie durch verwaltete Identitäten oder Dienstprinzipale ersetzt werden können. Dienstprinzipale werden von benutzerbezogenen Richtlinien ohnehin nicht erfasst und brauchen eigene Regeln für Workload-Identitäten.

Worauf sollte man in den ersten 14 Tagen achten?

Nach dem Umschalten einer Richtlinie auf „Ein“ empfehlen wir, die Anmeldeprotokolle zwei Wochen lang täglich auszuwerten. Achten Sie auf fehlgeschlagene Anmeldungen mit Conditional-Access-Bezug, auf Benutzer, die wiederholt an derselben Richtlinie scheitern, und auf Anmeldungen der Notfallkonten. Halten Sie für Rückfragen einen festen Ansprechpartner bereit.

Die Kommunikation an die Belegschaft entscheidet mit über den Erfolg. Kündigen Sie die Änderung rechtzeitig an, erklären Sie in zwei Sätzen den Grund und nennen Sie einen Kanal für Probleme. Microsoft stellt dafür Vorlagen bereit, die sich anpassen lassen.

Welche Fehler sehen wir bei der Einführung am häufigsten?

• Security Defaults sind noch aktiv. Security Defaults und Conditional Access schließen sich aus. Wer die Sicherheitsstandards abschaltet, ohne dass die Ersatzrichtlinien bereits laufen, schafft eine Lücke. Planen Sie die Umstellung so, dass beides am selben Tag passiert.
• Alle Gäste versehentlich ausgenommen. Um Rückfragen von Partnern zu vermeiden, wird „Gast- oder externe Benutzer“ pauschal aus der MFA-Richtlinie genommen. Damit fehlt der Schutz genau dort, wo Sie die Konten am wenigsten kontrollieren.
• Dienstkonten vergessen. Ein Konto für den Scanner oder eine Schnittstelle scheitert an der neuen Richtlinie, und der Betrieb steht.
• Kein benannter Ausnahmeprozess. Ausnahmen werden direkt in einzelne Richtlinien eingetragen, niemand weiß nach einem Jahr noch, warum.

Welche Nachweise erwartet der Prüfer?

Prüfer und Versicherer fragen typischerweise nach drei Dingen: dem Export der aktiven Richtlinien mit Datum, Auszügen aus den Anmeldeprotokollen, die die Wirkung belegen, und der Liste der Ausnahmen mit Begründung. Wer die Einführung wie oben beschrieben durchführt, hat diese Unterlagen am Ende bereits vorliegen. Bewahren Sie zusätzlich die Report-only-Auswertungen auf. Sie zeigen, dass die Einführung geplant und kontrolliert erfolgt ist.

Häufig gestellte Fragen

Welche Lizenz brauche ich für Conditional Access?

Conditional Access setzt Microsoft Entra ID P1 voraus. Diese Lizenz ist unter anderem in Microsoft 365 Business Premium sowie in Microsoft 365 E3 und E5 enthalten. Risikobasierte Richtlinien und Access Reviews für Ausnahmegruppen benötigen Entra ID P2 beziehungsweise Entra ID Governance.

Müssen Notfallkonten auch aus Report-only-Richtlinien ausgenommen werden?

Nein. Report-only-Richtlinien blockieren keine Anmeldung und benötigen deshalb keine Ausnahme. Spätestens beim Umschalten auf „Ein“ muss die Gruppe der Notfallkonten aber ausgenommen sein.

Wie lange sollte eine Richtlinie im Report-only-Modus laufen?

Zwei bis vier Wochen. Wir richten uns zusätzlich nach dem Geschäftsrhythmus: Wenn Monatsabschluss, Schichtwechsel oder Außendienst-Touren besondere Anmeldemuster erzeugen, sollte der Beobachtungszeitraum diese einschließen.

Was passiert, wenn trotz allem jemand ausgesperrt wird?

Dann melden Sie sich mit einem Notfallkonto an, setzen die betroffene Richtlinie auf Report-only zurück und analysieren die Anmeldung im Protokoll. Jede Nutzung eines Notfallkontos sollte anschließend dokumentiert und nachbereitet werden.

Der nächste Schritt

Wie gut Ihre aktuellen Richtlinien schützen, prüfen wir im Gap Assessment zum Festpreis, inklusive Notfallkonten, Ausnahmen und Nachweislage. Den laufenden Betrieb und die Auswertung der Anmeldeprotokolle übernehmen wir auf Wunsch im Rahmen von Managed Security.

Erstgespräch vereinbaren