Leur employé est parti. Nous gérons la boutique — et nous ne pouvions pas prouver que son accès était parti aussi.

Le constat qui a figé l’audit

Nous créons et maintenons des boutiques PrestaShop pour d’autres entreprises. Les boutiques ne nous appartiennent pas — nous les exploitons pour le compte de nos clients, ce qui veut dire que la sécurité de leur Back Office est notre responsabilité. C’est le métier. C’est aussi pour cette raison que l’histoire que je vais raconter nous est tombée dessus à nous, pas à quelqu’un d’autre.

Il y a peu, l’une des entreprises dont nous gérons la boutique a vu partir un employé. Rien de spectaculaire, rien dans le départ lui-même qui mérite un récit. Mais cette personne avait des accès répartis dans toute l’activité que nous opérons pour son employeur — dont un compte PrestaShop Back Office — et son départ a déclenché ce qui aurait dû être une revue d’accès routinière sur la boutique, sa messagerie et son hébergement. En tant que gardiens de cette boutique, cette revue nous revenait.

Elle a trouvé le désordre habituel que l’on attend d’une organisation qui a grandi plus vite que ses processus. Mais un constat a tout arrêté net — et ce n’était pas le login Back Office auquel tout le monde pense d’abord. C’était la boîte mail :

La boîte mail de l’employé parti — sa boîte personnelle, ainsi que les boîtes de rôle partagées qu’il utilisait — était encore active. Son mot de passe n’avait jamais été renouvelé. Et quelqu’un s’y connectait encore tous les jours.

Voici la partie qui devrait vous inquiéter plus encore que le constat lui-même : parce que toute l’équipe du client travaillait depuis une seule connexion de bureau partagée, et parce que certains identifiants étaient partagés entre plusieurs personnes, il était impossible de savoir si ces connexions quotidiennes venaient de la personne partie ou d’un collègue toujours en poste qui faisait l’ancien travail depuis l’ancienne boîte. Les deux explications collaient parfaitement aux logs. Une ligne de log indique qu’un identifiant a été utilisé depuis une adresse — et une adresse IP identifie une connexion, pas une personne. Des semaines après que quelqu’un a cessé de travailler pour l’entreprise, nous — l’agence responsable de la sécurité de cette boutique — ne pouvions pas prouver que son accès s’était arrêté avec lui.

C’est l’histoire de ce billet. Pas une intrusion — nous n’en avons trouvé aucune preuve, et pour être précis sur ce que les logs montraient réellement : les identifiants encore actifs de la boîte mail de l’ancien employé ont été utilisés ; qui les détenait, c’est précisément ce que personne n’a pu établir. Quelque chose de plus discret et, je dirais, de plus courant qu’une intrusion : une boutique dont les responsables ne pouvaient pas répondre à la question « qui peut entrer dans quoi, maintenant ? » — et, quand nous avons essayé de reconstruire la réponse à partir des logs, nous avons découvert que les logs ne pouvaient pas nous la donner non plus. Et si c’est vrai pour une boîte mail, la même architecture vous laisse tout aussi aveugle sur le Back Office — c’est là que vise le reste de ce billet.

Si vous exploitez — ou exploitez pour quelqu’un d’autre — une boutique PrestaShop où plus d’une personne touche au Back Office, ce billet est la checklist que j’aurais voulu avoir en main avant d’en avoir besoin.

Pourquoi la forensic a échoué — et pourquoi la vôtre échouerait aussi

Quand le constat « toujours actif, toujours connecté » est apparu, l’étape suivante semblait évidente : faire de la forensic, sortir les logs, attribuer chaque connexion, confirmer qu’aucun abus n’avait eu lieu. Nous avons fait ce travail. Il a largement échoué, et les raisons de cet échec méritent d’être détaillées, parce qu’elles ne sont pas propres à ce client — elles sont l’état par défaut d’un stack d’hébergement typique de petite entreprise, et nous voyons la même forme dans les boutiques que nous gérons.

Les logs ne remontaient pas assez loin. Le serveur mail ne conservait les logs détaillés de connexion que pendant environ quatre semaines. Tout ce qui était plus ancien avait simplement disparu. Si la question est « ce compte a-t-il été utilisé à mauvais escient depuis le départ de la personne il y a des mois ? », une fenêtre de quatre semaines ne peut pas y répondre — aucune compétence n’y change quoi que ce soit.

