🍪 🕵️ Détecter l’énumération d’identifiants et les accès atypiques

Comparer chaque compte à son propre historique, repérer une suite d’identifiants et décider quoi faire d’un compte signalé

Hello les petits Biscuits !

Bienvenue sur la 51ème édition de Ruby Biscuit.
Vous êtes maintenant 598 abonnés 🥳

Cette édition de Ruby Biscuit est sponsorisée par AppSignal.

Le monitoring Ruby, sans multiplier les outils

Vous utilisez plusieurs outils pour surveiller vos applications Ruby ? Entre les erreurs, les requêtes N+1, Sidekiq, les logs et les métriques système, difficile d’avoir une vue d’ensemble.

AppSignal rassemble tout ça au même endroit, dans une seule gem Ruby : suivi des erreurs, détection des requêtes N+1, monitoring de Sidekiq, logs et métriques système.

L’objectif : identifier plus facilement les problèmes de vos applications sans multiplier les outils de monitoring.

Des utilisateurs illimités, une seule facture.

🎁 Essayez AppSignal gratuitement pendant 30 jours, sans carte bancaire.

👉 Découvrir AppSignal

Bonne lecture.

Vous lisez Ruby Biscuit, la newsletter Rails de Capsens. S’abonner gratuitement

---

Un compte authentifié qui télécharge des documents ne viole aucune règle : le mot de passe est bon, les droits sont corrects, chaque requête est valide. Seul l’ensemble de ses requêtes peut être anormal, et une application ne le voit pas requête par requête. Cet article construit, avec Rails et Redis, une détection qui compare chaque compte à son propre historique : des compteurs par utilisateur, une baseline robuste, un détecteur d’énumération d’identifiants, un score combiné, puis la marche à suivre quand un compte est signalé.

Où en est l’enquête ? Un virement de 15 000 € n’est jamais parti : son job a attendu derrière des milliers de jobs de filigrane, tous déclenchés par les téléchargements d’un seul compte, en rafale le mardi soir. Reste à savoir si ce compte est utilisé par son propriétaire, et c’est la question de cet article.

Cette série suit un même incident, en fil rouge, au fil des techniques abordées. Les encadrés « ⏪ Ce que vous auriez vu » montrent les lignes de log ou les écrans que le bon outillage aurait produits cette nuit-là, et qui n’ont jamais existé faute de préparation. Vous pouvez les sauter : le reste se lit comme un tutoriel autonome.

Pourquoi un seuil ne suffit pas

Détecter un comportement anormal revient à mesurer un écart, et la première question est : par rapport à quoi ? L’approche la plus courante répond par un plafond fixe, par exemple un nombre maximal de téléchargements par jour. Prenons un compte qui télécharge beaucoup de documents : un client zélé, un cabinet d’audit mandaté ou un intrus produisent la même courbe de volume, et ce plafond doit pourtant les départager.

Ce plafond se trompe aux deux extrémités. Pour attraper un compte qui télécharge quelques dizaines de documents par jour, il faudrait le fixer à moins de trente téléchargements par jour : il sonnerait alors pour tout client qui récupère ses relevés annuels en une soirée, et l’équipe finirait par ne plus lire ces alertes. Fixé à cent téléchargements quotidiens, il laisse passer ce même compte jour après jour. Le plafond garde pourtant sa place à un autre niveau : fixé très haut, il empêche un seul compte de vider la base le temps qu’une alerte soit lue. Il ne détecte rien de subtil, et c’est ce que cherche cet article.

La question « combien est-ce trop ? » n’a pas de réponse unique, car elle dépend de qui télécharge. On peut en poser une autre : cet utilisateur ressemble-t-il à lui-même ?

Une baseline est la description statistique du comportement habituel d’un utilisateur (combien de documents il consulte par jour, depuis où, à quelle heure), à laquelle on compare son comportement du moment.

Construire la baseline d’un utilisateur

Quatre dimensions suffisent pour commencer : le volume d’accès par jour, la diversité des ressources touchées, la plage horaire et la stabilité des points d’accès (adresses, navigateur). Tout repose sur des compteurs quotidiens par utilisateur, alimentés comme à l’article 1 par l’événement que Rails publie à chaque requête. Le contrôleur y ajoute l’utilisateur courant, l’adresse et le navigateur. Ces compteurs vivent dans Redis plutôt que dans l’outil de logs de l’article 3, que le job de détection n’a pas à interroger chaque nuit pour chaque compte.

