MSP : pourquoi votre prestataire est devenu votre principale faille

Trois compromis MSP majeurs en sept jours. cPanel, SimpleHelp, Trellix. Si votre stratégie de sécurité s'arrête à votre périmètre direct, vous êtes en train de payer pour des attaquants qui passent par la porte d'à côté — celle de votre prestataire.

Le MSP, ce point unique de défaillance qu'on refuse de regarder

Quand je rentre dans un comité de pilotage cyber d'une PME ou d'une ETI, je pose toujours la même question : « combien de prestataires ont un accès administrateur à votre infrastructure ? ». La réponse moyenne tourne autour de quatre. L'hébergeur web, l'infogérant infrastructure, l'éditeur de votre ERP qui télémaintient en VPN, le prestataire RMM qui pousse les patches sur les postes utilisateurs. Quatre identités à privilèges qui ne figurent pas dans votre IAM, qui ne respectent pas votre politique de mots de passe, qui n'envoient pas leurs logs à votre SIEM. Quatre maillons que vous n'auditez pas et qui peuvent ruiner six mois d'efforts de sécurité interne en une nuit.

Cette semaine, trois exemples concrets. Lundi 5 mai, ShinyHunters a publié les données de 275 millions d'utilisateurs Canvas — on parle d'Instructure, prestataire LMS de Harvard, MIT, Oxford et plus de 9 000 établissements. Vendredi, MuddyWater a été pris la main dans le sac à se faire passer pour le ransomware Chaos via Microsoft Teams pour exfiltrer des credentials. Mardi 6 mai, Trellix — un éditeur de cybersécurité — a annoncé la fuite d'une partie de son code source. Le point commun ? Aucun. Sauf un : dans chaque cas, c'est l'utilisateur final qui paie le prix d'une décision prise par un fournisseur en amont.

L'économie du compromis cascade

Les opérateurs de ransomware ont compris depuis longtemps un calcul que les RSSI peinent à intégrer dans leur cartographie de risque : compromettre un MSP, c'est multiplier le rendement par cinquante. Un seul accès root sur l'instance cPanel d'un hébergeur mutualisé donne accès à 200 sites clients, 200 bases de données, 200 sauvegardes. Un seul accès administrateur à un panneau SimpleHelp donne le contrôle de plusieurs centaines de machines pilotées en RMM. Le ROI de l'attaquant est monstrueux — et le coût d'entrée a chuté.

La CVE-2026-41940 sur cPanel est l'exemple textbook de cette dynamique. Vulnérabilité critique, score CVSS 9,8, exploitable sans authentification, PoC public. Délai entre publication du PoC et déploiement de ransomware en environnement réel : moins de 24 heures. Pas un an, pas un mois, pas une semaine. Vingt-quatre heures. Et qui paie ? Pas l'hébergeur — il est entre deux feux. Ses clients. Des PME qui découvrent que leur site est offline, leur base RGPD divulguée et leur sauvegarde chiffrée parce qu'un autre client du même serveur n'avait rien à voir avec eux mais partageait l'infrastructure.

Cette asymétrie n'est pas nouvelle. Ce qui change en 2026, c'est l'industrialisation. Les groupes ransomware achètent désormais aux courtiers d'accès initial des listes ciblées de MSP exposés sur SimpleHelp ou cPanel. Les courtiers eux-mêmes utilisent des scanners automatisés qui détectent en quelques heures les instances vulnérables après publication d'un CVE. La chaîne est devenue une supply chain industrielle de l'attaque.

Le mythe de la responsabilité contractuelle

« Mais on a un contrat, ils sont responsables ». Phrase entendue cent fois. Lecture du contrat ensuite — et là, surprise : la clause de responsabilité est plafonnée à trois mois de redevance, exclut explicitement les pertes indirectes (donc l'arrêt d'activité), et exige une notification dans des délais que le prestataire lui-même ne tient jamais. Le contrat type d'un MSP français standard plafonne sa responsabilité à environ 8 000 € pour un client qui paie 2 000 € par mois. La PME qui perd 80 000 € de chiffre d'affaires sur trois jours d'arrêt n'aura jamais d'indemnisation à hauteur du préjudice.

