Un contrat résilié ne signifie pas nécessairement un accès révoqué. Dans les systèmes d’information modernes, fournisseurs SaaS, prestataires et applications tierces disposent parfois d’autorisations étendues sur les données et services de l’entreprise. Lorsque la relation prend fin, certaines permissions techniques peuvent subsister.
L’incident impliquant ConnectWise Cloud Backup en octobre 2026 rappelle qu’une identité applicative légitime peut aussi devenir un vecteur d’attaque lorsqu’un identifiant est compromis. Comment identifier les accès tiers encore actifs et organiser leur révocation ?
Qu’est-ce qu’un accès tiers dans un système d’information ?
Un accès tiers est une autorisation accordée à un fournisseur, à un partenaire ou à une application externe pour interagir avec des ressources du SI. Il peut prendre plusieurs formes :
- Permissions OAuth : droits délégués à une application pour accéder à des ressources ;
- Comptes de service : identités techniques utilisées pour des traitements automatisés ;
- Clés API : identifiants permettant les échanges entre systèmes ;
- Secrets et certificats applicatifs : moyens d’authentification des applications ;
- Rôles administrateurs : privilèges élevés sur des ressources sensibles.
Ces mécanismes sont indispensables aux activités numériques. Leur multiplication rend toutefois difficile la réponse à une question pourtant simple : qui, en dehors de l’entreprise, peut encore lire ou modifier ses données ?
La dette d’autorisation : des droits qui survivent aux projets
Chaque déploiement SaaS, connexion CRM, outil RH ou projet de migration introduit de nouvelles identités et permissions. Quand une solution est remplacée ou qu’un projet s’arrête, ses autorisations ne sont pas toujours supprimées. Cette accumulation de droits historiques, parfois sans propriétaire clairement identifié, constitue une dette d’autorisation.
Le problème n’est pas seulement d’avoir accordé trop de droits au départ : c’est aussi de ne pas avoir organisé leur réévaluation et leur suppression au fil du temps.
ConnectWise Cloud Backup : un incident révélateur en octobre 2026
En octobre 2026, des chercheurs en cybersécurité ont documenté l’usage non autorisé d’un identifiant associé à l’application ConnectWise Cloud Backup (anciennement SkyKick Backup). Des connexions à des environnements Microsoft 365 ont été observées dès le 15 octobre 2026 depuis une infrastructure inhabituelle, avec obtention de jetons Microsoft Graph par l’identité de l’application.
Selon Huntress, des connexions non autorisées étaient confirmées dans 162 environnements clients au 16 octobre. Todyl a également décrit des authentifications applicatives effectuées sans utilisation d’un compte collaborateur.
Parce que l’application disposait déjà de permissions accordées dans les environnements concernés, la compromission de son identifiant créait un risque d’accès aux ressources autorisées. Cet incident ne prouve pas que les fournisseurs concernés étaient « anciens » ou que leurs contrats étaient terminés : il illustre plus largement le risque associé à des autorisations applicatives puissantes et persistantes.
Le point à retenir : la sécurité des données dépend aussi des identités non humaines auxquelles l’entreprise a accordé sa confiance.
Pourquoi un ancien fournisseur peut-il conserver des accès après son départ ?
La résiliation contractuelle est souvent pilotée par les achats, le juridique ou les métiers. La révocation des permissions dépend, quant à elle, de la DSI, des administrateurs cloud et des équipes de cybersécurité. Sans processus partagé, ces deux événements peuvent être dissociés.
Supprimer un compte utilisateur, débrancher une intégration ou désinstaller un logiciel ne garantit pas toujours l’effacement de tous les consentements OAuth, identités de service, clés, secrets et rôles associés. Certaines autorisations applicatives fonctionnent même sans session humaine active.
Permissions déléguées et permissions applicatives : une distinction essentielle
Dans Microsoft Entra ID, une application peut obtenir des permissions déléguées, utilisées dans le contexte d’un utilisateur connecté, ou des permissions applicatives, mobilisables directement par l’application. Ces dernières nécessitent une vigilance particulière lors des revues d’accès, notamment lorsqu’elles couvrent un périmètre étendu.
La documentation Microsoft Learn sur les permissions applicatives détaille les contrôles possibles.
Quels risques représentent les accès tiers non maîtrisés ?
- Exposition des données : lecture ou modification de fichiers, messages ou données métiers dans le périmètre autorisé.
- Privilèges excessifs : accès d’administration accordés au-delà du besoin réel.
- Persistance malveillante : exploitation de secrets ou d’identités techniques compromis pour maintenir un accès.
- Défaut de traçabilité : difficulté à rattacher une activité technique à un fournisseur et à un usage légitime.
- Risque de conformité : difficulté à justifier et démontrer les contrôles appliqués aux accès aux données.
Ces risques concernent aussi bien les fournisseurs sortants que les partenaires toujours actifs. L’objectif n’est donc pas de multiplier les suppressions indiscriminées, mais de maîtriser le cycle de vie des habilitations.
Comment auditer et sécuriser les accès tiers en cinq étapes ?
1. Cartographier les applications et identités techniques
Recenser les applications connectées, les fournisseurs associés, les comptes de service, les identités applicatives, les clés API ainsi que les secrets et certificats. L’inventaire doit inclure les environnements cloud et les intégrations historiques.
2. Identifier un propriétaire et une justification pour chaque accès
Chaque autorisation doit correspondre à un besoin métier actuel et à un responsable identifiable. Une permission sans propriétaire, ou rattachée à un contrat terminé, mérite une investigation prioritaire.
3. Évaluer les droits et hiérarchiser les risques
Comparer les permissions accordées au besoin réel, avec une attention renforcée aux droits d’écriture, aux privilèges d’administration et aux applications pouvant agir sans utilisateur connecté. Tenir compte de la sensibilité des données exposées.
4. Révoquer les autorisations obsolètes de manière contrôlée
Préparer la suppression des consentements OAuth, comptes techniques, attributions de rôles et identifiants inutiles. Vérifier au préalable les dépendances techniques pour éviter toute interruption d’activité, puis contrôler l’absence d’accès résiduel après l’opération.
5. Industrialiser les revues d’habilitations
Mettre en place des revues périodiques, des alertes sur les changements sensibles et des processus formalisés lors du changement de fournisseur. L’automatisation peut faciliter la détection des droits inutilisés, sans remplacer l’arbitrage métier et technique.
Intégrer la révocation des accès à l’offboarding fournisseur
L’offboarding fournisseur doit être traité avec la même rigueur que le départ d’un administrateur : la fin du contrat déclenche une série de contrôles documentés.
- Avant la sortie : recenser les accès et préparer les éventuelles migrations ou transferts de service.
- À la fin du contrat : révoquer ou désactiver les accès devenus inutiles selon un calendrier coordonné.
- Après la sortie : vérifier les permissions résiduelles, les identifiants encore valides et les connexions anormales.
- Dans la durée : conserver les preuves de clôture et améliorer les procédures de sortie.
Cette coordination suppose des responsabilités explicites entre achats, métiers, DSI, responsables IAM et cybersécurité. La réussite du contrôle dépend autant de la gouvernance que des outils.
De l’audit technique à une gouvernance durable des identités
La gestion des accès tiers ne peut pas reposer uniquement sur un nettoyage ponctuel. Une démarche pérenne combine trois leviers : la visibilité sur les identités et leurs propriétaires, le contrôle des privilèges et des usages, et la maîtrise du cycle de vie, de l’attribution à la révocation.
Pour les DSI et RSSI, l’enjeu est aussi organisationnel : relier les changements contractuels aux opérations de sécurité et suivre des indicateurs tels que le nombre d’accès sans propriétaire, les permissions sensibles ou le délai de révocation après une sortie fournisseur.
Comment le Groupe BBU accompagne la maîtrise des accès tiers
La sécurisation des accès tiers mobilise des compétences de cybersécurité, de gouvernance IT, d’organisation et de pilotage de la transformation. Dans cette perspective, le Groupe BBU peut accompagner la structuration d’une démarche adaptée au contexte de l’entreprise :
- Diagnostic des pratiques : analyse des processus existants de gestion des habilitations ;
- Cartographie et priorisation : identification des accès et situations à risque ;
- Amélioration des processus : définition des rôles, contrôles et étapes d’offboarding ;
- Pilotage des actions : feuille de route de remédiation, coordination et suivi des parties prenantes ;
- Gouvernance durable : indicateurs, revues périodiques et amélioration continue.
L’objectif : passer d’une gestion réactive des autorisations à un dispositif cohérent et mesurable, intégré aux opérations du SI.
FAQ : les questions fréquentes sur la gestion des accès tiers
Comment savoir si un ancien prestataire a encore accès à mon SI ?
Il faut rapprocher l’inventaire des fournisseurs et contrats de celui des applications, comptes de service, permissions OAuth et identités techniques. La revue des journaux de connexion et des autorisations aide à déterminer quels accès subsistent et sont utilisés.
Quelle différence entre supprimer un compte et révoquer une permission OAuth ?
Supprimer un compte agit sur l’identité concernée. Révoquer une permission OAuth retire une autorisation accordée à une application. Certaines permissions applicatives restent indépendantes d’une session utilisateur : elles nécessitent donc un contrôle distinct.
Comment auditer les applications tierces dans Microsoft Entra ID ?
Le centre d’administration Microsoft Entra permet d’inspecter les applications d’entreprise, leurs permissions et les journaux pertinents. La revue doit aussi porter sur les rôles administratifs, les identités de service et les secrets applicatifs.
À quelle fréquence faut-il revoir les habilitations ?
La fréquence dépend des risques et des exigences internes. Une revue périodique doit être complétée par des contrôles déclenchés à chaque changement de contrat, de fournisseur ou de périmètre, avec une surveillance renforcée des accès privilégiés.
Qui doit révoquer les accès d’un fournisseur ?
Le responsable métier confirme la fin du besoin et les équipes techniques assurent la révocation. Les achats et la cybersécurité contribuent au déclenchement, à la coordination et à la vérification du processus.
Conclusion : un contrat terminé ne doit pas laisser un accès ouvert
L’incident ConnectWise rappelle qu’une application de confiance peut devenir un vecteur d’attaque si son identité est compromise. Au-delà de cet événement, chaque organisation gagne à vérifier que les permissions accordées aux fournisseurs restent nécessaires, proportionnées et traçables.
Et si certains de vos anciens prestataires disposaient encore d’accès à votre SI ? Le Groupe BBU peut vous accompagner pour identifier les risques, renforcer la gouvernance des habilitations et structurer les actions de sécurisation.
Échangeons sur vos enjeux de cybersécurité et de gestion des accès tiers.
