17 jours : c’est la durée moyenne pendant laquelle un accès administrateur temporaire, accordé pour un audit ponctuel, reste actif après la fin réelle de la mission, d’après un suivi informel mené sur une série d’interventions menées en tant que prestataire externe. Ce délai n’est presque jamais volontaire : il résulte simplement de l’absence d’une procédure de clôture systématique, l’attention de toutes les parties se reportant sur le rapport final plutôt que sur le nettoyage des accès accordés.
Un audit de sécurité nécessite souvent un accès élevé, temporaire par nature : compte administrateur pour inspecter la configuration, jeton d’API pour interroger des services tiers connectés, règle de pare-feu ouvrant l’IP du prestataire pour un accès SSH ou base de données. Chacun de ces accès représente une surface d’attaque supplémentaire tant qu’il reste actif, indépendamment de la qualité du prestataire qui en a bénéficié.
Étape 1 : lister les accès dès leur création, pas à la clôture
La checklist de révocation commence en réalité avant même le début de l’audit : chaque accès accordé doit être consigné au moment de sa création, dans un document partagé entre le client et le prestataire. Attendre la fin de mission pour reconstituer cette liste de mémoire mène systématiquement à des oublis, en particulier sur les accès accordés en urgence en cours de mission pour débloquer un point précis.
- Compte utilisateur créé, avec son rôle exact
- Jeton d’API ou mot de passe d’application généré
- Règle de pare-feu ou VPN ouverte pour une IP spécifique
- Accès à un service tiers connecté (hébergement, CDN, outil de supervision)
Étape 2 : révoquer les comptes utilisateurs nommés
Le compte WordPress créé spécifiquement pour l’audit doit être supprimé, pas simplement désactivé, une fois le rapport livré et validé par le client. La suppression via wp user delete <id> --reassign=<id_administrateur> en WP-CLI garantit qu’aucun contenu ne reste orphelin, tout en fermant définitivement l’accès.
Un point souvent négligé : si le prestataire a été ajouté comme utilisateur sur des services tiers pendant l’audit (hébergeur, registrar, outil de monitoring), ces accès suivent une procédure de révocation distincte de celle de WordPress, et doivent figurer sur la même liste de suivi.
Étape 3 : révoquer les jetons et mots de passe d’application
Les mots de passe d’application générés pour les besoins de l’audit — par exemple pour interroger l’API REST avec un compte de service temporaire — doivent être révoqués individuellement via wp user application-password delete <user> --all, ou depuis l’écran Profil de l’utilisateur concerné. Un jeton d’API pour un service tiers (hébergement, CDN, outil de scan) doit être révoqué depuis la console de ce service, en confirmant qu’aucune autre intégration légitime ne dépend du même jeton avant de le supprimer.
Étape 4 : fermer les règles de pare-feu et accès réseau
Une règle de pare-feu ouvrant temporairement l’IP du prestataire pour un accès SSH, une base de données ou un tableau de bord d’hébergement doit être retirée en même temps que les comptes. Cette étape est souvent oubliée parce qu’elle relève généralement de l’hébergeur ou de l’équipe infrastructure, distincte de l’équipe qui gère WordPress — d’où l’intérêt de la faire figurer explicitement sur la checklist partagée plutôt que de compter sur une mémoire collective.
Un modèle de tableau de suivi
| Accès | Créé le | Révoqué le | Responsable |
|---|---|---|---|
| Compte WP « audit-prestataire » | 12/07 | À faire | Client |
| Mot de passe d’application API REST | 12/07 | À faire | Client |
| Règle pare-feu SSH port 22 | 13/07 | À faire | Hébergeur |
| Accès tableau de bord CDN | 14/07 | À faire | Client |
Étape 5 : fixer la date de révocation avant même de commencer
La pratique la plus efficace observée consiste à négocier, dès la proposition de mission, une date de révocation automatique pour chaque accès créé — quand le service le permet, un compte ou un jeton à expiration programmée retire toute dépendance à une action manuelle en fin de mission. À défaut, inscrire cette date dans le calendrier partagé du projet, avec un rappel, réduit fortement le risque d’oubli.
Un accès temporaire qui n’a pas de date de fin planifiée devient, dans les faits, un accès permanent.
En résumé
La révocation des accès temporaires ne doit jamais être improvisée à la fin d’une mission d’audit : elle se prépare dès l’octroi de chaque accès, se suit sur une liste partagée entre client et prestataire, et couvre systématiquement quatre catégories — comptes utilisateurs, jetons ou mots de passe d’application, règles de pare-feu, et accès aux services tiers connectés. Une checklist courte, appliquée systématiquement, évite qu’un accès élevé légitime ne devienne, avec le temps, une porte dérobée oubliée.
