Azure Identitätssicherheit: warum MFA nicht reicht

Was ist Azure-Identitätssicherheit?

Azure-Identitätssicherheit ist die Gesamtheit der Kontrollen, die Microsoft Entra ID-Konten, privilegierte Rollen, Authentifizierungsmethoden, Anwendungszugriffe und administrative Sitzungen über Microsoft 365, Azure und verbundene SaaS-Anwendungen hinweg schützt. Sie ist die Eingangstür zum Tenant. Ist die Identitätsebene schwach, benötigt ein Angreifer möglicherweise gar keinen Server-Exploit: Ein gestohlenes Passwort, ein phishbarer Authentifizierungsablauf, eine schwache Ausnahme oder eine privilegierte Sitzung können bereits ausreichen.

MFA ist Teil der Antwort, aber MFA allein ist keine vollständige Strategie für die Azure-Identitätssicherheit. Ein Tenant benötigt zusätzlich eine Conditional-Access-Abdeckung, starke Authentifizierungsmethoden für privilegierte Rollen, risikobasierte Reaktionen, Kontrollen für Notfallzugriffe, eine Governance für Anwendungen sowie die Validierung, dass Richtlinien tatsächlich auf reale Anmeldungen angewendet werden.

Die beiden immer wieder auftretenden Basisfehler sind einfach:

privilegierte Konten ohne erzwungene starke Authentifizierung
deaktivierte Security Defaults ohne gleichwertige Conditional-Access-Abdeckung

Diese Fehler schaffen eine Lücke zwischen dem, was Administratoren für geschützt halten, und dem, was Microsoft Entra ID tatsächlich durchsetzt.

Security Defaults vs. Conditional Access

Security Defaults sind Microsofts integrierte Basisschutzmaßnahmen für Organisationen, die einen einfachen Ausgangspunkt benötigen. Die Microsoft-Dokumentation beschreibt Security Defaults als geeignet für Organisationen, die ihre Sicherheit verbessern möchten, aber nicht wissen, wo sie anfangen sollen, sowie für Organisationen, die die kostenlose Stufe von Microsoft Entra ID nutzen.

Security Defaults verlangen von allen Benutzern die Registrierung für Multi-Faktor-Authentifizierung, verlangen von Administratoren MFA bei jeder Anmeldung, fordern andere Benutzer zur MFA auf, wenn Microsoft dies für notwendig hält, blockieren veraltete Authentifizierungsprotokolle, blockieren den Device-Code-Flow und verlangen MFA für privilegierte Aktivitäten wie den Zugriff auf das Azure-Portal, das Microsoft Entra Admin Center, Azure PowerShell und Azure CLI. Sie sind bewusst einfach gehalten und nicht anpassbar: Der Schalter ist entweder ein oder aus, ohne Scoping und ohne Ausnahmen.

Conditional Access ist die flexiblere Richtlinien-Engine. Organisationen mit Microsoft Entra ID P1- oder P2-Lizenzierung und komplexeren Anforderungen benötigen in der Regel Conditional Access für die Anwendungssteuerung, den Gerätestatus, Standorte, Risikobedingungen, Authentifizierungsstärken, Sitzungskontrollen und begrenzte Ausnahmen.

Der gefährliche Zustand ist die Übergangslücke: Security Defaults sind deaktiviert, aber Conditional Access bietet noch keinen gleichwertigen oder stärkeren Schutz. Microsofts Anleitung zur Abkehr von Security Defaults besagt, dass Organisationen nach der Deaktivierung von Security Defaults umgehend Conditional-Access-Richtlinien aktivieren sollten, um die Organisation zu schützen. Microsoft liefert inzwischen von Microsoft verwaltete Conditional-Access-Richtlinien für diese Übergabe: Legacy-Authentifizierung blockieren, Multi-Faktor-Authentifizierung für die Azure-Verwaltung verlangen, Multi-Faktor-Authentifizierung für Administratoren verlangen und Multi-Faktor-Authentifizierung für alle Benutzer verlangen. Beachten Sie deren Standardzustand: Microsoft erstellt sie im Nur-Bericht-Modus (Report-only), der auswertet und protokolliert, aber nichts erzwingt, und aktiviert sie frühestens nach 30 Tagen, falls sie in diesem Zustand belassen werden. Bis zu diesem Umschalten erzwingt eine Richtlinienliste, die abgedeckt aussieht, gar nichts – dieselbe Falle, die in Conditional Access Report-only-Modus und veraltete Ausnahmen beschrieben wird.

