Vous n’allez pas appliquer une astuce isolée. Vous allez observer, formuler une hypothèse, tester sans masquer le symptôme, puis conserver une preuve et un retour arrière.
Le problème concret
Un site accumule des comptes administrateurs, accès FTP, clés API et connexions hébergeur créés au fil des prestataires. Certains comptes sont partagés ou appartiennent à des personnes parties. Personne ne peut dire rapidement qui possède quel accès ni pourquoi.
Un accès oublié suffit à contourner les protections ajoutées dans WordPress. Les comptes partagés empêchent d’attribuer une action. La réduction de surface commence par l’inventaire, le moindre privilège et la maîtrise des moyens de récupération.
Ce qu’il faut comprendre
Chaque accès doit être nominatif, justifié, protégé et révocable. Le rôle correspond aux tâches réellement nécessaires, pas au confort. Les accès externes — hébergeur, domaine, DNS, SMTP, CDN, sauvegarde, paiement — sont aussi importants que les comptes WordPress.
Avant d’intervenir
Ne commencez pas par appliquer une astuce. Reproduisez la situation, notez la date, l’URL, le compte utilisé et les versions des composants concernés. Travaillez sur une copie lorsque la manipulation peut toucher l’affichage, les données, les commandes ou les accès. Vérifiez qu’une sauvegarde récente existe et que vous savez quelle partie restaurer. Prenez une capture de l’état initial et copiez les valeurs que vous allez modifier. Une intervention reste ainsi comparable et annulable.
Diagnostic guidé
Avant de modifier le site, rassemblez des faits comparables. Procédez dans cet ordre :
- Exportez les utilisateurs WordPress avec rôle, dernière activité disponible et propriétaire.
- Inventoriez hébergement, domaine, DNS, FTP/SFTP, base, SMTP, CDN, paiement, sauvegarde et services connectés.
- Repérez comptes partagés, adresses génériques, anciens prestataires, clés sans date et administrateurs sans justification.
- Vérifiez les moyens de récupération : adresse du propriétaire, double authentification, codes de secours et contact support.
Procédure détaillée
- Attribuer un propriétaire. Chaque compte et secret reçoit un responsable, un usage, une date de création ou révision et une méthode de révocation.
- Réduire les rôles. Créez des comptes séparés et accordez le rôle minimal. Un rédacteur ou gestionnaire de boutique n’a pas besoin d’installer des extensions.
- Renforcer les comptes sensibles. Activez une authentification forte compatible avec les flux utilisés, stockez les codes de secours et testez la récupération avant de l’imposer.
- Révoquer progressivement. Désactivez d’abord les accès inutiles, surveillez, puis supprimez lorsque leur absence est confirmée. Faites tourner les secrets partagés après le départ d’un intervenant.
- Planifier la revue. Révisez l’inventaire à chaque changement d’équipe et à intervalle régulier. Aucun compte ne doit rester sans propriétaire.
Cas pratique
Un ancien développeur n’apparaît plus dans WordPress, mais son accès SFTP partagé fonctionne encore et une clé d’administration CDN est conservée dans un ancien e-mail. L’inventaire élargi révèle ces chemins. Un compte nominatif est créé pour le prestataire actuel, les secrets sont renouvelés et les comptes partagés sont supprimés après test.
Un site accumule des comptes administrateurs, accès FTP, clés API et connexions hébergeur créés au fil des prestataires.
Le registre des accès, la liste des révocations et la procédure de récupération administrateur. avec des critères vérifiables et un retour arrière documenté.
Interpréter les résultats
- Si le propriétaire d’un accès est inconnu, suspendez-le d’abord lorsque le service le permet.
- Si une intégration dépend d’une clé partagée, créez une nouvelle clé, basculez et vérifiez avant de révoquer l’ancienne.
- Si la double authentification bloque un flux légitime, corrigez ou documentez ce flux plutôt que de désactiver la protection globalement.
Cartographier les accès sensibles
Remplacez les doubles accolades avec vos informations, puis copiez le prompt.
Tu es un assistant de diagnostic WordPress. Tu ne dois inventer aucun fait, réglage, résultat ou version.
OBJECTIF
Crée un inventaire des accès et propose une réduction progressive des privilèges sans bloquer les tâches légitimes.
CONTEXTE À UTILISER
– WordPress et administrateurs : {{à compléter}}
– hébergement et registrar : {{à compléter}}
– DNS et e-mails : {{à compléter}}
– sauvegardes : {{à compléter}}
– prestataires : {{à compléter}}
– méthodes de récupération : {{à compléter}}
CONSIGNES
1. Commence par lister les informations manquantes qui empêchent une conclusion fiable.
2. Classe les hypothèses du test le moins risqué au plus risqué.
3. Pour chaque hypothèse, indique le contrôle, la preuve attendue et ce qui l’invaliderait.
4. Sépare clairement observation, hypothèse et recommandation.
5. Ajoute une sauvegarde préalable, une procédure de retour arrière et une vérification après intervention.
6. Si une action peut toucher la production, les commandes, les comptes ou les données, demande un test sur une copie.
FORMAT DE RÉPONSE ATTENDU
– matrice système/personne/privilège
– comptes à révoquer ou réduire
– ordre sécurisé des changements
– test de récupération à effectuer
Termine par : « Ce qui doit être validé par un humain avant toute action ».Contrôle humain obligatoire : ne transmettez aucun mot de passe, clé, donnée client ou information de paiement ; vérifiez chaque proposition avant de l’appliquer.
Exercice à réaliser
Construisez un registre couvrant WordPress et huit services externes. Pour chaque accès, indiquez propriétaire, rôle, protection, dernière vérification et action. Traitez ensuite un compte test selon la procédure de révocation.
Livrable : le registre des accès, la liste des révocations et la procédure de récupération administrateur.
Documenter la décision
Dans votre compte rendu, séparez l’observation, l’hypothèse, le test, le résultat et la décision. Indiquez aussi les hypothèses écartées : elles évitent de recommencer le même diagnostic. Joignez les mesures ou captures avant/après, mais retirez les données personnelles, clés, jetons et informations de paiement. Une autre personne doit pouvoir comprendre ce qui a été testé, reproduire le contrôle et exécuter le retour arrière sans dépendre de votre mémoire.
Critères de réussite
- Tous les administrateurs sont nominatifs.
- Les secrets partagés identifiés sont renouvelés ou planifiés.
- Les codes de secours sont accessibles au bon responsable.
- La revue possède une prochaine date.
Retour arrière
Conservez un compte de secours contrôlé avant les révocations. Si une fonction légitime est interrompue, réactivez temporairement l’accès identifié ou utilisez la nouvelle clé préparée. Ne restaurez pas un compte partagé sans définir son propriétaire.
Erreurs fréquentes
Supprimer avant d’avoir inventorié les dépendances.
Réutiliser un mot de passe entre services.
Oublier domaine, DNS, SMTP ou API.
Activer une protection sans tester la récupération.
Approfondissement : raisonner comme lors d’une intervention
La surface d’attaque inclut WordPress, mais aussi l’hébergement, le registrar, les boîtes e-mail, les sauvegardes, les outils de déploiement et les comptes des prestataires. Un compte administrateur supprimé dans WordPress ne suffit pas si une ancienne personne conserve le panneau d’hébergement. Classez chaque accès par propriétaire, privilège, méthode d’authentification et procédure de récupération.
Matrice de tests et de preuves
Ne cherchez pas à confirmer immédiatement votre première intuition. Traitez chaque point de diagnostic comme une hypothèse concurrente. Pour chaque ligne, conservez une preuve datée et indiquez si elle confirme, affaiblit ou ne permet pas de départager l’hypothèse.
| Hypothèse | Contrôle | Preuve attendue |
|---|---|---|
| H1 | Exportez les utilisateurs WordPress avec rôle, dernière activité disponible et propriétaire. | Inventaire de tous les systèmes et propriétaires, pas seulement WordPress. |
| H2 | Inventoriez hébergement, domaine, DNS, FTP/SFTP, base, SMTP, CDN, paiement, sauvegarde et services connectés. | Journal des connexions ou dernière utilisation des comptes privilégiés. |
| H3 | Repérez comptes partagés, adresses génériques, anciens prestataires, clés sans date et administrateurs sans justification. | Test d’une tâche réelle avec le rôle minimal proposé. |
| H4 | Vérifiez les moyens de récupération : adresse du propriétaire, double authentification, codes de secours et contact support. | Exercice documenté de récupération par un second responsable. |
Scénario avancé
Un audit découvre trois comptes administrateurs génériques, un accès FTP commun et un registrar lié à l’e-mail d’un ancien prestataire. Les comptes sont attribués nominativement, le FTP remplacé par des accès individuels et le registrar transféré après validation d’un second propriétaire. Chaque révocation est testée, et un exercice de récupération confirme que l’organisation ne dépend plus d’une seule personne.
Rejouez ensuite le scénario dans les mêmes conditions, puis dans une condition volontairement différente. Cette seconde passe vérifie que le résultat vient bien de la modification et non d’un cache, d’une session, d’un délai externe ou d’une coïncidence.
Contrôle de compréhension
Quelle information doit être obtenue avant toute modification ?
La liste des systèmes, personnes, privilèges, secrets et mécanismes de récupération.
Quel résultat invaliderait votre hypothèse principale ?
Une tâche légitime impossible avec le rôle réduit ou nécessitant le partage d’un compte.
Quelle preuve doit rester dans le compte rendu ?
L’inventaire daté, les révocations, les exceptions temporaires et le test de reprise.
Revue finale à froid
Revenez sur l’intervention après une nouvelle connexion et, si le sujet le permet, depuis un autre navigateur ou un autre compte. Relisez votre rapport sans vous fier à votre mémoire : le contexte, les valeurs initiales, l’action, la preuve, la décision et le retour arrière doivent être compréhensibles. Si un de ces éléments manque, la leçon n’est pas encore terminée, même si le symptôme semble avoir disparu.
↓Télécharger la fiche de travail (PDF)PDF↓Version éditable (Markdown)MD