Chez un éditeur de logiciel, le phishing ne vise presque jamais les données de l'éditeur lui-même. Il vise le chemin d'accès aux environnements de ses clients : consoles d'administration, outils de support, secrets d'intégration continue. Un seul compte interne hameçonné peut donc produire un incident multi-clients, avec les obligations contractuelles et réglementaires qui vont avec.
Les comptes réellement ciblés ne sont pas ceux qu'on protège en premier
Le réflexe consiste à durcir les comptes de direction. Dans un éditeur SaaS, les comptes les plus rentables pour un attaquant sont ailleurs :
- Support niveau 2 et 3, qui disposent souvent d'une fonction d'impersonation permettant d'ouvrir la session d'un utilisateur client pour reproduire un incident.
- Ingénierie de production et SRE, qui détiennent les accès aux consoles cloud, aux bases multi-tenant et aux pipelines de déploiement.
- Comptes de service et jetons d'intégration, qui n'ont ni visage ni notification push, mais des droits très larges et une durée de vie longue.
- Customer Success, qui manipule les configurations clients et sert de canal de confiance vers les administrateurs côté client.
Ces populations partagent un point commun : elles travaillent vite, sur des alertes entrantes, et sont habituées à cliquer sur des liens qu'elles n'ont pas sollicités. C'est exactement le terrain que cherche un hameçonnage ciblé.
Quatre scénarios propres au modèle SaaS
Le faux ticket entrant. Un message se présente comme une demande client urgente, avec une pièce jointe ou un lien vers une « capture d'écran de l'erreur ». La page relais reproduit le portail interne d'authentification. L'agent de support s'authentifie de bonne foi.
L'alerte d'astreinte usurpée. Une notification imite l'outil de supervision ou le fournisseur cloud : incident critique, action immédiate requise. La pression temporelle est intégrée au scénario, la vérification saute.
Le consentement applicatif détourné. L'attaquant n'essaie pas de voler un mot de passe : il fait approuver une application tierce demandant des autorisations larges sur la messagerie ou le stockage. L'utilisateur clique sur « Autoriser », et l'accès persiste sans mot de passe ni second facteur.
L'invitation de dépôt ou de projet. Un lien de collaboration usurpé conduit vers une page d'authentification relayée. La cible visée est le pipeline de build, donc la chaîne d'approvisionnement logicielle.
Dans les trois premiers cas, la MFA classique ne bloque rien : soit elle est traversée par un proxy inverse qui relaie l'échange en direct et récupère le cookie de session, soit elle n'est tout simplement pas sollicitée.
| Actif visé | Vecteur privilégié | Impact typique | Parade prioritaire |
|---|---|---|---|
| Console d'administration multi-tenant | Page relais AiTM | Accès transverse aux données clients | Facteur lié à l'origine + sessions courtes |
| Fonction d'impersonation support | Faux ticket urgent | Lecture de données d'un client identifié | Validation explicite par action, journal côté client |
| Jetons CI/CD et secrets | Invitation de dépôt usurpée | Altération d'une version livrée | Rotation, cloisonnement, revue des droits |
| Boîte mail interne | Consentement applicatif | Exfiltration persistante sans authentification | Contrôle des applications autorisées |
| Compte Customer Success | Usurpation d'un contact client | Modification de configuration client | Double validation des changements sensibles |
Le cadre réglementaire pèse sur l'éditeur, pas seulement sur son client
Trois textes structurent les attentes.
Le Cyber Resilience Act (règlement (UE) 2024/2847), en vigueur depuis fin 2024 avec des obligations principales à horizon fin 2027, impose une logique de sécurité dès la conception pour les produits comportant des éléments numériques, et interdit notamment les mots de passe par défaut. Un mécanisme d'authentification faible n'est plus seulement un risque opérationnel, il devient un défaut de conformité produit.
La directive NIS2 ((UE) 2022/2555) cite explicitement l'authentification multifacteur ou continue parmi les mesures de gestion des risques attendues, et couvre les fournisseurs de services numériques. Enfin, un éditeur qui héberge des données pour le compte de clients européens reste soumis au RGPD en qualité de sous-traitant, avec les obligations de notification que cela implique.
Concrètement, un incident d'hameçonnage interne devient un événement à qualifier, à notifier et à expliquer contractuellement à chaque client concerné.
Parades réalistes dans un contexte d'éditeur
- Basculer les populations à privilèges vers une méthode liée à l'origine. FIDO2/WebAuthn rend une page relais inexploitable, car la réponse cryptographique est calculée pour un domaine précis. C'est la mesure au meilleur rapport effort/effet pour le support et la production.
- Retirer le SMS-OTP des parcours internes. Le NIST SP 800-63B classe l'OTP par SMS ou voix comme « restricted ». Le conserver sur une console d'administration est difficile à défendre.
- Traiter le consentement applicatif comme une action sensible. Restreindre les autorisations accordées aux applications tierces, exiger une validation administrative, auditer régulièrement les consentements existants.
- Réduire la valeur d'une session volée. Durée de vie courte sur les périmètres d'administration, révocation possible en quelques minutes, réauthentification exigée pour les opérations à effet client.
- Ajouter une preuve d'intention sur les actions à portée externe. Ouvrir une session client, exporter une base, publier une version : ces gestes méritent une validation explicite au moment de l'acte, et non la confiance héritée d'une connexion réussie le matin même.
- Donner à vos clients de la traçabilité. Journaux d'accès administrateur exposés côté client, alertes sur usage d'impersonation : c'est un argument commercial autant qu'une mesure de sécurité.
FAQ
La MFA suffit-elle à protéger nos équipes support ?
Pas si elle repose sur un code ou une approbation transmissible. Un proxy inverse relaie la demande en temps réel et récupère le cookie de session émis après une authentification réussie. Seules les méthodes liées à l'origine, ou une validation d'intention au moment de l'action, changent l'issue.
Comment détecter une compromission de compte interne rapidement ?
Surveillez les corrélations : authentification réussie suivie d'un changement de paramètres, usage d'impersonation hors des heures de traitement des tickets, création de jetons d'API, connexions depuis des infrastructures d'hébergement. L'événement isolé est banal, la séquence ne l'est pas.
Faut-il notifier nos clients pour un simple compte hameçonné ?
Cela dépend de l'accès dont disposait ce compte et des données atteintes. La règle pratique est de qualifier l'incident selon le périmètre technique réel, pas selon l'intention supposée de l'attaquant, puis d'appliquer vos engagements contractuels et vos obligations RGPD.
Le changement de mot de passe clôt-il l'incident ?
Non. Si un cookie de session ou un jeton d'API a été capturé, il reste exploitable après le changement de mot de passe. La révocation des sessions et la rotation des secrets sont les deux gestes qui coupent réellement l'accès.
Aller plus loin : le 4ᵉ facteur cognitif · MFA résistante au phishing · vol de session après authentification · Cyber Resilience Act et éditeurs