Adaptives MFA & Risikobewertung

Traditionelles MFA ist binär: Entweder erfordert jede Anmeldung einen zweiten Faktor, oder keine. Dies schafft eine Spannung zwischen Sicherheit (immer MFA verlangen) und Benutzererfahrung (MFA erzeugt Reibung). Adaptives MFA löst diese Spannung, indem es zusätzliche Authentifizierung nur dann verlangt, wenn die Anmeldung riskant erscheint.

Auris implementiert adaptives MFA durch eine Risikobewertungs-Engine, die jeden Authentifizierungsversuch über fünf Dimensionen bewertet. Wenn der berechnete Risikoscore einen konfigurierbaren Schwellenwert überschreitet, eskaliert Auris die Authentifizierungsanforderungen — fordert einen zusätzlichen Faktor an, blockiert den Versuch oder benachrichtigt den Benutzer.

Funktionsweise des adaptiven MFA

Das adaptive MFA-System läuft als Post-Authentifizierungsschritt. Nachdem die primären Anmeldedaten des Benutzers verifiziert wurden (Passwort, Magic-Link, Social-Login), bewertet die Risikobewertungs-Engine den Anmeldekontext, bevor Tokens ausgestellt werden.

Der Kerngedanke: Ein Benutzer, der sich von seinem üblichen Gerät, seiner üblichen IP und zu seiner üblichen Zeit anmeldet, kommt ohne Reibung durch. Der gleiche Benutzer, der sich von einem neuen Gerät in einem neuen Land um 3 Uhr morgens anmeldet, erhält eine MFA-Challenge — oder wird vollständig gesperrt.

Das 5-Faktor-Risikobewertungsmodell

Jeder Faktor trägt einen gewichteten Score zur gesamten Risikobewertung bei. Die einzelnen Faktor-Scores werden zu einem Gesamtscore zwischen 0 (kein Risiko) und 100 (maximales Risiko) kombiniert.

Faktor 1: IP-Reputation

Die Engine bewertet den Ruf der Quell-IP-Adresse.

IP-Reputationsdaten stammen vom konfigurierten GeoIP-Anbieter (ip-api.com für kostenlose Deployments, MaxMind GeoIP2 für bezahlte). Der Anbieter gibt Metadaten zurück, einschließlich isVpn, isProxy und isDatacenter-Flags.

Warum es wichtig ist: Legitime Benutzer melden sich selten von Rechenzentrum-IPs oder Tor-Exit-Nodes an. VPN-Nutzung ist häufiger und kann für einige Benutzerpopulationen erwartet werden (Fernarbeiter, datenschutzbewusste Benutzer), weshalb VPN-Scores niedriger sind als Rechenzentrum- oder Blocklisten-Scores.

Faktor 2: Gerätevertrauen

Die Engine vergleicht den aktuellen Geräte-Fingerabdruck mit zuvor gesehenen Fingerabdrücken für diesen Benutzer.

Geräte-Fingerabdrücke werden als SHA-256-Hash von Browser-Eigenschaften berechnet (User-Agent, Bildschirmauflösung, Zeitzone, Sprache, installierte Plugins). Das DeviceFingerprint-Modell speichert eine Zuordnung von userId + fingerprintHash, mit einem einzigartigen Constraint zur Vermeidung von Duplikaten.

Warum es wichtig ist: Ein neues Gerät ist eines der stärksten Signale dafür, dass die Anmeldung möglicherweise nicht vom Kontoinhaber stammt. In Kombination mit anderen Faktoren (neue IP, neues Land) erhöht ein neues Gerät den Risikoscore erheblich.

Faktor 3: Geo-Anomalie (Unmögliche Reise)

Die Engine prüft, ob der Anmeldeort physikalisch plausibel ist, angesichts der jüngsten Anmeldehistorie des Benutzers.

Unmögliche Reisen werden mithilfe der Haversine-Formel erkannt, um die Großkreis-Entfernung zwischen dem aktuellen und dem vorherigen Anmeldeort zu berechnen, und dann durch die verstrichene Zeit zu dividieren, um die erforderliche Reisegeschwindigkeit zu berechnen.

Die Standard-Maximalreisegeschwindigkeit beträgt 900 km/h (ungefähre Geschwindigkeit eines Linienjets). Wenn die erforderliche Geschwindigkeit diesen Schwellenwert überschreitet, wird die Anmeldung als unmögliche Reise markiert.

