MSP : pourquoi votre prestataire est devenu votre principale

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.

MSP compromis : l'effet cascade et comment l'anticiper

Trois compromis MSP majeurs en sept jours — cPanel, SimpleHelp, Trellix. Le schéma est toujours le même : l'attaquant compromet l'outil de gestion à distance que le MSP utilise pour administrer ses clients, et accède simultanément à des centaines d'environnements sans avoir besoin de compromettre chacun individuellement. C'est l'efficacité de la supply chain attack appliquée aux prestataires.

Pourquoi les MSP sont des cibles de choix pour les groupes ransomware

Les Managed Service Providers concentrent trois caractéristiques qui en font des cibles privilégiées des opérateurs ransomware :

• Accès à plusieurs centaines d'environnements clients depuis un point unique : compromettre un MSP, c'est potentiellement accéder à la totalité de sa base clients avec un seul set de credentials. Des groupes comme REvil et ALPHV ont industrialisé cette approche.
• Outils de gestion à distance (RMM) avec accès système complet : les outils RMM (Kaseya VSA, ConnectWise Automate, Datto RMM, SimpleHelp) ont par conception un accès total aux endpoints clients. Leur compromission donne à l'attaquant une persistance invisible — il utilise des outils légitimes, pas du malware détectable.
• Maturité sécurité variable : les MSP varient énormément en taille et en maturité sécurité. Un MSP de 5 personnes gérant 200 clients PME peut avoir lui-même des pratiques de sécurité insuffisantes — pas de MFA sur ses outils RMM, pas de segmentation entre ses environnements clients, des credentials partagés entre techniciens.

Comment évaluer la maturité sécurité de votre MSP avant un incident

Si votre infrastructure est gérée par un MSP, voici les questions à poser et les documents à exiger pour évaluer votre exposition :

• Certifications et audits tiers : votre MSP dispose-t-il d'une certification ISO 27001 ? D'un rapport SOC 2 Type II ? D'un rapport de test de pénétration récent (moins de 12 mois) ? L'absence de ces éléments n'est pas rédhibitoire pour une petite structure, mais doit motiver une discussion sur ses pratiques de sécurité.
• MFA sur tous les accès RMM : les outils RMM de votre MSP sont-ils protégés par MFA ? En 2026, un outil RMM sans MFA est une vulnérabilité critique. C'est non-négociable.
• Segmentation entre les environnements clients : un technicien qui administre votre infrastructure peut-il accéder à celle d'un autre client depuis la même console ? La segmentation entre clients dans l'outil RMM est une exigence fondamentale.
• Processus de notification d'incident : quel est le délai de notification si votre MSP détecte une compromission de ses outils ? Ce délai est-il contractualisé ? La différence entre une notification en 2 heures et une notification en 48 heures peut être la différence entre un incident contenu et une catastrophe.
• Gestion des accès privilégiés : les credentials d'accès à vos systèmes sont-ils stockés dans un gestionnaire de mots de passe dédié avec rotation régulière ? Sont-ils partagés entre les techniciens, ou chaque technicien a-t-il ses propres credentials ?

Clauses contractuelles à imposer à votre MSP

Le contrat avec votre MSP doit inclure des dispositions spécifiques sur la sécurité, particulièrement si ce prestataire a accès à des données sensibles ou à des systèmes critiques :

• Notification d'incident sous 4 heures : tout incident affectant les systèmes du MSP susceptible d'impacter votre environnement doit faire l'objet d'une notification immédiate. 4 heures est le délai maximal acceptable pour un prestataire avec accès à votre infrastructure critique.
• Droit d'audit des accès : vous devez pouvoir consulter à tout moment les logs d'accès de votre MSP à vos systèmes. Ces logs doivent être conservés pendant au minimum 12 mois.
• Obligation de MFA : le contrat doit explicitement imposer l'utilisation du MFA sur tous les outils d'accès à votre infrastructure. Un avenant technique peut préciser les solutions acceptables.
• Responsabilité en cas d'incident : définissez explicitement les responsabilités financières en cas d'incident résultant d'une défaillance sécurité du MSP. La responsabilité contractuelle standard des MSP est souvent limitée à quelques mois de prestation — très insuffisant en cas de fuite de données.

Foire aux questions — Sécurité MSP et prestataires

Que faire si votre MSP ne veut pas répondre aux questions de sécurité ?

Un MSP qui refuse de communiquer sur ses pratiques de sécurité ou de fournir ses certifications est un signal d'alarme sérieux. La sécurité de votre infrastructure dépend directement de la sécurité de votre MSP. Si votre prestataire actuel ne peut pas justifier d'un niveau de maturité minimal (MFA sur RMM, séparation des clients, procédure de notification d'incident), envisagez sérieusement une mise en concurrence. Le marché des MSP s'est professionnalisé — des alternatives certifiées existent pour la quasi-totalité des services.

Comment détecter une compromission de vos systèmes via votre MSP ?

La compromission via MSP est difficile à détecter car elle utilise des accès légitimes. Les indicateurs à surveiller : des activités RMM en dehors des fenêtres de maintenance planifiées, des connexions depuis des IP ou géographies inhabituelles pour votre MSP, des modifications de configuration non demandées, des installations de logiciels non planifiées. Un SIEM qui corrèle les activités des outils RMM avec les fenêtres de maintenance documentées peut détecter des anomalies. La règle minimale : tout accès RMM hors maintenance planifiée doit déclencher une alerte et une vérification.