Warum MFA allein nicht ausreicht

MFA verbessert die Widerstandsfähigkeit gegen eine reine Passwort-Kompromittierung, aber nicht alle MFA-Methoden bieten das gleiche Schutzniveau. Ein Tenant kann weiterhin exponiert sein, wenn:

Administratoren aufgrund von Notfall-Troubleshooting von den Conditional-Access-Richtlinien des Tenants ausgeschlossen sind
Conditional Access nur auf ausgewählte Anwendungen angewendet wird, während Admin-Portale weiterhin erreichbar bleiben
privilegierte Benutzer phishbare Methoden verwenden, obwohl stärkere Methoden verfügbar wären
Notfallkonten (break-glass accounts) existieren, aber nicht bei jeder Anmeldung überwacht werden
Legacy-Authentifizierung oder ältere Clients für einige Workflows weiterhin verfügbar bleiben
die Registrierung und Wiederherstellung von Authentifizierungsmethoden nur schwach kontrolliert werden
Sitzungen und Refresh-Token nach einem riskanten Ereignis gültig bleiben

Eine Lücke wurde inzwischen auf Plattformebene geschlossen, und das verändert, wie das Ausnahmeproblem zu bewerten ist. Microsoft erzwingt MFA bei Azure-Anmeldungen inzwischen unabhängig von der Tenant-Konfiguration: seit Oktober 2024 für das Azure-Portal, das Microsoft Entra Admin Center und das Microsoft Intune Admin Center, seit Februar 2025 für das Microsoft 365 Admin Center und seit dem 1. Oktober 2025 für Azure CLI, Azure PowerShell, die Azure-Mobile-App, IaC-Tools und Azure Resource Manager REST-Endpunkte bei Erstellungs-, Änderungs- und Löschvorgängen. Diese Erzwingung setzt sich über die Absicht des Tenants hinweg: Microsoft erklärt, dass Conditional-Access-Ausnahmen und -Ausschlüsse hierfür nicht mehr gelten und dass sie jedes Benutzerkonto betrifft, einschließlich Notfallkonten. Sie erstreckt sich nicht auf Microsoft Graph, das weiterhin den eigenen Richtlinien unterliegt, und Microsoft erzwingt sie derzeit nicht in Azure für US Government oder andere souveräne Clouds. MFA auf Plattformebene hebt die Untergrenze für eine kurze Liste von Admin-Oberflächen an. Sie verschafft einem Tenant jedoch keine Conditional-Access-Abdeckung, keine Methodenstärke und keine Geräte- oder Risikobedingungen.

Microsoft Entra Authentifizierungsstärken (authentication strengths) existieren, weil die Methodenstärke eine Rolle spielt. Eine Conditional-Access-Authentifizierungsstärke kann bestimmte Methodenkombinationen verlangen, einschließlich phishing-resistenter Optionen wie Passkeys/FIDO2-Sicherheitsschlüssel oder zertifikatsbasierter Authentifizierung, sofern diese eingesetzt und unterstützt wird.

Die Angriffskette

Schritt 1 – Den schwachen Identitätspfad finden

Ein Angreifer sucht nach Konten, die sich ohne starke Kontrollen authentifizieren lassen: Admin-Konten ohne MFA, von Conditional Access ausgeschlossene Konten, veraltete Konten, unüberwachte Notfallkonten oder Anwendungen mit weitreichenden Berechtigungen.

