In vielen Tenants, die ich betreue, ist Multi-Faktor-Authentifizierung (MFA) längst Standard, zumindest für privilegierte Konten. Und doch stoße ich fast jede Woche auf Ausnahmen: einzelne Benutzer, die ohne MFA ins Azure-Portal kommen, Notfallkonten mit uraltem Passwort oder Automatisierungen, die unter einer Benutzeranmeldung laufen. Genau das will Microsoft mit einer neuen Ankündigung abstellen. In der zweiten Jahreshälfte 2024 kommt die Azure-MFA-Pflicht, zuerst für das Azure-Portal, das Entra Admin Center und das Intune Admin Center, später auch für CLI- und Automatisierungszugriffe.

Ab der zweiten Jahreshälfte 2024 verlangen die Admin-Portale zwingend MFA

Microsoft hat offiziell angekündigt, dass für den Zugriff auf die genannten Admin-Portale künftig zwingend MFA erforderlich ist (zum Blogbeitrag, zur offiziellen Dokumentation). Der Rollout startet in der zweiten Jahreshälfte 2024, ein genaues Datum hat Microsoft bislang nicht genannt. Anfangs geht es nur um die Admin-Portale im Browser. Azure CLI, PowerShell und IaC-Tools sollen später folgen. Für Workload-Identitäten wie Service Principals oder Managed Identities ändert sich ausdrücklich nichts. Microsoft will damit die letzten Zugänge ohne MFA zur Administration schließen, und zwar unabhängig davon, welche Conditional-Access-Richtlinien eine Organisation selbst konfiguriert hat.

Aus meiner Erfahrung bieten gerade die Ausnahmen Angreifern den bequemsten Weg hinein, etwa selten genutzte Konten, Break-Glass-Konten oder technische Benutzer mit Portalzugriff. Microsoft nimmt sich hier also ein sehr reales Risiko vor, das mir in der Beratung ständig begegnet.

Ausnahmekonten und alte Automatisierungen sorgen für die meisten Probleme

Sobald die verpflichtende MFA aktiv ist, kommt niemand mehr ohne MFA ins Portal. Das klingt banal, bereitet in der Praxis aber durchaus Ärger.

Tipp aus der Praxis: Schaut vorher in die Sign-in-Logs von Entra und filtert die Anmeldungen nach „MFA erforderlich = Nein“ und „Anmeldung erfolgreich“. Dann seht ihr, welche Konten tatsächlich noch ohne MFA durchkommen. Meist sind es mehr, als man vermutet.

Genau hinschauen sollte man bei den Break-Glass-Konten, also den Notfall-Admin-Konten. Spätestens jetzt müssen sie auf FIDO2-Sicherheitsschlüssel oder zertifikatbasierte Authentifizierung umgestellt werden, sonst steht man im Ernstfall vor verschlossener Tür. Microsoft rät ohnehin dazu, diese Konten so stark wie möglich abzusichern (Notfallzugriffskonten).

Dazu kommen Skripte und automatisierte Aufgaben, die mit Benutzerkonten im Portal arbeiten. Die finde ich in den meisten Tenants, und nach der Umstellung laufen sie schlicht nicht mehr. Solche Automatisierungen gehören deshalb konsequent auf Service Principals oder Managed Identities. Wie man Client-Secrets durch moderne Authentifizierung ersetzt, habe ich ausführlich im Beitrag Client-Secrets ablösen: Workload Identity Federation in Azure beschrieben.

Die MFA-Pflicht greift zusätzlich zu eigenen Conditional-Access-Richtlinien

Viele Organisationen nutzen bereits Conditional Access, um MFA gezielt durchzusetzen oder Ausnahmen festzulegen. Die neue Pflicht arbeitet unabhängig davon und kommt zu den bestehenden CA-Richtlinien hinzu. Für die besonders sensiblen Admin-Portale würde ich trotzdem nicht auf eigene Richtlinien verzichten, etwa um Session Controls, Gerätekonformität oder standortbasierten Zugriff zu erzwingen. Im Zusammenspiel sieht das ungefähr so aus:

flowchart TD
    Anmeldung["User Login"] --> Portal["Azure/Entra/Intune Admin-Portal"]
    Portal --> MFAZwang["Microsoft MFA-Pflicht"]
    MFAZwang --> CA["Eigene Conditional Access Policy"]
    CA --> Zugriff["Zugriff gewährt"]
    CA --> Block["Blockiert"]

Abbildung: Ablauf mit Microsofts MFA-Pflicht und eigener Conditional-Access-Richtlinie.

Die MFA-Pflicht legt damit eine neue Untergrenze fest. Wer in einer eigenen CA-Richtlinie bestimmten Benutzergruppen noch MFA-Ausnahmen gewährt, wird merken, dass diese im Portal nicht mehr ziehen. Für andere Anwendungen oder APIs gilt die eigene CA-Logik weiterhin.

Vier Aufgaben gehören jetzt auf die Liste

Einen großen Teil der Vorbereitung kann man schon heute erledigen, damit der Wechsel ohne Störungen abläuft. In meinen Projekten gehe ich meist so vor:

  • Auswertung der Sign-in-Logs auf Anmeldungen ohne MFA
  • Überprüfung und Modernisierung der Break-Glass-Konten (FIDO2/CBA)
  • Migration von Automatisierungen auf Service Principals oder Managed Identities
  • Überprüfung und ggf. Nachschärfung der eigenen Conditional-Access-Richtlinien für Admin-Portale

Vor allem die Migration der Skripte und Automatisierungen macht oft mehr Arbeit als gedacht, erst recht, wenn noch alte PowerShell-Module oder Legacy-Authentifizierung im Spiel sind. Auch die Notfallkonten sollte niemand auf die lange Bank schieben. Wer das versäumt, sperrt sich im Ernstfall womöglich selbst aus.

Ein bisschen Zwang tut der Admin-Sicherheit gut

Eigentlich hätte MFA für alle Zugriffe auf kritische Admin-Oberflächen schon längst selbstverständlich sein müssen. Gerade in größeren oder über Jahre gewachsenen Umgebungen ist es das aber nicht. Die neue Azure-MFA-Pflicht gibt hier den richtigen Anstoß, weil sie die letzten unsicheren Zugänge beseitigt. Wer vorbereitet ist, muss sich keine Sorgen machen, alle anderen sollten jetzt loslegen. Für die meisten Tenants dürfte das der letzte Schubs sein, auch die übrigen Altlasten in der Cloud-Sicherheit aufzuräumen.

Wer seine Umgebung regelmäßig überprüft und auf bewährte Verfahren wie den Temporary Access Pass oder moderne Authentifizierungsmethoden setzt, ist gut aufgestellt. Ich halte die neue Vorgabe für einen echten Fortschritt und für eine gute Gelegenheit, die eigene Admin-Strategie einmal kritisch zu prüfen.