Qubole : quand des accès cloud oubliés exposent vos anciens clients au vol de données

L'affaire Qubole en bref

Le 9 novembre 2026, Le Monde Informatique révélait une campagne d'attaques observée entre le 14 et le 26 octobre 2026 : des cybercriminels ont détourné des accès AWS liés à Qubole, une plateforme de traitement de données, pour voler des secrets et des données chez plusieurs entreprises clientes. Le détail le plus intéressant de cette histoire n'est pas tant la technique utilisée que la cause racine du problème : certaines des entreprises touchées avaient abandonné Qubole depuis longtemps sans jamais révoquer les autorisations qu'elles lui avaient accordées sur leur infrastructure cloud.

Autrement dit, des sociétés qui pensaient ne plus avoir aucun lien avec ce prestataire se sont retrouvées exposées des mois, voire des années après avoir cessé de l'utiliser. La porte n'avait simplement jamais été fermée à clé.

Pourquoi ce scénario n'est pas réservé aux grands comptes

On pourrait se dire que ce genre d'incident ne concerne que des infrastructures cloud complexes, loin du quotidien d'une TPE ou d'une PME. C'est une erreur. Le mécanisme qui a permis cette attaque — des autorisations techniques accordées à un prestataire, puis jamais nettoyées — est en réalité extrêmement courant dans les petites structures, pour trois raisons simples :

• La multiplication des outils SaaS. CRM, ERP, plateforme e-commerce, outil d'emailing, logiciel de facturation, extension marketing... une PME utilise aujourd'hui facilement une vingtaine d'outils connectés entre eux, souvent via des API ou des comptes OAuth.
• Le turnover des prestataires. Une agence web change, un freelance termine sa mission, un développeur quitte l'entreprise : chacun a potentiellement eu accès à des comptes cloud, des hébergements, des interfaces d'administration.
• L'absence de responsable clairement désigné. Dans beaucoup de PME, personne n'a officiellement la mission de faire le "off-boarding technique" : révoquer les accès d'un outil ou d'un prestataire quand la collaboration se termine. Le sujet tombe entre deux chaises, entre le service informatique (s'il existe) et la direction.

Résultat : des accès techniques s'accumulent au fil des années, sans que personne ne fasse jamais le ménage. Et comme le montre le cas Qubole, il suffit qu'un seul de ces accès oubliés soit compromis chez le prestataire pour que ses anciens clients se retrouvent exposés, parfois sans même en avoir conscience.

Les types d'accès qui restent trop souvent actifs

Quand on parle d'"accès oubliés", il ne s'agit pas d'un concept abstrait. Voici les catégories les plus fréquentes, que l'on retrouve dans la quasi-totalité des audits techniques :

Les clés API

Une clé API donne à un outil tiers le droit d'interroger ou de modifier des données dans votre système : votre boutique en ligne, votre CRM, votre hébergement cloud. Ces clés sont souvent générées une fois lors de l'intégration, puis plus jamais revues — même quand l'outil en question n'est plus utilisé.

Les tokens OAuth

Quand vous autorisez une application à se connecter "avec votre compte Google" ou "avec votre compte Microsoft", vous générez un token OAuth qui reste valide tant qu'il n'est pas explicitement révoqué. Un ancien outil marketing peut ainsi garder un accès en lecture, voire en écriture, à votre messagerie ou à votre Drive des années après sa désinstallation.

Les comptes de service

Ce sont des comptes techniques, souvent créés par un prestataire pour automatiser des tâches (synchronisation de données, sauvegardes, déploiements). Ils échappent généralement aux audits classiques parce qu'ils n'apparaissent pas dans l'annuaire des utilisateurs humains.

Les webhooks

Un webhook est une notification automatique envoyée par votre système vers une URL externe à chaque événement (nouvelle commande, nouveau formulaire rempli, etc.). Si l'outil destinataire a disparu, le webhook continue parfois d'envoyer des données vers une adresse qui n'est plus sous contrôle.

Les accès admin d'anciens freelances ou agences

C'est probablement le cas le plus répandu en PME : un développeur ou une agence ayant travaillé sur le site, l'hébergement ou les outils internes conserve un compte administrateur actif longtemps après la fin de la mission, simplement parce que personne n'a pensé à le désactiver.

Checklist : auditer et révoquer les accès tiers

La bonne nouvelle, c'est que ce risque se corrige avec de la méthode, pas forcément avec un gros budget. Voici une checklist simple à appliquer de manière récurrente dans votre entreprise.

À faire tous les trimestres

• Lister tous les outils SaaS et intégrations actuellement connectés à votre système d'information (site web, hébergement, messagerie, CRM, ERP, boutique en ligne).
• Vérifier la liste des applications tierces autorisées dans les paramètres de sécurité de vos comptes Google Workspace, Microsoft 365 et de votre hébergement cloud.
• Passer en revue les clés API actives sur votre hébergement, votre boutique en ligne et vos outils métier : à quoi servent-elles encore, qui les utilise réellement ?
• Identifier les comptes administrateurs existants et vérifier qu'ils correspondent tous à des personnes ou prestataires encore actifs.

À faire systématiquement à la fin d'un contrat

• Révoquer immédiatement tous les accès du prestataire ou freelance sortant : comptes admin, FTP, base de données, hébergement, outils tiers.
• Changer les mots de passe partagés auxquels il avait accès.
• Régénérer les clés API qu'il aurait pu créer ou consulter.
• Désactiver les webhooks ou intégrations qu'il avait mis en place, sauf s'ils sont documentés et toujours nécessaires.

Bonnes pratiques à mettre en place durablement

Au-delà de l'audit ponctuel, quelques réflexes réduisent fortement ce type de risque sur le long terme :

• Un gestionnaire de secrets. Plutôt que de laisser des clés API traîner dans des fichiers de configuration ou des messages Slack, centralisez-les dans un outil dédié qui trace qui y a accès et quand.
• Le principe du moindre privilège. Un prestataire ou un outil tiers ne devrait avoir accès qu'au strict nécessaire pour faire son travail, jamais à l'ensemble de votre infrastructure par facilité.
• La rotation régulière des clés. Changer périodiquement les clés API et tokens, même actifs, limite la durée de vie d'un accès compromis qui n'aurait pas encore été détecté.
• Une clause contractuelle de révocation. Tout contrat avec un prestataire technique devrait prévoir explicitement que les accès sont révoqués à la fin de la mission, et préciser qui en a la responsabilité.

Comment intégrer ce sujet dans un contrat de maintenance

Chez YouOnline, cette logique d'audit des accès tiers fait partie des sujets que nous abordons avec nos clients dans le cadre d'un accompagnement sur la durée. Concrètement, cela passe par un inventaire initial des accès et intégrations existants, une revue régulière pour repérer ce qui n'est plus utilisé, et une procédure claire de révocation à chaque fin de collaboration avec un outil ou un prestataire — y compris le nôtre, le jour où la relation s'arrête.

L'affaire Qubole rappelle une vérité simple : la sécurité d'une entreprise ne dépend pas seulement de ses propres outils, mais aussi de tous les accès qu'elle a accordés au fil du temps, parfois pour une intégration devenue inutile depuis longtemps. Faire le ménage régulièrement dans ces autorisations techniques coûte beaucoup moins cher qu'une fuite de données découverte après coup.

Source : Le Monde Informatique — Qubole : des accès cloud oubliés exposent les entreprises au vol de données