Microsoft 365 tinkamai apsaugoti: Conditional Access, MFA išimtys ir Break-Glass paskyros kasdieniniame administravime

Freitag, 16:40 Uhr. Zwei Dinge passieren gleichzeitig: Im Helpdesk laufen Tickets auf („Anmeldung nicht möglich“), und aus dem Management kommt die Rückfrage, warum eine kurzfristig freizugebende SharePoint-Datei plötzlich nicht erreichbar ist. Im Admin-Chat steht der eigentliche Auslöser schon: „Neue Conditional-Access-Policy vor 20 Minuten aktiviert.“ Eigentlich sollte sie nur alte Anmeldewege blockieren. Jetzt trifft sie offenbar auch die Administratoren.

In genau diesem Moment entscheidet sich, ob „Microsoft 365 richtig absichern“ bei Ihnen ein belastbarer Betriebsstandard ist oder eine Sammlung gut gemeinter Häkchen. Denn das Problem ist selten „MFA war nicht aktiv“. Das Problem ist: Wer kommt jetzt noch in den Tenant, um die Policy zu korrigieren – und wie verhindern Sie, dass die schnelle Rettung (eine spontane Ausnahme) zum dauerhaften Einfallstor wird?

Die weniger hilfreiche Reaktion sieht oft so aus: „Schaltet für die betroffenen Gruppen MFA aus, Hauptsache die Leute kommen wieder rein.“ Das funktioniert kurzfristig, verschiebt aber das Risiko in die nächste Woche – und meist bleibt die Ausnahme länger als geplant. Die bessere Reaktion ist unaufgeregt und vorbereitet: Es gibt getestete Break-Glass-Accounts (Notfallzugänge), CA-Änderungen folgen einem Rollout-Muster, und Ausnahmen sind als Lifecycle-Objekte organisiert (Owner, Ablaufdatum, Kontrollroutine). Dann wird im Incident nicht improvisiert, sondern abgearbeitet.

Warum Conditional Access im Alltag über Sicherheit oder Supportlast entscheidet

Conditional Access (CA) in Microsoft Entra ID (Identitätsplattform, früher „Azure AD“) ist im Kern eine regelbasierte Zugriffskontrolle. Sie entscheiden nicht nur „MFA an/aus“, sondern kombinieren Bedingungen wie Gerätezustand (Compliance, häufig über MDM/Intune), Standortsignale, Risikoindikatoren und die Zielressource („Cloud-App“ wie Exchange Online, SharePoint, Admin-Portale). Das ist genau die Stärke: Sie können Zugriffe differenzieren, statt alles über eine pauschale Regel zu erschlagen.

Die Nebenwirkung ist betrieblich: CA hat einen großen Wirkbereich („Blast Radius“). Eine unglücklich gescopte Policy wirkt sofort und kann ganze Anmeldewege blockieren. Microsoft weist ausdrücklich darauf hin, dass CA-Policies im Fehlerfall sogar Notfallkonten sperren können – also genau dann versagen, wenn diese Konten gebraucht werden.^[Quelle] Die praktische Folgerung ist unbequem, aber wichtig: Notfallzugänge müssen so konzipiert sein, dass sie im Ernstfall funktionieren – und dazu gehört typischerweise der bewusste Ausschluss aus bestimmten CA-Policies.

CA-Design ist kein Screenshot, sondern ein Regelwerk mit Nebenwirkungen

Viele Unternehmen starten mit zwei sinnvollen Grundideen: „MFA für alle“ und „Legacy Authentication blocken“. Das wird aber schnell komplex, weil die Realität nicht homogen ist. Typische Nebenwirkungen, die in Betrieb und Administration sichtbar werden:

