En assurance, l'attaque AiTM (adversary-in-the-middle) trouve un terrain particulier : la distribution est intermédiée. Courtiers, agents généraux, délégataires de gestion et experts accèdent aux mêmes systèmes que les salariés, depuis des postes que la compagnie ne maîtrise pas. Le proxy inverse capture la session d'un intermédiaire, et l'attaquant hérite d'un accès légitime à des portefeuilles entiers — sans avoir eu besoin d'entrer dans le réseau de l'assureur.
Pourquoi l'intermédiation change le calcul de risque
Une compagnie peut imposer un facteur résistant au phishing à ses collaborateurs. Elle l'impose plus difficilement à un réseau de plusieurs milliers de cabinets indépendants, chacun avec son niveau d'équipement. Le résultat est une surface d'authentification hétérogène : le même extranet est protégé par un facteur solide pour les uns et par un simple code temporaire pour les autres.
L'attaquant choisit naturellement le maillon le plus faible. Il ne cible pas la compagnie : il cible un cabinet, souvent de petite taille, dont l'adresse de messagerie est publique sur son site.
Deuxième particularité : la valeur des données. Un contrat d'assurance concentre l'état civil, la composition du foyer, le patrimoine, parfois des éléments de santé relevant de l'article 9 du RGPD. Une session ouverte sur un extranet de gestion donne accès à cette matière en lecture, immédiatement monétisable pour de l'usurpation ou du hameçonnage ciblé.
Les parcours réellement visés
| Parcours assurance | Ce que capture la session volée | Préjudice recherché | Contre-mesure prioritaire |
|---|---|---|---|
| Extranet courtier / agent | Portefeuille clients complet | Extraction de données, prospection frauduleuse | Facteur lié à l'origine imposé au réseau |
| Souscription en ligne | Simulation, pièces justificatives | Fraude à la souscription, faux contrats | Contrôle des pièces, validation d'intention |
| Déclaration et suivi de sinistre | Historique, montants, expertises | Détournement d'indemnisation | Verrouillage du changement d'IBAN |
| Espace assuré particulier | Coordonnées, garanties, échéances | Prétexte pour un appel frauduleux | Notification hors bande des modifications |
| Délégation de gestion | Droits étendus sur un périmètre | Actions de masse peu visibles | Journalisation par délégataire, quotas |
| Portail santé / prévoyance | Données de santé | Sanction RGPD, atteinte réputationnelle | Chiffrement, minimisation, sessions courtes |
Le changement d'IBAN, point de bascule
Le préjudice financier en assurance passe rarement par un virement initié par l'attaquant. Il passe par la modification des coordonnées bancaires de règlement. L'attaquant installé dans une session légitime modifie l'IBAN sur un dossier de sinistre en cours ; l'indemnisation part ensuite par le circuit normal, validée par des collaborateurs qui n'ont aucune raison de douter.
Ce mécanisme a deux conséquences pratiques. D'abord, la détection ne doit pas se concentrer sur les connexions anormales mais sur les modifications de données de règlement. Ensuite, la parade la plus efficace est procédurale : délai de carence entre le changement d'IBAN et le premier versement, notification systématique à l'assuré sur un canal distinct, et contre-appel sur un numéro de référence détenu par la compagnie — jamais sur celui fourni dans le dossier modifié.
Ce qui fonctionne, ce qui ne fonctionne pas
Ce qui ne suffit pas. Le code temporaire par application ou par SMS est relayé en direct par le proxy inverse. La sensibilisation seule ne protège pas non plus : la page vue par la victime est le vrai site, servi à travers l'attaquant, et le certificat est valide.
Ce qui agit sur la connexion. La liaison à l'origine de FIDO2/WebAuthn rend la réponse inexploitable sur le domaine du relais. Pour un réseau d'intermédiaires, la difficulté n'est pas technique mais contractuelle : il faut inscrire le niveau d'authentification exigé dans les conventions de distribution et de délégation, avec un calendrier réaliste.
Ce qui agit après la connexion. Une session volée reste utilisable. Réduire sa durée de vie, réévaluer le contexte en cours d'usage et exiger une preuve explicite sur les actions à effet financier limitent la fenêtre d'exploitation. C'est l'apport du facteur cognitif : un défi résolu au moment de l'action, dans un canal éphémère ouvert par QR code dynamique à usage unique, sans secret réutilisable qu'un relais pourrait capter. Le déploiement en overlay d'une MFA existante permet de commencer par les gestes sensibles — changement d'IBAN, validation d'indemnisation — sans refondre l'extranet.
Feuille de route pour un réseau intermédié
- Cartographier les canaux d'accès : combien d'extranets, quels facteurs, quels délégataires.
- Classer les gestes, pas les écrans. Un même portail mêle consultation banale et actions à fort impact ; le niveau d'authentification doit suivre le geste.
- Contractualiser le niveau d'authentification dans les conventions, avec une date d'effet.
- Verrouiller les données de règlement par un contrôle indépendant du canal de saisie.
- Surveiller les extractions massives : un cabinet qui consulte en une heure ce qu'il consulte habituellement en un mois est un signal exploitable.
- Préparer la révocation : savoir couper les sessions d'un intermédiaire donné, sans couper tout le réseau, et l'avoir testé.
FAQ
L'assureur est-il responsable si la compromission vient d'un courtier ?
Le sujet dépasse cet article, mais deux constats s'imposent. L'assureur reste responsable du traitement des données qu'il héberge, et il définit le niveau d'authentification exigé à l'entrée de son extranet. Le risque se pilote donc par le contrat autant que par la technique.
Un code temporaire par application protège-t-il l'extranet courtier ?
Il protège contre la réutilisation d'un mot de passe volé, ce qui est utile face au credential stuffing. Il ne protège pas contre un proxy inverse, qui relaie le code dans sa fenêtre de validité.
Comment détecter une session volée sur un extranet de gestion ?
Surveillez les volumes de consultation par compte, les horaires atypiques, et surtout la séquence « connexion réussie puis modification de coordonnées bancaires ». Comparez aussi l'empreinte du navigateur au sein d'une même session.
Faut-il traiter différemment la santé et la prévoyance ?
Oui. Les données de santé relèvent d'un régime renforcé au titre du RGPD. Le niveau d'authentification, la durée des sessions et la journalisation doivent y être plus stricts que sur les branches dommages.
Aller plus loin : le 4ᵉ facteur cognitif · comprendre l'attaque AiTM · DORA et le secteur assurance · choisir une solution d'authentification