Moins de comptes admin : le réglage qui évite la moitié des retours
Un graphiste n'a pas besoin d'être administrateur. Un ancien stagiaire non plus. Après un incident, passez les rôles en revue : c'est gratuit, rarement fait, et ça évite une bonne part des retours. Moins de comptes privilégiés, moins de sessions à révoquer.
Un graphiste n'a pas besoin d'être admin. Un ancien stagiaire non plus. Après incident, passez les rôles en revue. C'est gratuit et rarement fait.
Pourquoi trop d'admins explique tant de seconds appels
Quand tout le monde est administrateur, un seul mot de passe faible ou une seule session volée suffit. L'attaquant n'a pas besoin d'une faille d'extension : il a déjà le droit d'installer un plugin, d'éditer un fichier, de créer un second admin. Dans les sites que nous reprenons, la home a souvent été « nettoyée » deux fois ; le compte `demo` ou `agence2019` était encore là.
Le moindre privilège n'est pas une doctrine militaire. C'est une liste courte : qui peut installer, qui peut publier, qui peut seulement éditer ses pages. Chaque personne au-dessus de ce besoin est une surface. Après un piratage, cette revue coûte une heure et évite une nuit.
Ce n'est pas un substitut au nettoyage. Un site encore infecté avec moins d'admins reste infecté. C'est le geste de refermeture le moins cher, une fois les fichiers comparés. Le guide des premiers gestes place le changement de mots de passe avant cette revue ; l'ordre compte.
Qui n'a vraiment pas besoin du rôle le plus haut
Le graphiste qui change des images : éditeur ou un rôle sur mesure, pas administrateur. Le rédacteur : auteur ou éditeur. Le stagiaire de l'été dernier : aucun compte. Le consultant SEO qui « a besoin de Yoast » : souvent un rôle inférieur suffit ; s'il installe des plugins, c'est un autre contrat, temporaire, révocable.
L'agence qui maintient le site a besoin d'un accès, pas forcément de cinq. Un compte nominatif par personne, pas `agence` partagé. Quand le prestataire change, on révoque. Ancien développeur qui a encore les accès et stagiaire ou freelance admin couvrent les cas les plus fréquents.
Les comptes techniques (newsletter, ERP, « connecteur ») n'ont pas besoin du rôle admin du CMS. Une clé d'API limitée, un utilisateur applicatif, un FTP jailed sur un dossier : c'est plus étroit, c'est plus long à poser, c'est ce qui évite qu'un connecteur oublié réécrive `wp-config`.
- Un compte nominatif, jamais un prénom générique partagé.
- Rôle le plus bas qui permet le travail du jour.
- Date de fin prévue pour les accès temporaires.
La revue juste après l'incident
Exportez la liste des utilisateurs avant d'en supprimer. Un admin créé à 3 h du matin date l'entrée. Cette date sert à l'hébergeur, à Google, parfois à l'assureur. Supprimer trop vite pour « faire propre » détruit la chronologie. Notez, puis retirez, puis changez votre propre mot de passe — dans cet ordre, pour ne pas laisser une session ouverte recréer le compte.
Cherchez les e-mails jetables, les logins qui ne sont personne, les rôles élevés sans activité métier. Sur WordPress, les utilisateurs n'apparaissent pas tous dans « Extensions » : ouvrez aussi les mots de passe d'application. Voir application passwords oubliés.
Si vous n'avez plus accès à l'admin, passez par la base ou le panel. Ne recréez pas un super-admin « pour avancer » sans révoquer les autres ensuite. Un ticket factuel chez l'hébergeur (compte suspendu) peut débloquer un accès lecture le temps de lister.
WordPress, Joomla, PrestaShop : les équivalents
WordPress : Administrateur, Éditeur, Auteur, Contributeur, Abonné. Boutique : les rôles WooCommerce (boutique, comptable) n'ont pas besoin d'installer des plugins. Joomla : Super User est le piège ; Manager et Admin ne sont pas interchangeables. Un second Super User à e-mail jetable est un signal d'accès, pas un oubli de stagiaire. Voir Joomla : Super User et /images.
PrestaShop : employés et profils. Un profil « Traducteur » qui a le droit modules est un Super User déguisé. Magento : rôles ACL, clés d'intégration. Drupal : rôles et permissions ; un rôle « editor » avec `administer modules` est un admin. Site PHP sur mesure : souvent un seul compte FTP et un seul admin maison — c'est l'inverse du moindre privilège. Cartographiez avant d'effacer. Site PHP piraté.
Dans tous les cas, le critère n'est pas le nom du rôle. C'est : peut-il installer du code ? peut-il lire la config ? peut-il créer un pair ? Si oui, c'est un privilège à justifier.
Comptes oubliés : agence, stagiaire, freelance
Les accès survivent aux contrats. L'agence de 2018, le freelance d'une homepage, le stagiaire qui « devait juste mettre les photos ». Après un incident, écrivez à ceux que vous reconnaissez : « nous révoquons, redemandez si besoin ». Silence ou e-mail mort : révocation sans débat.
Un prestataire qui refuse un compte nominatif et exige `admin` / `admin` partagé n'est pas un critère de qualité. Choisir un prestataire de nettoyage : accès révocable, constat écrit, pas de mots de passe personnels demandés avant devis.
Les comptes « urgence » créés pendant l'attaque (support de l'hébergeur, ami informaticien) doivent avoir une date de fin. Sinon ils deviennent le prochain oubli. Notez-les dans le même tableau que les extensions abandonnées.
Sessions, clés et mots de passe d'application
Changer le mot de passe admin sans révoquer les sessions laisse une fenêtre. WordPress : régénérer les clés AUTH dans `wp-config` si besoin, déconnecter tout le monde. Application passwords et jetons WooCommerce / REST survivent au mot de passe principal. Révoquez ce que vous ne reconnaissez pas.
PrestaShop : clés webservice. Magento : intégrations. Drupal : clés et consumers. Un connecteur « Slack » ou un Zapier oublié est un admin qui ne se voit pas dans la liste des prénoms. Clés REST WooCommerce en clair et webservice PrestaShop détaillent ces angles.
Search Console, Ads, Stripe, Brevo : ce ne sont pas des rôles CMS, mais le même principe. Une clé inconnue se révoque. Un utilisateur Google « à vie » sur la propriété du domaine se retire. Le piratage du site n'implique pas automatiquement ces comptes — encore faut-il vérifier qu'ils n'ont pas le même mot de passe.
Le même principe côté panel et FTP
Le panel d'hébergement est le rôle le plus haut de tous. Un graphiste n'en a pas besoin. Un FTP jailed sur `wp-content/uploads` suffit souvent pour les médias. Des comptes FTP « backup », « agence », « old » : listez-les dans cPanel ou Plesk, révoquez. Si le panel a été forcé, tous les sites du compte suivent. Voir cPanel ou Plesk forcé.
Le mot de passe d'hébergement doit être distinct de l'admin CMS et de la messagerie. Mot de passe hébergement différent du CMS. Si c'était le même, partez du principe que tout a été lu.
SSH : pas de root au quotidien, clés plutôt que mot de passe, utilisateurs nominatifs. Sur un VPS, un « nettoyage WordPress » ne suffit pas si root a été pris. VPS compromis.
- Panel : le moins de personnes possible.
- FTP / SFTP nominatifs, dossiers bornés.
- SSH : pas de mot de passe root partagé dans un email.
En faire une habitude, pas un serment du lundi
Une revue trimestrielle : utilisateurs CMS, FTP, panel, clés API. Dix minutes si la liste est courte. C'est le même rituel que la liste des extensions abandonnées. Les deux tableaux se tiennent ensemble.
La 2FA se pose après la revue, pas à la place. Un second facteur sur un compte `admin` partagé par cinq personnes n'est plus un second facteur. Nominatif d'abord, 2FA ensuite.
Si la revue révèle plus de comptes que de personnes dans l'entreprise, vous avez déjà le diagnostic. Créer un espace permet de faire constater l'incident ; la revue des rôles, vous pouvez la commencer ce soir, sans outil payant.