# Votre sauvegarde Microsoft 365 peut aussi être attaquée : une liste de contrôle pour PME canadiennes après l'incident de ConnectWise Cloud Backup > Amen Security Team · 2026-10-23T13:33:32.765Z · cybersecurity · microsoft-365 · cloud-backup · cybersecurity · supply-chain · smb · canada Avoir une sauvegarde Microsoft 365 n’est pas la même chose qu’être en sécurité. En octobre 2026, des attaquants ont mis la main sur un identifiant appartenant à une application de sauvegarde elle-même — pas le mot de passe d’un employé — et ont utilisé l’accès que les clients avaient déjà accordé à cette application pour ouvrir une session dans des locataires Microsoft 365. Si un outil de sauvegarde se connecte à votre locataire, sa sécurité fait partie de votre sécurité, et la liste de contrôle ci-dessous montre comment vérifier cette connexion. La plupart des propriétaires classent la sauvegarde dans la catégorie « réglée » : quelqu’un l’a configurée, les rapports affichent « réussite », et tout le monde passe à autre chose. Elle mérite une heure de votre attention, parce que ce qui a cédé n’était pas un mot de passe — c’était une application de confiance aux autorisations étendues, que personne n’avait revérifiées depuis le jour de son installation. Ce qui s’est réellement passé ConnectWise Cloud Backup (anciennement SkyKick) est un service que de nombreux fournisseurs de TI utilisent pour sauvegarder les données Microsoft 365 — courriels, OneDrive, SharePoint, Teams et informations d’annuaire. Le 16 octobre 2026, ConnectWise a divulgué un accès non autorisé impliquant des identités d’application associées à ce service; le lendemain, l’entreprise a désactivé sept identités d’application touchées et suspendu Cloud Backup ainsi que ses services connexes SaaS Security et Cloud Management pendant son enquête. Microsoft Threat Intelligence a décrit l’événement comme une attaque active contre la chaîne d’approvisionnement : l’attaquant a utilisé l’identité OAuth compromise de l’application de sauvegarde pour obtenir des jetons d’accès dans les locataires des clients, en abusant des autorisations que les clients avaient accordées à l’application auparavant — y compris, a noté Microsoft, des autorisations très élevées comme Directory.ReadWrite.All. Microsoft a observé des ouvertures de session réussies par l’identité de l’application le 15 octobre, ainsi que des activités de reconnaissance via l’API Microsoft Graph et des tentatives d’ajout de nouveaux identifiants dans des locataires pour conserver l’accès. Il faut distinguer deux choses, parce que les manchettes les confondent. ConnectWise affirme que ses archives de sauvegarde stockées demeurent chiffrées, isolées et préservées, sans indication qu’elles aient été compromises. Le risque se situait dans les locataires actifs — les boîtes courriel et les fichiers auxquels l’application pouvait accéder avec ses autorisations — et chaque locataire doit encore être examiné individuellement. Selon sa mise à jour du 23 octobre, le rétablissement du service se faisait par phases, les connexions touchées devant rester désactivées jusqu’à ce que ConnectWise publie ses instructions de reconnexion. Lisez la source primaire par vous-même : le [ConnectWise Trust Center advisory](https://www.connectwise.com/company/trust/advisories) (publié initialement le 16 octobre 2026, mis à jour depuis) et le [CSO Online's reporting](https://www.csoonline.com/article/4237087/connectwise-backup-credentials-exposed-multiple-microsoft-365-tenants.html). Pourquoi la MFA n’a pas suffi « Nous avons activé l’authentification multifacteur — comment quelqu’un peut-il encore entrer? » Parce que personne ne s’est connecté en tant que personne. Un service de sauvegarde fonctionne au moyen d’une identité d’application (en termes Microsoft Entra, un principal de service). Votre entreprise lui a accordé une autorisation, une seule fois, de lire les boîtes courriel et les fichiers pour pouvoir les sauvegarder. Quiconque détient l’identifiant de cette application peut le présenter, recevoir des jetons et hériter de toutes les autorisations accordées à l’application — sans demande de mot de passe, sans défi d’authentification multifacteur. Ce n’est pas une raison pour cesser d’utiliser des services de sauvegarde. C’est une raison de traiter chaque application connectée à votre locataire comme un jeu de clés du bâtiment — et de savoir combien de jeux existent, qui les détient et jusqu’où chacun ouvre la porte. C’est la même discipline qui sous-tend une bonne [configuration Microsoft 365 et cloud](https://amensecurity.ca/fr/services/cloud). La liste de contrôle : dix choses à faire ce mois-ci Vous n’avez pas à exécuter ces étapes vous-même — mais vous devriez pouvoir demander chacune par son nom, à la personne ou à l’entreprise qui gère votre Microsoft 365, et obtenir des réponses datées et écrites. - Étape 1 — Répertoriez chaque application connectée à votre locataire Microsoft 365. Examinez les applications d’entreprise dans le centre d’administration Microsoft Entra. Si personne ne peut produire cette liste, c’est votre premier constat. - Étape 2 — Notez ce que chaque application est autorisée à faire. Signalez les autorisations larges dont une application n’a peut-être pas besoin — la lecture/écriture à l’échelle du locataire pour le courriel, les fichiers ou l’annuaire est le profil à remettre en question. - Étape 3 — Examinez les ouvertures de session des applications, pas seulement celles des utilisateurs. Recherchez les ouvertures de session de principaux de service provenant d’adresses IP inconnues. Si une application ConnectWise est ou était connectée à votre locataire, suivez les directives de ConnectWise pour examiner l’activité et les changements en remontant au moins jusqu’au 13 octobre 2026. - Étape 4 — Vérifiez les identifiants ou les rôles ajoutés récemment. La technique signalée comprenait l’ajout de nouveaux identifiants à des applications pour maintenir l’accès. Tout secret d’application, certificat ou rôle d’administrateur que votre équipe ne reconnaît pas exige une explication écrite. - Étape 5 — Activez le flux de consentement administrateur. Le personnel ne devrait pas pouvoir accorder à des applications tierces l’accès aux données de l’entreprise de son propre chef; les nouvelles autorisations devraient exiger l’approbation délibérée d’un administrateur. - Étape 6 — Retirez les intégrations dormantes. Les anciens essais, les outils retirés et les applications d’un fournisseur précédent restent souvent connectés pendant des années. Si ce n’est pas utilisé, déconnectez-le — un accès permanent que personne ne surveille est exactement le risque que cet incident a exposé. - Étape 7 — Posez cinq questions simples à votre fournisseur de sauvegarde. Comment les identifiants des applications sont-ils stockés? Quelles autorisations votre application détient-elle dans notre locataire — la liste complète, pas un résumé? À quelle vitesse nous aviseriez-vous d’un incident? Quel est l’état actuel de votre service? Et que devrions-nous examiner dans notre propre locataire cette semaine? - Étape 8 — Confirmez que vous pouvez restaurer pendant que votre service de sauvegarde est en panne. Pendant cet incident, la suspension a mis en pause les sauvegardes planifiées et interrompu l’accès aux restaurations. Connaissez votre deuxième voie : un export distinct, une deuxième copie ou une procédure manuelle documentée pour vos données les plus critiques. - Étape 9 — Testez réellement une restauration, et approuvez-la. Choisissez une boîte courriel et un dossier SharePoint; restaurez-les à un emplacement de test, et consignez qui l’a vérifié et quand. Une sauvegarde qui n’a jamais été restaurée est un espoir, pas un contrôle. (Notre [liste de contrôle de migration cloud](https://amensecurity.ca/fr/blog/cloud-migration-checklist) fait le même constat.) - Étape 10 — Décidez de vos formalités en cas d’atteinte avant d’en avoir besoin. En vertu de la LPRPDE (PIPEDA), une atteinte présentant un risque réel de préjudice grave entraîne des obligations de déclaration et de tenue de registres. Écrivez dès maintenant qui prend cette décision, où les registres sont conservés et qui sont vos ressources externes. Voir aussi nos [services de cybersécurité](https://amensecurity.ca/fr/services/cybersecurity). Les questions que les propriétaires posent sans cesse La conservation intégrée de Microsoft 365 suffit-elle, ou ai-je besoin d’une sauvegarde distincte? Pour la plupart des PME, la conservation seule n’est pas une sauvegarde. La conservation aide pour les suppressions accidentelles et certains besoins de conformité, mais elle vit à l’intérieur du même locataire — pas une copie indépendante que vous contrôlez. Une sauvegarde distincte vous donne cette copie, et cet incident ajoute un devoir : auditer l’accès que cette sauvegarde détient. À quelle fréquence les sauvegardes devraient-elles être testées, et qui devrait approuver le test? Testez selon un calendrier défendable — trimestriel est un rythme raisonnable pour une entreprise de 30 à 80 personnes — et après tout changement majeur à votre configuration. L’approbation devrait venir d’une personne nommée, avec un registre daté de ce qui a été restauré. Si votre fournisseur effectue les tests, demandez à voir le registre. Quels paramètres de sécurité Microsoft 365 devraient être activés par défaut? Commencez par le contrôle au cœur de cet incident : le consentement aux applications. Exigez l’approbation d’un administrateur pour les nouvelles autorisations d’applications, examinez les applications déjà dans votre locataire et faites examiner les journaux d’ouverture de session — y compris ceux des applications. L’authentification multifacteur pour chaque utilisateur reste importante; elle ne suffit simplement plus à elle seule. La LPRPDE exige-t-elle de déclarer une atteinte à la protection des données, et dans quel délai? En général : si une atteinte touchant des renseignements personnels présente un risque réel de préjudice grave, elle doit être déclarée au Commissariat à la protection de la vie privée du Canada et les personnes concernées doivent être avisées, dès que possible — et les registres de toute atteinte doivent être conservés pendant 24 mois. Il s’agit d’information générale, pas d’un avis juridique. Vous ne pourrez pas respecter ces délais si l’étape 10 n’a pas été réfléchie à l’avance. Le constat honnête Rien dans cet incident ne plaide contre la sauvegarde infonuagique. Il plaide contre la confiance non examinée. Les entreprises qui traversent bien un incident de chaîne d’approvisionnement sont celles qui peuvent répondre vite à des questions simples : qu’est-ce qui est connecté à notre locataire, à quoi cela peut-il accéder, quand avons-nous restauré pour la dernière fois, et qui vérifie? Si vous souhaitez un deuxième regard sur cette liste pour votre propre locataire, notre [évaluation gratuite](https://amensecurity.ca/fr/contact) est un point de départ pratique — apportez votre inventaire d’applications, ou demandez-nous de le dresser avec vous. ## Sujet : Cybersécurité et conformité - [Guide principal](https://amensecurity.ca/fr/services/cybersecurity.md) - [TI gérées ou dépannage à la demande : comparaison côte à côte](https://amensecurity.ca/fr/guides/msp-vs-break-fix.md) --- Source page: https://amensecurity.ca/fr/blog/microsoft-365-backup-security-checklist Markdown version for AI agents · Amen Security Email: info@amensecurity.ca Phone: +1 (204) 514-3536