---
id: CP-235
slug: honeypot-honeytoken-canarytokens
lang: fr
title: "Honeypots et honeytokens : des pièges pour repérer l'intrus"
description: "Serveur factice, faux document, fausse clé d'accès : ce que sont les leurres de sécurité, et ce que le salarié doit faire s'il en croise un."
canonical_url: https://startbrain.io/cyberpedia/fr/articles/honeypot-honeytoken-canarytokens/
markdown_url: https://startbrain.io/cyberpedia/fr/articles/honeypot-honeytoken-canarytokens.md
publisher: Brain (https://startbrain.io)
license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)
cite_as: "Brain, « Honeypots et honeytokens : des pièges pour repérer l'intrus », Cyberpedia, 2026. https://startbrain.io/cyberpedia/fr/articles/honeypot-honeytoken-canarytokens/ (CC BY 4.0)"
wing: 3
theme: browse_safely
reflex: cr-078
schema: G3
updated: "2026-11-03"
translations:
  fr: https://startbrain.io/cyberpedia/fr/articles/honeypot-honeytoken-canarytokens/
  en: https://startbrain.io/cyberpedia/en/articles/honeypot-honeytoken-canarytokens-traps/
  de: https://startbrain.io/cyberpedia/de/articles/honeypot-honeytoken-canarytokens-koeder/
  es: https://startbrain.io/cyberpedia/es/articles/honeypot-honeytoken-canarytokens-senuelos/
sources:
  - "n": 1
    title: honeypot - Glossary | CSRC
    publisher: NIST
    url: https://csrc.nist.gov/glossary/term/honeypot
    accessed: "2026-11-03"
  - "n": 2
    title: Building a Security Operations Centre (SOC)
    publisher: NCSC (Royaume-Uni)
    url: https://www.ncsc.gov.uk/collection/building-a-security-operations-centre
    published: "2022-05-23"
    accessed: "2026-11-03"
  - "n": 3
    title: "Unsecured Credentials: Credentials In Files, Sub-technique T1552.001 - Enterprise | MITRE ATT&CK®"
    publisher: MITRE ATT&CK
    url: https://attack.mitre.org/techniques/T1552/001/
    accessed: "2026-11-03"
  - "n": 4
    title: File and Directory Discovery, Technique T1083 - Enterprise | MITRE ATT&CK®
    publisher: MITRE ATT&CK
    url: https://attack.mitre.org/techniques/T1083/
    accessed: "2026-11-03"
  - "n": 5
    title: Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK®
    publisher: MITRE ATT&CK
    url: https://attack.mitre.org/techniques/T1528/
    accessed: "2026-11-03"
  - "n": 6
    title: "Valid Accounts: Cloud Accounts, Sub-technique T1078.004 - Enterprise | MITRE ATT&CK®"
    publisher: MITRE ATT&CK
    url: https://attack.mitre.org/techniques/T1078/004/
    accessed: "2026-11-03"
  - "n": 7
    title: CHAPITRE II - Principes
    publisher: CNIL
    url: https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre2
    accessed: "2026-11-03"
  - "n": 8
    title: Disable or Remove Feature or Program, Mitigation M1042 - Enterprise | MITRE ATT&CK®
    publisher: MITRE ATT&CK
    url: https://attack.mitre.org/mitigations/M1042/
    accessed: "2026-11-03"
---

# Honeypots et honeytokens : des pièges pour repérer l'intrus

Un honeypot est un leurre. Le glossaire du NIST le définit comme un système (par exemple un serveur web) ou une ressource de système (par exemple un fichier sur un serveur) conçu pour être attractif pour les pirates et les intrus, « like honey is attractive to bears » [1]. Dans cette fiche, « honeytoken » désigne la même idée à plus petite échelle : une donnée sans usage réel, comme un faux identifiant ou une fausse clé d'accès, placée là où un intrus la trouvera. Les sources citées ici ne définissent pas ce terme.

Pour un salarié, ces pièges restent le plus souvent invisibles. Ils servent à la sécurité de l'entreprise, qui les installe et les surveille. Cette fiche explique le principe, ce qu'on attend de chacun si un leurre apparaît sur son chemin, et les défauts qui rendent ces dispositifs inutiles ou dangereux.

