Stagiaire ou freelance encore administrateur six mois plus tard
Passez les utilisateurs après chaque mission. Un compte « agence 2023 » encore administrateur est une porte. Moins spectaculaire qu'un webshell, plus fréquent — et plus simple à fermer, à condition de le faire.
Passez les utilisateurs après chaque mission. Un compte « agence 2023 » ouvert est une porte. Moins spectaculaire qu'un webshell, plus fréquent.
Le scénario le plus banal n'a pas de hoodie
Un stage de six semaines, un freelance pour la refonte d'été, l'agence qui a « juste posé le pixel ». Le site marche. Personne ne revient dans Utilisateurs. Deux ans plus tard, ce compte sert — à son ancien titulaire, à quelqu'un qui a repris son ordinateur, à un mot de passe réutilisé fuité ailleurs. Pas d'exploit. Une session.
Dans les constats, ces comptes ont des noms gentils : `stage`, `marie-com`, `wp-agency`, `elementor-pro`. Ils sont administrateurs « le temps de l'install ». Le temps n'a pas une date de fin.
Ce n'est pas le même dossier humain que l'ancien développeur en conflit. Ici, souvent, personne n'est fâché. C'est pire en fréquence : on ne pense même pas à révoquer.
Ce que « après chaque mission » veut dire
Le jour de la recette, ou le jour de la dernière facture, quelqu'un ouvre Utilisateurs, FTP, invitations. Ce qui n'a plus de mission perd le privilège. Pas « on baissera le rôle plus tard ». Plus tard n'arrive pas.
Si la mission peut revenir (TMA, cinq heures par mois), le compte reste, nominatif, avec une 2FA, et une date de revue. Un compte éternel sans nom n'est pas de la TMA. C'est de l'oubli organisé.
Inscrivez cette revue dans le même rituel que la facture. Si ce n'est pas écrit, ce n'est pas un processus. C'est un vœu.
- CMS : supprimer ou rétrograder, invalider les sessions.
- Panel : utilisateur FTP de la mission, pas le compte principal.
- Google / Meta / newsletter : retirer l'invitation.
CMS, panel, pubs : la même revue
WordPress n'est qu'une liste. Le panel d'hébergement en est une autre. Tag Manager, Business Manager, Search Console, la boutique d'extensions, le compte Stripe « pour tester le webhook ». Une mission « juste le site » a souvent touché trois de ces listes.
Un freelance qui n'a plus wp-admin mais encore GTM peut poser un tag. Le site fichiers est « clean ». Le checkout, non. GTM détourné et pixel Meta injecté : le véhicule n'est pas toujours PHP.
PrestaShop : employés et profils. Un « stagiaire logistique » encore SuperAdmin, c'est le même oubli, autre libellé.
Rôles : admin n'est pas le seul problème
Un éditeur qui peut installer des extensions, un shop manager qui peut poser des webhooks, un « SEO » qui édite `robots.txt` via plugin : assez pour déposer ou servir du sale. Après une mission, le rôle utile disparaît avec la mission. On ne « laisse éditeur, c'est plus prudent qu'admin ».
Les mots de passe d'application et les clés REST créés pour un outil de migration restent actifs. Relisez-les. Application passwords.
Principe du moindre privilège : le graphiste n'a pas besoin d'installer des plugins. Le rédacteur n'a pas besoin du FTP. C'est plus facile à tenir en créant le compte juste que de le nettoyer deux ans après. Moindre privilège.
Le compte partagé « pour aller plus vite »
Donner `admin` / `Marque2020!` au stagiaire, c'est rendre la révocation impossible : vous ne pouvez pas supprimer « le » compte sans vous exclure. Créez `prenom-stage`. Toujours. Même pour trois jours. Même si « c'est urgent ». L'urgence passe ; le compte partagé reste.
Même logique pour le panel. Un utilisateur FTP `ftp-marie` se supprime. Le mot de passe du titulaire du compte, une fois communiqué, se tourne — et il aurait dû être distinct. Panel ≠ CMS.
Les accès prestataire s'appliquent au stage : coffre, révocable, pas le SMS du dirigeant.
Quand vous tombez dessus pendant un incident
Vous ouvrez Utilisateurs pour un piratage, et vous trouvez `agence-2019`. Ne l'accusez pas d'emblée. Notez-le, révoquez, tournez. Le malware peut venir d'un plugin ; ce compte est une porte de plus, ouverte. On ferme les portes, on n'écrit pas un roman.
Si les journaux montrent un login de ce compte à l'heure du payload, c'est un indice. Vous le figez. Vous ne le débattez pas sur le serveur en production.
Ne « laissez le compte pour demander à Marie ce qu'elle en pense » pendant que le shell tourne. Marie répondra sur un mail. Le compte, lui, sort ce soir.
Mettre en place une fin de mission réelle
Une checklist de clôture, une page. CMS, FTP, GSC, GTM, newsletter, dépôt Git, 2FA à retirer. Le freelance signe (même un mail) qu'il a détruit ses copies. Vous vérifiez les listes, pas sa parole.
Dans le contrat ou le devis de TMA : les comptes sont nominatifs, la fin de mission entraîne la révocation, un accès permanent se facture et se nomme. Sinon vous offrez une porte à durée indéterminée.
Pour une asso, une mairie, un cabinet : le bénévolat et les stagiaires tournent. La revue trimestrielle des admins est moins glamour qu'un nouveau site, plus utile. C'est de la gouvernance, pas de l'informatique de luxe.
Ce que ça change pour la prochaine fois
Moins de comptes = moins de surface. Quand un incident arrivera vraiment par une extension, vous ne perdrez pas une journée à démêler « est-ce le stage de 2022 ». Vous aurez une liste courte, à jour.
La surveillance alerte sur un nouvel admin. Elle n'alerte pas sur un vieux compte que vous avez décidé de garder. La décision, c'est vous.
Si vous déléguez un nettoyage, mentionnez les comptes que vous reconnaissez. Ça accélère. Ceux que vous ne reconnaissez pas, on les traite comme inconnus, jusqu'à preuve.