Pire : la transposition NIS 2 en France impose à l'entité essentielle ou importante la responsabilité de la chaîne de sous-traitance. Si votre MSP n'est pas conforme et qu'un incident a lieu via lui, c'est vous qui êtes en infraction du devoir de diligence (article 21 NIS 2). L'ANSSI peut sanctionner l'entité d'aval, pas le prestataire d'amont. Le législateur a transféré la charge de surveillance vers vous, en supposant — à tort — que vous aviez les moyens de l'exercer.

Ce qui marche réellement (et ce qui ne marche pas)

Les questionnaires fournisseur de 80 questions remplis une fois par an : illusion de contrôle. Le prestataire les remplit à la chaîne, son commercial valide, le RSSI signe. Aucune vérification réelle. J'ai vu des MSP cocher « MFA actif sur tous les comptes administrateurs » alors que leur console SimpleHelp acceptait encore des mots de passe sans deuxième facteur. Le questionnaire est un document de couverture juridique, pas un outil de sécurité.

Ce qui marche, par contre, c'est la combinaison de quatre pratiques que peu d'organisations appliquent réellement :

1. La cartographie active des accès tiers

Liste exhaustive de chaque compte d'administration externe, mise à jour mensuellement, croisée avec les logs de connexion. Si un compte n'a pas servi depuis 90 jours, il est désactivé. Si un compte est utilisé en dehors des horaires contractuels, alerte. Cette cartographie n'est pas dans votre Active Directory — elle est dans une feuille de calcul partagée entre RSSI et DSI, mise à jour à la main, et c'est très bien comme ça.

2. La rotation imposée des credentials prestataire

Tous les 90 jours, vous régénérez les credentials donnés au MSP. Pas le MSP qui demande la rotation — vous qui la déclenchez. La fenêtre d'exposition est limitée. Et accessoirement vous découvrez régulièrement quels prestataires ont créé des comptes secondaires non documentés, ce qui mérite une discussion.

3. La surveillance des indicateurs d'activité MSP

Vous monitorez votre propre infrastructure ? Très bien. Vous monitorez aussi l'actualité de vos MSP ? Quand BleepingComputer publie qu'un acteur ransomware vise les utilisateurs de SimpleHelp, vous devez le savoir avant le commercial du prestataire. Mettez en place une veille active sur le nom de chaque outil RMM, hébergeur, éditeur SaaS critique. C'est gratuit, ça prend quinze minutes par jour, et ça change la temporalité de votre réponse.

4. La capacité de désactivation d'urgence

Si vous deviez couper l'accès administrateur de votre MSP en quinze minutes, sauriez-vous le faire ? La majorité des organisations que j'audite répondent non — soit par méconnaissance des configurations, soit par dépendance opérationnelle (« si on coupe le MSP, plus rien ne fonctionne »). Cette dépendance est le vrai problème. Tant qu'elle existe, vous n'avez aucun pouvoir de négociation face à un MSP compromis qui vous fait courir un risque actif.

Conclusion : le maillon n'est plus dans votre périmètre

Trois compromis cascade en une semaine. Ce n'est pas un accident statistique, c'est une tendance lourde. La frontière de votre cybersécurité ne s'arrête plus à votre pare-feu, ni à votre EDR, ni à votre tenant Microsoft 365. Elle s'étend à chaque prestataire ayant un accès privilégié à vos systèmes — donc, en pratique, à une dizaine d'entités externes que vous ne pilotez pas, dont la posture de sécurité varie de excellente à catastrophique, et dont vous découvrirez la qualité réelle uniquement quand l'une d'elles se fera compromettre.

L'effort à fournir pour reprendre le contrôle de cette chaîne n'est pas titanesque. Quelques heures par mois pour cartographier, deux jours par trimestre pour roter les credentials, une procédure d'urgence à écrire et tester. Mais ça demande de poser une question gênante au comité de direction : combien d'entreprises tierces peuvent provoquer un arrêt de notre activité de plus de 48 heures ? Si la réponse est plus de zéro, vous avez un sujet à traiter.