Angriffsschutz

Auris wird mit mehreren Verteidigungsebenen ausgeliefert, die bei jeder Authentifizierungsanfrage aktiviert werden. Diese Systeme arbeiten unabhängig voneinander, sind aber in einer bestimmten Pipeline geschichtet — jede Prüfung läuft in Reihenfolge, so dass spätere, teurere Prüfungen nur erreicht werden, nachdem günstigere Anfangsfilter bestanden wurden.

Rate Limiting

Auris wendet Sliding-Window-Rate-Limiting auf alle API-Endpunkte an. Rate Limits werden im Arbeitsspeicher pro Instanz durchgesetzt und werden nicht über Instanzen in einer Multi-Node-Bereitstellung hinweg geteilt — wenn du verteiltes Rate Limiting benötigst, konfiguriere einen Redis-unterstützten gemeinsamen Speicher.

Stufen

Genaue Limitwerte sind pro Stufe über Umgebungsvariablen oder die Console konfigurierbar (Console → Sicherheit → Rate Limiting).

Antwort-Header

Alle API-Antworten von rate-begrenzten Endpunkten enthalten Standard-Header:

Wenn ein Rate Limit überschritten wird, gibt Auris HTTP 429 Too Many Requests mit dem Retry-After-Header zurück. Clients sollten diesen Header respektieren und entsprechend zurückweichen.

HTTP/1.1 429 Too Many Requests
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1718016000
Retry-After: 47
Content-Type: application/json
 
{
  "ok": false,
  "error": {
    "code": "RATE_LIMIT_EXCEEDED",
    "message": "Zu viele Anfragen. Bitte versuche es in 47 Sekunden erneut."
  }
}

Brute-Force-Schutz

Auris verfolgt fehlgeschlagene Login-Versuche pro Benutzerkonto und pro IP-Adresse. Nach einer konfigurierbaren Anzahl aufeinanderfolgender Fehlschläge wird das Konto oder die IP für eine eskalierende Dauer gesperrt.

Wie die Sperrung funktioniert

1. Jeder fehlgeschlagene Login-Versuch erstellt einen LoginAttempt-Datensatz mit Zeitstempel, IP und User-Agent.
2. Wenn die Fehleranzahl für ein Konto oder eine IP den konfigurierten Schwellenwert innerhalb des Beobachtungsfensters überschreitet, wird ein AccountLockout-Datensatz erstellt.
3. Während einer Sperrung geben alle Login-Versuche für das betroffene Konto sofort HTTP 423 Locked zurück — Keycloak-Authentifizierung wird nicht versucht.
4. Die Sperrdauer eskaliert mit wiederholten Sperren: Erste Sperrung = 5 Minuten, zweite = 30 Minuten, dritte = 24 Stunden (konfigurierbar).

Konfiguration

Konfigurieren über Console → Sicherheit → Brute-Force-Schutz:

Manuelle Entsperrung

Administratoren können Konten manuell über die Console entsperren (Benutzer-Detail → Sicherheit → Konto entsperren) oder per API:

Passwortsicherheit

HaveIBeenPwned-Integration

Wenn ein Benutzer ein Passwort setzt oder ändert, prüft Auris es gegen die HaveIBeenPwned (HIBP) Pwned Passwords-Datenbank mithilfe der k-Anonymity-API. Nur die ersten 5 Zeichen des SHA-1-Hashes werden an HIBP gesendet — das Klartext-Passwort verlässt Auris nie.

Wenn das Passwort in bekannten Datenleck-Datensätzen erscheint, lehnt Auris es ab und fordert den Benutzer auf, ein anderes Passwort zu wählen. Diese Prüfung gilt für:

• Benutzerregistrierung
• Passwort-Änderungsanfragen
• Vom Admin erstellte Passwörter über die API

Komplexitätsanforderungen

Minimale Passwortanforderungen in Console → Sicherheit → Passwortrichtlinie konfigurieren:

