L'authentification continue consiste à ne plus considérer l'identité comme acquise après la connexion, mais à la réévaluer pendant toute la durée de la session. Elle répond à un problème réel : une session ouverte reste valide des heures, et un jeton volé se présente comme une requête parfaitement légitime. Sa limite est tout aussi réelle : la plupart des mises en œuvre observent des indices, pas des preuves.
Le problème qu'elle cherche à résoudre
Le modèle classique produit un point de contrôle unique : l'utilisateur prouve son identité, puis une session s'ouvre et fait autorité jusqu'à son expiration. Trois situations mettent ce modèle en défaut.
- Le vol de jeton. Un cookie ou un jeton de rafraîchissement dérobé par malware, par extension malveillante ou capté lors d'une attaque en relais permet d'agir sans repasser par aucun facteur.
- Le poste laissé accessible. Une session ouverte sur un terminal non verrouillé est une identité disponible.
- Le changement de contexte en cours de session. Le terminal peut devenir non conforme après l'authentification : désactivation d'une protection, connexion à un réseau hostile.
Dans les trois cas, la connexion initiale a été honnête. Ce n'est pas l'authentification qui a échoué, c'est sa durée de validité qui n'a plus de rapport avec la réalité.
Deux familles de mécanismes, souvent confondues
Il est important de les distinguer, car elles n'apportent pas la même garantie.
La réévaluation contextuelle. Le système observe des attributs pendant la session — adresse réseau, conformité du terminal, cohérence des accès — et réagit s'ils changent. Des cadres d'échange de signaux entre fournisseurs d'identité et applications, développés au sein d'initiatives ouvertes, visent à propager rapidement un événement de sécurité — révocation, compromission soupçonnée, changement d'état du terminal — pour que les sessions en cours soient réévaluées sans attendre leur expiration naturelle.
La biométrie comportementale. Le système modélise une manière d'utiliser le terminal : rythme de frappe, mouvements du pointeur, gestuelle sur écran tactile, séquences de navigation. Un écart avec le modèle abaisse le niveau de confiance.
| Approche | Ce qu'elle observe | Ce qu'elle établit | Angle mort |
|---|---|---|---|
| Réévaluation contextuelle | attributs techniques de la session | cohérence entre le contexte et la politique | un attaquant sur le poste de la victime présente le bon contexte |
| Biométrie comportementale | manière d'interagir | vraisemblance de continuité d'usage | modèle probabiliste, dérive dans le temps, faux positifs |
| Ré-authentification périodique | rien en continu | une preuve fraîche à intervalle donné | friction, et fenêtre entre deux vérifications |
| Validation liée à l'action | l'intention sur une opération précise | une preuve contemporaine de l'acte | ne couvre que les actions instrumentées |
La confusion à éviter : indice contre preuve
Les deux premières approches produisent une présomption. Un rythme de frappe conforme rend plausible que la même personne soit devant le clavier ; il ne le démontre pas. Une adresse réseau stable indique une continuité de contexte ; elle ne dit rien de qui pilote la session.
Cette nuance a des conséquences directes :
- Face à un malware sur le poste de la victime, tous les signaux contextuels restent conformes. L'attaquant opère depuis le bon appareil, le bon réseau, avec la bonne session.
- Face à une session détournée après une attaque en relais, l'authentification initiale a réellement eu lieu, et le contexte reproduit peut être très proche.
- Face à un écart comportemental, le système ne peut que baisser un score, jamais conclure. Il faut alors décider quoi faire de cette baisse — et c'est là que tout se joue.
La réponse cohérente n'est pas de bloquer sur un indice, ce qui produirait des interruptions intolérables, mais de demander une preuve. Autrement dit, l'authentification continue prend tout son sens lorsqu'elle sert de déclencheur à une élévation, et non de décision autonome. C'est l'articulation avec le step-up et avec la validation au niveau de l'action.
Les questions de vie privée et de dialogue social
Observer en permanence la manière dont une personne utilise son poste soulève des questions qui dépassent la technique. Une biométrie comportementale traite des données susceptibles de renseigner sur le rythme de travail, les pauses, la vitesse d'exécution. Trois précautions s'imposent :
- Finalité strictement limitée à la sécurité, avec exclusion explicite de tout usage de gestion de la performance.
- Information des personnes et consultation des instances représentatives, avant déploiement.
- Minimisation : traitement local lorsque c'est possible, conservation courte, absence de constitution d'un profil détaillé et durable.
Le traitement local sur le terminal est ici l'option la plus protectrice, et elle correspond à l'approche décentralisée retenue par HIAsecure — biométrie éventuelle traitée sur l'appareil, aucune donnée identifiante détenue par l'éditeur.
Une mise en œuvre raisonnable
- Réduire d'abord la durée de vie des sessions sur les périmètres critiques et savoir révoquer les jetons. C'est peu coûteux et immédiatement efficace contre le vol de session.
- Propager les événements de sécurité vers les applications, plutôt que d'attendre l'expiration naturelle des jetons.
- Utiliser les signaux comportementaux comme déclencheurs, pas comme verdicts.
- Instrumenter les actions sensibles pour qu'elles portent leur propre validation : c'est la protection la plus robuste contre une session détournée.
FAQ
L'authentification continue remplace-t-elle l'authentification initiale ?
Non. Elle en prolonge l'effet en surveillant la cohérence de la session. Une preuve initiale faible ne devient pas forte parce qu'elle est surveillée ensuite.
La biométrie comportementale est-elle fiable ?
Elle produit un score de vraisemblance, sensible au contexte : fatigue, blessure, changement de matériel, poste partagé. Elle convient à la détection d'anomalies, pas à la décision d'accès prise isolément.
Protège-t-elle du vol de session ?
Partiellement. Elle détecte un usage depuis un contexte différent, mais pas un attaquant opérant depuis le terminal de la victime. La parade la plus solide reste de valider l'action sensible elle-même, indépendamment de la session.
Faut-il l'activer sur toute la population ?
Rarement pertinent d'emblée. Les accès à privilèges et les parcours financiers offrent le meilleur rapport entre bénéfice de sécurité et charge d'exploitation, et permettent de calibrer avant toute généralisation.
Aller plus loin : valider l'intention au moment de l'action · Zero Trust : principes et limites · authentification adaptative · vol de session et token theft