Warum es wichtig ist: Wenn ein Benutzer sich vor 30 Minuten von Mailand aus angemeldet hat und sich jetzt von Tokio aus anmeldet, würde die erforderliche Reisegeschwindigkeit etwa 18.000 km/h betragen. Dies ist physikalisch unmöglich und deutet stark darauf hin, dass die zweite Anmeldung von einer anderen Person mit gestohlenen Anmeldedaten kommt.

Faktor 4: Verhaltenssignale

Die Engine analysiert Muster im Authentifizierungsverhalten des Benutzers.

Die Verhaltensanalyse verwendet die historischen Anmeldedaten des Benutzers (gespeichert in LoginAttempt-Datensätzen), um ein Profil des normalen Verhaltens zu erstellen. Abweichungen von diesem Profil erhöhen den Risikoscore.

Warum es wichtig ist: Credential-Stuffing-Angriffe und unbefugter Zugriff erfolgen oft zu ungewöhnlichen Stunden, können von mehreren fehlgeschlagenen Versuchen vorausgegangen sein (Passwörter testen) und können mehrere Anwendungen in schneller Folge anvisieren.

Faktor 5: Aktionssensitivität

Verschiedene Aktionen tragen unterschiedliche inhärente Risikoniveaus, unabhängig vom Kontext des Benutzers.

Warum es wichtig ist: Selbst wenn ein Anmeldekontext vollständig normal ist (bekanntes Gerät, bekannte IP, übliche Zeit), sollte die Änderung der E-Mail-Adresse oder die Deaktivierung von MFA mit erhöhter Sorgfalt behandelt werden. Aktionssensitivität stellt sicher, dass hochwirksame Operationen immer einen minimalen Risikoscore-Aufschlag erhalten.

Gewichtete Bewertungsformel

Der endgültige Risikoscore wird als gewichtete Summe der fünf Faktor-Scores berechnet, bei maximal 100 gekappt.

Standard-Gewichtungen:

Gewichtungen können in der Konsole unter Einstellungen → Angriffsschutz → Adaptives MFA angepasst werden, um deinem Bedrohungsmodell zu entsprechen. Zum Beispiel:

• Eine Finanzanwendung könnte die Geo-Anomalie-Gewichtung auf 2.0 erhöhen
• Eine Anwendung mit vielen VPN-Benutzern könnte die IP-Reputations-Gewichtung auf 0.5 reduzieren
• Eine Anwendung mit hoher Admin-Fluktuation könnte die Aktionssensitivitäts-Gewichtung erhöhen

Risikoniveaus

Der berechnete Score wird einem Risikoniveau zugeordnet:

Risikoniveau-Schwellenwerte sind in der Konsole konfigurierbar. Die Zuordnung zwischen Risikoniveaus und Aktionen ist ebenfalls konfigurierbar:

Step-Up-Authentifizierung

Step-Up-Authentifizierung ist der Prozess, bei dem zusätzliche Authentifizierungsfaktoren verlangt werden, wenn der Risikoscore einen Schwellenwert überschreitet. Auris verfolgt die „Stärke” der aktuellen Authentifizierung anhand von zwei Standard-OIDC-Claims:

ACR (Authentication Context Class Reference)

ACR ist ein String, der das Vertrauensniveau der Authentifizierung angibt. Auris verwendet ein abgestuftes ACR-Modell:

AMR (Authentication Methods Reference)

AMR ist ein Array von Strings, das angibt, welche Methoden während der Authentifizierung verwendet wurden:

Challenge-Orchestrierung

Wenn Step-Up-Authentifizierung erforderlich ist, präsentiert Auris die entsprechende MFA-Challenge basierend auf den registrierten Methoden des Benutzers und dem erforderlichen ACR-Niveau:

Aktueller ACR: basic (nur Passwort)
Erforderlicher ACR: mfa (mindestens ein zusätzlicher Faktor)

Benutzer hat registriert:
  - TOTP ✓
  - SMS OTP ✓
  - WebAuthn ✗ (nicht registriert)

Verfügbare Challenge-Methoden: TOTP, SMS OTP
Ausgewählte Challenge: TOTP (höchste Priorität registrierter Methode)

Die Challenge-Auswahl folgt dieser Prioritätsreihenfolge:

1. WebAuthn (Hardware-Key / Passkey) — am stärksten, phishing-resistent
2. TOTP (Authenticator-App) — stark, keine Netzwerkabhängigkeit
3. SMS OTP — akzeptabel, aber anfällig für SIM-Swapping

Wenn das Risikoniveau CRITICAL ist und der Benutzer WebAuthn registriert hat, kann Auris speziell WebAuthn verlangen, anstatt einen schwächeren Faktor wie SMS zu akzeptieren.

ACR und AMR in JWT-Claims