• Scope-Fallen: „All cloud apps“ trifft auch Admin-Portale und selten genutzte, aber kritische Verwaltungsendpunkte. Ein Fehler blockiert nicht nur Nutzer, sondern auch den Rettungsweg.
• Identitäten-Mix: Menschen (interaktive Anmeldung) und technische Identitäten (Automatisierung) werden in Gruppen vermischt. Dann erzwingt CA plötzlich Interaktion, wo keine möglich ist.
• Signal-Unschärfe: Standortsignale sind in der Praxis durch VPN-Egress, Mobilfunkwechsel, Proxy-Ketten und Reisetätigkeit weniger „hart“, als sie im Policy-Editor wirken.
• Ausnahmen-Wildwuchs: Jede Ausnahme reduziert den Schutz. Ohne Ablaufdaten und regelmäßige Prüfung wird aus „temporär“ schnell „historisch“.

Microsoft 365 richtig absichern: CA als Szenario-Entscheidung statt „Best Practice“-Kopie

CA wird stabil, wenn Sie es als Szenario-Entscheidung behandeln: Welche Anmeldewege sind geschäftskritisch? Wo ist Missbrauch besonders teuer? Welche Zugriffe müssen auch im Störfall möglich bleiben? Daraus entsteht eine Policy-Landkarte, die sich administrieren lässt.

Szenario 1: Standardnutzer – Reibung reduzieren, ohne Schutz zu verschenken

Für die meisten Mitarbeitenden ist das Ziel nicht „maximal streng“, sondern „verlässlich und nachvollziehbar“. Ein guter Standard ist: MFA (zweiter Faktor), kombiniert mit einem sauberen Gerätepfad. „Gerät compliant“ heißt dabei konkret: das Gerät erfüllt Mindestanforderungen (Patchlevel, Verschlüsselung, PIN/Biometrie, kein Jailbreak/Root) und ist als verwaltetes Gerät bekannt. Wenn dieser Pfad nicht sauber steht, erzeugt CA vor allem Tickets: neue Telefone, defekte Authenticator-Registrierung, Gerätewechsel, wiederkehrende MFA-Prompts.

Das Betriebsziel ist daher doppelt: Schutz erhöhen und gleichzeitig die Anzahl wiederkehrender Ausnahmen senken. Das gelingt, wenn der Nutzerweg klar ist: Registrierung, Gerätewechsel, verlorenes Gerät, Wiederherstellung. Wenn diese Prozesse fehlen, wird CA zum Dauerthema im Tagesgeschäft.

Szenario 2: Administratoren – anderes Risikoprofil, andere Regeln

Privilegierte Rollen (z. B. Global Administrator) sind ein anderes Spielfeld. Ein kompromittiertes Admin-Konto ist nicht „ein Nutzer betroffen“, sondern potenziell der gesamte Tenant. Microsoft empfiehlt, privilegierte Accounts klar zu separieren und deren Nutzung stark zu überwachen; dazu gehören auch Notfallzugänge und Alarmierung bei deren Nutzung.^[Quelle]

Das heißt nicht, dass Sie Admins „bestrafen“ müssen. Es heißt: Sie machen Admin-Zugriffe absichtlich sichtbar und behandeln sie wie kritische Betriebshandlungen. Dazu passen getrennte Admin-Identitäten, strengere CA-Bedingungen und bevorzugt phishing-resistente Authentifizierung (z. B. FIDO2-Sicherheitsschlüssel, also kryptografische Hardware-Token, die gegen klassische Phishing-Weiterleitungen deutlich robuster sind).

Szenario 3: Dienstkonten und Schnittstellen – nicht alles ist ein Login im Browser

Viele individuelle Unternehmenssoftware-Landschaften hängen indirekt an Microsoft 365: Mailversand aus einer Business-Software, Ablage nach SharePoint, Benachrichtigungen in Teams, Archivierung, Exporte oder DMS-Prozesse. Diese Integrationen arbeiten oft nicht interaktiv. Wenn CA hier „MFA“ erzwingt, ist das nicht „sicherer“, sondern schlicht kaputt.

