Sécuriser les systèmes de recommandation contre l’empoisonnement

Sécuriser les systèmes de recommandation contre l’empoisonnement

Un système de recommandation transforme des traces de consultation, d’achat, de recherche ou de clic en décisions d’affichage, de classement ou de ciblage. Cette chaîne est une surface d’attaque à part entière : modifier le signal suffit souvent à modifier la décision, sans compromettre le modèle ni son infrastructure.

Explication de la marmotte

Un système de recommandation ressemble à un disquaire qui observe les choix des clients pour décider quels albums mettre en vitrine. Si quelqu’un truque les fiches de vente ou se fait passer pour cent clients différents, la vitrine finit par promouvoir ce qui arrange le tricheur plutôt que ce qui intéresse réellement les visiteurs.

→ Lire l’explication complète de la marmotte

Signaux comportementaux : l’intégrité avant la fraîcheur

Le compromis central est brutal : plus le système prend en compte les événements récents, plus il personnalise vite, mais plus un attaquant peut déplacer son résultat vite. La recommandation à très faible latence est rarement justifiée pour des actions à impact commercial, éditorial ou de sécurité. Le choix défendable consiste à séparer les signaux immédiats, réservés à une personnalisation réversible, des signaux consolidés qui alimentent les modèles et les classements durables.

Un événement comportemental doit porter au minimum : un identifiant d’événement non prédictible, un horodatage émis côté serveur, l’identité authentifiée ou un niveau de confiance de session, la source d’émission, l’objet concerné et une preuve d’intégrité. Un clic déclaré exclusivement par le navigateur n’est pas une preuve d’intérêt. C’est une déclaration non vérifiée, ce qui est très différent malgré les slides qui appellent cela de la « donnée first party ».

Le serveur doit lier l’événement à une action observable : réponse HTTP rendue, ressource effectivement demandée, transaction validée ou durée de consultation cohérente. Cette corrélation ne transforme pas chaque clic en vérité mathématique, mais elle augmente le coût d’un empoisonnement automatisé. Sans cette liaison, un script peut produire des milliers de signaux valides au sens du format, absurdes au sens du produit, et néanmoins parfaitement appétissants pour un algorithme.

La bonne architecture maintient une provenance par événement, pas seulement par agrégat. Une moyenne de note sans la liste des contributions vérifiables interdit d’exclure une campagne malveillante après coup. La suppression logique d’événements identifiés, suivie d’un recalcul déterministe des profils et des index, doit être prévue avant le premier modèle. Sinon, le système sait qu’il a été contaminé mais ne sait pas se décontaminer. C’est une position philosophique assez faible pour un service qui pilote des décisions.

Les flux événementiels doivent être conçus avec les mêmes exigences que les autres traitements asynchrones : idempotence, ordre partiel explicite, rétention, rejeu contrôlé et schémas versionnés. La page sur l’architecture événementielle couvre les contraintes de transport ; ici, l’exigence supplémentaire est de préserver la capacité d’attribuer et de retirer un signal.

Manipulation de profil et empoisonnement de recommandation

La manipulation de profil cible un compte ou un navigateur afin de modifier ses recommandations : consultations forcées, recherche injectée, ajout au panier automatisé, vol de session ou scripts exécutés dans une page compromise. L’empoisonnement collectif, souvent nommé shilling, cherche au contraire à augmenter ou diminuer la visibilité d’un objet en créant de nombreux profils et interactions artificielles.

Les attaques Sybil reposent sur une multiplication d’identités apparentes. Leur défense ne consiste pas à ajouter un CAPTCHA partout, ce qui transforme surtout les utilisateurs légitimes en opérateurs de saisie de panneaux routiers. Il faut attribuer une confiance graduée aux identités : ancienneté du compte, preuve de contrôle d’un canal, cohérence d’usage, réputation de l’émetteur, vitesse de création et diversité réelle des interactions.

Un modèle de détection doit aussi regarder la structure du graphe comportemental. Une grappe de comptes qui consulte les mêmes objets dans le même ordre, depuis des environnements proches, puis disparaît, est un signal de campagne. La règle doit porter sur la similarité temporelle et contextuelle, jamais sur une seule adresse réseau : une sortie d’entreprise, un réseau mobile ou un établissement scolaire peuvent légitimement concentrer des utilisateurs.

Les attaques par injection de contenu empoisonnent le signal sans créer de faux comptes. Un titre optimisé pour déclencher des clics, des métadonnées mensongères ou un contenu redirigeant peuvent obtenir une forte exposition, puis réinjecter cette exposition comme preuve de pertinence. Les champs éditoriaux et les attributs utilisés comme caractéristiques de classement doivent donc provenir d’une chaîne de publication authentifiée et journalisée. Une modification de métadonnées doit déclencher une nouvelle évaluation, pas hériter silencieusement de la réputation de la version précédente.