# app/controllers/application_controller.rb
def append_info_to_payload(payload)
  super
  payload[:user_id] = current_user&.id
  payload[:remote_ip] = request.remote_ip
  payload[:user_agent] = request.user_agent
end

# config/initializers/behavior_metrics.rb
WINDOW_TTL = 35.days.to_i

ActiveSupport::Notifications.subscribe("process_action.action_controller") do |event|
  payload = event.payload
  user_id = payload[:user_id]
  doc_id = payload[:params]["id"].to_s.first(64)
  ip = payload[:remote_ip].to_s.first(45)
  agent = payload[:user_agent].to_s.first(200)
  next unless user_id && doc_id.present? && payload[:controller] == "DocumentsController"

  day = Date.current.iso8601
  keys = %w[count ids ips uas].map { |kind| "docs:#{kind}:#{user_id}:#{day}" }

  REDIS.pipelined do |pipe|
    pipe.incr(keys[0])
    pipe.sadd(keys[1], doc_id)
    pipe.sadd(keys[2], ip)
    pipe.sadd(keys[3], agent)
    keys.each { |key| pipe.expire(key, WINDOW_TTL) }
  end
rescue StandardError => e
  Rails.logger.error("[behavior] #{e.class}: #{e.message}")
end

Les clés portent la date et expirent seules, ce qui donne une fenêtre glissante sans nettoyage à écrire. Le rescue final reste indispensable : comme vu à l’article 1, un Redis indisponible ferait sinon échouer la requête. La plage horaire suit le même principe, avec un compteur par heure.

La médiane remplace la moyenne, car quelques jours aberrants déplacent la moyenne, et un attaquant patient s’en sert pour que la suite paraisse normale. Pour la dispersion, même logique avec l’écart absolu médian (la médiane des écarts à la médiane), plus robuste que l’écart-type sur des comportements humains irréguliers. L’écart du jour se mesure en multiples de cette dispersion. Une quarantaine de documents donne ainsi un écart quasi nul pour un cabinet d’audit qui en télécharge autant chaque jour ouvré, et un écart très élevé pour un investisseur qui les télécharge un mardi.

# app/services/baseline.rb
class Baseline
  WINDOW_DAYS = 28
  MAD_FLOOR = 1.0 # valeur indicative

  def initialize(user_id, today: Date.current)
    @user_id = user_id
    @today = today
  end

  # Écart du jour, en multiples de la dispersion habituelle du compte.
  def deviation
    history = (1..WINDOW_DAYS).map { |i| count_for(@today - i) }
    center = median(history)
    spread = [median(history.map { |c| (c - center).abs }), MAD_FLOOR].max
    (count_for(@today) - center) / spread
  end

  private

  def count_for(day)
    REDIS.get("docs:count:#{@user_id}:#{day.iso8601}").to_i
  end

  def median(values)
    sorted = values.sort
    mid = sorted.size / 2
    sorted.size.odd? ? sorted[mid] : (sorted[mid - 1] + sorted[mid]) / 2.0
  end
end

Ce calcul n’a rien à faire dans la requête : un job nocturne l’exécute sur la journée écoulée pour les comptes actifs, sur une file dédiée à l’analyse et jamais sur celle des paiements. L’incident est né d’un dispositif de traçabilité placé au mauvais endroit, et la détection ne doit pas répéter l’erreur du filigrane.

Quelques remarques

• Un compte qui se connecte rarement a une médiane et une dispersion nulles. Sans le plancher MAD_FLOOR, son premier téléchargement donnerait un écart infini.

• La baseline se laisse empoisonner. Dès que les jours anormaux dépassent la moitié de la fenêtre, la médiane les adopte pour normaux ; on exclut donc de la baseline les jours déjà signalés.

• Un compte neuf n’a pas d’historique, et tout lui paraît inconnu. On neutralise pendant ses premières semaines les signaux qui comparent à l’historique, mais on garde la densité de la suite, qui n’en dépend pas : sans cela, un compte créé exprès pour énumérer passerait sous le radar.