Schritt 2 – Gültige Anmeldedaten oder eine Sitzung erlangen

Der Erstzugriff kann aus Passwort-Wiederverwendung, Credential-Phishing, Token-Diebstahl, Missbrauch des Helpdesks oder einem kompromittierten Gerät stammen. Die genaue Technik variiert, aber die identitätsbezogene Kontrollfrage bleibt dieselbe: Verlangt der Tenant eine stärkere Authentifizierungsmethode, ein konformes Gerät, eine risikoarme Anmeldung oder einen genehmigten Admin-Pfad, bevor Zugriff gewährt wird?

Schritt 3 – Eine administrative Angriffsfläche erreichen

Wenn das Konto ohne die vorgesehenen Kontrollen das Azure-Portal, das Microsoft Entra Admin Center, Microsoft-365-Admin-Portale, Microsoft Graph oder PowerShell erreichen kann, besteht im Tenant eine Lücke in der effektiven Richtlinie.

Schritt 4 – Zugriff sichern

Sobald der Angreifer sich im System befindet, kann er versuchen, eine Authentifizierungsmethode hinzuzufügen, einen neuen Benutzer anzulegen, eine Rolle zuzuweisen, eine Anwendung zu registrieren, einem Dienstprinzipal Anmeldedaten hinzuzufügen oder eine Conditional-Access-Richtlinie abzuschwächen. Diese Aktionen sollten für privilegierte Identitäten als hochrelevante Audit-Ereignisse behandelt werden.

Erkennung

Anmelde- und Richtliniensignale

Überprüfen Sie die Microsoft Entra-Anmeldeprotokolle und Conditional-Access-Ergebnisse auf:

erfolgreiche privilegierte Anmeldungen, bei denen MFA nicht verlangt wurde, obwohl sie es hätte sein sollen
Anmeldungen, bei denen die Authentifizierungsmethode nicht die erwartete Stärke erfüllt
Admin-Zugriffe von nicht verwalteten Geräten oder aus unerwarteten Standorten
Anmeldungen mit mittlerem oder hohem Risiko, die erfolgreich abgeschlossen wurden
wiederholte Fehlversuche gefolgt von einem Erfolg bei einem Admin-Konto
Anmeldungen durch Notfallkonten
Nutzung von Legacy-Clients oder -Protokollen, wo diese eigentlich blockiert sein sollten

Audit-Log-Signale

Überwachen Sie Tenant-Änderungen, die Identitätskontrollen schwächen können:

Änderungsbereich	Warum es wichtig ist
Aktualisierung einer Conditional-Access-Richtlinie	Kann MFA-, Geräte-, Risiko- oder App-Anforderungen entfernen
Aktualisierung einer Conditional-Access-Ausnahme	Kann einen unauffälligen Umgehungspfad schaffen
Änderung einer Authentifizierungsmethode	Kann Kontowiederherstellung oder Persistenz unterstützen
Rollenzuweisung	Kann ein einzelnes Konto zur Kontrolle über den Tenant machen
Änderung von App-Anmeldedaten	Kann dauerhafte, app-basierte Persistenz schaffen
Änderung der Security Defaults	Kann den Basisschutz entfernen, wenn er nicht ersetzt wird

Einschränkungen bei der Erkennung

Alarmieren Sie nicht allein aufgrund der Existenz von MFA. Alarmieren Sie anhand der tatsächlichen Ergebnisse. Die Frage lautet nicht „Hat der Tenant eine MFA-Richtlinie?", sondern „Hat diese Anmeldung dieser Identität an dieser Ressource die erforderliche Kontrolle erfüllt?" Conditional-Access-Ergebnisse, Authentifizierungsdetails, Risikostufe, Benutzerrolle, Anwendung, Gerät und Standort spielen dabei alle eine Rolle.

Behebung

Die sichere Grundlage ist entweder Security Defaults für einfache Tenants oder ein vollständiges Conditional-Access-Design für komplexere Tenants. Beides fehlen zu lassen, ist der vermeidbare Fehler.

