La gestion de sites clients à grande échelle nécessite de réfléchir à la sécurité de l’infrastructure au-delà de la simple installation d’extensions de sécurité ou de l’application de mots de passe forts.
Lorsque vous hébergez des dizaines ou des centaines de sites WordPress, l’architecture d’hébergement devient un facteur de sécurité qui peut soit protéger l’ensemble de votre portefeuille, soit le mettre en péril.
L’hébergement mutualisé traditionnel permet de réduire les coûts, mais cela signifie également que les sites partagent le même système de fichiers, le même espace de traitement et la même pile réseau. Ainsi, lorsqu’un site d’un serveur partagé est compromis, les logiciels malveillants peuvent se propager à d’autres sites.
Les risques de sécurité cachés des environnements d’hébergement mutualisé
Chaque site d’un serveur d’hébergement mutualisé utilise une partie de l’unité centrale, de la mémoire vive et de l’espace de stockage du serveur. Cela est logique pour les fournisseurs d’hébergement du point de vue des coûts et permet de maintenir des prix accessibles pour les clients.
Cependant, du point de vue de la sécurité, il existe des vulnérabilités qui augmentent avec le nombre de sites que vous gérez. Le problème principal concerne le partage des ressources. Les autorisations de fichiers et l’isolement des utilisateurs peuvent offrir une certaine protection, mais il s’agit de contrôles au niveau du logiciel qui peuvent être exploités. Après tout, les attaques de phishing, les logiciels malveillants et les ransomwares restent les principales menaces pour tout site.
Comprendre les notions de » propagation latérale » et de « contamination croisée » peut aider à clarifier les risques :
- La propagation latérale fait référence aux logiciels malveillants qui se déplacent d’un système compromis vers d’autres systèmes au sein du même réseau ou environnement.
- La contamination croisée se produit lorsqu’un problème de sécurité affectant un site se propage à d’autres sites partageant la même infrastructure.
Si vous gérez des portefeuilles de clients, il peut être intéressant d’économiser de l’argent en utilisant un hébergement partagé. Cependant, l’extension obsolète ou le mot de passe faible d’un seul client peut constituer une menace pour l’ensemble de votre installation d’hébergement.
Si vous tenez compte du temps passé à surveiller les menaces et à remédier aux incidents de sécurité sur plusieurs sites, la valeur de l’hébergement mutualisé diminue.
Comment les logiciels malveillants se propagent-ils entre les sites sur les serveurs mutualisés ?
La nature exacte de toute contamination intersites dépend de la manière dont le fournisseur d’hébergement met en œuvre la séparation des utilisateurs et les autorisations de fichiers. Malgré cela, le problème fondamental reste le même dans la plupart des configurations d’hébergement partagé : ces environnements créent des surfaces d’attaque où des comptes compromis peuvent accéder aux fichiers d’autres utilisateurs par le biais d’autorisations mal configurées ou de scripts vulnérables.
Les voies d’infection intersites sont les suivantes :
- Les scripts PHP lisent les fichiers des répertoires d’autres utilisateurs lorsque les autorisations sont mal configurées.
- Les répertoires temporaires partagés permettent aux logiciels malveillants de se propager entre les sites.
- Les vulnérabilités au niveau du serveur permettent aux processus d’un site d’en affecter d’autres.
- Les comptes d’utilisateurs compromis accèdent aux répertoires voisins par l’intermédiaire de pools de ressources partagées.
Bookswarm, client de Kinsta, a découvert ce problème en gérant des centaines de sites clients sur une plateforme d’hébergement partagée. Il a constaté que la configuration de serveurs mixtes créait des problèmes de sécurité en plus des compromissions de sites individuels. L’architecture signifiait qu’une attaque sur un site était une attaque sur les autres
Cela crée également un fardeau opérationnel, car vous avez besoin d’une surveillance constante pour détecter les compromissions avant qu’elles ne se propagent. Si un site montre des signes d’infection, vous devez vérifier tous les autres sites sur le même serveur. La réponse aux incidents devient un exercice à l’échelle du portefeuille plutôt qu’une solution isolée.
Le problème de la contamination des listes de blocage
Les adresses IP partagées créent un autre niveau de risque dans l’hébergement mutualisé traditionnel. Lorsque plusieurs sites partagent la même IP, ils partagent également la même réputation aux yeux des fournisseurs de courrier électronique, des moteurs de recherche et des services de sécurité.
Étant donné qu’un seul compromis peut entraîner la mise sur liste noire de l’ensemble de l’adresse IP, chaque site sur cette IP souffre de plusieurs problèmes en cascade :
- La délivrabilité des e-mails diminue pour l’ensemble de votre portefeuille lorsqu’un site compromis déclenche des filtres anti-spam tels que Spamhaus.
- Les moteurs de recherche signalent l’IP partagée comme suspecte, ce qui affecte le classement de tous les sites associés.
- Les services de sécurité et les pare-feu bloquent les requêtes provenant de l’adresse IP, ce qui perturbe le fonctionnement des sites qui n’ont rien à voir avec la compromission initiale.
- Les sites clients perdent leurs indicateurs de confiance lorsque les outils de sécurité associent l’IP partagée à une activité malveillante.
Le processus de rétablissement d’une liste noire d’adresses IP nécessite un effort coordonné avec votre fournisseur d’hébergement. Vous devez identifier le site à l’origine du problème, le nettoyer, puis demander sa suppression des différentes listes de blocage. Pendant ce processus, tous les sites sur l’IP partagée continuent d’en subir les conséquences.
Pendant ce temps, vous devez expliquer à vos clients pourquoi leur e-mail a cessé de fonctionner ou pourquoi leur site a été signalé, même s’ils ont suivi des pratiques optimales en matière de sécurité WordPress. La cause profonde est liée à des décisions d’infrastructure sur lesquelles les propriétaires de sites individuels n’ont aucun contrôle. Toute cette maintenance permanente vous fait perdre du temps par rapport au travail de vos clients et à vos projets de développement.
Isolation au niveau du conteneur pour l’hébergement WordPress
L’isolation des sites répond à de nombreux problèmes fondamentaux de l’hébergement partagé. Par exemple, Kinsta fait fonctionner chaque site dans son propre conteneur isolé avec des ressources dédiées. Cela signifie que chaque site WordPress dispose de son propre conteneur qui comprend tout ce qui est nécessaire pour fonctionner : Linux, NGINX, PHP et MySQL.
L’isolation se fait au niveau du système d’exploitation grâce à deux mécanismes fondamentaux :
- Les espaces de noms fournissent à chaque conteneur sa propre vue des ressources du système. Un processus s’exécutant dans un conteneur ne peut pas voir ou interagir avec les processus d’un autre conteneur.
- Les groupes de contrôle (« cgroups ») imposent des limites de ressources et garantissent que chaque conteneur a accès à sa propre allocation de CPU et de RAM.
De plus, les threads PHP de votre site WordPress ne peuvent pas voir ou interagir avec les processus d’autres sites. Cette séparation au niveau du noyau permet d’éviter les scénarios dans lesquels un processus compromis d’un site tente d’accéder à des ressources appartenant à d’autres sites.
Les piles réseau fonctionnent également de manière indépendante dans chaque conteneur. Chaque site dispose de sa propre interface réseau et de son propre traitement IP. Cette isolation s’étend à l’ensemble de la pile et élimine le problème des voisins bruyants qui affecte l’hébergement partagé.
Lorsqu’un site connaît un pic de trafic ou exécute des opérations gourmandes en ressources, cela n’affecte que le conteneur de ce site. L’allocation de ressources dédiées signifie que les autres sites continuent à fonctionner avec leur allocation complète, indépendamment de ce qui se passe ailleurs dans l’infrastructure.
Comment l’isolation des conteneurs empêche la propagation latérale des logiciels malveillants
Lorsqu’un site est compromis dans un environnement conteneurisé, le logiciel malveillant reste confiné à l’intérieur du conteneur. Cette séparation empêche les processus compromis d’accéder à d’autres conteneurs par le biais de plusieurs mécanismes :
- Les systèmes de fichiers restent isolés, de sorte que les logiciels malveillants ne peuvent pas se propager en exploitant des répertoires partagés ou des fichiers temporaires.
- Les espaces de noms des processus empêchent les codes malveillants d’analyser les processus d’autres conteneurs ou d’interagir avec eux.
- L’isolation du réseau limite la capacité des sites compromis à analyser ou à attaquer les sites voisins.
- Les espaces mémoire restent complètement séparés, ce qui empêche les attaques par débordement de mémoire tampon de franchir les limites des conteneurs.
Si le site est hébergé sur Kinsta, nos systèmes de surveillance peuvent détecter immédiatement le conteneur compromis et réagir pendant que les autres sites de votre portefeuille continuent de fonctionner.
Vérifier l’isolation réelle par rapport aux affirmations commerciales
Tous les fournisseurs d’hébergement ne mettent pas en œuvre l’isolation des conteneurs de la même manière. Certains utilisent le terme « isolé » pour décrire des limites douces sur l’utilisation des ressources tout en continuant à faire fonctionner plusieurs sites dans des environnements partagés. Comprendre ce qui constitue une véritable isolation au niveau du conteneur vous aide à évaluer vos options d’hébergement et à éviter les risques de sécurité qui découlent d’un marketing trompeur.
Une véritable isolation des conteneurs signifie que chaque site fonctionne dans son propre espace de noms du système d’exploitation avec des ressources dédiées auxquelles les autres sites n’ont pas accès. Si vous êtes à la recherche d’un nouveau fournisseur d’hébergement, vous devez vous concentrer sur quelques points :
- Chaque site dispose-t-il de son propre conteneur avec des allocations de CPU et de RAM dédiées auxquelles les autres sites n’ont pas accès ?
- Les systèmes de fichiers sont-ils complètement séparés au niveau du noyau en utilisant des espaces de noms plutôt que de simples autorisations au niveau de l’utilisateur ?
- Que se passe-t-il pour les autres sites lorsqu’un conteneur est compromis ou connaît un pic de trafic ?
- Quelle technologie de conteneurisation l’hébergeur utilise-t-il (LXC, LXD, Docker) et comment applique-t-il l’isolation ?
- L’hébergeur peut-il fournir une documentation technique sur ses mécanismes d’isolation et son architecture ?
La différence entre les limites douces et l’isolation dure est importante à la fois pour la sécurité et les performances. Les limites douces peuvent restreindre la quantité de CPU qu’un site peut utiliser, mais elles opèrent dans un environnement partagé où les processus d’un site peuvent toujours interagir avec les autres. L’isolation dure avec des ressources dédiées signifie que chaque site fonctionne dans un environnement complètement séparé où les sites voisins ne peuvent pas accéder à ses ressources ou être affectés par ses activités.
Méthodes de vérification technique
La recherche de spécifications techniques détaillant la technologie de conteneurisation peut vous aider à comprendre dans quelle mesure un hébergeur connaît l’architecture sous-jacente. Par exemple, les fournisseurs qui utilisent LXC, LXD, Docker ou des technologies similaires devraient être en mesure de décrire les mécanismes d’isolation spécifiques qu’ils mettent en œuvre.
Les certifications de conformité telles que SOC 2 Type II et ISO 27001 indiquent que les pratiques de sécurité ont été auditées par des parties indépendantes. Ces certifications exigent des contrôles de sécurité documentés et des tests réguliers, ce qui donne plus d’assurance que les seules déclarations marketing. Kinsta possède les deux certifications et se soumet à des audits réguliers pour vérifier que les mécanismes d’isolation fonctionnent comme annoncé.
Si vous utilisez l’hôte pendant une période d’essai, vous pouvez également vérifier le fonctionnement de l’isolation de différentes manières, par exemple en surveillant la consommation des ressources sur plusieurs sites du même serveur ou en observant ce qui se passe pendant les opérations gourmandes en ressources processeur d’un site particulier.
Avec Kinsta, ce type de validation pratique est possible au cours de votre premier mois, sans frais.
Comprendre ce que l’isolation des sites signifie pour votre stratégie d’hébergement
Passer d’un hébergement mutualisé à une architecture de conteneurs isolés peut changer la posture de sécurité fondamentale de l’ensemble de votre portefeuille WordPress pour le mieux, et même la façon dont vous abordez la gestion de l’infrastructure à l’échelle.
Sur plusieurs sites clients en hébergement mutualisé, la probabilité qu’au moins un site subisse un incident de sécurité est proche de la certitude. La vraie question est de savoir si cet incident reste limité à un seul site ou s’il crée des problèmes en cascade sur l’ensemble de votre portefeuille.
Pour les agences et les équipes qui gèrent de nombreux sites WordPress, l’hébergement est en fin de compte une décision de risque au niveau du portefeuille. Si vous recherchez une infrastructure conçue spécifiquement pour gérer des sites à grande échelle, Kinsta propose des solutions adaptées aux agences et aux environnements WordPress à grand volume.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