• Ces compteurs restent des données personnelles, une adresse et un navigateur rattachés à un compte formant un profil. On garde les compteurs le temps de la fenêtre, les adresses et navigateurs connus plus longtemps (400 jours ici), la finalité comme la durée s’inscrivent au registre des traitements, et on ne stocke jamais de contenu de document. Enfin, request.remote_ip n’est fiable que si les proxys de confiance sont bien déclarés, faute de quoi on compare des adresses de proxy.

• Gardez ces compteurs dans un Redis distinct de celui de Sidekiq : on veut pouvoir leur appliquer une politique d’éviction, ce qu’on évite pour la file de jobs.

Détecter une énumération

Une IDOR (Insecure Direct Object Reference) survient quand une application sert une ressource à partir d’un identifiant fourni par le client, sans vérifier que cette ressource appartient à celui qui la demande. Changez le 42 d’une URL en 43 : si le document d’un autre client s’affiche, l’application est vulnérable.

Celui qui exploite ce défaut doit essayer des identifiants, et la forme de ses essais le trahit. Un investisseur relit ses propres documents, toujours les mêmes et dans le désordre. L’énumérateur, lui, parcourt une suite : identifiants consécutifs ou presque, trous qui produisent des 404, ressources jamais consultées auparavant. Deux ratios traduisent cela : la part d’identifiants nouveaux, et la densité de la suite (identifiants distincts rapportés à l’étendue qu’ils couvrent).

# app/services/enumeration_check.rb
class EnumerationCheck
  WINDOW_DAYS = 28
  MIN_IDS = 20

  def initialize(user_id, day: Date.current)
    @user_id = user_id
    @day = day
  end

  # Part des identifiants du jour absents de la fenêtre précédente.
  def new_ratio
    return 0.0 if today_ids.empty?

    seen = REDIS.sunion(*(1..WINDOW_DAYS).map { |i| ids_key(@day - i) })
    (today_ids - seen).size.fdiv(today_ids.size)
  end

  # Proche de 1 : une suite consécutive. Proche de 0 : des identifiants dispersés.
  def density
    ids = today_ids.map(&:to_i).sort
    return 0.0 if ids.size < MIN_IDS

    ids.size.fdiv(ids.last - ids.first + 1)
  end

  private

  def today_ids
    @today_ids ||= REDIS.smembers(ids_key(@day))
  end

  def ids_key(day)
    "docs:ids:#{@user_id}:#{day.iso8601}"
  end
end

Ces ratios mesurent la forme des accès plus que leur volume. La densité n’a de sens qu’à partir d’un certain nombre d’identifiants : trois documents générés ensemble (un contrat, une attestation, un reçu) se suivent aussi, d’où un minimum fixé dans le code. Un énumérateur qui reste sous ce minimum échappe à ce signal, mais pas aux autres sur un compte ancien.

Tout ce qui précède est une deuxième ligne de défense. La première est l’autorisation. Document.find(params[:id]) sert n’importe quel document à qui en connaît l’identifiant, alors que current_user.documents.find(params[:id]) lève une ActiveRecord::RecordNotFound (une 404) pour tout document qui n’est pas le sien. L’IDOR disparaît avec cette ligne, et aucune détection ne la remplace. Quand les règles dépassent la simple appartenance, on les centralise dans des politiques d’autorisation, dont Pundit et Action Policy sont deux implémentations courantes.

Note : des identifiants séquentiels facilitent l’énumération, des identifiants opaques (UUID, valeurs aléatoires) la rendent coûteuse sans la rendre impossible. Ils ne dispensent pas du contrôle d’accès : un identifiant difficile à deviner peut se lire ailleurs, dans un log par exemple (article 2). Avec des UUID, la densité de la suite n’a plus de sens, et seule la part de ressources nouvelles reste utilisable.

Combiner les signaux

