Accès adaptatif au risque

Un score de risque déterministe et explicable, calculé à la connexion à partir de six signaux, avec des seuils par tenant qui déclenchent un step-up MFA ou un refus.

À chaque connexion, Obexal peut calculer un score de risque à partir de l'historique propre de l'utilisateur (les 60 derniers jours, jusqu'à 500 événements). Aucune boîte noire de machine learning : les signaux sont fixes, le résultat est reproductible, et chaque élévation est auditée avec les signaux exacts qui se sont déclenchés.

Un score déterministe et explicable

Chaque signal qui se déclenche ajoute une contribution fixe au score, si bien que le même historique produit toujours le même résultat. Le calcul étant déterministe, vous pouvez toujours répondre à la question « pourquoi cet utilisateur a-t-il été challengé » : la réponse est dans le journal d'audit, signal par signal.

Les six signaux

Signal	Se déclenche quand
`new_ip`	L'IP source n'a jamais été vue dans une connexion réussie de cet utilisateur
`rapid_ip_change`	Une connexion réussie depuis une autre IP a eu lieu très peu de temps avant
`failed_burst`	Plusieurs échecs récents évoquent un motif de credential stuffing
`new_device`	Le User-Agent n'a jamais été vu dans une connexion réussie
`off_hours`	L'heure du jour (UTC) n'a jamais été vue, évalué seulement une fois qu'un historique d'activité suffisant existe
`impossible_travel`	Le déplacement depuis la dernière connexion réussie est physiquement impossible

new_ip et new_device exigent au moins une connexion réussie antérieure : un tout nouvel utilisateur n'est donc pas pénalisé à sa première connexion. off_hours attend qu'un historique de connexions réussies suffisant existe avant de juger une heure inhabituelle.

Voyage impossible

Les pays de l'IP courante et de la dernière connexion réussie sont résolus avec la base GeoIP locale (aucune API externe). À partir de la distance entre les deux pays et du temps écoulé, le signal se déclenche quand la vitesse de déplacement implicite entre les deux connexions serait physiquement impossible.

La détection est volontairement conservatrice : elle n'évalue que les sauts suffisamment distants, si bien qu'un court trajet à travers une frontière proche (France vers Belgique, par exemple) ne peut jamais paraître « impossible ». Pas de base GeoIP, un pays irrésoluble ou le même pays des deux côtés ne produit aucun signal.

Seuils et actions

Le score est comparé à deux seuils que vous fixez pour votre organisation : à partir de mfaThreshold un step-up MFA est exigé, et à partir de denyThreshold la connexion est refusée. Vous choisissez à partir de quel niveau de risque accumulé une connexion est élevée vers la MFA puis vers le refus ; denyThreshold reste supérieur ou égal à mfaThreshold, si bien que le refus est toujours le plus strict des deux.

Les deux endpoints exigent la permission tenant:manage avec un jeton d'API admin. Un domaine personnalisé remplace accounts.obexal.com.

curl -sS https://accounts.obexal.com/v1/admin/risk-policy \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN"
# {"policy": {"enabled": false, "mfaThreshold": 3, "denyThreshold": 6}}

curl -sS -X PUT https://accounts.obexal.com/v1/admin/risk-policy \
  -H "Authorization: Bearer $OBEXAL_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"enabled": true, "mfaThreshold": 3, "denyThreshold": 6}'
# 204 No Content

Combinaison avec l'accès conditionnel

L'action issue du risque est fusionnée avec la décision des règles statiques d'accès conditionnel : la plus stricte l'emporte (allow < require_mfa < deny). Le risque ne peut que durcir une décision, jamais assouplir un deny statique. Comme pour l'accès conditionnel, un require_mfa visant un utilisateur sans facteur enrôlé refuse la connexion.

Opt-in et priorité à la disponibilité

L'accès adaptatif au risque est désactivé par défaut (enabled: false) : vous l'activez par tenant, idéalement après avoir observé le journal d'audit quelque temps pour calibrer les seuils.

La couche de risque est conçue pour ne jamais bloquer une connexion légitime lorsqu'un signal est indisponible : si la politique est désactivée ou qu'un signal ne peut pas être évalué, la connexion se poursuit normalement et aucune élévation n'est appliquée. C'est un compromis délibéré en faveur de la disponibilité plutôt que d'une élévation invérifiable. Si vous avez besoin d'une garantie dure, exprimez-la comme règle statique d'accès conditionnel, sur laquelle la couche de risque s'appuie.

Chaque élévation est auditée

Toute action de risque autre que allow écrit un événement auth.login.risk_elevated dans le journal d'audit, portant l'action retenue, le score et la liste des signaux, par exemple ["new_ip", "failed_burst"]. Chaque challenge et chaque refus reste ainsi explicable après coup.