Moindre privilège : auditer les comptes et rôles d’un site client

En reprenant la gestion d’un site vieux de plusieurs années, l’un des premiers réflexes à adopter consiste à ouvrir l’écran Utilisateurs et à regarder, sans a priori, qui a accès à quoi. Le résultat surprend presque à chaque fois : d’anciens prestataires jamais désactivés, un stagiaire parti depuis longtemps toujours en administrateur, des comptes créés pour un test ponctuel jamais supprimés.

Cette accumulation n’est pas une négligence isolée : elle découle du principe même selon lequel il est plus rapide d’accorder un accès large « pour ne pas avoir de problème » que de réfléchir au juste niveau de droits nécessaire. Le principe du moindre privilège inverse cette logique : chaque compte ne doit disposer que des droits strictement nécessaires à son usage réel, ni plus. Voici la check-list que nous suivons pour cet audit.

1. Lister tous les comptes existants et leur dernière connexion

WP-CLI permet d’obtenir rapidement la liste complète des comptes avec leur rôle :

wp user list --fields=ID,user_login,user_email,roles,user_registered

La date de dernière connexion n’est pas stockée nativement par WordPress ; elle nécessite soit une extension de journalisation déjà en place, soit l’ajout ponctuel d’un enregistrement sur le hook wp_login avant de démarrer l’audit, pour disposer de cette information lors du prochain passage.

2. Identifier les comptes administrateurs et questionner chacun

wp user list --role=administrator --fields=ID,user_login,user_email

Pour chaque compte administrateur listé, une question simple : cette personne a-t-elle réellement besoin d’un accès complet au site — gestion des extensions, des utilisateurs, des réglages globaux — ou son usage réel se limite-t-il à la rédaction de contenu, auquel cas un rôle editor suffirait largement ?

3. Comprendre les six rôles natifs avant de réattribuer

• Administrator : contrôle total, y compris l’installation d’extensions et de thèmes — capable d’exécuter du code sur le serveur via ce biais.
• Editor : gère tout le contenu du site, y compris celui des autres auteurs, sans accès aux réglages ni aux extensions.
• Author : publie et gère ses propres articles uniquement.
• Contributor : rédige des articles qui restent en attente de relecture, sans droit de publication directe.
• Subscriber : gère uniquement son propre profil, généralement utilisé pour les commentaires ou un accès membre restreint.

Un rôle mal choisi accorde presque toujours plus que nécessaire : attribuer administrator à un rédacteur qui ne fait que publier des articles est une pratique courante, mais elle multiplie sans raison le nombre de comptes capables d’installer une extension, donc d’exécuter du code sur le serveur.

4. Désactiver plutôt que conserver « au cas où »

Face à un compte visiblement inutilisé depuis longtemps, la tentation est de le laisser en l’état par prudence. C’est l’inverse qui protège réellement le site :

wp user update 42 --role=subscriber
# ou, si le compte n'a plus aucune utilité
wp user delete 42 --reassign=1

L’option --reassign permet de transférer le contenu déjà publié par ce compte vers un autre utilisateur, évitant de perdre l’attribution des articles existants lors de la suppression.

5. Vérifier les comptes créés par des extensions

Certaines extensions créent des comptes techniques pour leur propre fonctionnement (intégration avec un service externe, compte de support). Ces comptes méritent le même examen que les comptes humains : leur rôle est-il proportionné à leur usage réel, et l’extension qui les a créés est-elle toujours active sur le site ?

6. Documenter l’audit pour qu’il reste utile

Un audit de comptes fait une seule fois se dégrade dès le mois suivant ; c’est sa répétition régulière, documentée, qui en fait un outil de sécurité durable.

Consigner la date de l’audit, les comptes désactivés et la justification de chaque rôle attribué permet, au passage suivant, de repartir d’une base claire plutôt que de tout réexaminer depuis zéro. Un simple tableau partagé avec le client suffit pour ce suivi.

En résumé

Auditer les comptes et les rôles d’un site repris en gestion révèle presque systématiquement des accès superflus accumulés au fil du temps. La démarche décrite ici — lister, questionner chaque administrateur, réattribuer un rôle proportionné, désactiver sans hésiter, documenter — réduit concrètement la surface d’attaque d’un site sans toucher une seule ligne de code.