Une transaction sensible n'est pas forcément un paiement. C'est toute action dont l'exécution non voulue produit un dommage difficilement réversible : un changement de coordonnées bancaires fournisseur, l'export d'un fichier client, la modification d'une adresse de récupération, la publication d'un tarif, l'ouverture d'un droit d'accès. Les identifier est le premier travail ; leur appliquer une preuve d'intention est le second.
Cartographier ce qui est réellement sensible
L'exercice se mène par l'impact, pas par l'application. Une grille en trois colonnes suffit à produire une liste exploitable.
| Action | Impact d'une exécution non voulue | Réversible ? |
|---|---|---|
| Modification d'un IBAN fournisseur | paiement détourné, récurrent | difficilement |
| Création ou élévation d'un compte à privilèges | persistance de l'attaquant | oui, si détecté |
| Export massif de données personnelles | violation à notifier, exposition durable | non |
| Changement d'adresse de récupération | perte de contrôle du compte | non, une fois exploité |
| Signature d'un engagement contractuel | obligation juridique | contentieux |
| Modification d'une règle de transfert de messagerie | interception durable | oui, si détecté |
| Publication d'un contenu ou d'un tarif | atteinte à l'image, perte commerciale | partiellement |
Deux enseignements se dégagent systématiquement de cet exercice. D'abord, la liste est courte : rarement plus d'une quinzaine d'actions dans une organisation de taille moyenne. Ensuite, elle traverse les applications : les actions les plus dangereuses ne sont pas concentrées dans l'outil financier.
Le piège de la session de confiance
Le modèle dominant reste : authentifier une fois, puis faire confiance pendant toute la durée de la session. Ce modèle repose sur une hypothèse qui ne tient plus — que celui qui agit est celui qui s'est authentifié.
Trois façons de rompre ce lien sans casser le moindre contrôle :
- Le vol de jeton : un cookie récupéré par un logiciel malveillant ou un proxy inverse permet d'agir dans une session déjà ouverte.
- Le poste laissé accessible : un cas banal, rarement modélisé, et particulièrement pertinent en environnement partagé — atelier, hôpital, guichet.
- La manipulation : la personne agit elle-même, mais pas selon sa volonté réelle.
Dans les trois cas, exiger une preuve au moment de l'action rétablit ce que la session ne garantit plus. C'est le principe de l'authentification transactionnelle, cohérent avec la doctrine du NIST SP 800-207 : « ne jamais faire confiance, toujours vérifier ».
Construire une politique de step-up qui tient
Une politique d'élévation d'exigence échoue presque toujours pour la même raison : elle est trop large, elle irrite, elle est assouplie, puis contournée. Quatre principes la rendent durable.
- Peu d'actions, bien choisies. Mieux vaut cinq actions réellement protégées que cinquante actions protégées sur le papier et neutralisées par des dérogations.
- Une exigence proportionnée. Le continuum 2FA → 4FA permet de réserver le challenge complet aux cas qui le méritent, et de rester léger ailleurs.
- Un déclenchement contextuel. Un score de risque contextuel — terminal, réseau, horaire, écart par rapport aux habitudes — permet d'ajouter l'exigence quand elle a du sens plutôt que systématiquement.
- Aucun chemin de contournement. Si une même action est réalisable par téléphone, par courriel ou via le support, la protection du parcours principal ne vaut que ce que vaut le parcours de secours.
Le facteur cognitif s'insère à ce point précis : il fournit une preuve qui ne se dicte pas, ne se rejoue pas et ne s'obtient pas depuis une session dérobée, parce qu'elle repose sur une méthode de résolution personnelle acquise lors d'un enrôlement hors ligne.
Ce que la conformité en attend
Les textes européens ne prescrivent pas de mécanisme, mais convergent sur l'exigence de traçabilité et de proportionnalité au risque.
- NIS2 (directive UE 2022/2555) : mesures de gestion des risques citant l'authentification multifacteur ou continue.
- DORA (règlement UE 2022/2554), applicable depuis janvier 2025 : résilience opérationnelle démontrable dans le secteur financier.
- RGPD : les exports de données personnelles figurent parmi les actions dont l'exécution non voulue déclenche une obligation de notification.
Ce qui a une valeur probante n'est pas la mention « MFA validée » mais la trace de ce qui a été présenté à la personne et du fait qu'une action de résolution a eu lieu.
Une mise en œuvre progressive
Le déploiement en overlay d'une chaîne existante permet d'avancer sans refonte : on branche l'exigence supplémentaire sur les actions inventoriées, application par application, en commençant par celles dont l'impact est le plus élevé et la population la plus restreinte. Un pilote sur une seule action à fort impact vaut mieux qu'un projet transverse qui n'aboutit pas.
FAQ
Comment décider qu'une action est sensible ?
Par la question « que se passe-t-il si elle est exécutée sans que personne ne l'ait voulue ? ». Si la réponse implique une perte financière, une obligation de notification ou un contentieux, elle appartient à la liste.
N'est-ce pas trop de friction pour les équipes ?
La friction se mesure au nombre d'occurrences, pas à l'intensité de chaque contrôle. Une exigence forte sur une action réalisée quelques fois par semaine est bien mieux acceptée qu'une exigence moyenne imposée à chaque connexion.
Faut-il un projet applicatif par application ?
Un déploiement en overlay limite les modifications applicatives, mais l'identification du point de déclenchement reste un travail à mener parcours par parcours. C'est le principal poste d'effort.
Comment traiter les cas d'urgence ?
En prévoyant une procédure documentée, tracée et limitée dans le temps plutôt qu'une dérogation informelle. Les dérogations non cadrées deviennent le chemin d'attaque privilégié.
Aller plus loin : l'authentification cognitive · l'authentification transactionnelle · sécuriser un accès à privilèges · le MTD face au vol de session