Chez un éditeur SaaS, le détournement de session a une propriété que n'ont pas les autres secteurs : il traverse la frontière de l'entreprise. Une session interne volée devient un accès aux environnements des clients, donc un incident à notifier, à documenter et à expliquer contractuellement — souvent à plusieurs organisations simultanément.
Les jetons qui comptent vraiment ne sont pas ceux des collaborateurs
L'analyse s'arrête trop souvent aux cookies de navigateur. Dans une plateforme moderne, les jetons les plus exposés sont ailleurs.
Les jetons de service. Ils authentifient des composants entre eux, ne bénéficient d'aucun second facteur, disposent de droits larges et ont une durée de vie longue par nécessité opérationnelle.
Les jetons d'intégration délivrés aux clients. Un client qui connecte votre produit à ses outils génère un jeton. Ce jeton vit chez lui, dans un environnement que vous ne maîtrisez pas, et constitue un chemin d'entrée symétrique.
Les jetons de rafraîchissement. Conçus pour éviter les reconnexions, ils autorisent la production de nouveaux accès sans nouvelle authentification. Leur vol est bien plus intéressant que celui d'un cookie de courte durée.
Les sessions d'administration interne. Consoles d'exploitation, outils de support avec fonction d'impersonation, tableaux de bord de facturation : ce sont les cibles qui donnent l'accès le plus large au moindre effort.
| Type de jeton | Durée typique | Second facteur associé | Risque en cas de vol |
|---|---|---|---|
| Cookie de session collaborateur | Courte à moyenne | Oui, à l'ouverture | Accès aux outils internes |
| Jeton de rafraîchissement | Longue | Non, par conception | Renouvellement d'accès sans authentification |
| Jeton d'API client | Très longue | Non | Accès programmatique aux données du client |
| Compte de service interne | Permanent | Non | Mouvement latéral dans la plateforme |
| Session d'administration | Courte, si bien réglée | Oui | Accès transverse à plusieurs tenants |
Comment ces jetons sortent
Trois voies dominent chez les éditeurs. Un relais d'authentification sur le portail interne, qui capture le cookie émis après une connexion réussie. Un dérobeur d'informations ou une extension malveillante sur le poste d'un ingénieur, qui lit les secrets stockés localement — y compris ceux laissés dans des fichiers de configuration ou des variables d'environnement. Enfin, une fuite involontaire : jeton commité dans un dépôt, présent dans un journal d'exécution, exposé dans une capture d'écran de support.
Ces trois voies ont en commun de ne produire aucun événement d'authentification anormal. La détection doit donc porter sur l'usage : appels d'API depuis une origine inhabituelle, volumétrie inattendue sur un compte de service, usage d'un jeton d'administration en dehors des heures d'astreinte, ou emploi simultané d'un même jeton depuis deux localisations incompatibles.
Ce que la conformité attend d'un éditeur
Le Cyber Resilience Act ((UE) 2024/2847), en vigueur depuis fin 2024 avec des obligations principales à horizon fin 2027, ancre la sécurité dès la conception pour les produits comportant des éléments numériques et proscrit les mots de passe par défaut. La gestion du cycle de vie des identifiants et des jetons entre pleinement dans cette logique.
La directive NIS2 ((UE) 2022/2555) couvre les fournisseurs de services numériques et attend des mesures de gestion des risques, dont l'authentification multifacteur ou continue, ainsi qu'une capacité de notification des incidents. Le RGPD s'applique au titre de la sous-traitance, avec l'obligation d'assister le client responsable de traitement. Enfin, l'ISO/IEC 27001 structure la démonstration attendue lors des audits clients.
Parades spécifiques au modèle SaaS
- Traiter les jetons non humains comme des identités à part entière : inventaire, propriétaire désigné, durée maximale, rotation planifiée, révocation testée.
- Réduire la portée avant de réduire la durée. Un jeton restreint à une opération et à un tenant limite le préjudice bien plus efficacement qu'une expiration raccourcie sur un jeton omnipotent.
- Encadrer l'impersonation de support : autorisation explicite, durée limitée, motif obligatoire, journal visible du client. C'est une exigence de confiance autant qu'un contrôle.
- Détecter la réutilisation d'un jeton de rafraîchissement : un même jeton présenté deux fois est un signal de vol, et doit invalider la chaîne.
- Lier les sessions d'administration au poste lorsque la plateforme le permet, afin qu'un cookie copié soit inutilisable ailleurs.
- Exiger une preuve d'intention pour les actions à effet client — export de base, modification de configuration d'un tenant, publication d'une version. C'est ce que permet l'authentification cognitive : une validation produite au moment de l'acte, indépendante de la session en cours.
- Préparer la révocation de masse. Savoir invalider en une opération l'ensemble des jetons d'un périmètre est la seule réponse crédible à une compromission de secret, et doit être testée avant d'en avoir besoin.
FAQ
Faut-il des sessions très courtes pour les équipes techniques ?
Sur les consoles d'administration, oui. Ailleurs, la contrainte crée des contournements — sessions maintenues artificiellement actives, jetons stockés en clair. Mieux vaut restreindre la portée et exiger une preuve fraîche sur les actions sensibles.
Comment repérer un jeton d'API compromis ?
Par l'écart de comportement : origine réseau nouvelle, séquence d'appels différente, volumétrie inhabituelle, ou appels hors des plages horaires du client. Ces signaux existent dans vos journaux d'API, mais sont rarement corrélés par identité de jeton.
Un client peut-il être à l'origine de l'incident ?
Oui, si le jeton d'intégration délivré à ce client a fuité de son côté. D'où l'intérêt de jetons à portée restreinte, d'une révocation en libre-service et d'une visibilité offerte au client sur l'usage de ses propres jetons.
Quelle est la première mesure à prendre après une compromission ?
Révoquer et faire tourner les secrets du périmètre concerné, avant même l'analyse détaillée. Le temps passé à qualifier l'incident est du temps pendant lequel l'attaquant conserve un accès valide.
Aller plus loin : authentification cognitive : le pilier · vol de session : mécanismes et détection · NIS2 pour les éditeurs · accès à privilèges et PAM