Nach Abschluss der Authentifizierung (einschließlich etwaiger Step-Up-Challenges) enthält das Zugriffstoken die erreichten ACR- und AMR-Werte:

{
  "sub": "usr_abc123",
  "iss": "https://auth.acme-corp.com",
  "aud": "your-client-id",
  "acr": "urn:auris:acr:mfa",
  "amr": ["pwd", "otp"],
  "exp": 1739880900
}

Ressourcen-Server können diese Claims prüfen, um ihre eigenen Mindest-Authentifizierungsanforderungen durchzusetzen:

// MFA für sensible API-Endpunkte verlangen
const acr = decodedToken.acr
if (acr === 'urn:auris:acr:basic') {
  return Response.json(
    { error: 'This endpoint requires multi-factor authentication' },
    { status: 403 }
  )
}

Benutzerdefinierte Risikoregeln

Zusätzlich zu den fünf integrierten Faktoren unterstützt Auris benutzerdefinierte Risikoregeln — von Administratoren definierte Bedingungen, die dem Risikoscore hinzufügen oder abziehen.

Erstellen benutzerdefinierter Regeln

Benutzerdefinierte Risikoregeln werden in der Konsole unter Einstellungen → Angriffsschutz → Adaptives MFA → Benutzerdefinierte Regeln verwaltet.

Jede Regel hat:

Beispielregeln

Risiko für Unternehmens-IPs reduzieren:

Bedingung: request.ip IN 203.0.113.0/24
Score-Anpassung: -20

Anmeldungen aus deinem Unternehmensnetzwerk sind von Natur aus vertrauenswürdiger, daher wird der Risikoscore reduziert.

Risiko für kürzlich erstellte Konten erhöhen:

Bedingung: user.createdAt > NOW - 7 days
Score-Anpassung: +15

Neue Konten werden häufiger von Angreifern während einer Credential-Stuffing-Kampagne erstellt.

Risiko für bestimmte E-Mail-Domains erhöhen:

Bedingung: user.email ENDS_WITH @suspicious-domain.com
Score-Anpassung: +25

Temporäre E-Mail-Domains oder bekannte missbräuchliche Domains erhalten einen Risikozuschlag.

Bedingungsengine

Die Bedingungsengine unterstützt diese Operatoren:

Bedingungen werden gegen dasselbe Kontextobjekt ausgewertet, das für Actions verfügbar ist, sodass alle Felder auf user, application, connection, request und tenant verfügbar sind.

Integration in den Anmelde-Flow

Adaptives MFA integriert sich nach der Anmeldedaten-Verifizierung in den Auris-Anmelde-Flow.

Die Risikobewertung wird als RiskAssessment-Datensatz in der Datenbank mit dem berechneten Score, den einzelnen Faktor-Aufschlüsselungen, dem Risikoniveau und ob Step-Up erforderlich war, gespeichert. Diese Daten sind in Audit-Logs und im Angriffsschutz-Dashboard verfügbar.

Risikobewertungshistorie

Jede Risikobewertung wird gespeichert und ist in der Konsole unter Einstellungen → Angriffsschutz → Risikobewertungen zugänglich:

Die Historienansicht enthält Diagramme mit:

• Risikoscore-Verteilung über die Zeit
• Häufigste Risikofaktoren, die erhöhte Scores auslösen
• Step-Up-MFA-Erfolgsrate (wie oft Benutzer die Challenge abschließen vs. abbrechen)

Diese Daten helfen dir, Schwellenwerte und Gewichtungen für deine spezifische Benutzerpopulation zu optimieren.

Vergleich mit statischen MFA-Richtlinien

Auris unterstützt beide Modelle. Du kannst obligatorisches MFA auf Tenant-Ebene (jede Anmeldung erfordert einen zweiten Faktor) und adaptives MFA gleichzeitig konfigurieren. In dieser Konfiguration fügt adaptives MFA Step-Up-Challenges zusätzlich zur Basis-MFA-Anforderung hinzu — zum Beispiel WebAuthn anstelle von TOTP verlangen, wenn das Risiko hoch ist.

Verwandte Konzepte

• Multi-Faktor-Authentifizierung — MFA-Methoden und -Richtlinien konfigurieren
• Angriffsschutz — Brute-Force, verdächtige Anmeldung, CAPTCHA
• Sitzungen & Token-Rotation — Wie Risikobewertungen die Sitzungserstellung beeinflussen
• Sicherheitseinstellungen — Konsolen-Leitfaden für alle Sicherheitskontrollen
• Actions-Engine — Benutzerdefinierte Hooks, die neben der Risikobewertung ausgeführt werden