Comment détecter un attaquant qui consulte trop de données ?

CorgiBOX stocke les informations de ses clients dans une application maison : identité, contrat, historique du support, mais aussi données personnelles détaillées et éléments de facturation. Alice travaille au support. Son rôle lui donne un droit de lecture sur les dossiers clients, ce qui est parfaitement normal : c'est son métier.

Ce matin-là, son compte est compromis. L'attaquant se connecte, passe le MFA grâce à une session volée, ouvre un premier dossier, puis un deuxième. Puis vingt. Puis cent. Puis mille. Rien n'est techniquement anormal : le compte est valide, la session est valide, le droit est réellement attribué, le chemin d'accès est celui de tous les jours.

À quel moment ce comportement devient-il anormal ? La réponse n'est ni « il suffisait de mettre du MFA », ni « il suffisait de retirer à Alice le droit de lire beaucoup de fiches ». Un attaquant n'a pas toujours besoin d'obtenir un droit qu'il ne possède pas : il peut simplement abuser, beaucoup plus vite ou beaucoup plus largement que prévu, d'un droit parfaitement légitime.

Quatre acronymes reviennent dès qu'on parle d'autorisation externalisée. Inutile de les apprendre par cœur : il suffit de voir qui fait quoi.

Le PAP est l'endroit où l'on administre les politiques : quelles règles voulons-nous appliquer ? Le PDP est le moteur qui prend la décision à partir des politiques, des attributs et du contexte. Le PEP est placé sur le chemin réel de l'action — application, API, API Gateway, composant d'Access Management, bastion — il interroge le PDP puis applique la réponse. Le PIP fournit les informations nécessaires à la décision : identité, rôle, organisation, caractéristiques de la ressource, niveau de risque, attributs métier.

Point d'expertise important : installer un PDP ne crée pas un moteur comportemental. Pour savoir qu'Alice a ouvert 487 fiches en cinq minutes, quelqu'un doit avoir calculé ce chiffre. Selon le SI, il vient de l'application elle-même, de l'API Gateway, d'une couche de télémétrie, du SOC, d'un moteur de détection, d'un dispositif antifraude ou d'un service interne de scoring.

La chaîne est simple : la détection produit ou enrichit un signal, le PDP confronte ce signal aux politiques et au contexte métier, le PEP applique la décision sur l'action réelle.

Ariovis travaille avec Axiomatics sur l'autorisation fine et dynamique. Dans une architecture cible, ce type de moteur joue le rôle de PDP : les politiques sont centralisées, les décisions sont prises en temps réel, et l'IGA devient l'une des sources d'information qui alimentent la décision — identités, modèle de rôles, règles, attributs de gouvernance.

L'application ne se contente alors plus de vérifier qu'Alice a le rôle Support : elle délègue une question plus précise, celle de savoir si Alice peut lire ce dossier, avec cette session, dans ce contexte. Les applications historiques et les SaaS non adaptés continuent de recevoir des habilitations classiques ; les applications modernes délèguent progressivement davantage. C'est une trajectoire, pas un basculement.

Les comptes de service ne sont pas des anomalies du SI qu'on tolère faute de mieux. Ce sont des identités non humaines, à gouverner et à contrôler comme les autres — avec d'autres attributs.

Dans ce contexte, 83 421 lectures sont parfaitement normales. Et il ne viendrait à personne l'idée de demander à ce batch de valider une notification sur son téléphone : les facteurs de confiance d'une identité non humaine sont ailleurs — identité du workload, certificat ou mécanisme cryptographique, credential adapté, origine, environnement, scheduler, application appelante, destination, pattern d'utilisation.

Un compte de service compromis ne doit pas se transformer en identité universelle permettant d'interroger tout ce qui est techniquement joignable depuis la machine. Lorsque les chemins sensibles disposent de points d'enforcement et s'appuient sur la politique dynamique, cela réduit fortement les possibilités d'abus et de déplacement latéral sur les ressources effectivement placées sous cette politique.

La nuance compte. Une architecture d'autorisation ne protège pas une ressource qui contourne le PDP, une API laissée sans contrôle, un accès direct à une base de données ou un chemin technique resté ouvert. C'est d'ailleurs pour cela que, dans une trajectoire Zero Trust, l'API Gateway est souvent un point d'enforcement pertinent pour les identités non humaines : le batch appelle la gateway, la gateway interroge le PDP, et la question n'est plus seulement « le token est-il valide ? » mais « cette identité technique peut-elle faire cette action sur cette API, dans ce contexte ? ». C'est un pattern parmi d'autres, pas l'unique architecture possible.

Une politique de sécurité qui bloquerait toute identité lisant beaucoup de données arrêterait CorgiBOX en une nuit. Le métier a besoin de batchs, d'intégrations, de migrations, de sauvegardes et de traitements de masse. C'est justement pour cela que la sécurité doit comprendre le métier assez finement pour distinguer l'usage massif attendu de l'usage frauduleux.

Alice dispose réellement du droit Support. Le batch dispose réellement d'un droit massif sur les factures. La question n'est donc pas de savoir qui lit le plus.

Elle est de savoir si cet accès reste cohérent avec l'identité, la ressource, l'action, le contexte, le comportement et le niveau de risque que nous avons décidé d'accepter.