MFA-Muster
Zielbild
Section titled “Zielbild”MFA ist kein Häkchen, sondern eine Qualitätsfrage: Welche Faktoren erlaubst du, für wen, in welchem Risiko- und Gerätekontext? Gute MFA-Implementierungen reduzieren Account Takeover, ohne produktive Workflows zu brechen.
Muster 1: Unterschiedliche Anforderungen für Admins und Benutzer
Section titled “Muster 1: Unterschiedliche Anforderungen für Admins und Benutzer”- Admins: phish-resistente Verfahren bevorzugen (FIDO2, Windows Hello for Business), idealerweise zusätzlich “compliant device” und eingeschränkte Locations.
- Benutzer: MFA als Baseline, phish-resistent als Ziel; Übergangsphase mit App-based MFA.
Muster 2: Phish-resistent als Standard etablieren
Section titled “Muster 2: Phish-resistent als Standard etablieren”Wenn die Organisation reif genug ist, ist dies ein starkes Zielbild:
- Authentication Strengths in Conditional Access
- FIDO2-Security Keys für privilegierte Konten
- Windows Hello for Business für Managed Devices
Das reduziert die Angriffsfläche gegenüber Push-Fatigue und OTP-Phishing.
Muster 3: Übergang ohne Stillstand (Onboarding)
Section titled “Muster 3: Übergang ohne Stillstand (Onboarding)”Onboarding ist oft der Engpass. Bewährte Bausteine:
- Temporäre Access Pass (TAP) für initiale Registrierung
- klare Self-Service-Flows (My Sign-Ins, Security Info)
- definierte “Grace Period” für neue Benutzer/Geräte
Praktisch bewährt:
- Kombinierte Registrierung (MFA + Self-Service Password Reset) so einführen, dass Benutzer nicht mehrfach “durch Prozesse” müssen.
- Für Admins ein eigenes Onboarding (FIDO2/WHfB) statt “gleich wie alle”.
Muster 4: Schwache Faktoren nur als Ausnahme
Section titled “Muster 4: Schwache Faktoren nur als Ausnahme”- SMS/Voice nur, wenn nötig (z. B. bestimmte Benutzergruppen/Übergang), mit klarer Exit-Strategie.
- App-based MFA (Number Matching) ist meist der bessere Übergang.
Wenn du Push nutzt, setze Number Matching und zusätzliche Kontextinformationen (z. B. App/Standort) – das reduziert “blindes Bestätigen”.
Muster 5: Break-Glass operationalisieren
Section titled “Muster 5: Break-Glass operationalisieren”Break-Glass ist kein “Geheimkonto”, sondern ein kontrollierter Notfallpfad:
- extrem starke Passwörter, getrennte Aufbewahrung
- strikte Überwachung und Alarmierung bei Nutzung
- bewusst aus CA ausgenommen, aber nur für den Notfall
Anti-Patterns
Section titled “Anti-Patterns”- Ein globales MFA-Setting ohne CA-Design (keine Differenzierung nach Rolle/Risiko).
- Viele dauerhafte Ausnahmen (untergräbt Baseline).
- MFA nur “für Portal”: Angriffe laufen oft über Token-Diebstahl und Modern Auth Apps.
Betriebsaspekt: Wiederherstellung und Support
Section titled “Betriebsaspekt: Wiederherstellung und Support”MFA ist auch Support-Realität. Plane:
- Prozesse für verloren gegangene Geräte/Authenticator-Wechsel
- klare Zuständigkeit (Helpdesk vs Security)
- Logging/Alerting für ungewöhnliche MFA-Resets
Verknüpfung mit Conditional Access
Section titled “Verknüpfung mit Conditional Access”MFA-Patterns sind ohne CA nicht steuerbar. Der Einstieg ist Conditional Access Grundlagen.