Multifaktorauthentifizierung, jetzt! Microsoft setzt MFA ab dem 15. Oktober 2024 durch

Ab dem 15. Oktober 2024 wird Microsoft in Entra ID und allen damit verbundenen Clouddiensten die verpflichtende Einführung der Multifaktorauthentifizierung (MFA) für alle Benutzer durchsetzen. Diese Maßnahme betrifft sämtliche Lizenzmodelle von Entra ID und zielt darauf ab, die Sicherheit der Nutzerkonten mit administrativen Befugnissen deutlich zu erhöhen.

zur Meldung von Microsoft

MFA-Aktivierung in Entra ID

🔍 Was passiert, wenn in meinem Tenant noch kein MFA aktiviert ist?

Microsoft stellt klar, dass MFA ab dem 15. Oktober 2024 verpflichtend wird. Administratoren/Benutzerkonten, die bis zu diesem Stichtag kein MFA eingerichtet haben, können dann gezwungen sein, dies vor der nächsten Anmeldung nachzuholen. Auch Break Glass Konten und weitere zuvor ausgeschlossene Benutzer sind davon betroffen und benötigen zukünftig einen zweiten Faktor. Auch wenn Microsoft in diesem Artikel die Einrichtung und bei der Aktivierung empfiehlt. 

Grundsätzlich sind alle Administratorkonten von diesem Change betroffen. 

MFA-Pflicht bei der Anmeldung:
Die Reihenfolge der Umstellung für Ihre Cloud-Anwendungen

Die betroffenen Konten beschreibt Microsoft wie folgt:

„Alle Benutzenden, die sich bei den zuvor aufgeführten Anwendungen anmelden, um einen Vorgang zum Erstellen, Lesen, Aktualisieren oder Löschen (Create, Read, Update, or Delete, CRUD) auszuführen, benötigen ab dem Zeitpunkt der Durchsetzung eine mehrstufige Authentifizierung. Endbenutzende, die auf Anwendungen, Websites oder Dienste zugreifen, die in Azure gehostet werden, sich aber nicht bei den aufgeführten Anwendungen anmelden, sind nicht verpflichtet, MFA zu verwenden. Die Authentifizierungsanforderungen für Endbenutzende werden vom Besitzenden der Anwendung, Website oder des Dienstes festgelegt.

Workloadidentitäten wie verwaltete Identitäten und Dienstprinzipale sind von der MFA-Durchsetzung nicht betroffen. Wenn sich Benutzeridentitäten als Dienstkonto anmelden, um die Automatisierung (einschließlich Skripts oder andere automatisierte Aufgaben) auszuführen, müssen sich diese Benutzeridentitäten nach Beginn der Erzwingung mit MFA anmelden. Benutzeridentitäten werden für die Automatisierung nicht empfohlen. Sie sollten diese Benutzeridentitäten zu Workloadidentitäten migrieren.

Sobald die Durchsetzung beginnt, sind auch Notfallkonten oder Notfallzugänge erforderlich, um sich mit MFA anzumelden. Es wird empfohlen, diese Konten für die Verwendung von Passkey (FIDO2) zu aktualisieren oder die zertifikatbasierte Authentifizierung für MFA zu konfigurieren. Beide Methoden erfüllen die MFA-Anforderung.“

Quelle: MIcrosoft

MFA-Implementierung

Welche Worst-Case-Szenarien können auf Sie zukommen?

Im ungünstigsten Fall könnte der Zugriff auf den eigenen Tenant verloren gehen, wenn Administratoren die für die Authentifizierung erforderlichen MFA-Methoden nicht mehr zur Verfügung stehen, etwa durch Verlust des Smartphones oder durch ein fehlerhaftes Zurücksetzen der MFA. Dieser Fall ist jedoch eher unwahrscheinlich, da in den meisten Tenants mehrere Administratoren vorhanden sind, die sich gegenseitig absichern können. Dies ist allerdings kein „Best Practice“ nach dem Minimalprinzip.

Wesentlich kritischer wird es bei Service Accounts, die sich automatisiert bei Systemen anmelden müssen. Diese Accounts müssen durch User Managed Identities in Azure ersetzt werden, oder es muss eine Conditional Access Policy eingerichtet werden, die solche Service Accounts von der MFA-Anforderung ausnimmt.

Wahrscheinlich ist das Schlimmste, was passieren könnte, dass momentan einfach keine Möglichkeit für die 2-Faktorauthentifizierung bei betroffenen Benutzern vorhanden ist. Sei es ein Diensttelefon, zusätzliche E-Mail-Konten oder per NFC konfigurierbare Schlüsselanhänger. Bei einer ungeplanten Umstellung besteht die Gefahr, dass Mitarbeitende erstmal nicht mehr arbeiten können, da ohne MFA keine Anmeldung möglich ist. Des Weiteren kann es auch zu der unkontrollierten Inbetriebnahme von privaten Geräten als Token durch die Benutzer kommen.

Die Lösung: MFA vor der Deadline implementieren und sich damit vertraut machen

Dafür gibt es zwei Methoden. Die erste Methode erfolgt über die Aktivierung der in Entra ID integrierten Sicherheitsstandards. Hierbei durchlaufen Administratoren einen kurzen Einrichtungsassistenten, um MFA zu aktivieren. Der Nachteil dieser Methode ist, dass alle Benutzer betroffen sind und keine Ausnahmen definiert werden können. Zudem haben Benutzer 14 Tage Zeit, um MFA zu aktivieren und werden nicht gezwungen diese Sicherheitsmaßnahme direkt wahrzunehmen.

Die zweite Methode ist die Implementierung von MFA im Zusammenspiel mit Conditional Access. Diese Lösung bietet deutlich mehr Flexibilität, setzt jedoch eine Microsoft Entra P1- oder P2-Lizenz voraus. Mit Conditional Access können spezifische Benutzer und Gruppen von der MFA-Pflicht ausgenommen werden, und die Richtlinie kann sofort durchgesetzt werden. Darüber hinaus ermöglicht Conditional Access eine stärkere Absicherung des Zugriffs auf Office 365, beispielsweise durch Einschränkungen auf bestimmte Geräte oder geografische Regionen. So könnten Sie den Zugriff aus bestimmten Ländern wie Russland oder China komplett unterbinden oder auf firmeneigene Geräte beschränken.

Im Notfall kann die MFA-Frist im Portal bis zum 15. April 2025 verlängert werden, doch auch hier ist ein zeitnahes Handeln äußerst wichtig.

Unser Fazit zur Einführung von MFA als verpflichtende Sicherheitsmaßnahme

Die Einführung von MFA als verpflichtende Sicherheitsmaßnahme ist ein wichtiger Schritt, um die Sicherheit von Identitäten zu gewährleisten und vor unbefugtem Zugriff zu schützen. Dass Microsoft dieses Feature nun erzwingt, sollte als Chance gesehen werden, die eigene Sicherheitsinfrastruktur signifikant zu verbessern.

Gerne begleiten wir Sie bei diesem Schritt und helfen Ihnen bei der Planung und Inbetriebnahme von MFA in der Cloud. Auch bei generellen Themen, wie der Gestaltung der Berechtigungen in Ihrem Tenant nach dem Minimalprinzip, sind wir für Sie da!