Operativ brauchen Sie deshalb eine klare Trennung zwischen human identities (Menschen, MFA-fähig) und non-human identities (technische Identitäten). Für technische Identitäten sind typische Stellschrauben: minimal notwendige Berechtigungen, begrenzte Token-/Secret-Lebensdauer, Rotation (geregelter Austausch von Secrets/Zertifikaten), Logging und ein Prozess für Key-Compromise. Das ist weniger sichtbar als eine MFA-Prompt, aber deutlich wichtiger für Betriebssicherheit.

MFA-Ausnahmen: Der schnelle Fix, der später teuer wird

MFA-Ausnahmen entstehen selten aus „Lust auf weniger Sicherheit“. Sie entstehen, weil ein Prozess klemmt: ein Gerät ist nicht compliant, ein Dienstleister kommt nur kurzfristig, ein Shared-Device-Szenario passt nicht ins Standardmodell, oder der Rollout war zu breit. Das Risiko beginnt, wenn Ausnahmen nicht mehr als Ausnahme behandelt werden.

Was eine MFA-Ausnahme wirklich ist (und was nicht)

Eine MFA-Ausnahme ist nicht automatisch „ohne zweiten Faktor“. Gerade für Notfallkonten betont Microsoft eher den gegenteiligen Weg: phishing-resistente Authentifizierung statt schwächerer Verfahren.^[Quelle] Übertragen auf den Alltag heißt das: Prüfen Sie zuerst, ob Sie statt „MFA aus“ eine passende, robustere Methode nutzen können (z. B. FIDO2 für Admins, zertifikatsbasierte Verfahren für bestimmte Szenarien) – und ob das betrieblich handhabbar ist (Token-Aufbewahrung, Ersatzverfahren, Verlustprozess).

Wenn Sie dennoch „MFA aus“ als Ausnahme brauchen, muss sie wie ein Risikoobjekt geführt werden: begründet, befristet, überwacht, mit Owner und Rückbauplan.

Typische Ausnahmekategorien – und die bessere Alternative

Break-Glass-Accounts (Emergency Access): Notausgang, nicht Hintertür

Break-Glass-Accounts (Microsoft: „Emergency Access Accounts“) sind Konten, die Sie für den Notfall vorhalten: Fehlkonfiguration von CA, Ausfall von MFA-Mechanismen, Probleme in einer Föderationskette, kompromittierte Admin-Konten. Microsoft empfiehlt ausdrücklich, solche Konten einzuplanen, damit Sie sich nicht selbst aussperren.^[Quelle]

Was Microsoft konkret empfiehlt – und was das im Betrieb auslöst

Aus der Microsoft-Dokumentation lassen sich Leitlinien ableiten, die sich direkt in Betriebsvorgaben übersetzen lassen:

• Mindestens zwei Notfallkonten, um keinen Single-Point-of-Failure zu bauen (gesperrt, verloren, kompromittiert).^[Quelle]
• Cloud-only anlegen, damit der Notfallzugang nicht an AD-Sync oder On-Prem-Abhängigkeiten hängt.
• Gezielt aus CA-Policies ausschließen, insbesondere aus Block- und Restriktionspolicies, weil das Konto sonst im Notfall ebenfalls blockiert werden kann.^[Quelle]
• Jede Nutzung überwachen und alarmieren, weil seltene Nutzung genau deshalb ein starkes Incident-Signal ist.^[Quelle]

Die verbleibende Lücke ist nicht technisch, sondern organisatorisch: Wer hält die Zugangsdaten? Wie wird Zugriff protokolliert? Wie testen Sie, ohne das Konto „normal“ zu machen? Und was passiert nach einer Nutzung (Passwortwechsel, Review, Dokumentation)? Wenn diese Fragen nicht beantwortet sind, bleibt der Notausgang theoretisch.

Die häufigste Fehlannahme: „Break-Glass = MFA aus“

