Risque tiers : leçons de Qubole, Fireworks AI et SEGA

Ce qui s’est passé

Trois incidents récents ont un point commun. Aucune des organisations touchées n’a été attaquée directement au départ. C’est un fournisseur de confiance qui a servi de porte d’entrée, ou dont le système a laissé fuir les données.

Qubole : un accès AWS « de confiance » détourné

Des pirates ont exploité l’accès AWS de confiance dont disposait Qubole (une plateforme d’analyse de données en infonuagique) pour pénétrer dans les comptes de ses clients et y voler des données. Pour fonctionner, ce type de service reçoit souvent un accès entre comptes (cross-account access : une autorisation qui permet au compte AWS du fournisseur d’agir dans le compte AWS du client). Une fois cet accès détourné, l’attaquant hérite des permissions accordées au fournisseur. Si vous utilisez ce service, consultez les avis du fournisseur pour obtenir les détails techniques (vecteur initial, comptes touchés, indicateurs de compromission).

Fireworks AI : une nouvelle fuite après le piratage d’un fournisseur infonuagique

Fireworks AI (une plateforme de services d’intelligence artificielle) a annoncé une nouvelle fuite de données, cette fois à la suite du piratage d’un de ses propres fournisseurs infonuagiques. C’est donc un risque de quatrième partie (le fournisseur de votre fournisseur) : le client final subit un incident né deux niveaux plus loin dans la chaîne d’approvisionnement.

SEGA : 2,2 millions d’adresses courriel exposées via l’infolettre

Une fuite liée au système d’infolettre de SEGA a exposé 2,2 millions d’adresses courriel. Les outils d’envoi d’infolettres sont souvent gérés par une plateforme externe spécialisée. Ils contiennent pourtant l’une des listes les plus sensibles d’une entreprise : ses clients et ses prospects.

Pourquoi ça compte pour une PME

Une PME québécoise utilise en moyenne des dizaines de services externes : comptabilité en ligne, CRM (logiciel de gestion des relations clients), infolettre, hébergeur web, sauvegarde infonuagique, outils d’IA, prestataire TI. Chacun garde une partie de vos données ou a un accès à vos systèmes. Ces trois incidents en tirent trois leçons concrètes.

• Un accès de confiance donne les mêmes pouvoirs à l’attaquant. Si votre fournisseur peut lire tous vos compartiments de stockage (buckets S3), l’attaquant qui le compromet le peut aussi. Le risque dépend directement de l’étendue des permissions que vous avez accordées.
• Vous ne voyez pas toute la chaîne. Le cas Fireworks AI montre que la faille peut venir d’un sous-traitant de votre sous-traitant, que vous ne connaissez même pas.
• Une simple liste de courriels a de la valeur. Une liste de clients exposée alimente l’hameçonnage ciblé (faux courriels qui imitent votre entreprise pour piéger vos clients). Votre réputation est touchée, même si la faute vient du fournisseur.

Le volet légal : la Loi 25 vous rend responsable

Au Québec, la Loi 25 (qui a modernisé la Loi sur la protection des renseignements personnels dans le secteur privé) est claire : si un fournisseur traite des renseignements personnels pour vous, vous en restez responsable. Une fuite chez ce sous-traitant est un incident de confidentialité que vous devez gérer. Concrètement :

• prendre des mesures raisonnables pour réduire le risque de préjudice et éviter que l’incident se reproduise ;
• inscrire l’incident à votre registre des incidents de confidentialité, obligatoire même pour les incidents mineurs ;
• si l’incident présente un risque de préjudice sérieux, aviser avec diligence la Commission d’accès à l’information (CAI) et les personnes concernées ;
• le contrat avec un fournisseur qui reçoit des renseignements personnels doit être écrit et prévoir des mesures de protection de ces renseignements ;
• si les données sont hébergées ou traitées hors du Québec (fréquent avec les services infonuagiques), une évaluation des facteurs relatifs à la vie privée (EFVP : analyse des risques pour la vie privée avant de transférer les données) est exigée.

Comment se protéger

Priorité 1 — Cartographier vos fournisseurs (cette semaine)

Vous ne pouvez pas protéger ce que vous ne connaissez pas. Dressez un inventaire simple, dans un tableur, avec au minimum :

• le nom du fournisseur et le service rendu ;
• les données auxquelles il a accès (renseignements personnels ? financiers ? santé ?) ;
• les accès dont il dispose : compte utilisateur, compte de service (compte technique utilisé par une application, sans humain derrière), clé d’API (mot de passe technique qui permet à un logiciel d’en appeler un autre), rôle AWS entre comptes, accès à distance ;
• le lieu d’hébergement des données (Québec, Canada, étranger) ;
• l’existence d’un contrat écrit avec des clauses de sécurité ;
• la personne responsable chez vous et le contact sécurité chez le fournisseur.

En pratique ITIL, cet inventaire alimente la gestion des fournisseurs et la gestion des configurations. Classez chaque fournisseur selon son niveau de risque (critique, élevé, moyen, faible) pour savoir par où commencer.

Priorité 2 — Réduire les accès au strict nécessaire (sous 30 jours)

Appliquez le principe du moindre privilège : chaque fournisseur reçoit uniquement les permissions indispensables à sa mission, et rien de plus.

