Profil employé PrestaShop créé à 3 h du matin
Un profil employé PrestaShop créé à 3 h, ou un « Catalogue » trop ouvert, suffit souvent. Exportez les permissions, puis désactivez. Changez aussi les clés webservice : elles survivent au mot de passe back-office.
Supprimez après export des permissions. Un employé « catalogue » trop ouvert suffit parfois. Changez aussi les webservice keys.
Ce qu'un employé fantôme permet déjà
Selon le profil : installer un module (skimmer), modifier le thème, exporter clients, changer l'URL de retour paiement, créer d'autres employés. Inutile d'être « SuperAdmin » si le profil Catalogue a été mal copié. L'heure 3 h du matin n'est pas une preuve à elle seule (fuseau, cron d'import) ; combinée à un email inconnu, si.
Ne vous arrêtez pas à la liste des employés. Un prestataire légitime parti en 2022 est un fantôme fonctionnel. Même traitement : export, retrait ou rôle minimal, mot de passe mort.
Cadre : PrestaShop que faire, guide.
Lister, dater, exporter avant de supprimer
Administration → Employés : id, email, profil, dernière connexion, date d'ajout, actif. Capture + CSV / copier table `ps_employee`. Les permissions détaillées sont dans le profil (`ps_access` / `ps_authorization_role` selon version). Exportez le profil du fantôme, pas seulement son nom.
Puis désactivez (souvent préférable à une suppression immédiate : les logs et les liaisons restent). Changez votre propre mot de passe après, pas avant (une session fantôme ouverte vous réécrit).
- Tous les employés, y compris inactifs.
- Profils custom : matrice des droits.
- Dernières connexions : fuseau noté.
Le profil « trop large » sans nouveau compte
Un employé « marketing » avec Modules et Paiement cochés : pas besoin de créer `admin_8372`. Resserrez les profils après incident. Le merchandising n'installe pas de modules. Le SAV n'exporte pas toute la base clients sans besoin. C'est moins spectaculaire qu'un fantôme, c'est plus fréquent.
Webservice keys : le jumeau silencieux
Paramètres avancés → Webservice. Une clé `customers` + `orders` + `write` est un employé machine. Révoquez ce que vous ne nommez pas (ERP, app, marketplace). Une clé survit au changement de mot de passe employé. Même famille que clés Magento et clés Woo.
Les permissions de la clé : lisez-les. `write` sur `employees` permet de se recréer un humain. Tournez, puis surveillez la table des clés 10 jours.
Sessions et cookie du back-office
Changer le mot de passe ne tue pas toujours le cookie déjà émis. Videz les sessions employé (table selon version), régénérez le nom de cookie si vous savez le recoller dans la config, forcez HTTPS / cookie secure. Un 2FA back-office (module officiel ou SSO) se pose APRÈS le ménage, pas comme seul geste pendant que le fantôme existe encore.
Où l'entrée a pu se faire
Faille de module, back-office exposé sans limitation de tentatives, webservice ouvert, SQL, voisin de compte, mot de passe réutilisé. Désactiver le fantôme sans chercher l'entrée, c'est J+2 un autre email. Logs d'accès `/admin-xxxx/`, fail2ban, journal FTP. Voisin si plusieurs sites sur le FTP.
Modules installés par ce compte
Les dates de dossiers `modules/` vs la date de création de l'employé. Un module paiement ou transport posé la même nuit : archivez, désactivez. Module transport, skimmer. Les overrides datés du même moment aussi.
Relire à J+3 et J+10
Une persistance (webshell, cron, clé oubliée) recrée un employé. Alerte mail native ou module de logs si vous en posez un après. Les comptes « agence, le temps du debug » ont la vie dure : date de fin écrite.
Page service PrestaShop, déclaration créer un compte.
- Fantômes exportés puis inactifs.
- Profils resserrés.
- Clés webservice nommées ou mortes.
- Sessions invalidées, relire à J+10.
Journaux employés et ce que Presta n'écrit pas
Selon la version, PrestaShop journalise peu (dernière connexion, parfois des logs modules). Un module d'audit (officiel ou sérieux) se pose APRÈS le ménage, pas pendant. Les access.log `/admin-xxx/` restent la meilleure datation : POST vers un contrôleur modules / employees. Gardez-les. Un hébergeur qui rotate à 7 jours : exportez le premier jour.
Un employé « boutique » par défaut jamais renommé, mot de passe `admin` / le SIRET : ce n'est pas un fantôme créé à 3 h, c'est une porte ouverte depuis l'install. Tournez-le comme un fantôme. Changez aussi l'URL du back-office si elle est encore `/admin` prévisible — utile après, pas à la place de la révocation.
Les tokens « rester connecté » et les cookies sur un ordinateur d'agence : un mot de passe neuf ne suffit pas si l'agence a encore le cookie. Invalidez les sessions, prévenez l'agence, donnez un accès plus étroit le lendemain si le chantier continue. Ancien développeur est le même dossier, autre CMS.