Les systèmes fondés sur l’apprentissage en ligne sont les plus exposés. Une mise à jour incrémentale applique immédiatement les nouveaux signaux, ce qui réduit le délai de réaction mais ouvre une boucle de rétroaction : le contenu promu reçoit plus d’interactions, ces interactions justifient sa promotion, puis le classement finit par applaudir sa propre décision. Pour les objets à risque, préférer des mises à jour par lots, avec fenêtre d’observation, détection d’anomalies et seuil de confiance. La fraîcheur perd quelques minutes ou quelques heures ; l’intégrité ne se récupère pas avec un redémarrage.

Contrôles d’accès et séparation des plans de décision

Trois plans doivent être séparés : la collecte des événements, le calcul des profils et la diffusion des recommandations. Une compromission du plan de collecte ne doit pas donner un accès d’écriture aux index de diffusion. Une compromission du service de diffusion ne doit pas permettre de réentraîner un modèle. Cette séparation impose des identités de service distinctes, des permissions minimales et des journaux d’audit inviolables.

L’authentification interservices par Transport Layer Security mutuel (mTLS) limite l’usurpation de service, mais ne garantit pas que le service authentifié produit des événements honnêtes. Une clé cliente volée signe avec beaucoup d’assurance, ce qui est précisément son métier. La protection doit donc combiner identité technique, limitation de débit, validation métier et détection statistique.

Les clés de signature ou de code d’authentification de message doivent être stockées dans un KMS (Key Management Service) ou dans un HSM (Hardware Security Module) lorsque la criticité impose que la clé ne sorte pas sous forme exportable. La rotation doit accepter deux clés actives : une pour vérifier les événements produits avant la bascule, une pour signer les nouveaux. Révoquer brutalement une clé casse les producteurs retardataires ; accepter indéfiniment l’ancienne transforme la rotation en décoration murale.

L’accès humain aux outils de modération, de correction de profils et de déclenchement de recalcul doit être fédéré, à privilèges séparés et journalisé. La capacité à exclure un signal est un pouvoir de modification du classement. Elle mérite donc une approbation à deux personnes pour les opérations globales, une traçabilité de motif et un mécanisme d’annulation. Les fondations d’identité restent pertinentes ici : le compte administrateur le mieux protégé ne compense pas une autorisation trop large.

Exemple : validation et signature d’un événement de consultation

L’exemple suivant produit un événement signé avec un secret injecté dans l’environnement, puis refuse les horodatages trop éloignés. Il s’exécute avec Python 3, sans dépendance externe. En production, remplacer la variable d’environnement par un accès court au KMS et conserver la clé hors des journaux.

#!/usr/bin/env python3
# Exécuter : EVENT_HMAC_KEY='octets-secrets-aleatoires' python3 event.py
import hashlib
import hmac
import json
import os
import time
import uuid

key = os.environ["EVENT_HMAC_KEY"].encode()
event = {
    "event_id": str(uuid.uuid4()),       # Identifiant unique pour l'idempotence
    "subject_id": "account:42",          # Identité déjà authentifiée côté serveur
    "object_id": "content:873",
    "action": "view",
    "issued_at": int(time.time()),       # Horodatage côté serveur
    "source": "recommendation-api",
}

payload = json.dumps(event, sort_keys=True, separators=(",", ":")).encode()
event["signature"] = hmac.new(key, payload, hashlib.sha256).hexdigest()

# Vérification avant admission dans le flux de signaux.
received = event.copy()
signature = received.pop("signature")
canonical = json.dumps(received, sort_keys=True, separators=(",", ":")).encode()
assert hmac.compare_digest(signature, hmac.new(key, canonical, hashlib.sha256).hexdigest())
assert abs(time.time() - received["issued_at"]) <= 300  # Rejeter les événements rejoués
print(json.dumps(event))

Cette signature garantit l’intégrité entre producteurs autorisés et collecteur. Elle ne garantit ni la sincérité de l’action, ni l’absence de robot derrière un compte légitime. Le contrôle de rejeu dépend aussi d’un registre persistant des event_id sur la fenêtre d’acceptation. Sans ce registre, un événement parfaitement signé peut être répété jusqu’à rendre sa signature très enthousiaste.

Supervision, retrait de signal et reprise contrôlée

La supervision doit mesurer des distributions, pas uniquement la disponibilité des services : taux d’événements par identité, diversité des objets consultés, concentration par objet, délai entre création de compte et action, part des signaux rejetés et divergence entre données brutes et données admises. Un tableau de bord qui affiche seulement la latence du moteur confirme que le moteur tourne. Il ne confirme pas qu’il réfléchit à autre chose qu’à une campagne de fraude.