Le webmail masquait la vraie source. Les connexions via le client webmail hébergé étaient proxifiées par le serveur lui-même, de sorte que le log mail enregistrait l’adresse locale du serveur comme source de session — pas l’IP réelle de la personne. Toute une catégorie d’accès était anonymisée par l’architecture.

Les IP partagées ont détruit l’attribution. Tout le monde dans le bureau du client sortait par une seule connexion haut débit. Une connexion depuis l’IP du bureau pouvait être n’importe laquelle d’une douzaine de personnes — y compris, potentiellement, quelqu’un qui n’y travaillait plus mais avait encore le mot de passe et, disons, une raison de passer, ou un appareil qui se synchronisait encore automatiquement. NAT, VPNs et réseaux partagés produisent tous le même effet : l’IP vous dit d’où vient une connexion, jamais qui se trouvait derrière.

Les identifiants partagés l’ont détruite une deuxième fois. Plusieurs boîtes de rôle et l’accès à l’hébergement lui-même utilisaient des mots de passe connus de plusieurs personnes. Quand cinq personnes connaissent un mot de passe, une ligne de log prouve qu’un mot de passe a été utilisé — jamais qui l’a utilisé.

Les accès préexistants étaient invisibles. La limite la plus importante de toutes : les logs enregistrent des événements, pas une connaissance. Si quelqu’un a copié un mot de passe, exporté une boîte mail ou noté une clé API pendant qu’il avait légitimement accès, aucun log ne le montrera jamais. La revue pouvait honnêtement conclure « nous n’avons trouvé aucune preuve d’abus » — et nous avons dû ajouter immédiatement la réserve que toute personne en sécurité connaît : l’absence de preuve n’est pas la preuve de l’absence.

Mis bout à bout, voici la vraie leçon, et c’est la thèse de tout ce billet :

Vous ne pouvez pas enquêter sur ce que vous n’avez jamais empêché. Quand vous en êtes à faire de la forensic, vous avez déjà perdu la version de cette histoire où vous obtenez une réponse nette. La prévention n’est pas seulement moins chère que la forensic — dans un stack marchand typique, c’est la seule des deux qui fonctionne réellement.

Notre propre maison n’était pas propre non plus

Je serais malhonnête si je présentais cela comme « un client avait une mauvaise hygiène et nous, agence diligente, avons fait la leçon depuis la touche ». La même revue a audité des accès qui incluaient nos propres comptes d’agence sur cette boutique — et elle a trouvé deux choses dont je ne suis pas fier.

L’un de mes propres mots de passe n’avait pas été changé depuis environ cinq ans. Il était long, il était unique, il n’avait jamais — d’après tout ce qu’un log pouvait montrer — été utilisé à mauvais escient. Ce n’est pas le sujet. Cinq ans, ce sont cinq ans d’anciens collaborateurs, d’anciens appareils, de profils de navigateur oubliés et de fuites chez des tiers qui s’accumulent contre un secret statique. Comme personnes payées pour veiller sur cette boutique, nous savions mieux faire. C’était quand même vrai.

Mon « VPN » aggravait les choses au lieu de les améliorer. Pendant des années, j’avais utilisé un service VPN gratuit qui faisait tourner ses serveurs de sortie entre des data centers aléatoires. Côté sécurité, il apportait peu. Côté forensic, c’était une catastrophe inversée : mes propres connexions légitimes à la boutique apparaissaient dans les logs comme des rafales depuis des IP de data centers inconnus dans plusieurs pays — exactement l’empreinte d’une prise de contrôle de compte. Pendant la revue, nous avons brûlé de vraies heures à prouver que le motif le plus inquiétant de toute l’historique des logs, c’était moi, l’administrateur de la boutique, naviguant à travers la roulette des nœuds de sortie d’un VPN gratuit. Un outil adopté au nom de la sécurité avait généré le bruit qui a presque enterré le signal.

Je les inclus parce que c’est la forme honnête de ce problème, et parce que tenir les Back Offices de clients nous oblige à nous appliquer la même liste. L’hygiène des identifiants n’échoue pas parce que les gens sont négligents ou stupides. Elle échoue parce que rien dans les opérations quotidiennes ne force le sujet. La boutique fonctionne. Les mails arrivent. Le mot de passe de 2021 vous connecte encore. Chaque jour où rien ne va mal est un jour où la dette se compose invisiblement — jusqu’à ce qu’un départ, un audit ou un incident vous oblige à regarder.

Le cycle de vie des identifiants a deux moitiés. Tout le monde en fait une.

