Protection contre les Attaques

Auris inclut plusieurs couches de défense qui s’activent sur chaque requête d’authentification. Ces systèmes opèrent indépendamment mais sont superposés dans un pipeline spécifique — chaque vérification est exécutée en séquence pour que les vérifications suivantes, plus coûteuses, ne soient atteintes qu’après que les filtres initiaux plus économiques sont passés.

Limitation de Débit

Auris applique une limitation de débit à fenêtre glissante à tous les endpoints API. Les limites de débit sont appliquées en mémoire par instance et ne sont pas partagées entre les instances dans un déploiement multi-nœuds — si tu as besoin d’une limitation de débit distribuée, configure un store partagé supporté par Redis.

Niveaux

Les valeurs exactes des limites sont configurables par niveau via des variables d’environnement ou la Console (Console → Sécurité → Limitation de Débit).

Headers de Réponse

Toutes les réponses API depuis les endpoints avec limitation de débit incluent des headers standard :

Quand une limite de débit est dépassée, Auris retourne HTTP 429 Too Many Requests avec le header Retry-After. Les clients doivent respecter ce header et effectuer un backoff en conséquence.

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": "Trop de requêtes. Réessaie dans 47 secondes."
  }
}

Protection Brute-Force

Auris trace les tentatives de connexion échouées par compte utilisateur et par adresse IP. Après un nombre configurable d’échecs consécutifs, le compte ou l’IP est bloqué pour une durée croissante.

Comment Fonctionne le Blocage

1. Chaque tentative de connexion échouée crée un enregistrement LoginAttempt avec timestamp, IP et user agent.
2. Quand le compteur d’échecs pour un compte ou IP dépasse le seuil configuré dans la fenêtre d’observation, un enregistrement AccountLockout est créé.
3. Pendant un blocage, toutes les tentatives de connexion pour le compte affecté retournent HTTP 423 Locked immédiatement — aucune authentification Keycloak n’est tentée.
4. La durée du blocage s’intensifie avec les blocages répétés : premier blocage = 5 minutes, deuxième = 30 minutes, troisième = 24 heures (configurable).

Configuration

Configure via Console → Sécurité → Protection Brute-Force :

Déblocage Manuel

Les administrateurs peuvent débloquer manuellement les comptes via la Console (Détail utilisateur → Sécurité → Débloquer le Compte) ou l’API :

Sécurité des Mots de Passe

Intégration HaveIBeenPwned

Quand un utilisateur définit ou change un mot de passe, Auris le vérifie contre la base de données Pwned Passwords de HaveIBeenPwned (HIBP) en utilisant l’API k-Anonymity. Seuls les 5 premiers caractères du hash SHA-1 sont envoyés à HIBP — le mot de passe en clair ne quitte jamais Auris.

Si le mot de passe apparaît dans les datasets de violations connues, Auris le rejette et demande à l’utilisateur d’en choisir un différent. Cette vérification s’applique à :

• L’inscription utilisateur
• Les demandes de changement de mot de passe
• Les mots de passe créés par l’administrateur via l’API

Exigences de Complexité

Configure les exigences minimales pour le mot de passe dans Console → Sécurité → Politique de Mot de Passe :

Les exigences sont appliquées aux mots de passe gérés par Auris. Les utilisateurs SSO s’authentifient via leur IdP d’entreprise et ne sont pas soumis aux politiques de mots de passe d’Auris.

Détection de Connexions Suspectes

Auris analyse chaque connexion pour des anomalies comportementales. La détection est exécutée après une authentification Keycloak réussie — si les credentials de connexion sont corrects mais le contexte est suspect, Auris peut notifier l’utilisateur, bloquer la connexion ou déclencher une MFA step-up.

Méthodes de Détection

1. Nouvel appareil

Auris calcule une empreinte hash depuis une combinaison de user agent du navigateur, résolution d’écran et autres signaux stables. Si l’empreinte n’a jamais été vue pour cet utilisateur auparavant, la connexion est signalée comme “nouvel appareil”. L’enregistrement de l’appareil est stocké dans DeviceFingerprint après la première connexion réussie depuis ce contexte.

2. Nouvelle adresse IP

Auris trace les adresses IP depuis lesquelles un utilisateur a précédemment effectué une connexion. Une connexion depuis une IP qui n’a jamais été vue pour ce compte est signalée.

3. Nouveau pays

La recherche GeoIP détermine le pays de l’IP de connexion. Si le pays diffère de l’historique de connexions de l’utilisateur, la connexion est signalée. La détection du pays utilise ip-api.com (défaut) ou une base de données locale MaxMind GeoLite2 (configurable pour les déploiements hors ligne ou sensibles à la confidentialité).

4. Voyage impossible

Auris calcule la distance géographique (formule de Haversine) entre la position de connexion courante et celle de la connexion la plus récente, puis la divise par le temps écoulé pour dériver une vitesse de déplacement implicite. Si la vitesse dépasse un seuil configurable (défaut : 800 km/h — plus rapide que l’aviation commerciale), la connexion est signalée comme voyage impossible.