1. Security Defaults reaktivieren oder sofort ersetzen

Wenn der Tenant über kein ausgereiftes Conditional-Access-Design verfügt, aktivieren Sie Security Defaults. Nutzt die Organisation Conditional Access, dokumentieren Sie die Ersatz-Baseline, bevor Sie Security Defaults deaktivieren, und testen Sie sie anhand realer Anmeldeszenarien.

Das Ersatzdesign sollte mindestens privilegierte Benutzer, die Azure-Verwaltung, Microsoft-365-Admin-Oberflächen, riskante Anmeldungen und die Gefährdung durch Legacy-Authentifizierung abdecken.

2. Starke Authentifizierung für privilegierte Rollen verlangen

Verlangen Sie für normale privilegierte Benutzer MFA und ziehen Sie für die sensibelsten Rollen stärkere Methoden in Betracht. Nutzen Sie Conditional-Access-Authentifizierungsstärken, um phishing-resistente Methoden zu verlangen, wo die Umgebung dies unterstützt.

Zu den üblichen, besonders wertvollen Rollenpopulationen zählen:

Global Administrator
Privileged Role Administrator
Conditional Access Administrator
Security Administrator
Application Administrator
Cloud Application Administrator
Exchange Administrator und SharePoint Administrator in Tenants mit starker Microsoft-365-Nutzung

3. Notfallkonten separat verwalten

Notfallkonten sind für die Resilienz notwendig. Microsoft empfiehlt zwei oder mehr rein cloud-basierte Notfallkonten auf der Domain *.onmicrosoft.com, die weder föderiert noch aus einer On-Premises-Umgebung synchronisiert werden. Diese Konten sollten nicht als alltägliche Admin-Identitäten verwendet werden, und ihr Kontrolldesign sollte Abhängigkeiten vermeiden, die genau in dem Notfall versagen könnten, den sie eigentlich lösen sollen.

Phishing-resistente Authentifizierung für diese Konten ist nicht mehr optional. Die verpflichtende MFA-Erzwingung gilt auch für Notfallkonten, sodass ein reines Passwort-Notfallkonto inzwischen eine Aussperrung ist, die nur auf ihren Moment wartet. Microsofts aktuelle Empfehlung lautet, eine von zwei passwortlosen Methoden zu registrieren, die die verpflichtende MFA-Anforderung erfüllen – einen Passkey (FIDO2), den Microsoft empfiehlt, oder zertifikatsbasierte Authentifizierung, sofern bereits eine PKI vorhanden ist – und dabei eine andere Methode zu verwenden als die, die die regulären Admin-Konten nutzen. Schließen Sie diese Konten von Conditional-Access-Richtlinien aus, die Anmeldungen blockieren oder einschränken (Report-only-Richtlinien benötigen keinen Ausschluss), speichern Sie die Anmeldedaten an getrennten sicheren Orten, halten Sie die Global-Administrator-Zuweisung dauerhaft aktiv statt in PIM nur berechtigt (eligible), alarmieren Sie bei jeder Anmeldung, und validieren Sie die Konten mindestens alle 90 Tage. Meldet sich ein Notfallkonto an, sollte das Sicherheitsteam davon wissen.

4. Unnötige Ausnahmen entfernen

Überprüfen Sie jeden ausgeschlossenen Benutzer, jede Gruppe, jeden Standort, jede App und jede Gerätebedingung in Conditional Access. Ausnahmen, die während des Troubleshootings entstehen, werden häufig dauerhaft. Jede Ausnahme sollte einen Verantwortlichen, einen Grund, ein Ablaufdatum oder einen Überprüfungsrhythmus sowie eine kompensierende Überwachung haben.

5. Identitätssicherheit mit Risikoreaktion kombinieren