Quand quelqu’un arrive — un employé, un freelance, une agence, un partenaire commercial — l’accès est créé en quelques heures. Il le faut, sinon il ne peut pas travailler. Il y a une personne motivée (le nouvel arrivant), un manager motivé (qui a besoin qu’il soit productif) et un mode d’échec immédiat et visible si cela n’arrive pas.

Quand la relation se termine, la révocation n’a rien de tout cela. Personne n’est bloqué par le fait qu’un compte de partant continue d’exister. Il n’y a pas de message d’erreur, pas de plainte, pas de ticket. Le résultat par défaut de l’inaction est que tout continue de fonctionner — et c’est précisément le problème. L’onboarding s’impose de lui-même ; l’offboarding n’arrive que si vous en avez fait un processus délibéré et écrit. Et cela vaut pour chaque type de départ : l’employé qui démissionne, le prestataire dont le projet se termine, l’agence qu’un client remplace. Il y a ici un second piège qui nous a touchés directement : quand une boutique est exploitée par une agence mais opérée par les propres équipes du client, l’offboarding peut tomber dans l’espace entre les deux — le client suppose que son employé partant est « le problème de notre prestataire », l’agence n’apprend jamais que la personne est partie. L’accès ne sait pas à qui le problème était censé appartenir. Quelqu’un doit en être explicitement responsable, par écrit, des deux côtés.

Et dans une opération e-commerce, « l’accès » n’est jamais un seul compte. C’est une dispersion : le PrestaShop Back Office, les boîtes mail, les boîtes de rôle partagées, SSH et FTP, le panneau de contrôle d’hébergement, l’accès à la base de données, les clés webservice API, le tableau de bord du prestataire de paiement, la plateforme d’expédition, analytics, marketplaces, le gestionnaire de mots de passe, les documents partagés. Oubliez-en un seul et le départ n’est pas terminé — vous avez simplement cessé de regarder.

La checklist d’offboarding que la plupart des boutiques n’ont pas

C’est l’artefact à reprendre de ce billet. Imprimez-le, adaptez-le et attachez-le à votre processus de départ — que vous soyez le marchand ou l’agence qui exploite la boutique, l’objectif est que le dernier jour de quelqu’un, vous exécutiez une liste au lieu d’essayer de vous souvenir de tout le stack sous pression.

Deux notes de processus comptent autant que la liste : elle s’exécute le dernier jour, pas « dans quelques semaines » — la revue qui a déclenché ce billet a trouvé l’écart précisément parce que la révocation avait été traitée comme une tâche à faire plus tard. Et quelqu’un en est propriétaire par son nom — et quand une boutique est exploitée par une agence, ce « quelqu’un » et le passage de relais entre client et agence doivent être fixés avant que quelqu’un parte, pas improvisés après. Une checklist dont personne n’est propriétaire est une suggestion.

Un choix délibéré de la ligne 1 mérite d’être répété : désactiver, ne pas supprimer. Un compte désactivé ne peut pas se connecter, mais il conserve son identité et ses références existantes — ainsi, les enregistrements qui le mentionnent effectivement pointent encore vers une personne connue au lieu d’un lien orphelin. La suppression semble plus propre et orphelinise exactement les liens dont vous pourriez avoir besoin plus tard pour comprendre.

Durcissement : pour qu’un mot de passe divulgué ne suffise jamais

L’offboarding est du contrôle des dégâts pour un système où un mot de passe équivaut à un accès. La correction plus profonde consiste à rendre un Back Office survivable même quand un identifiant fuit — parce qu’un jour, cela arrivera. Voici les six changements que nous poussons maintenant sur chaque boutique que nous gérons, dans l’ordre où je les ferais :

1. Tuer les comptes partagés — une personne, un compte. C’est la base sur laquelle tout le reste repose. Le système d’employés de PrestaShop (Paramètres avancés → Équipe) existe précisément pour que vous ne partagiez jamais un login : donnez à chaque personne son propre compte avec un profil qui correspond à son vrai travail, et réservez SuperAdmin aux une ou deux personnes qui en ont réellement besoin. Le bénéfice est exactement ce que cette boutique n’avait pas quand nous avons hérité de son historique : quand chaque compte correspond à un humain, vous pouvez attribuer les actions et vous pouvez révoquer une personne sans réinitialiser tout le monde.

