Un accès serveur pour un prestataire, pas toutes les clés

Un prestataire doit intervenir sur votre serveur pour résoudre un problème précis. Lui transmettre le compte principal semble rapide, mais cet accès peut aussi ouvrir vos sauvegardes, votre messagerie technique et plusieurs applications sans rapport avec la mission.

La bonne question n’est pas de savoir si la personne est digne de confiance. Il faut pouvoir expliquer ce qu’elle peut faire, retrouver ses interventions et fermer proprement son accès lorsque le travail est terminé.

Décrire l’intervention avant de créer le compte

Listez les applications concernées, le type d’action et la période d’intervention. Consulter un journal d’erreur ne demande pas forcément les mêmes droits que modifier un service ou restaurer une base.

Précisez aussi les frontières : aucun changement sur les autres sites, aucune suppression de données, aucun redémarrage pendant une opération commerciale sensible sans accord. Cette définition permet au prestataire de signaler clairement quand le diagnostic nécessite une autorisation supplémentaire.

Éviter les identifiants partagés

Un accès nominatif permet d’associer une intervention à une personne et de retirer ses droits sans perturber les autres intervenants. Les mécanismes d’authentification et d’élévation de privilèges doivent être adaptés au serveur et testés avant la mission.

Le guide d’administration sécurisée de l’ANSSI fournit des principes pour organiser les accès d’administration. L’objectif n’est pas de recopier une architecture complexe dans une petite entreprise, mais d’éviter un accès permanent et indifférencié à tout le système.

Donner les droits nécessaires, progressivement

Dans un exemple fictif, une boutique demande de réparer son formulaire. Le prestataire commence avec les fichiers et journaux concernés sur un environnement de test. Si le problème se situe dans un service partagé, l’accès complémentaire est accordé pour cette étape et documenté.

Une restriction excessive peut aussi ralentir inutilement l’intervention. Préparez donc une personne capable de valider rapidement un besoin justifié. La sécurité fonctionne mieux avec une procédure claire qu’avec des blocages improvisés au moment de l’incident.

Préparer la reprise avant les modifications

Vérifiez l’existence d’un point de retour adapté aux éléments qui vont changer. Une sauvegarde globale ancienne ne permet pas nécessairement d’annuler un changement récent sans perdre des données métier. Le prestataire doit savoir comment la restauration sera décidée et réalisée.

Les commandes sensibles, changements de configuration et interruptions doivent être consignés à un niveau utile. Ne transformez pas pour autant les journaux en dépôt de mots de passe ou de données clients. Notre article sur les sauvegardes et la restauration détaille la différence entre disposer d’une copie et savoir reprendre l’activité.

Fermer la mission, pas seulement le ticket

À la fin, retirez les accès temporaires et vérifiez les connexions annexes éventuellement créées. Récupérez la liste des changements, les tests effectués et les points restant à surveiller. L’entreprise doit conserver la maîtrise des comptes d’hébergement et des moyens de récupération.

Un accompagnement Linux et cloud utile laisse un système plus compréhensible et des responsabilités identifiables. Il ne doit pas créer une nouvelle dépendance à un compte personnel dont personne ne connaît vraiment l’étendue.