5. Détection VPN / proxy / datacenter

La recherche GeoIP inclut des métadonnées indiquant si l’IP appartient à un fournisseur VPN connu, proxy ou datacenter cloud. Les connexions depuis ces IP sont signalées par défaut mais peuvent être autorisées si tes utilisateurs accèdent communément au service via VPN.

Actions Configurées

Chaque méthode de détection peut déclencher des actions indépendantes :

Configuration du Fournisseur GeoIP

Révision des Événements de Connexions Suspectes

Intégration CAPTCHA

Auris supporte trois fournisseurs CAPTCHA sur les pages de connexion, inscription et réinitialisation de mot de passe. Le CAPTCHA peut être configuré pour s’activer toujours, uniquement quand le risque est élevé, ou uniquement après un nombre de tentatives échouées.

Fournisseurs Supportés

Modes d’Activation

Configuration

Configure via Console → Sécurité → CAPTCHA :

1. Sélectionne le fournisseur CAPTCHA.
2. Saisis la Site Key (utilisée dans le navigateur) et la Secret Key (utilisée côté serveur pour la vérification).
3. Définis le mode d’activation et (pour AFTER_FAILURES) le seuil de tentatives.
4. Pour reCAPTCHA v3, définis le score minimum (0.0–1.0) en dessous duquel une connexion est bloquée.

Listes d’IP Autorisées/Bloquées

Auris supporte des règles IP basées sur CIDR au niveau tenant et par application. Les règles sont évaluées avant toute tentative d’authentification.

Types de Règles

Priorité : Les règles BLOCK ont toujours la priorité sur les règles ALLOW dans le même scope.

Scope : Les règles peuvent être scopées à l’ensemble du tenant (scope: TENANT) ou à une application spécifique (scope: APPLICATION, applicationId: ...).

Règles temporaires : Définis isTemporary: true et fournis expiresAt pour créer des règles qui expirent automatiquement. Utile pour des bans temporaires après une attaque détectée.

Gestion des Règles IP

{
  "cidr": "203.0.113.0/24",
  "type": "BLOCK",
  "scope": "TENANT",
  "label": "ASN suspect",
  "note": "Bloqué suite à une attaque de credential stuffing le 01/06/2025",
  "isTemporary": true,
  "expiresAt": "2025-07-01T00:00:00Z"
}

Notation CIDR

Auris supporte la notation CIDR IPv4 et IPv6 :

• IP unique : 203.0.113.42/32
• Sous-réseau : 203.0.113.0/24 (256 adresses)
• Plage complète : 10.0.0.0/8 (16,7 millions d’adresses)
• IPv6 unique : 2001:db8::1/128
• Plage IPv6 : 2001:db8::/32

Le Pipeline de Sécurité de Connexion

Chaque requête de connexion passe par les vérifications suivantes dans l’ordre. Chaque vérification peut court-circuiter le pipeline en retournant une erreur :

Requête de connexion entrante
        |
        v
1. Vérification IP Allow/Block
   Règle BLOCK correspondante ? → HTTP 403, arrêt
   Règle ALLOW présente ? → continuer
        |
        v
2. Vérification CAPTCHA
   Mode = ALWAYS ? → exiger un token valide
   Mode = ON_SUSPICIOUS ? → évaluer score risque, exiger si élevé
   Mode = AFTER_FAILURES ? → vérifier compteur d'échecs IP
   Token invalide/manquant ? → HTTP 400, arrêt
        |
        v
3. Limitation de Débit
   Limite par IP dépassée ? → HTTP 429, arrêt
   Limite par utilisateur dépassée ? → HTTP 429, arrêt
        |
        v
4. Vérification Brute-Force / Blocage
   Compte ou IP actuellement bloqué ? → HTTP 423, arrêt
        |
        v
5. Authentification Keycloak
   Credentials invalides ? → enregistrer tentative échouée, HTTP 401, arrêt
   Credentials valides ? → continuer
        |
        v
6. Analyse de Connexions Suspectes
   (non bloquant — exécuté de façon asynchrone, enregistre les événements)
   Détection haute gravité ? → déclencher l'action configurée (notify/block/require MFA)
        |
        v
7. Calcul du Score de Risque MFA Adaptative
   Score calculé depuis 5 facteurs
   Score au-dessus du seuil ? → exiger MFA step-up
        |
        v
8. Émission de Token
   Claims ACR et AMR définis selon les méthodes d'authentification complétées
   Retourne access token et refresh token

Permissions Requises

Pages Associées

• Authentification Multi-Facteur — TOTP, SMS OTP, WebAuthn et MFA adaptative
• Console : Paramètres de Sécurité — Guide complet de la Console pour toutes les fonctionnalités de sécurité
• Concepts : Flux de Connexion — Analyse détaillée du pipeline d’authentification
• Référence API : Sécurité — Documentation complète des endpoints pour règles IP, blocages et connexions suspectes