2. Révoquer complètement, pas seulement le mot de passe évident. La checklist ci-dessus est le sujet : un départ signifie exécuter les douze lignes, pas désactiver le login Back Office et considérer que c’est terminé. Le constat qui a ouvert ce billet n’était pas un compte Back Office — c’était une boîte mail. L’accès que vous oubliez est toujours celui qui compte.

3. Placer le Back Office derrière un mur IP — à la périphérie serveur, pas seulement dans l’application. Renommer le répertoire admin relève de l’obscurité, pas du contrôle ; une URL divulguée suffit à l’annuler. Ce qui change vraiment le calcul, c’est une allowlist : le Back Office ne répond qu’aux adresses de sortie connues du bureau et du VPN, et à personne d’autre sur internet. Et la réponse d’ingénierie honnête est que le meilleur endroit pour l’appliquer est entièrement devant PrestaShop — une règle au niveau serveur (nginx allow/deny, Apache Require ip), une politique Cloudflare Access ou une règle WAF sur le chemin admin, ou un VPN qui est la seule route réseau vers le Back Office. Appliqué là, le blocage se produit avant qu’une seule ligne de PHP ne tourne, donc même une vulnérabilité applicative ne peut pas le contourner par la conversation. Une allowlist dans l’application devient alors une deuxième couche utile — defense in depth, et souvent la seule couche disponible sur un hébergement mutualisé restrictif où nous ne contrôlons pas la périphérie. Notre module mprsecurityrevolution fournit cette couche sous forme de firewall IP — règles de blocage, règles whitelist, blocage par pays — et applique la même logique d’allowlist directement aux connexions employés avec une barrière trusted-admin-IP sur le Back Office. Dans tous les cas, l’effet est le même : un mot de passe admin divulgué ou non renouvelé — l’échec exact de cette histoire — ne suffit plus à lui seul. Un attaquant a besoin de l’identifiant et d’une position sur votre réseau.

4. Ajouter un second facteur aux connexions admin — PrestaShop ne le fera pas pour vous. Voici un fait qui surprend beaucoup de marchands : PrestaShop core — 1.7, 8 et 9 inclus — ne fournit aucune authentification à deux facteurs native pour le Back Office. PrestaShop 8 et 9 ont durci l’accès admin par d’autres moyens (une politique de mot de passe configurable et une meilleure gestion des sessions), mais un second facteur n’est jamais arrivé dans le core. Si vous voulez de la 2FA sur les connexions employés, elle doit venir d’un module ou d’une couche devant la boutique (un portail SSO ou quelque chose comme Cloudflare Access). Elle vaut le coup : une application TOTP sur le téléphone de chaque admin coûte quelques secondes par connexion et supprime toute la catégorie « quelqu’un, quelque part, connaît encore un vieux mot de passe » comme moyen suffisant d’entrer. mprsecurityrevolution ajoute l’authentification à deux facteurs TOTP aux connexions employés PrestaShop, pour que le Back Office l’obtienne sans infrastructure sur mesure. Soyez lucide sur ce que la 2FA apporte : elle réduit fortement le risque password-only — elle ne fait l’offboarding de personne. Un employé parti dont le compte est toujours actif et dont le téléphone est toujours enrôlé traverse la 2FA sans obstacle. Elle complète la checklist ; elle ne peut pas la remplacer.

5. Renouveler selon un calendrier et à chaque départ — et utiliser un vrai VPN. La rotation n’est pas une affaire de paranoïa ; il s’agit de limiter l’âge de tout secret qu’un ancien collaborateur, un vieux portable ou un tiers compromis pourrait encore détenir. Renouvelez les identifiants critiques selon un calendrier (panneau d’hébergement, base de données, tableaux de bord de paiement au minimum), et renouvelez tout ce qu’un partant a touché le jour de son départ — ce sont les lignes 3, 5, 6 et 9 de la checklist. Et si vous ou l’équipe de votre client utilisez un VPN pour accéder à quoi que ce soit, utilisez-en un vrai avec des adresses de sortie fixes et connues — WireGuard auto-hébergé ou un fournisseur professionnel réputé. Mon VPN gratuit à sorties rotatives n’a pas seulement ajouté une sécurité négligeable ; il a activement pollué les logs dont j’ai ensuite eu besoin. Un VPN avec une IP de sortie stable fait l’inverse : il rend l’accès légitime plus attribuable et donne à votre allowlist IP une adresse propre à laquelle faire confiance.

