Ce qu'un audit de reprise d'hébergement trouve en premier
Reprendre un hébergement dont personne n'a la documentation ressemble à un inventaire de grenier : on ouvre, on note, et l'on découvre surtout ce qui n'était pas prévu. Dans la pratique, les mêmes cinq choses reviennent, dans le même ordre, quel que soit le serveur. Les connaître évite de perdre les premières heures à chercher ailleurs.
L'inventaire : ce qui tourne, et ce que personne ne sait plus
La première heure d'un audit ne produit aucune correction : elle produit une liste. Quels services écoutent, sous quel compte, pour quel site, avec quel certificat, et qui s'en sert réellement. Cette liste est presque toujours plus longue que prévu, parce qu'elle contient ce qui a été installé pour essayer, puis oublié. Un serveur en production depuis quatre ans cache en moyenne deux ou trois services dont le propriétaire lui-même avait perdu le souvenir.
Le classement est aussi important que la liste. Un service utile et à jour, un service utile et abandonné, un service oublié : les trois n'appellent pas le même geste. Le premier se documente, le second se met à jour ou se remplace, le troisième se ferme. Confondre les trois est la meilleure façon de casser une chose qui marchait.
Les ports : ce qui répond depuis Internet
Deuxième découverte : la surface exposée. Un site web a besoin du port 443, parfois du 80 pour la redirection. Tout le reste est une décision, pas une fatalité. Les bases de données, les interfaces d'administration, les panneaux de statistiques et les serveurs de développement écoutent souvent sur toutes les interfaces alors qu'ils ne devraient écouter que sur la boucle locale.
La correction est rapide et sans risque quand elle est faite dans le bon ordre : d'abord vérifier depuis l'extérieur ce qui répond réellement, ensuite fermer, puis contrôler de nouveau. Fermer un port que personne n'utilise ne casse rien. Fermer un port utilisé par un script oublié casse quelque chose, d'où l'intérêt de l'inventaire de la première heure.
Les versions : la date de la dernière mise à jour
Troisième découverte, et la plus ennuyeuse à corriger : l'âge du logiciel. Système, serveur web, langage, base de données. Une machine à jour se reconnaît à une chose simple : la date de la dernière mise à jour de sécurité, qui doit être récente et vérifiable. Quand cette date remonte à huit mois, la question n'est plus de savoir si la machine est vulnérable, mais depuis combien de temps.
La mise à jour elle-même demande une précaution que les procédures oublient souvent : sauvegarder avant, et savoir revenir. Une mise à jour de langage ou de base de données casse parfois une extension oubliée. Sans point de retour testé, l'exploitant préfère reporter, et le report devient permanent.
Les certificats et les noms : ce qui expire sans prévenir
Quatrième découverte : les dates d'expiration. Certificats, noms de domaine, clés de messagerie. Ce sont les seules pannes parfaitement prévisibles d'un hébergement, et pourtant parmi les plus fréquentes. Un certificat expiré rend le site inaccessible à tous les visiteurs en même temps, sans dégradation progressive qui aurait alerté quelqu'un.
La correction tient en deux gestes : automatiser le renouvellement, et surveiller la date d'expiration depuis l'extérieur. Surveiller depuis l'extérieur est essentiel : un renouvellement automatique qui échoue silencieusement ne se voit que le jour où il n'a plus de marge. Un contrôle daté qui alerte à trente jours laisse le temps de réagir.
Les accès : qui peut entrer, et par où
Cinquième découverte : les comptes. Comptes créés pour un prestataire qui n'intervient plus, clés d'accès partagées par courriel, mots de passe identiques sur trois services, accès administrateur sans second facteur. Un audit sérieux ne cherche pas à faire peur : il compte. Le nombre de comptes ayant un accès administrateur est un indicateur plus parlant que n'importe quel discours sur la sécurité.
La remise en ordre se fait par retrait avant d'être par ajout : fermer les accès inutiles d'abord, poser ensuite un second facteur et des comptes nominatifs. L'ordre inverse crée de la complexité sans réduire le risque.
La sauvegarde et la procédure : ce qui manque le plus
Enfin, ce qui manque presque toujours : une sauvegarde dont quelqu'un connaît la date du dernier essai de restauration, et une procédure écrite pour redémarrer le site ailleurs. Sans procédure, la sauvegarde la plus fraîche ne sert à rien : personne ne sait dans quel ordre remonter les services, quels fichiers de configuration remettre, ni comment rétablir les noms de domaine.
Écrire cette procédure prend une heure et se relit une fois par an. C'est le document le plus rentable d'un hébergement, et celui que personne ne facture, parce qu'il ne se voit pas.
L'audit se termine par un document, pas par un rapport verbal
Un audit dont le résultat reste oral n'a servi à rien : dans six mois, la personne qui reprendra la machine repartira de zéro. Le livrable attendu tient en quelques pages : la liste des services et de leur propriétaire, les ports ouverts et leur justification, les versions et les dates de mise à jour, les expirations connues, les comptes administrateurs, et l'emplacement des sauvegardes avec la date du dernier essai de restauration.