Chez un éditeur SaaS, l'attaque AiTM (adversary-in-the-middle) a une caractéristique unique : elle transforme un incident interne en incident chez les clients. Une session volée sur une console d'administration, un outil de support ou un dépôt de code ne donne pas seulement accès aux données de l'éditeur — elle donne accès, par conception, aux environnements de ceux qui lui font confiance. Le proxy inverse relaie l'authentification ; ce qu'il capture ensuite peut être un jeton valable sur des milliers de tenants.
Le jeton, pas le mot de passe
L'écosystème SaaS fonctionne à la délégation. OAuth 2.0 et OpenID Connect font circuler des jetons d'accès et de rafraîchissement dont la durée de vie dépasse largement celle d'une session de navigateur. Cette architecture, excellente pour l'expérience utilisateur, produit une conséquence directe : le butin d'un AiTM chez un éditeur est durable.
Trois objets méritent une attention distincte.
- Le jeton de rafraîchissement, qui permet de régénérer des accès sans nouvelle authentification, parfois pendant des semaines.
- Les jetons d'application et clés d'API, qui ne sont associés à aucune session interactive et échappent donc aux contrôles conçus pour les humains.
- Les consentements OAuth, qu'un attaquant peut faire accorder à une application qu'il contrôle, créant une porte dérobée qui survit à la révocation des sessions et au changement de mot de passe.
Un traitement d'incident qui se limite à révoquer les sessions laisse les deux derniers intacts.
Le risque de propagation vers les clients
| Surface éditeur | Portée d'une session volée | Propagation vers les clients | Mesure de confinement |
|---|---|---|---|
| Console d'administration produit | Tous les tenants | Directe et massive | Facteur lié à l'origine, accès juste-à-temps |
| Outil de support avec impersonation | Tenant par tenant | Directe, discrète | Traçabilité par action, accord client |
| Chaîne d'intégration continue | Code et artefacts publiés | Différée, via une mise à jour | Signature des artefacts, revue à quatre yeux |
| Gestionnaire de secrets | Clés d'API tierces | Indirecte, large | Rotation, cloisonnement par environnement |
| Espace client (CIAM) | Comptes utilisateurs finaux | Ciblée | Détection d'usage, sessions courtes |
| Documentation et espaces partagés | Renseignement interne | Préparatoire | Classification, accès conditionnel |
La ligne la plus redoutée est celle de la chaîne d'intégration : la compromission ne se manifeste pas au moment du vol de session mais au moment de la livraison, chez les clients, avec la signature de l'éditeur.
Ce que la fonction support doit assumer
Les outils de support intègrent souvent une capacité d'impersonation : agir en tant qu'un utilisateur client pour reproduire un incident. C'est une fonctionnalité légitime et, du point de vue d'un attaquant, la plus intéressante du produit.
Trois garde-fous sont réalistes.
- Le consentement tracé : l'impersonation est déclenchée sur un ticket identifié, avec une durée limitée et une trace visible côté client.
- La réauthentification par action, et non par session : entrer dans le tenant d'un client est un geste, pas un état.
- La limitation des droits : la reproduction d'un incident demande rarement des droits d'écriture sur les données de production.
Parades, dans l'ordre où elles paient
Facteur lié à l'origine sur toutes les surfaces internes. Chez un éditeur, la population interne est réduite et technophile : c'est le secteur où le passage à FIDO2/WebAuthn se heurte au moins d'obstacles. Il doit couvrir la messagerie, les consoles, le dépôt de code et l'intégration continue, sans exception ni méthode de repli affaiblie.
Supprimer les replis. Un dispositif fort assorti d'une option « recevoir un code par e-mail en cas de problème » vaut le niveau de ce repli. C'est l'erreur la plus fréquente et la plus coûteuse.
Durée de vie des jetons alignée sur la sensibilité. Une console d'administration ne justifie pas un jeton de rafraîchissement longue durée. La commodité se paie ici en fenêtre d'exploitation.
Audit des consentements et des clés. Inventaire régulier des applications autorisées, des clés d'API et des jetons de service, avec propriétaire identifié et date de rotation. Cet inventaire est aussi ce qui rend une réponse à incident exploitable.
Preuve d'intention sur les gestes à portée client. Publication d'une version, modification d'un paramètre global, export de données, entrée dans un tenant : ces actions gagnent à exiger une validation explicite indépendante de la session. Le facteur cognitif répond à ce besoin par un défi résolu au moment de l'action, dans un canal éphémère ouvert par QR code dynamique à usage unique, et se déploie en overlay d'un fournisseur d'identité existant — ce qui évite de reconstruire le socle d'authentification pour couvrir quelques gestes critiques.
Documenter pour ses clients. Un éditeur soumis à des questionnaires de sécurité gagne à pouvoir décrire précisément sa posture d'authentification interne : c'est devenu un critère d'achat autant qu'une mesure de sécurité.
FAQ
Pourquoi un éditeur SaaS est-il une cible privilégiée ?
Parce qu'une seule compromission d'identité peut ouvrir l'accès à de nombreux clients à la fois. Le rapport entre l'effort d'attaque et le gain potentiel y est particulièrement favorable à l'attaquant.
Révoquer les sessions suffit-il après un incident AiTM ?
Non. Il faut aussi révoquer les jetons de rafraîchissement, auditer les consentements OAuth accordés pendant la fenêtre suspecte, vérifier les facteurs enrôlés et faire tourner les clés d'API. Chacun de ces éléments peut survivre à une simple révocation de session.
Les passkeys règlent-elles le problème pour un éditeur ?
Elles ferment la porte du relais sur la connexion, ce qui est essentiel. Restent le vol de jeton après authentification, les accès non interactifs par clé d'API, et les parcours de récupération de compte.
Comment concilier accès de support et confidentialité client ?
En traitant l'impersonation comme une action soumise à autorisation, tracée et limitée dans le temps, plutôt que comme une capacité permanente attachée à un rôle.
Aller plus loin : le 4ᵉ facteur cognitif · mécanique de l'attaque AiTM · vol de session et token theft · NIS2 pour les acteurs du numérique