Un signal seul produit souvent de faux positifs : un déplacement change d’adresse, un nouveau téléphone change de navigateur, un VPN fait les deux. Trois signaux se calculent à peu de frais avec les compteurs : une adresse jamais vue sur le compte depuis un an, une empreinte de client inhabituelle (un navigateur jamais vu) et des sessions concurrentes (plusieurs adresses distinctes le même jour). Un quatrième, l’incohérence géographique dans un intervalle trop court, demande une base de géolocalisation d’adresses et reste hors du code ci-dessous. Combinés avec l’écart de volume, retenu au-delà de quelques multiples de la dispersion, et les ratios d’énumération, ils donnent à chaque compte un score.

# app/services/risk_score.rb
class RiskScore
  # Poids et seuils indicatifs : les vôtres se règlent par observation.
  WEIGHTS = {
    unknown_ip: 2,
    unknown_user_agent: 1,
    volume_deviation: 2,
    new_resources: 1,
    dense_ids: 4,
    parallel_ips: 2
  }.freeze
  DIGEST_AT = 4
  ALERT_AT = 8

  # signals : { unknown_ip: true, volume_deviation: false, ... }
  def initialize(signals)
    @signals = signals
  end

  def value
    WEIGHTS.sum { |name, weight| @signals[name] ? weight : 0 }
  end

  def level
    return :alert if value >= ALERT_AT
    return :digest if value >= DIGEST_AT

    :none
  end
end

# app/jobs/behavior_scan_job.rb
class BehaviorScanJob
  include Sidekiq::Job
  sidekiq_options queue: :analytics, retry: 1

  # Seuils indicatifs, comme les poids de RiskScore.
  WINDOW_DAYS = 28
  KNOWN_TTL = 400.days.to_i
  VOLUME_AT = 5.0
  NEW_RATIO_AT = 0.8
  DENSITY_AT = 0.5
  PARALLEL_IPS_AT = 3

  def perform(user_id)
    day = Date.yesterday # le job tourne la nuit : on analyse la journée écoulée
    enumeration = EnumerationCheck.new(user_id, day: day)
    # Signaux qui ne dépendent d'aucun historique : valables pour un compte neuf.
    signals = {
      dense_ids: enumeration.density >= DENSITY_AT,
      parallel_ips: REDIS.scard("docs:ips:#{user_id}:#{day.iso8601}") >= PARALLEL_IPS_AT
    }
    # Signaux relatifs à l'historique : comptes de plus de 28 jours seulement.
    if User.find(user_id).created_at <= WINDOW_DAYS.days.ago
      signals.merge!(
        unknown_ip: unseen?("ips", user_id, day),
        unknown_user_agent: unseen?("uas", user_id, day),
        volume_deviation: Baseline.new(user_id, today: day).deviation >= VOLUME_AT,
        new_resources: enumeration.new_ratio >= NEW_RATIO_AT
      )
    end
    score = RiskScore.new(signals)
    if score.level == :none
      remember(user_id, day)
      return
    end

    active = signals.select { |_, on| on }.keys.join(",")
    Rails.logger.warn("[security] behavior #{score.level} user_id=#{user_id} score=#{score.value} signals=#{active}")
  end

  private

  # Vrai si une valeur du jour (adresse, navigateur) n'a jamais été vue sur le compte.
  def unseen?(kind, user_id, day)
    today = REDIS.smembers("docs:#{kind}:#{user_id}:#{day.iso8601}")
    (today - REDIS.smembers("docs:known_#{kind}:#{user_id}")).any?
  end

  # Mémoire plus longue que les compteurs : seules les journées sans alerte l'enrichissent.
  def remember(user_id, day)
    %w[ips uas].each do |kind|
      today = REDIS.smembers("docs:#{kind}:#{user_id}:#{day.iso8601}")
      next if today.empty?

      REDIS.sadd("docs:known_#{kind}:#{user_id}", today)
      REDIS.expire("docs:known_#{kind}:#{user_id}", KNOWN_TTL)
    end
  end
end

Ce job assemble les signaux de chaque compte actif chaque nuit et écrit une ligne de log quand le score atteint un niveau. Le client zélé de la première section, même s’il ne vient qu’une fois par an, ne cumule que des signaux faibles, le volume et des ressources nouvelles : son score reste sous le premier seuil, parce que ses adresses et navigateurs restent en mémoire plus longtemps que les compteurs.