Anforderungen werden auf von Auris verwaltete Passwörter angewendet. SSO-Benutzer authentifizieren sich über ihren Corporate-IdP und unterliegen nicht den Auris-Passwortrichtlinien.

Erkennung verdächtiger Logins

Auris analysiert jeden Login auf Verhaltensanomalien. Die Erkennung läuft nach erfolgreicher Keycloak-Authentifizierung — wenn die Login-Anmeldedaten korrekt sind, der Kontext aber verdächtig ist, kann Auris den Benutzer benachrichtigen, den Login blockieren oder MFA-Step-up auslösen.

Erkennungsmethoden

1. Neues Gerät

Auris berechnet einen Fingerabdruck-Hash aus einer Kombination von Browser-User-Agent, Bildschirmauflösung und anderen stabilen Signalen. Wenn der Fingerabdruck für diesen Benutzer noch nicht gesehen wurde, wird der Login als “neues Gerät” markiert. Der Geräte-Datensatz wird nach dem ersten erfolgreichen Login aus diesem Kontext in DeviceFingerprint gespeichert.

2. Neue IP-Adresse

Auris verfolgt, von welchen IP-Adressen sich ein Benutzer zuvor angemeldet hat. Ein Login von einer IP, die noch nie für dieses Konto gesehen wurde, wird markiert.

3. Neues Land

GeoIP-Lookup bestimmt das Land der Login-IP. Wenn das Land von der Login-Historie des Benutzers abweicht, wird der Login markiert. Ländererkennung verwendet ip-api.com (Standard) oder eine lokale MaxMind GeoLite2-Datenbank (konfigurierbar für Offline/datenschutzempfindliche Bereitstellungen).

4. Unmögliche Reise

Auris berechnet die geografische Entfernung (Haversine-Formel) zwischen dem aktuellen Login-Ort und dem jüngsten Login-Ort, dann dividiert durch die verstrichene Zeit, um eine implizierte Reisegeschwindigkeit abzuleiten. Wenn die Geschwindigkeit einen konfigurierbaren Schwellenwert überschreitet (Standard: 800 km/h — schneller als die kommerzielle Luftfahrt), wird der Login als unmögliche Reise markiert.

5. VPN / Proxy / Rechenzentrum-Erkennung

GeoIP-Lookup enthält Metadaten, die angeben, ob die IP zu einem bekannten VPN-Anbieter, Proxy oder Cloud-Rechenzentrum gehört. Logins von solchen IPs werden standardmäßig markiert, können aber erlaubt werden, wenn deine Benutzer häufig über VPN auf den Dienst zugreifen.

Konfigurierte Aktionen

Jede Erkennungsmethode kann unabhängige Aktionen auslösen:

GeoIP-Provider-Konfiguration

Verdächtige Login-Ereignisse überprüfen

CAPTCHA-Integration

Auris unterstützt drei CAPTCHA-Provider auf den Login-, Signup- und Passwort-Reset-Seiten. CAPTCHA kann so eingestellt werden, dass es immer ausgelöst wird, nur wenn das Risiko erhöht ist, oder nur nach einer Anzahl fehlgeschlagener Versuche.

Unterstützte Provider

Auslösemodi

Konfiguration

Konfigurieren über Console → Sicherheit → CAPTCHA:

1. CAPTCHA-Provider auswählen.
2. Den Site-Key (im Browser verwendet) und Secret-Key (serverseitig für die Verifizierung verwendet) aus dem Dashboard des Providers eingeben.
3. Auslösemodus und (für AFTER_FAILURES) Versuchsschwellenwert festlegen.
4. Für reCAPTCHA v3 den Mindest-Score-Schwellenwert (0,0–1,0) festlegen, unter dem ein Login blockiert wird.

IP-Allow/Block-Listen

Auris unterstützt CIDR-basierte IP-Regeln auf Tenant-Ebene und pro Anwendung. Regeln werden vor jedem Authentifizierungsversuch ausgewertet.