Security Defaults und MFA sind in größeren Tenants kein Ersatz für eine risikobasierte Reaktion. Nutzen Sie Risikosignale aus Microsoft Entra ID Protection über Conditional-Access-Risikobedingungen, um bei erkanntem Risiko eine Step-up-Authentifizierung, eine erneute Authentifizierung, eine Risikobehebung oder eine Blockierung zu verlangen. Microsofts aktuelle Empfehlung lautet, bei hohem Benutzerrisiko eine Risikobehebung zu verlangen und bei mittlerem oder hohem Anmelderisiko MFA plus die Sitzungshäufigkeit „Jedes Mal" zu fordern. Bauen Sie dies als Conditional-Access-Richtlinien und nicht im ID-Protection-Blade auf: Die im Microsoft Entra ID Protection konfigurierten Legacy-Risikorichtlinien werden am 1. Oktober 2026 eingestellt. Tenants, die diese noch nutzen, müssen die entsprechenden Äquivalente in Conditional Access neu erstellen und die alten Richtlinien deaktivieren.

Validierung nach Richtlinienänderungen

Validieren Sie den tatsächlich wirksamen Richtlinienpfad, statt Konfigurations-Screenshots zu vertrauen:

Testen Sie die Anmeldung eines privilegierten Benutzers am Azure-Portal und bestätigen Sie, dass die erwartete Kontrolle tatsächlich verlangt wird
Testen Sie gegebenenfalls die Anmeldung eines privilegierten Benutzers an Microsoft Graph oder PowerShell
Bestätigen Sie, dass dasselbe Konto nicht über eine andere Gruppen-, Standort-, App- oder Gerätebedingung ausgeschlossen ist
Überprüfen Sie die Anmeldeprotokolle, um das Conditional-Access-Ergebnis und die Details der Authentifizierungsmethode zu bestätigen
Validieren Sie die Alarmierung für Notfallkonten, indem Sie den Alarmierungspfad überprüfen, statt seine Existenz vorauszusetzen
Überprüfen Sie riskante Anmeldungen und bestätigen Sie, dass risikobasierte Richtlinien greifen würden
Bestätigen Sie, dass Legacy-Authentifizierung dort blockiert wird, wo Security Defaults oder Conditional Access dies eigentlich tun sollten
Prüfen Sie, ob die Anforderungen an die Authentifizierungsstärke ausschließlich durch die vorgesehenen Methoden erfüllt werden

Eine Kontrolle, die zwar existiert, aber nicht auf die Anmeldungen zutrifft, die Angreifer nutzen können, ist keine Identitätssicherheitskontrolle.

Wie EtcSec dies erkennt

EtcSec überprüft bei jedem Tenant-Scan die Azure-Identitätskontrollen. Alle drei nachfolgenden Prüfungen erfolgen auf Tenant-Ebene: Sie stellen fest, ob die Kontrolle überhaupt existiert – die Voraussetzung für die Frage je Anmeldung, um die es in diesem Artikel geht.

MFA_NOT_ENFORCED_ADMINS kennzeichnet einen Tenant, bei dem keine aktivierte Conditional-Access-Richtlinie Verzeichnisrollen mit einer MFA-Grant-Kontrolle adressiert.

AZ_SECURITY_DEFAULTS_DISABLED kennzeichnet einen Tenant, dessen Security-Defaults-Schalter deaktiviert ist. Ob eine gleichwertige Conditional-Access-Baseline diesen ersetzt hat, ist die gesonderte Prüfung, die dieser Artikel beschreibt.

CA_NO_MFA_REQUIREMENT kennzeichnet einen Tenant, bei dem keine aktivierte Conditional-Access-Richtlinie in ihren Grant-Kontrollen überhaupt MFA verlangt.

Die eigentlich relevante Frage ist nicht, ob ein Tenant auf dem Papier Richtlinien besitzt. Sie lautet, ob privilegierte Anmeldungen tatsächlich auf die vorgesehenen Kontrollen treffen und ob riskante Sitzungen eine Reaktion auslösen.

Azure Identitätssicherheit: Warum MFA Allein Nicht Ausreicht