Note : les poids et les seuils de ces extraits sont indicatifs, ce ne sont pas nos valeurs. Les vôtres se règlent sur vos propres données, et gagnent à rester confidentielles.

La rafale du mardi soir, avec ses connexions simultanées depuis des adresses inconnues sur un compte habituellement connecté depuis un seul appareil, aurait fait monter plusieurs signaux d’un coup.

⏪ Ce que vous auriez vu. Dans la nuit qui suit la première énumération, une alerte : [security] behavior alert user_id=4217 score=10 signals=dense_ids,unknown_ip,unknown_user_agent,volume_deviation,new_resources. Elle n’a jamais existé. Elle serait partie dix jours avant la rafale, avant le premier job de filigrane en retard, et le virement n’aurait jamais été inquiété.

Alerter plutôt que bloquer

Le score alimente deux régimes. Un signal fort et rare part immédiatement vers quelqu’un : c’est le niveau :alert, celui de notre compte. Un signal faible et persistant s’accumule dans un rapport quotidien qu’une personne lit vraiment : c’est le niveau :digest, celui d’une adresse nouvelle accompagnée d’un volume élevé, ou d’un cabinet d’audit qui ouvre un dossier dont les documents se suivent. Dans les deux cas on prévient un humain plutôt que de bloquer, car le blocage automatique se paie en faux positifs sur des utilisateurs légitimes, et c’est le sujet d’un prochain article. Le job tourne la nuit : entre une rafale et l’alerte, il peut s’écouler jusqu’à une journée, et rien dans ce dispositif ne l’arrête. C’est le rôle du plafond évoqué en début d’article, et les deux se complètent.

Une détection a besoin d’un destinataire et d’une procédure : qui reçoit, qui décide de contacter le titulaire, qui peut geler le compte, en combien de temps. Sans ces réponses écrites à l’avance, l’alerte reste sans suite. Le job écrit sa ligne dans les logs centralisés de l’article 3, où l’alerte se branche comme les autres.

Que faire d’un compte compromis

Une fois l’alerte reçue, les gestes immédiats sont d’invalider toutes les sessions du compte, de forcer la réinitialisation du mot de passe, d’exiger un second facteur à la reconnexion et de geler les opérations sensibles (virement, changement d’IBAN ou d’adresse e-mail). Avec Devise, la session contient un sel dérivé du mot de passe : le seul moyen natif de la couper est de le changer, ce qui suppose que le titulaire réponde à l’e-mail. Pour couper sans attendre, on ajoute un jeton de session au sel.

# app/models/user.rb (colonnes session_token et frozen_at ajoutées par migration)
class User < ApplicationRecord
  devise :database_authenticatable, :recoverable, :rememberable

  # Changer ce jeton invalide tous les cookies de session du compte.
  def authenticatable_salt
    "#{super}#{session_token}"
  end

  def lock_down!
    update!(session_token: SecureRandom.hex(16), frozen_at: Time.current)
    forget_me!
    send_reset_password_instructions
  end
end

Les contrôleurs sensibles (virement, changement d’IBAN) refusent l’action tant que frozen_at est renseigné.

Note : avec l’authentification native de Rails 8, les sessions sont des lignes de la table sessions, et user.sessions.destroy_all suffit.

Note : avant d’envoyer le lien de réinitialisation, vérifiez que l’adresse e-mail et le téléphone du compte n’ont pas été modifiés par l’attaquant, faute de quoi le lien part dans ses mains.

Préparez aussi la liste des documents consultés pendant la compromission : elle détermine qui informer et ce qu’on déclare à la CNIL.

Sur le plan réglementaire, des pièces d’identité et des justificatifs qui sortent forment une violation de données personnelles. Le responsable de traitement la notifie à l’autorité de contrôle (en France, la CNIL) dans les meilleurs délais et, si possible, 72 heures au plus tard après en avoir pris connaissance, sauf s’il est peu probable qu’elle entraîne un risque pour les personnes (RGPD, article 33). Il informe aussi les personnes concernées lorsque le risque est élevé (article 34), ce qu’on peut raisonnablement envisager ici vu l’usurpation d’identité et la fraude documentaire. Un sous-traitant alerte, lui, le responsable de traitement dans les meilleurs délais (article 33, paragraphe 2).