## En 30 secondes

- Où ça arrive : sur des systèmes, des fichiers ou des comptes que l'équipe sécurité a placés volontairement, sans que les salariés aient à s'en occuper.
- Ce que veut l'attaquant : trouver des mots de passe, des clés ou des jetons d'accès. Le leurre lui offre exactement cela, mais il ne mène nulle part.
- Le réflexe : ne pas toucher à un leurre, ne jamais en installer soi-même, et signaler à la sécurité tout message d'alerte ou fichier suspect.
- Si c'est déjà fait : prévenir la sécurité sans attendre, en indiquant ce qui a été ouvert et à quel moment.

## Questions directes

### À quoi sert un leurre ?

Il sert à repérer une intrusion. Le NCSC britannique rappelle que l'objectif premier de la cybersécurité est d'empêcher les attaques [2]. Ce n'est pas toujours possible [2]. Le rôle d'un centre des opérations de sécurité (SOC) est de limiter les dégâts en détectant et en traitant les attaques qui contournent les contrôles préventifs [2]. Un leurre est un moyen de détection parmi d'autres : il s'ajoute aux protections qui bloquent, il ne les remplace pas.

### Pourquoi un intrus s'y laisse-t-il prendre ?

Parce qu'il cherche précisément ce que le leurre imite. MITRE décrit des adversaires qui fouillent les systèmes de fichiers locaux et les partages réseau à la recherche de fichiers contenant des identifiants mal protégés [3]. Il peut s'agir de fichiers créés par des utilisateurs pour noter leurs mots de passe, de fichiers de configuration contenant des mots de passe, ou de code source avec des mots de passe intégrés [3]. Ces mêmes adversaires peuvent énumérer fichiers et dossiers pour décider de la suite de leur action [4]. Un faux fichier de mots de passe, rangé au bon endroit, ressemble à une trouvaille.

### Un salarié peut-il déclencher un leurre par erreur ?

C'est possible, et la fiche ne peut pas dire à quelle fréquence : les sources du dossier ne le documentent pas. La règle est donc simple. Un fichier, un compte ou un partage qui n'a aucun rapport avec votre travail n'est pas à ouvrir par curiosité. Si vous l'avez ouvert, dites-le à la sécurité plutôt que de le taire.

### Un salarié doit-il installer un leurre chez lui ou sur son poste ?

Non. Un leurre mal posé peut créer un problème au lieu d'en régler un. Le choix de l'emplacement, de l'isolement et de la surveillance revient à l'équipe sécurité.

## Comment ça marche

Il existe trois grandes familles de leurres, que la fiche distingue d'après les exemples du glossaire du NIST [1] et des fiches MITRE [3][5].

- Le serveur ou le système factice : c'est le honeypot au sens du NIST, un système attractif pour l'intrus [1].
- Le faux document ou le faux fichier : une ressource placée sur un serveur, que le NIST range aussi dans la définition du honeypot [1].
- Le faux jeton ou la fausse clé d'accès : un jeton d'application sert à faire des requêtes autorisées au nom d'un utilisateur ou d'un service, et il est courant dans les applications cloud et en conteneurs [5]. Un adversaire qui vole de tels jetons peut accéder aux données et agir avec les droits des comptes concernés [5]. Un jeton factice, selon le raisonnement de la fiche, attirerait la même convoitise.

Le principe d'alerte tient à l'usage : le leurre n'a aucune fonction dans le travail quotidien, donc tout contact avec lui mérite d'être examiné. Les sources du dossier ne détaillent pas le fonctionnement technique des outils du commerce, et cette fiche ne le décrit pas.

Le même raisonnement vaut pour les comptes. MITRE note que les comptes cloud, créés par une organisation pour ses utilisateurs, ses services ou l'administration, sont des cibles [6]. Un adversaire peut les viser par force brute ou par hameçonnage [6]. Un faux compte pourrait servir d'appât sur ce terrain, selon le raisonnement de la fiche.

## Ce que vous faites