Im Stress wird Break-Glass gerne als „MFA-freies Admin-Konto“ verstanden. Das ist nachvollziehbar, aber gefährlich: Genau diese Konten sind für Angreifer am attraktivsten. Microsoft betont für Emergency Access die Nutzung phishing-resistenter Methoden (beispielsweise FIDO2 oder zertifikatsbasierte Anmeldung) statt schwächerer Authentifizierung.^[Quelle]

Wenn ein Unternehmen dennoch bewusst ein Konto ohne MFA als „letzten Rettungsanker“ definiert, ist das kein Standard, sondern eine dokumentierte Risikoentscheidung. Dann müssen Schutzmaßnahmen maximal sein (starkes Passwort, Offline-Aufbewahrung, enges Monitoring, keine Alltagsnutzung, klare Eskalationskette). Wichtig ist die Ehrlichkeit in der Dokumentation: Das ist eine Verfügbarkeitsentscheidung mit Restrisiko, kein Sicherheitsgewinn.

So entwerfen Sie Conditional Access, ohne sich auszusperren

Ein robustes CA-Design trennt Policy-Typen und folgt einer Reihenfolge: erst verstehen, dann erzwingen. Microsoft beschreibt in der CA-Planung genau diese Logik: planen, testen, stufenweise ausrollen und Auswirkungen vor der Durchsetzung kennen.^[Quelle] Das lässt sich in Betriebsschritte übersetzen, die ohne Großprojekt beginnen können.

Nummerierte Schrittfolge: Rollout-Muster, das im Betrieb überlebt

1. Identitäten klassifizieren: Standardnutzer, privilegierte Nutzer, Gäste/B2B, Dienst-/Automationsidentitäten. Ohne diese Trennung wird jede Policy zur Überraschung.
2. Policy-Landkarte als Betriebsartefakt anlegen: pro Policy: Zweck, Scope (Benutzer/Gruppen), Zielressourcen, Ausschlüsse, Owner. Kurz, aber aktuell.
3. Break-Glass zuerst umsetzen und testen: zwei cloud-only Konten, getrennte Aufbewahrung, getesteter Login-Pfad. Testfrequenz festlegen und protokollieren.
4. Pilotgruppen definieren: IT plus repräsentative Fachbereiche, echte Gerätevielfalt (Windows/macOS/mobil), typische Arbeitsplätze (Büro, mobil, VPN).
5. Report-only nutzen, wo möglich: erst sehen, wen Sie treffen würden; dann Regeln und Scope korrigieren, bevor Sie blocken.
6. Rückfallmechanik klären: Wer darf im Incident Policies zurückstellen? Wie wird außerhalb der Bürozeiten entschieden? Welche Kommunikationswege sind gesetzt?
7. Helpdesk-Playbooks schreiben: Standardfälle (neues Telefon, verlorener Faktor, Gerät nicht compliant, Gastzugriff). Ziel: reproduzierbare Lösung statt „Ticket-Pingpong“.
8. Ausnahmen befristen: Jede Ausnahme bekommt Owner, Ablaufdatum und Prüftermin. „Bis auf Weiteres“ ist in der Praxis eine Dauerlücke.

Exclusions sind Governance, kein Sammelbecken

Microsoft zeigt in einem CA-Policy-Beispiel explizit, dass Emergency-/Break-Glass-Accounts in CA-Policies häufig unter „Exclude“ geführt werden sollten, etwa bei Block-Policies.^[Quelle] Das ist richtig – solange Sie Exclusions nicht als bequemen Ausweg missbrauchen.

Bewährt hat sich eine Einteilung in drei Klassen, die sich auch in Audits und im Incident gut erklären lässt:

• Klasse A (Notfall): Break-Glass, dauerhaft, sehr klein, mit Alarmierung und Testnachweis.
• Klasse B (technisch notwendig): Integrationen/Dienstkonten, nur mit minimalen Rechten, Rotation und klarer Ownership.
• Klasse C (temporär): Rollout- oder Sonderfälle, immer befristet und mit Rückbau-Owner.

