Octobre, c'est le Mois de la sensibilisation à la cybersécurité, et la plupart des conseils que tu liras ce mois-ci s'adressent aux entreprises qui disposent d'une équipe dédiée à la sécurité. Si tu gères ton propre VPS, ton propre serveur dédié ou ton compte revendeur, tu n'en as probablement pas. Tu n'as que toi-même, peut-être un développeur, et une longue liste de choses qui n'ont rien à voir avec la sécurité.
La bonne nouvelle, c'est que la plupart des incidents liés aux serveurs sont dus à une poignée de failles récurrentes. Ce guide te propose cinq questions qui les couvrent toutes. Chacune d'entre elles explique pourquoi c'est important, propose un petit test d'auto-évaluation et te donne une action à mettre en œuvre ce mois-ci. Tu peux les passer toutes en un après-midi.
1. Tu pourrais remettre ton site en ligne aujourd'hui ?
Presque tout le monde fait des sauvegardes. Mais très peu de gens en ont déjà restauré une. C'est là que le bât blesse : une sauvegarde peut afficher « réussie » pendant des mois alors que la copie est incomplète, stockée sur le même serveur qu'elle est censée protéger, ou remplacée avant même que tu ne t'en rendes compte.
La plupart des restaurations ne sont pas dues à des attaques. Elles sont souvent causées par une mise à jour de plugin qui a mal tourné, un dossier supprimé ou une migration qui a mal tourné un vendredi après-midi. Quoi qu’il en soit, la question reste la même : en combien de temps peux-tu revenir à la situation d’avant ?
Petit test rapide
- Tu sais exactement où tes sauvegardes sont stockées ? Est-ce que c'est ailleurs que sur le serveur lui-même ?
- As-tu restauré une sauvegarde au cours des six derniers mois ?
- Tu gardes suffisamment d'historique pour revenir à une version antérieure à l'apparition d'un problème ?
Une chose à faire ce mois-ci : choisis un site qui n'est pas essentiel et restaure-le. Chronomètre le temps que ça prend et vérifie ce qui a été restauré.
Pour en savoir plus : La qualité de ton plan de continuité dépend de ta dernière restauration
2. Qui peut accéder à ton serveur et à tes comptes en ce moment même ?
Chaque connexion, c'est une porte. Au fil du temps, les serveurs accumulent des portes dont personne ne se souvient avoir ouvertes : la clé SSH d'un ancien développeur, le compte d'accès au panneau de contrôle d'un prestataire, un identifiant d'administrateur partagé par toute l'équipe.
Les pirates n'ont pas toujours besoin de s'introduire dans un système quand ils disposent déjà d'un identifiant valide. Les identifiants volés et réutilisés sont présents dans une grande partie des violations de données, souvent bien après que la personne à qui ils appartenaient n'ait plus besoin d'y accéder.
Petit test rapide
- Pourrais-tu me donner la liste de toutes les personnes qui ont accès à ton compte d'hébergement, au SSH, au panneau de contrôle et à l'interface d'administration du CMS ?
- L'authentification multifactorielle est-elle activée pour ton compte d'hébergement et ton registraire de domaine ?
- Est-ce que tout le monde a son propre identifiant, ou est-ce que certains mots de passe sont partagés ?
Une chose à faire ce mois-ci : dresse la liste de tous les identifiants de connexion sur ton serveur et associe chacun d'entre eux à une personne bien réelle. Supprime tout ce que tu ne peux pas expliquer.
Pour en savoir plus : Qui peut accéder à ton serveur ? Un audit d'accès en 30 minutes
3. Qu'est-ce qui se trouve entre les pirates et ton site ?
Dès qu'un serveur est mis en ligne, un trafic automatisé commence à le tester pour repérer les identifiants faibles, les failles connues et tout ce qu'il peut exploiter. La plupart de ce trafic ne devrait même pas atteindre ton application.
C'est la couche située en amont de ton site qui se charge de ce filtrage. Selon ta configuration, il peut s'agir d'un pare-feu d'application web, d'un CDN avec protection DDoS comme Cloudflare, d'un scanner de logiciels malveillants tel qu'Imunify360, ou d'une combinaison de ces éléments. L'important, c'est de savoir de quels outils tu disposes et ce que chacun fait exactement, car leurs fonctions ne se recoupent pas autant qu'on pourrait le croire.
Petit test rapide
- Tu sais ce qui protège ton site contre le trafic malveillant avant qu'il n'atteigne le serveur ?
- Tu lances des analyses anti-malware à intervalles réguliers, et pas seulement quand tu remarques un problème ?
- Tu sais ce qui arriverait à ton site en cas d'afflux massif de visiteurs ?
Une chose à faire ce mois-ci : note tous les outils de sécurité installés sur ton serveur et leur fonction. Les lacunes et les doublons apparaîtront très vite.
Pour en savoir plus : Ai-je encore besoin d'Cloudflare e si j'ai un hébergement cloud ? et Ai-je encore besoin d' e si j'ai un hébergement cloud ?
4. Est-ce qu'il y a des programmes qui tournent encore avec un logiciel qui ne reçoit plus de mises à jour ?
Il y a une différence entre un logiciel obsolète et un logiciel qui n'est plus pris en charge. « Obsolète » veut dire qu'un correctif existe, mais que tu ne l'as pas installé. « Qui n'est plus pris en charge » veut dire qu'aucun correctif n'est prévu.
Celle-là a une date butoir. PHP 8.2 ne recevra plus de mises à jour de sécurité à partir du 31 décembre 2026, et c'est déjà le cas pour PHP 8.1 et les versions antérieures. Pour les sites sous WordPress , ce sont les plugins qui représentent le plus gros risque. La grande majorité des nouvelles failles de sécurité d'WordPress se trouvent dans les plugins, et certains de ces plugins ne sont plus maintenus par personne.
Petit test rapide
- Tu sais sur quelle version de PHP fonctionne chacun de tes sites ?
- Est-ce que certains de tes plugins n'ont pas été mis à jour depuis un an ou plus ?
- Le système d'exploitation de ton serveur est-il toujours pris en charge par son éditeur ?
Une chose à faire ce mois-ci : vérifie la version de PHP sur chaque site et supprime tous les plugins que tu n'utilises pas activement.
Pour en savoir plus : Y a-t-il sur ton serveur un logiciel qui ne reçoit plus de mises à jour ?
5. Quels aspects de la sécurité relèvent de ta responsabilité, et lesquels relèvent de celle de ton hébergeur ?
Chaque formule d'hébergement répartit les responsabilités en matière de sécurité entre toi et ton hébergeur. Avec une formule gérée, ton hébergeur peut se charger des mises à jour du système d'exploitation et de la configuration du serveur. En revanche, avec un VPS non géré ou un serveur dédié, c'est surtout à toi de t'en occuper. Quelle que soit la formule choisie, le code de ton site web, tes plugins et tes comptes utilisateurs restent sous ta responsabilité.
Le fait qu'il y ait une divergence, ça ne pose pas de problème. Ce qui pose problème, c'est de ne pas savoir où elle se trouve. Le pire moment pour découvrir qui était censé appliquer une mise à jour, c'est le lendemain du jour où elle n'a pas été appliquée.
Petit test rapide
- Tu sais si ton contrat est géré ou non, et ce qu'il couvre ?
- Tu sais qui installe les mises à jour de sécurité du système d'exploitation sur ton serveur ?
- Si ton site venait à être piraté ce soir, tu sais qui tu appellerais en premier ?
Une chose à faire ce mois-ci : lis les détails de ton forfait et note les tâches qui te reviennent. Si tu as des doutes, n'hésite pas à demander à notre équipe d'assistance.
Pour en savoir plus : Quels aspects de la sécurité relèvent de ta responsabilité, et lesquels relèvent de celle de ton hébergeur ?
Quand un seul serveur ne suffit pas
Si le fait de passer en revue cette liste t'a fait réaliser à quel point une grande partie de ta semaine est consacrée à la maintenance, tu n'es pas le seul. Les sauvegardes, la gestion des accès, l'application des correctifs et le filtrage sont autant de tâches qui ne cessent de prendre de l'ampleur à mesure que tu ajoutes des sites et que le trafic augmente.
InMotion Cloud, c'est notre cloud privé géré, destiné aux équipes qui préfèrent confier ces tâches à des ingénieurs. Les mises à jour du système d'exploitation, les sauvegardes, le filtrage WAF et DDoS, la surveillance et la gestion des incidents sont inclus dans toutes les formules, avec des ingénieurs expérimentés comme premier point de contact.