- Vous ne touchez pas à ce qui ne vous concerne pas. Un fichier nommé « mots_de_passe » dans un dossier partagé que vous n'utilisez jamais n'est pas une aubaine.
- Vous ne copiez, ne testez et ne partagez aucun identifiant, clé ou jeton trouvé par hasard.
- Vous signalez à la sécurité tout message d'alerte inattendu, tout fichier ou compte suspect, avec le nom, l'emplacement et l'heure.
- Vous n'installez pas de leurre vous-même, ni sur un poste, ni dans un espace cloud.
- Vous ne rangez pas vos propres mots de passe dans un fichier : MITRE cite justement ces fichiers parmi ceux que les adversaires recherchent [3].

## Les pièges

### Le leurre trop facile à reconnaître

Un faux document grossier, au nom trop évident, ne trompe personne. Les sources du dossier ne disent pas comment réussir un leurre crédible : le point est seulement signalé ici, sans consigne technique.

### L'alerte ignorée

Détecter ne sert à rien si personne ne réagit. Le NCSC décrit le SOC comme un ensemble qui détecte et répond [2]. Son guide traite à la fois de la détection et de la réponse aux incidents [2].

### Le leurre mal isolé

Les sources du dossier ne traitent pas l'isolement d'un leurre par rapport au reste du réseau. MITRE recommande en revanche, de façon générale, de réduire la surface d'attaque en supprimant les logiciels, fonctions et services inutiles [8], ce qui vaut aussi pour un leurre oublié.

### Les données personnelles collectées sans cadre

Si un leurre enregistre ce que fait une personne, les règles sur les données personnelles peuvent s'appliquer. Le RGPD, dans son article 5, demande qu'elles soient traitées de manière licite, loyale et transparente [7]. Elles doivent être collectées pour des finalités déterminées, explicites et légitimes [7]. Elles doivent aussi être limitées à ce qui est nécessaire [7]. Il exige aussi une sécurité appropriée du traitement [7]. Un dispositif de surveillance sans finalité claire ni information des personnes s'écarte de ces principes.

### Le compte cloud pris pour cible

Un compte cloud synchronisé avec les systèmes internes peut ouvrir la voie vers l'entreprise elle-même : MITRE précise que des comptes fédérés ou synchronisés peuvent permettre d'agir à la fois sur les systèmes internes et sur le cloud [6]. La fiche en déduit qu'un faux compte de ce type devrait être cloisonné comme un compte sensible.

## Sources

1. NIST, « honeypot - Glossary | CSRC ». https://csrc.nist.gov/glossary/term/honeypot (consulté le 3 novembre 2026)
2. NCSC (Royaume-Uni), « Building a Security Operations Centre (SOC) », 23 mai 2022. https://www.ncsc.gov.uk/collection/building-a-security-operations-centre (consulté le 3 novembre 2026)
3. MITRE ATT&CK, « Unsecured Credentials: Credentials In Files, Sub-technique T1552.001 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/techniques/T1552/001/ (consulté le 3 novembre 2026)
4. MITRE ATT&CK, « File and Directory Discovery, Technique T1083 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/techniques/T1083/ (consulté le 3 novembre 2026)
5. MITRE ATT&CK, « Steal Application Access Token, Technique T1528 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/techniques/T1528/ (consulté le 3 novembre 2026)
6. MITRE ATT&CK, « Valid Accounts: Cloud Accounts, Sub-technique T1078.004 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/techniques/T1078/004/ (consulté le 3 novembre 2026)
7. CNIL, « CHAPITRE II - Principes ». https://www.cnil.fr/fr/reglement-europeen-protection-donnees/chapitre2 (consulté le 3 novembre 2026)
8. MITRE ATT&CK, « Disable or Remove Feature or Program, Mitigation M1042 - Enterprise | MITRE ATT&CK® ». https://attack.mitre.org/mitigations/M1042/ (consulté le 3 novembre 2026)

---

Source originale : Cyberpedia, l'encyclopédie publique de cybersécurité et d'IA publiée par Brain. Version canonique : https://startbrain.io/cyberpedia/fr/articles/honeypot-honeytoken-canarytokens/
Vous pouvez reprendre ce texte librement sous licence CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/), à condition de citer « Brain, Cyberpedia » avec un lien vers l'adresse ci-dessus.
