# Révoquer tous les accès temporaires accordés pendant un audit, avant la clôture de mission > Un audit de sécurité laisse souvent des accès élevés actifs bien après la fin de la mission. Voici la checklist systématique à dérouler avant de clôturer. - Auteur : WordPress Développement - Publié le : 2023-08-11 - Mis à jour le : 2023-08-11 - Catégorie : Sécurité - URL : https://www.wpmoderne.fr/securite/revoquer-acces-temporaires-fin-audit/ ## L’essentiel - Lister les accès accordés dès leur création, pas à la fin - Vérifier comptes, jetons API et règles pare-feu, pas seulement les mots de passe - Fixer une date de révocation avant même de commencer l'audit 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 --reassign=` en WP-CLI garantit qu'aucun contenu ne reste orphelin, tout en fermant définitivement l'accès. > L'essentiel à retenir : Lister les accès accordés dès leur création, pas à la fin ; Vérifier comptes, jetons API et règles pare-feu, pas seulement les mots de passe ; Fixer une date de révocation avant même de commencer l'audit 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 --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.