Was ist Multi-Faktor-Authentifizierung (MFA)?
Multi-Faktor-Authentifizierung prüft eine Identität mit mindestens zwei Nachweisen aus unterschiedlichen Kategorien, etwa einem Passwort und einem Sicherheitsschlüssel. Zwei-Faktor-Authentifizierung (2FA) ist der Fall mit genau zwei. Passwort und Sicherheitsfrage sind beides Wissen und damit keine MFA.
Rechtlich verankert ist MFA in § 30 Abs. 2 Satz 2 Nr. 10 BSIG: Besonders wichtige und wichtige Einrichtungen brauchen „Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung“. Die Nummer setzt Art. 21 Abs. 2 Buchst. j der Richtlinie (EU) 2022/2555 um. Außerhalb dieses Kreises kann MFA aus Verträgen, Branchenstandards wie PCI DSS oder der Risikoabwägung nach Art. 32 DSGVO folgen.
| Kategorie | Beispiele | Schwachstelle |
|---|---|---|
| Wissen | Passwort, PIN, Wiederherstellungscode | wird weitergegeben oder auf gefälschten Seiten abgefragt |
| Besitz | Sicherheitsschlüssel, Chipkarte, Authenticator-App auf registriertem Gerät | Geräteverlust, Übernahme der Mobilfunknummer |
| Inhärenz | Fingerabdruck, Gesichtserkennung | nicht änderbar; kann der Mitbestimmung unterliegen |
Zählt ein Passkey als MFA?
Ein Passkey ist ein Anmeldeschlüssel nach den Standards der FIDO-Allianz, der an einen bestimmten Dienst gebunden ist (BSI zu Passkeys). Ob er als MFA zählt, hängt an einem Detail: Verlangt der Dienst, dass der Nutzer den Schlüssel mit PIN oder Biometrie freigibt? Nach Anhang B von NIST SP 800-63B-4 zeigt das Merkmal „User Verified“, ob ein Authentikator als mehrfaktoriell gilt; fehlt die Verifikation, gilt er als einfaktoriell.
Antippen eines Sicherheitsschlüssels belegt nur die Anwesenheit („User Present“), keine PIN und keine Biometrie. Prüfen Sie deshalb in der Konfiguration des Dienstes, ob er die Nutzerverifikation verlangt.
Welche Verfahren sind phishing-resistent?
| Verfahren | Phishing-resistent | Grenze |
|---|---|---|
| Passwort und Code per SMS | nein | Code wird weitergeleitet; Mobilfunknummer kann übernommen werden |
| Passwort und Code aus einer App | nein | eine gefälschte Seite leitet den Code sofort weiter |
| Passwort und Push-Bestätigung, auch mit Zahlenabgleich | nein | erschwert versehentliche Freigaben, bindet die Anmeldung aber nicht an den echten Dienst |
| Passkey oder Sicherheitsschlüssel mit Nutzerverifikation | ja | Schutz hängt weiter an Registrierung und Wiederherstellung |
Nach Abschnitt 3.2.5 von NIST SP 800-63B-4 setzt Phishing-Resistenz eine kryptografische Authentifizierung voraus; Verfahren, bei denen ein Code abgetippt wird, etwa per SMS oder aus einer App, gelten dort nicht als phishing-resistent. Gegen wiederverwendete Passwörter schützen sie trotzdem. Den Code auf demselben Gerät zu empfangen, mit dem man sich anmeldet, rät das BSI zur Zwei-Faktor-Authentisierung ab. Für Administratorkonten und Fernzugriff ist ein phishing-resistentes Verfahren die stärkere Wahl.
Die Wege um die Anmeldung herum prüfen
Beispiel (fiktiv): Administratoren melden sich mit Passkeys an. Der Servicedesk ersetzt einen verlorenen Faktor aber nach Nennung von Name und Personalnummer. Der Registrierungsbericht zeigt „MFA aktiv“, die Lücke zeigt er nicht.
Prüfen Sie mit einem Testkonto oder in einer Planübung diese vier Wege:
| Weg | Prüffrage | Bestanden, wenn | Nachweis |
|---|---|---|---|
| normale Anmeldung | Erzwingt die Anwendung das vorgesehene Verfahren für dieses Konto? | eine Anmeldung ohne das vorgesehene Verfahren wird abgelehnt | Richtlinie und passender Anmeldeeintrag |
| Geräteverlust | Welche Identitätsprüfung gilt, bevor ein neuer Faktor registriert wird? | ein neuer Faktor wird erst nach einer Prüfung registriert, die ein Anrufer mit Name und Personalnummer allein nicht besteht | Wiederherstellungsverfahren und Testergebnis |
| Ausweichverfahren | Kann ein schwächeres Verfahren das vorgesehene umgehen? | kein schwächeres Verfahren ist für das Konto zugelassen, außer in freigegebenen Ausnahmen | erlaubte Verfahren und Ausnahmeentscheidungen |
| nach der Wiederherstellung | Werden alte Faktoren und Sitzungen ungültig, wird der Nutzer informiert? | alte Faktoren und Sitzungen sind ungültig, der Nutzer ist benachrichtigt | Sperr- und Benachrichtigungsprotokolle |
Ein Notfallzugang kann gewollt sein. Er braucht einen Verantwortlichen, eigene Schutzmaßnahmen und Überwachung, und er wird getestet.
Registriert heißt nicht erzwungen
Dass Beschäftigte einen zweiten Faktor registriert haben, beweist nicht, dass jede Anwendung ihn verlangt. Prüfen Sie erfasste Konten, Ausnahmen in den Richtlinien, ältere Authentifizierungsprotokolle, die keinen zweiten Faktor abfragen, und die tatsächlichen Anmeldungen.
Dienstkonten für automatisierte Abläufe lassen sich nicht interaktiv per MFA schützen; sie brauchen eigene Maßnahmen wie eingeschränkte Rechte. Für Beschäftigte ohne Diensthandy planen Sie Hardware-Token oder Chipkarte ein. Und MFA ersetzt keine Zugriffskontrolle: Wer sich anmelden darf, darf damit noch nicht jede Aktion ausführen. Wie MFA in das ISMS eingebettet wird, beschreibt der Leitfaden ISMS einführen.
MFA-Nachweis je Asset in Rizzqo
In Rizzqo erscheinen die Authentifizierungsanforderungen der hinterlegten Kataloge, etwa ISO/IEC 27002, an den unterstützenden Assets mit Anmeldung, etwa VPN-Zugang, E-Mail-Dienst oder Cloud-Konsole. Der Eigentümer des Assets beantwortet, ob dort MFA erzwungen wird, und hängt die Konfiguration des Identitätsanbieters als Nachweis an. Die Antwort wird mit Name und Zeitstempel finalisiert.
Für ein Altsystem ohne zweiten Faktor bewertet der Risikoeigentümer das Risiko mit Eintrittswahrscheinlichkeit in Prozent und Auswirkung in Euro. Ausgleichsmaßnahmen laufen als Aufgaben, die sich in beide Richtungen mit Jira synchronisieren.