Les alertes doivent comparer des fenêtres temporelles homogènes et des segments comparables. Un pic global peut venir d’une campagne légitime ; un pic concentré sur un objet, un pays, une version de client ou une cohorte fraîchement créée mérite une quarantaine. Les règles de quarantaine doivent marquer les événements, jamais les détruire immédiatement. L’investigation exige la donnée brute, avec des durées de conservation définies et des accès restreints.

La reprise doit pouvoir reconstruire un état de recommandation depuis un instant de confiance : instantané des profils, journal d’événements signé, version exacte du code de transformation et version du modèle. Sauvegarder seulement le modèle est insuffisant, car la source empoisonnée reste disponible pour le réentraîner. Les artefacts de calcul doivent être immuables et traçables dans la chaîne décrite par les pratiques de gestion de code et d’intégration continue.

Le mécanisme ne garantit pas la neutralité éditoriale, l’absence de biais statistique, la qualité intrinsèque d’un contenu ni la conformité d’un traitement de données personnelles. Ces sujets exigent une gouvernance des données, des critères métier documentés et un contrôle humain. La sécurité protège l’intégrité du processus déclaré ; elle ne rend pas juste une politique de classement discutable.

🐝 Ce qui arrive si on s’en passe

Sans confiance graduée des identités ni provenance par événement, les faux profils ne servent pas seulement à promouvoir un contenu : ils deviennent un instrument de lecture. Un attaquant qui crée quelques comptes calqués sur l’historique connu d’une cible, puis observe les listes de type « consulté aussi » ou « acheté ensemble », peut isoler les co-occurrences produites par cette seule personne et en déduire ses consultations ou achats récents. Le moteur publie alors des données individuelles sous forme d’agrégat. Sans séparation entre signaux immédiats et consolidés, chaque injection produit un effet visible en quelques minutes, ce qui permet de tester à faible coût quels signaux pèsent le plus dans le classement et d’ajuster la campagne avant qu’une alerte statistique ne se déclenche.

🦫 Explication de la marmotte 🍫

Un système de recommandation enregistre des actions : consulter une page, chercher un produit, regarder une vidéo ou acheter un article. Il utilise ensuite ces actions pour estimer ce qui pourrait intéresser une personne et choisir ce qui sera affiché. Le problème apparaît quand les actions enregistrées ne représentent plus un comportement réel.

Une personne malveillante peut créer beaucoup de comptes, faire semblant de s’intéresser toujours au même contenu ou envoyer de fausses actions depuis un programme. Elle peut aussi prendre le contrôle d’un compte existant et modifier peu à peu ses préférences. Si le système accepte ces données sans contrôle, il donne davantage de place au contenu manipulé. Cette visibilité produit de nouvelles interactions, puis le système prend ces interactions pour une confirmation. L’erreur se nourrit alors elle-même.

La protection commence par vérifier d’où vient chaque action, quand elle a été produite et si elle correspond à une activité réellement observée. Les actions trop rapides, répétées ou regroupées de façon inhabituelle sont mises à l’écart. Elles ne doivent pas modifier immédiatement les décisions durables.

Il faut aussi conserver l’historique permettant de retirer les fausses actions et de recalculer les préférences. Si cet historique manque, supprimer un compte frauduleux ne retire pas forcément son influence passée. Enfin, les clés utilisées pour prouver l’origine des messages, les sauvegardes et les alertes doivent être gérées séparément du moteur qui affiche les recommandations.

À lire aussi

• Comment sécuriser Redis et Memcached distribuésArchitecture de mise en cache distribuée sécurisée avec Redis et Memcached, exposition réseau, authentification, empoisonnement et exploitation.
• Sécuriser les providers et state TerraformLes providers Terraform et le state d’infrastructure forment une surface de confiance critique qui exige audit, chiffrement, verrouillage et revue de plan.
• Qualité des données et erreurs silencieusesLa qualité des données devient un sujet de sécurité quand une erreur silencieuse modifie une décision, un droit ou une exposition sans déclencher d’alerte.
• Ce que « hébergé en France » garantitLa mention « hébergé en France » répond à la question de la localisation des disques, qui n'est presque jamais celle qui compte. Ce qui décide de la souveraineté réelle d'un service, c'est la juridiction du fournisseur, la maîtrise des clés, la chaîne des sous-traitants et le chemin par lequel on administre la plateforme.

Pages voisines

La citent

• Différence entre IA et LLM : un champ entier, un type de modèle
• Pourquoi le ML échoue à détecter les menaces

Sécuriser les systèmes de recommandation contre l’empoisonnement

Elle cite

• Architecture de journalisation d’audit immuable centralisée
• Principes et architecture de l'événementiel
• Sécuriser event sourcing et CQRS à grande échelle
• Comment contourner un rate limit par rotation d’en-têtes
• Intégration continue avec Git : automatiser vos workflows