6. Logger les actions admin — parce que vous ne pouvez enquêter que sur ce que vous avez loggé. Les impasses forensic précédentes n’étaient pas de la malchance ; elles étaient la posture de logging par défaut d’un stack standard. Et une réserve mérite d’être dite clairement : le logging intégré de PrestaShop n’est pas un audit trail complet. La page Logs du core (Paramètres avancés → Logs) enregistre les erreurs et un sous-ensemble d’événements, mais beaucoup d’actions pertinentes pour la sécurité — connexions et leurs sources, changements de permissions, modifications de configuration — ne laissent aucune trace durable et consultable, et la rétention est ce que votre routine de maintenance laisse par hasard. Décidez maintenant quelles questions vous devriez pouvoir résoudre après un incident — qui s’est connecté au Back Office et d’où, qui a créé ou désactivé un employé, qui a changé des permissions, qui a touché à une configuration sensible — et assurez-vous que quelque chose enregistre durablement ces réponses aujourd’hui, avec plus de quatre semaines de rétention. C’est pourquoi le logging d’activité et d’audit est l’un des piliers de la protection admin de mprsecurityrevolution, aux côtés de sa gestion des sessions (un seul endroit pour voir chaque session Back Office active et terminer celles qui ne devraient pas exister — le problème « toujours connecté depuis un ancien appareil » — sur PS 1.7, 8 et 9 ; les versions plus anciennes n’ont aucun contrôle de ce type, et sur PS 9 il complète la gestion des sessions du core comme console unique pour repérer et tuer les sessions), du monitoring d’intégrité des fichiers et des contrôles de sécurité email. Quand la question inconfortable finira par arriver — et si vous gérez des boutiques pour d’autres, elle arrivera — « nous loggons qui a fait quoi dans le Back Office » fait la différence entre une réponse et un haussement d’épaules.

Par où commencer si ce billet vous a mis mal à l’aise

Commencez par la vérité, pas par l’outillage. Notre scanner gratuit et open source, mprsecurityscan, audite une boutique de l’intérieur — fichiers exposés, durcissement manquant, paramètres par défaut risqués — et vous donne des constats avec des étapes de correction manuelles. Il ne fait que détecter et il est gratuit, parce que la première étape est de savoir où vous en êtes réellement. Ensuite, appliquez la checklist ci-dessus à toutes les personnes qui ont déjà eu accès — chaque employé, prestataire, agence et partenaire actuel et ancien — et laissez les résultats vous dire lequel des six durcissements il vous faut d’abord. Quand vous voulez que les contrôles admin soient appliqués plutôt que mémorisés, c’est le rôle de mprsecurityrevolution : le firewall IP, la gestion des sessions, le logging d’activité et d’audit, le monitoring d’intégrité des fichiers et la sécurité email qu’il fournit aujourd’hui, plus l’authentification à deux facteurs et la barrière de login trusted-admin-IP pour le Back Office. Aucun module ne rend l’offboarding automatique ni le risque interne impossible — rien ne le fait — mais il déplace les contrôles critiques de « quelqu’un s’en est souvenu » vers « le système l’applique ». C’est le standard que nous nous imposons sur chaque boutique que nous gérons, et celui que nous voudrions pour la nôtre.

La fin discrète

La revue qui a déclenché tout cela s’est terminée sans drame : le compte de l’employé parti a été désactivé — désactivé, pas supprimé, pour que son identité et ses références restent intactes au lieu d’être orphelines — les mots de passe ont été renouvelés, et la checklist existe maintenant, a un propriétaire et fait partie de notre manière de transmettre les accès avec ce client.

Aucune intrusion n’a été trouvée. Mais « aucune intrusion n’a été trouvée » et « aucune intrusion n’a eu lieu » sont deux phrases différentes, et l’écart entre elles est permanent — cette boutique ne le saura tout simplement jamais avec certitude, parce que les logs qui auraient pu le dire n’ont jamais été conservés, et que l’accès qui aurait dû s’arrêter avec l’emploi lui a silencieusement survécu.

Cette non-connaissance permanente et insoluble est le vrai coût d’un cycle de vie des identifiants mal géré. Vous ne le payez pas le jour où quelqu’un part. Vous le payez des mois plus tard, au moment d’une revue ou d’un incident, quand chaque question revient avec « impossible à dire ». Et si vous êtes celui à qui l’on confie la boutique de quelqu’un d’autre, c’est son entreprise qui le paie — c’est pourquoi nous considérons que c’est à nous de le faire correctement.

La meilleure réponse à incident est la connexion qui n’a jamais eu lieu. Révoquez comme si vous le pensiez vraiment.