• Rôles AWS entre comptes : limitez chaque rôle aux ressources précises (un compartiment S3 donné, et non tous). Exigez un ExternalId (identifiant secret partagé avec le fournisseur, qui empêche un tiers d’utiliser le rôle à sa place).
• Clés d’API : une clé par fournisseur et par usage, avec des droits limités (lecture seule si possible). Ne partagez jamais une clé administrateur.
• Comptes de service : ne réutilisez jamais un compte humain pour un fournisseur. Désactivez l’accès dès la fin du contrat.
• Données envoyées aux services d’IA : n’envoyez que le minimum. Retirez ou masquez les renseignements personnels lorsque c’est possible.

Exemple de politique de confiance AWS pour un rôle fournisseur, avec ExternalId obligatoire :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::<ID_COMPTE_FOURNISSEUR>:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "<VALEUR_SECRETE_UNIQUE>" }
      }
    }
  ]
}

Pour repérer les rôles de votre compte AWS qui font confiance à des comptes externes :

aws iam list-roles \
  --query "Roles[].{Role:RoleName,Trust:AssumeRolePolicyDocument.Statement[].Principal.AWS}" \
  --output json

Le service IAM Access Analyzer d’AWS peut aussi signaler automatiquement les ressources partagées avec des entités externes.

Priorité 3 — Détecter une utilisation anormale des accès tiers

• Activez AWS CloudTrail (journal de toutes les actions faites dans votre compte AWS) dans toutes les régions, et conservez les journaux dans un compte séparé.
• Surveillez les événements AssumeRole qui viennent de comptes fournisseurs : heures inhabituelles, nouvelles adresses IP, accès à des ressources que le fournisseur n’utilise jamais, téléchargements massifs.
• Activez Amazon GuardDuty (service de détection des menaces d’AWS) si ce n’est pas déjà fait.

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
  --max-results 50

Si vous utilisez l’un des services cités dans ces incidents, consultez les avis du fournisseur pour obtenir les indicateurs de compromission précis. Cherchez-les ensuite dans vos journaux.

Priorité 4 — Faire tourner vos secrets régulièrement

Un secret (mot de passe, clé d’API, clé d’accès AWS, jeton) qui ne change jamais reste utilisable indéfiniment s’il a été volé.

• Fixez une durée de vie maximale : par exemple 90 jours pour les clés d’API et les clés d’accès AWS.
• Faites une rotation immédiate de tous les secrets partagés avec un fournisseur dès qu’il annonce un incident.
• Stockez les secrets dans un coffre-fort numérique (AWS Secrets Manager, Azure Key Vault, gestionnaire de mots de passe d’entreprise), jamais dans un courriel ou un fichier partagé.
• Préférez les rôles temporaires aux clés d’accès permanentes lorsque c’est possible.

Pour repérer les clés d’accès AWS anciennes, générez le rapport des identifiants :

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d

En pratique ITIL, chaque rotation est un changement standard : il est préapprouvé, documenté et planifié pour éviter de couper un service en production.

Priorité 5 — Intégrer la sécurité aux contrats

Pour chaque fournisseur à risque élevé ou critique, le contrat devrait prévoir :

• l’obligation de vous aviser rapidement de tout incident touchant vos données, avec un délai précis (par exemple 24 à 72 heures) ;
• la liste de ses propres sous-traitants qui traitent vos données, et l’obligation de vous informer de tout changement ;
• les mesures de sécurité minimales : chiffrement, authentification multifacteur (MFA : un deuxième facteur en plus du mot de passe), journalisation ;
• le lieu d’hébergement des données ;
• la suppression ou la restitution des données à la fin du contrat ;
• la fourniture d’attestations de sécurité (rapport SOC 2, ISO 27001) lorsqu’elles existent.

Priorité 6 — Préparer votre réponse à un incident chez un fournisseur

Quand un fournisseur annonce une fuite, ouvrez un incident dans votre processus de gestion des incidents, comme si l’attaque vous visait directement :

1. Qualifier : quelles données et quels accès ce fournisseur détenait-il chez vous ? Votre inventaire de la priorité 1 donne la réponse en quelques minutes.
2. Contenir : suspendez ou restreignez l’accès du fournisseur, et faites la rotation de tous les secrets partagés.
3. Enquêter : analysez vos journaux (CloudTrail, connexions, exports) sur la période concernée.
4. Documenter : inscrivez l’incident au registre exigé par la Loi 25.
5. Évaluer le préjudice : avec votre responsable de la protection des renseignements personnels, déterminez s’il existe un risque de préjudice sérieux. Si c’est le cas, avisez la CAI et les personnes concernées.
6. Prévenir l’hameçonnage : si des courriels clients ont fuité, comme dans le cas SEGA, prévenez vos clients que de faux messages pourraient imiter votre entreprise.
7. Corriger durablement : en gestion des problèmes ITIL, réévaluez les accès et le contrat de ce fournisseur.

Qui alerter

• À l’interne : la direction, le responsable de la protection des renseignements personnels (par défaut, la personne ayant la plus haute autorité dans l’entreprise) et le responsable TI ou votre prestataire TI.
• À l’externe : la Commission d’accès à l’information si le risque de préjudice est sérieux, votre assureur cyber si vous en avez un, et le Centre canadien pour la cybersécurité pour signaler l’incident.