Monitoring und Audit: Woran Sie merken, dass Ihr Konzept funktioniert

„Sicher“ ist kein Zustand, den man einmal konfiguriert. Es ist ein Betriebsmuster: sehen, bewerten, reagieren. Für Emergency Access fordert Microsoft hochpriorisierte Alerts bei jeder Nutzung.^[Quelle] Das Prinzip dahinter ist für CA/MFA insgesamt nützlich: Alles, was selten passieren sollte, muss auffallen.

Konkrete Signale, die Sie regelmäßig prüfen sollten

• Sign-in-Logs privilegierter Konten: ungewöhnliche Clients, Uhrzeiten, Länder-/Netzsignale. Standort ist nicht beweissicher, aber ein guter Hinweisgeber.
• Änderungen an CA-Policies: Wer hat wann was geändert – und gibt es ein Change-/Incident-Ticket dazu?
• Ausnahmenliste: Anzahl der MFA/CA-Exclusions, abgelaufene Einträge, Ausnahmen mit Admin-Bezug.
• Externe Identitäten (B2B/Gäste): Wer hat Zugriff auf sensible Teams/Sites, und passen Bedingungen und Laufzeiten noch?

Klare Grenzen: Wo „Best Practice“ bewusst abweicht

Es gibt Umgebungen, in denen Standardmuster angepasst werden müssen: regulierte Branchen, isolierte Admin-Netze, komplexe Hybrid-Identitäten oder Legacy-Anwendungen, die an kritischen Prozessen hängen (Versand, Produktion, Abrechnung). Dann sind MFA-Ausnahmen oder abweichende CA-Bedingungen nicht automatisch „schlecht“. Sie sind aber eine Risikoentscheidung, die kompensiert werden muss.

Typische harte Grenzen, die Sie offen benennen sollten

• Technische Altlasten: Manche Clients/Protokolle können moderne Authentifizierung nicht. Dann ist die Entscheidung: ersetzen, kapseln oder Restrisiko begrenzt akzeptieren.
• Notbetrieb und Verfügbarkeit: Wenn Prozesse auch bei Störungen funktionieren müssen, brauchen Sie definierte Notfallwege – aber nicht über eine „Ausnahme im Alltag“, die stillschweigend bleibt.
• Ownership: Wenn niemand Ausnahmen verantwortet und regelmäßig prüft, wird Governance scheitern. Dann zuerst Verantwortlichkeiten und Rhythmus klären, erst danach Policies verschärfen.

Was Sie nächste Woche konkret erledigen können (ohne Großprojekt)

Wenn MFA und erste CA-Policies bereits aktiv sind, lässt sich der Reifegrad oft kurzfristig verbessern – nicht durch mehr Komplexität, sondern durch Ordnung und Testbarkeit:

• Break-Glass sauber aufsetzen: zwei cloud-only Konten, aus relevanten CA-Block-/Restriktionspolicies ausgeschlossen, Alarmierung aktiv, sichere Aufbewahrung.
• Ausnahmen inventarisieren: Exclusions exportieren, in A/B/C klassifizieren, Ablaufdaten setzen, Owner festlegen.
• Pilotierung nachziehen: definierte Pilotgruppe, künftige CA-Änderungen zuerst dort testen (inklusive typischer Geräte- und Standortpfade).
• Runbook „Lockout nach CA-Change“ schreiben: kurz, konkret, mit Reihenfolge: Log-Prüfung, Rückfallmaßnahme, Scope-Korrektur, Nachkontrolle.

Wenn Sie die Absicherung von Microsoft 365 nicht nur konfigurieren, sondern betrieblich stabil aufstellen wollen, lohnt sich ein kurzer Architektur- und Betriebscheck entlang Ihrer Identitäten, Ausnahmefälle und Notfallwege.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.