Regeltypen

Vorrang: BLOCK-Regeln haben immer Vorrang vor ALLOW-Regeln innerhalb desselben Geltungsbereichs.

Geltungsbereich: Regeln können auf den gesamten Tenant (scope: TENANT) oder eine bestimmte Anwendung (scope: APPLICATION, applicationId: ...) beschränkt werden.

Temporäre Regeln: isTemporary: true setzen und expiresAt angeben, um Regeln zu erstellen, die automatisch ablaufen. Nützlich für temporäre Sperren nach einem erkannten Angriff.

IP-Regeln verwalten

{
  "cidr": "203.0.113.0/24",
  "type": "BLOCK",
  "scope": "TENANT",
  "label": "Verdächtiges ASN",
  "note": "Gesperrt nach Credential-Stuffing-Angriff am 01.06.2025",
  "isTemporary": true,
  "expiresAt": "2025-07-01T00:00:00Z"
}

CIDR-Notation

Auris unterstützt sowohl IPv4- als auch IPv6-CIDR-Notation:

• Einzelne IP: 203.0.113.42/32
• Subnetz: 203.0.113.0/24 (256 Adressen)
• Gesamter Bereich: 10.0.0.0/8 (16,7 Millionen Adressen)
• IPv6 einzeln: 2001:db8::1/128
• IPv6 Bereich: 2001:db8::/32

Die Login-Sicherheits-Pipeline

Jede Login-Anfrage durchläuft die folgenden Prüfungen in dieser Reihenfolge. Jede Prüfung kann die Pipeline durch Rückgabe eines Fehlers kurzschließen:

Eingehende Login-Anfrage
        |
        v
1. IP-Allow/Block-Prüfung
   BLOCK-Regel übereinstimmend? → HTTP 403, Stopp
   ALLOW-Regel vorhanden? → weiter
        |
        v
2. CAPTCHA-Verifizierung
   Modus = ALWAYS? → gültiges Token erforderlich
   Modus = ON_SUSPICIOUS? → Risikoscore auswerten, bei hoch erforderlich
   Modus = AFTER_FAILURES? → IP-Fehleranzahl prüfen
   Ungültiges/fehlendes Token? → HTTP 400, Stopp
        |
        v
3. Rate Limiting
   Pro-IP-Limit überschritten? → HTTP 429, Stopp
   Pro-Benutzer-Limit überschritten? → HTTP 429, Stopp
        |
        v
4. Brute-Force / Sperr-Prüfung
   Konto oder IP aktuell gesperrt? → HTTP 423, Stopp
        |
        v
5. Keycloak-Authentifizierung
   Ungültige Anmeldedaten? → Fehlversuch aufzeichnen, HTTP 401, Stopp
   Gültige Anmeldedaten? → weiter
        |
        v
6. Analyse verdächtiger Logins
   (nicht-blockierend — läuft asynchron, zeichnet Ereignisse auf)
   Hochgradige Erkennung? → konfigurierte Aktion auslösen (benachrichtigen/blockieren/MFA erfordern)
        |
        v
7. Adaptives MFA-Risikoscoring
   Risikoscore aus 5 Faktoren berechnet
   Score über Schwellenwert? → MFA-Step-up erforderlich
        |
        v
8. Token-Ausstellung
   ACR- und AMR-Claims basierend auf abgeschlossenen Auth-Methoden setzen
   Access Token und Refresh Token zurückgeben

Erforderliche Berechtigungen

Verwandte Seiten

• Multi-Faktor-Authentifizierung — TOTP, SMS-OTP, WebAuthn und adaptives MFA
• Console: Sicherheitseinstellungen — Vollständige Console-Anleitung für alle Sicherheitsfunktionen
• Konzepte: Login-Flow — Detaillierte Aufschlüsselung der Authentifizierungs-Pipeline
• API-Referenz: Sicherheit — Vollständige Endpunkt-Dokumentation für IP-Regeln, Sperren und verdächtige Logins