Un client a fait intervenir successivement trois prestataires différents sur son serveur en deux ans : une agence pour la mise en place initiale, un développeur indépendant pour une migration, un freelance pour un correctif urgent. Chacun avait reçu le même accès SSH avec la même clé, jamais révoquée entre les missions. Quand un incident est survenu bien plus tard, impossible de savoir lequel des trois avait exécuté la commande à l’origine du problème, ni même si l’un d’eux disposait encore d’un accès actif sans que personne ne s’en souvienne.
Confier un accès SSH ou WP-CLI à un prestataire externe est une nécessité opérationnelle courante, mais elle mérite une discipline précise, faute de quoi elle devient un angle mort de sécurité qui s’accumule au fil des interventions. Voici la checklist que nous appliquons systématiquement.
Une clé SSH individuelle, jamais partagée
- Chaque prestataire génère sa propre paire de clés SSH, la clé privée ne quitte jamais son poste, seule la clé publique est transmise pour être ajoutée au serveur.
- Aucune clé partagée entre plusieurs prestataires ou plusieurs missions, même de la même agence : une clé, une personne, une période d’intervention.
- La clé publique est ajoutée à
authorized_keysavec un commentaire explicite identifiant le prestataire et la date d’ajout, pas seulement une chaîne anonyme.
# dans authorized_keys, un commentaire clair par entrée
ssh-ed25519 AAAA...xyz prestataire-dupont-migration-2025-03Restreindre ce qu’une clé peut exécuter
SSH permet de restreindre les actions autorisées pour une clé précise directement dans le fichier authorized_keys, sans dépendre du bon vouloir du prestataire. Pour une intervention ponctuelle bien définie, la directive command= force l’exécution d’une commande unique, quelle que soit la commande réellement demandée par le client SSH :
command="wp --path=/var/www/site cache flush",no-port-forwarding,\
no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAA...xyz prestataire-cachePour un accès plus large mais encadré, un compte système dédié avec un shell restreint, ou une configuration ForceCommand dans sshd_config limitée à un sous-ensemble de commandes WP-CLI autorisées, réduit la surface d’action sans bloquer le travail légitime prévu.
Des comptes temporaires plutôt que permanents
Pour une intervention ponctuelle (correctif urgent, migration unique), un compte système créé spécifiquement pour la mission, avec une date de fin connue à l’avance, évite d’avoir à se souvenir de le révoquer plus tard :
useradd -m -s /bin/bash -e 2025-04-15 prestataire-migration
L’option -e de useradd fixe une date d’expiration du compte, après laquelle il devient automatiquement inutilisable sans intervention manuelle supplémentaire, un filet de sécurité utile quand la révocation manuelle est oubliée dans le feu de l’action.
Restreindre les commandes WP-CLI sensibles
Au-delà de l’accès SSH lui-même, certaines commandes WP-CLI méritent une attention particulière selon le niveau de confiance accordé au prestataire : wp user create, wp option update sur des options sensibles, ou wp db query qui exécute du SQL arbitraire directement en base. Pour un prestataire dont la mission ne nécessite que des opérations de cache ou de maintenance, ces commandes plus larges n’ont pas de raison d’être accessibles.
Tracer chaque intervention
La traçabilité ne doit pas reposer uniquement sur la mémoire de l’équipe. Plusieurs mécanismes complémentaires permettent de reconstituer après coup qui a fait quoi :
- Les journaux d’authentification SSH du serveur (
/var/log/auth.logou équivalent) conservent la trace des connexions par clé, à condition d’avoir attribué une clé individuelle à chacun. - Un historique de commandes (
auditdou un shell configuré pour journaliser chaque commande exécutée) donne une vue précise de ce qui a été fait pendant la session, pas seulement de la connexion. - Une extension de journal d’activité WordPress (comme celles évoquées dans notre comparatif dédié) complète cette traçabilité côté application, pour les actions effectuées via WP-CLI qui modifient le contenu du site.
La checklist de fin de mission
- Révoquer la clé SSH du prestataire dès la mission terminée, sans attendre une future intervention hypothétique.
- Vérifier qu’aucun compte système temporaire créé pour l’occasion ne subsiste au-delà de sa date prévue.
- Passer en revue les commandes exécutées pendant la mission si un historique est disponible, en particulier pour une intervention urgente réalisée sous pression.
- Documenter dans un registre partagé (même un simple tableau) quel prestataire a eu accès, à quelle période et pour quelle mission.
Depuis que nous tenons ce registre d’accès prestataires à jour, la question « qui avait encore accès à ce serveur » ne prend plus une demi-journée de recherche dans les journaux : la réponse est dans le tableau, à jour, consultée en quelques secondes.
En résumé
Un accès prestataire mal géré est rarement la cause directe d’un incident, mais il complique systématiquement l’investigation quand un incident survient ailleurs, car il ajoute des inconnues à un système déjà sous tension. Une clé individuelle par prestataire, des restrictions de commandes quand c’est possible, des comptes temporaires avec date d’expiration et un registre d’accès à jour forment une discipline simple, peu coûteuse à maintenir, qui referme cet angle mort progressivement.
