Contexte
Dans le cadre de mon alternance Administrateur Systèmes & SecOps, j’ai conçu et déployé la plateforme technique d’une campagne de sensibilisation au phishing pour Defensys (nom fictif : je ne nomme pas l’organisation réelle, par discrétion professionnelle pendant mon contrat). L’objectif était de mesurer l’exposition réelle des collaborateurs à l’ingénierie sociale, puis de les former, dans le respect du RGPD et avec l’accord de la direction.
Campagne interne autorisée, menée sur l’infrastructure de l’organisation, avec un cadrage écrit et un périmètre limité aux comptes professionnels. Aucune personne extérieure au périmètre autorisé n’a été ciblée.
J’ai depuis reconstruit la plateforme sous une forme générique et rejouable, testée de bout en bout (campagne réelle créée via l’API GoPhish, métriques vérifiées dans Grafana). Le code est disponible dans un dépôt privé sur GitHub — accès sur demande.
Architecture
La plateforme assemble six briques, chacune dans son propre conteneur :
- GoPhish : création des campagnes, modèles de mail, pages d’atterrissage, suivi des envois, ouvertures, clics et soumissions. Sa base de données est du SQLite intégré : GoPhish ne supporte nativement que SQLite et MySQL, pas PostgreSQL — une confusion que j’ai faite dans une première version de ce projet, avant de la corriger en revérifiant le fonctionnement réel de l’outil.
- Un exporteur Prometheus que j’ai écrit moi-même : GoPhish ne publie pas nativement de métriques. Ce script interroge son API REST et traduit chaque campagne en indicateurs exploitables par Grafana.
- Prometheus et Grafana : supervision technique et tableaux de bord des indicateurs de campagne (envoyés, ouverts, cliqués, identifiants soumis), avec filtrage par campagne.
- Portail de formation (Nginx) : les modules de sensibilisation que voient les collaborateurs après le test.
Un principe guide le déploiement : séparer strictement l’administration de la surface publique. Les interfaces d’administration de GoPhish, Grafana et Prometheus n’écoutent que sur 127.0.0.1 et ne sont joignables que via VPN. Seules la page d’atterrissage et le portail de formation passent par Traefik et sont exposées publiquement, sur les seuls ports 80 et 443 ouverts par le pare-feu. Une plateforme de phishing mal protégée serait elle-même une cible de choix : son propre durcissement fait partie du livrable.
Méthodologie de conception des scénarios
Un scénario de phishing efficace ne s’improvise pas. Pour que le test mesure un vrai risque, et pas seulement la vigilance générale, chaque scénario a été construit sur un levier d’ingénierie sociale reconnu plutôt que sur un prétexte inventé au hasard :
- Urgence financière : une opération ou des coordonnées bancaires à valider rapidement.
- Autorité hiérarchique ou institutionnelle : une demande présentée comme venant d’un supérieur ou d’un organisme de tutelle.
- Confiance et familiarité : un collègue, un document partagé, un outil déjà utilisé au quotidien.
- Prétexte technique : expiration de mot de passe, connexion inhabituelle, assistance à distance.
Pour s’approcher d’un cas réel, une partie des scénarios reprenait les codes visuels (mise en page, ton, vocabulaire) de services tiers largement utilisés dans le secteur, reconstitués par observation plutôt qu’en copiant des éléments protégés. Le but n’est pas la ressemblance pour elle-même, mais la crédibilité nécessaire pour que le test ait une valeur statistique.
Mise en œuvre dans GoPhish
- Profils d’envoi authentifiés (SPF et DKIM alignés), pour que l’e-mail de test passe les mêmes contrôles qu’un message légitime.
- Groupes de cibles avec prénom et nom, pour personnaliser chaque message via les variables natives de GoPhish.
- Pages d’atterrissage avec capture des données soumises activée : l’objectif est de mesurer qui saisit des identifiants, pas seulement qui clique. Le taux de clic seul sous-estime largement le risque.
- Redirection après soumission vers le portail de formation plutôt qu’un message de démasquage intégré à la page : cela garde le test crédible jusqu’au bout et sépare clairement le moment du test du moment pédagogique.
Mesure et restitution
L’exporteur interroge l’API GoPhish et traduit chaque campagne en métriques Prometheus (envoyés, ouverts, cliqués, identifiants soumis, signalés), consommées par deux tableaux de bord Grafana : un suivi des campagnes, filtrable par scénario, et un suivi de l’état de la plateforme elle-même. Pour le scénario le plus sensible (changement de coordonnées bancaires), la mesure GoPhish est complétée par une question de debrief : « Avez-vous vérifié cette demande par un canal indépendant avant d’agir ? » Le clic mesure la vigilance, cette question mesure le réflexe réellement attendu.
Portail de formation
Les collaborateurs redirigés après un clic arrivent sur un portail dédié, avec des modules courts : reconnaître un e-mail de phishing, vérifier un lien ou une pièce jointe avant d’interagir, les bonnes pratiques d’authentification, la conduite à tenir en cas d’erreur, et un rappel des obligations RGPD propres au secteur. Les modules sont en cours de rédaction.
Enseignements
- Le clic n’est qu’un indicateur parmi d’autres. La soumission d’identifiants et le réflexe de vérification par un canal indépendant comptent davantage.
- Une plateforme de sensibilisation est un projet d’infrastructure à part entière : elle mérite le même durcissement que n’importe quel service exposé.
- Vérifier plutôt que supposer. En reconstruisant la plateforme, j’ai découvert par le test que GoPhish ne supporte pas PostgreSQL, et qu’une erreur de montage de volume aurait fait perdre toutes les données à chaque redémarrage du conteneur. Les deux étaient invisibles tant que rien n’avait été réellement exécuté.
- Séparer le test de la pédagogie évite de fausser la mesure tout en gardant un temps dédié à la formation.
Suite
- Finaliser les modules du portail de formation.
- Publier, une fois les résultats disponibles et anonymisés, un retour d’expérience chiffré sur les leviers d’ingénierie sociale les plus efficaces.