Côté LCB-FT, ces pièces ont été recueillies pour identifier et vérifier l’identité des clients (article L. 561-5 du code monétaire et financier) : entre de mauvaises mains, elles permettent d’ouvrir des comptes ailleurs. Côté DORA, l’incident peut relever du régime de déclaration vu à l’article 1 s’il est classé majeur, et le service externe de génération de PDF est un prestataire de services TIC de l’entité financière cliente, dont la défaillance a amplifié l’incident : c’est le terrain du chapitre V du règlement, consacré au risque lié aux tiers.

Note : la notification peut se faire par phases quand toutes les informations manquent (article 33, paragraphe 4).

Chacune de ces obligations suppose une chronologie horodatée et la liste des personnes et des documents concernés, que les logs des articles 2 et 3 permettent de produire.

Retour sur l’enquête

Dans les logs centralisés, les requêtes de notre compte sur /documents/:id/download suivent une suite : 7301, 7302, 7304, avec des trous qui produisent des 404. Les trois adresses de la rafale, géolocalisées, tombent dans trois pays distincts, aucun n’étant celui d’où le titulaire se connectait jusque-là, et la première connexion depuis une adresse inconnue date de la veille du premier téléchargement. Le compte n’avait pas activé de second facteur.

Il avait été compromis, très probablement par hameçonnage ciblé, ce qu’aucun log de l’application ne peut confirmer. Une IDOR sur /documents/:id/download a permis d’énumérer les documents des autres clients, lentement d’abord, puis en rafale : environ 2 900 documents emportés, dont des pièces d’identité et des justificatifs de connaissance client (KYC).

Chaque document emporté déclenchait un job de filigrane, et c’est ce stock de jobs qui a retardé le virement : la panne de paiement et l’exfiltration relèvent d’un seul événement. Le passé est reconstitué, à l’hameçonnage près, et la prochaine fois reste possible.

En deux mots

Comparer chaque compte à son propre historique permet de repérer une phase lente qu’un plafond global ne voit pas : des compteurs par utilisateur, une médiane, la forme de la suite d’identifiants demandés, un score qui combine ces signaux et une procédure prête pour le compte signalé. Cela demande de conserver des données de comportement, de trier des faux positifs chaque matin et d’écrire cette procédure avant d’en avoir besoin. Et cela ne remplace pas le contrôle d’accès, qui aurait rendu cette attaque impossible.

Une détection ne bloque rien : elle prévient quelqu’un, après coup, d’où l’intérêt d’un plafond très haut en garde-fou. Le prochain article de la série regarde ce qu’on peut refuser automatiquement, et ce que cela coûte aux utilisateurs légitimes.

— Inès, Responsable de la Sécurité des Systèmes d’Information chez Capsens

---

Pour aller plus loin

• Notification des violations et information des personnes : Règlement (UE) 2016/679, articles 33 et 34, EUR-Lex

• Gestion et déclaration des incidents liés aux TIC : Règlement (UE) 2022/2554 (DORA), article 19 et chapitre V, EUR-Lex

• Délais et contenu des notifications DORA : Règlement délégué (UE) 2025/301, EUR-Lex

• Classification des incidents DORA : Règlement délégué (UE) 2024/1772, EUR-Lex

• Identification et vérification de l’identité des clients : Article L. 561-5 du code monétaire et financier, Légifrance

• Contrôle d’accès au niveau de l’objet : Insecure Direct Object Reference Prevention Cheat Sheet, OWASP

• Enrichir le payload d’une requête : ActionController::Instrumentation, API Rails

• Abonnement aux événements de requête : Active Support Instrumentation, guides Rails

• Sel de session et invalidation : Devise, lib/devise/models/authenticatable.rb, dépôt heartcombo/devise

• Ajout à un ensemble : SADD, documentation Redis

• Union d’ensembles : SUNION, documentation Redis

• Compteurs : INCR, documentation Redis

• Médiane et écart absolu médian : Detecting outliers: Do not use standard deviation around the mean, use absolute deviation around the median, Leys et al., Journal of Experimental Social Psychology

Si cet article vous a été utile, partagez-le à un(e) collègue.