Isolation par site
L'isolation est ce qui distingue un incident d'une panne. Chaque site que nous hébergeons s'exécute dans une cage CloudLinux LVE au niveau du noyau avec ses propres plafonds de processeur, de RAM, d'E/S et de processus, sa propre vue de système de fichiers CageFS, sa propre version de PHP et son propre système de limitation des bases de données. Un site qui subit une attaque, est compromis ou exécute simplement une requête intensive est contenu là où il se trouve — et cette base d'isolation est incluse dans chaque formule, sans vous être revendue en option. Disponibilité : la limitation des bases de données par site et les statistiques de ressources par site sont en cours de développement actif et ne sont pas encore disponibles. Tout le reste est d'ores et déjà opérationnel.
La flotte de workers exécute CloudLinux OS, qui intègre le multi-tenant directement au niveau du noyau. Chaque site dispose d'un environnement virtuel léger, ou LVE, qui constitue une limite stricte plutôt qu'une simple convention de courtoisie. Rien de ce qu'un site fait à l'intérieur de sa cage ne peut dépasser le budget alloué à quelqu'un d'autre.
LVE limite le processeur, la RAM, les E/S, les IOPS, les processus et les processus d'entrée pour chaque site de manière indépendante. Lorsqu'un site dépasse son plafond, il est bridé dans sa propre cage — l'incident est consigné pour ce site, et les sites situés de part et d'autre continuent de fonctionner sans être affectés.
Un plugin bloqué dans une boucle, une tâche cron mal écrite ou un robot d'indexation assommant un point de terminaison atteint d'abord les limites de processus et de processus d'entrée du site. Un seul site ne peut tout simplement pas saturer la machine.
Puisque les processus d'entrée sont limités par cage, un flux malveillant ciblant un site ne peut pas saturer le serveur. Le bridage des connexions et des requêtes LiteSpeed ainsi que le pare-feu réseau Imunify360 interviennent en amont, de sorte que l'attaque reste le problème de la cible.
Chaque anomalie LVE est enregistrée par site et transmise au moteur de règles de la plateforme, qui peut resserrer ou assouplir les limites automatiquement. Vous comprenez pourquoi un site a été bridé et à quel moment — de manière progressive, réversible et consignée.
L'isolation des ressources empêche un site d'accaparer les ressources. L'isolation du système de fichiers l'empêche de fouiner. CageFS offre à chaque client une vue privée et restreinte de la machine.
Sous CageFS, un locataire ne voit que ses propres fichiers et un ensemble minimal et nettoyé de binaires système — et ne peut pas voir les autres locataires, les sites des autres locataires, ni les fichiers système sensibles. Le mode d'échec habituel de l'hébergement mutualisé, où un compte compromis devient une position d'observation sur tous les autres comptes de la machine, est bloqué au niveau du noyau.
C'est ce qui importe le plus le jour où un problème survient. Si un site est compromis — par le biais d'un plugin obsolète, d'un identifiant volé, d'un thème vulnérable — c'est CageFS qui limite les dégâts à cette seule cage. Notre spécification de sécurité pèse ses mots : CageFS confine les failles. Le confinement est la seule promesse honnête, et c'est celle qui détermine si un incident nécessite le nettoyage d'un seul site ou de l'ensemble de la flotte.
Les sauvegardes renforcent cette même limite. Les sauvegardes par site sont immuables, déportées et isolées du parc en cours d'exécution, avec des restaurations testées. Ainsi, même dans le pire des cas de compromission d'un site, il existe une voie de récupération propre et indépendante qui ne dépend pas de l'état de la machine sur laquelle il tournait.
L'isolation de la couche Web ne représente que la moitié du problème. Sur un parc WordPress, ce qui ralentit le plus souvent un serveur, ce sont les requêtes d'un site, et non son trafic. Ce point est géré explicitement.
CloudLinux MySQL Governor limite l'utilisation de la base de données par site, de sorte que les requêtes lourdes d'un seul site ne peuvent pas ralentir le serveur pour tous les autres. C'est le contrôle anti-ralentissement, et il fonctionne que le site bruyant remarque ou non qu'il est bridé.
Le parc exécute MariaDB (ou Percona), choisi pour les charges de travail WordPress plutôt que par défaut, avec Governor superposé en tant que couche d'équité par locataire.
Un cache d'objets Redis par site absorbe les lectures répétées avant qu'elles n'atteignent la base de données, ce qui réduit la pression que Governor doit arbitrer en premier lieu. Le cache et l'isolation fonctionnent comme un seul et même système.
CloudLinux alt-PHP offre à chaque site son propre sélecteur de version PHP, ses propres extensions (imagick, gd, redis et consorts) et ses propres paramètres renforcés — avec des processus LSAPI encadrés par les limites LVE de ce site, de sorte que la concurrence PHP fait partie de la cage plutôt qu'un moyen d'y échapper.
L'isolation détermine la propagation d'un problème. La mise en application détermine la suite des événements. Nous avons remplacé la suspension globale par une machine à états, pilotée par des flux de travail durables et appliquée sur le travailleur via LiteSpeed, LVE et Imunify.
L'isolation n'est pas une fonctionnalité de formule qui apparaît trois niveaux plus haut. C'est une propriété de l'infrastructure, elle est donc identique que vous exécutiez une seule boutique WooCommerce ou deux mille sites réseau.
Les réseaux de masse et PBN fonctionnent sur la même infrastructure LVE et CageFS, associée à une rotation des comptes CDN tenant compte des empreintes et à la diffusion de HTML statique. L'isolation est ce qui rend la densité sûre : les sites partagent une flotte sans partager leur destin.
Les sites WordPress gérés, WooCommerce, PHP, statiques et Node bénéficient des mêmes environnements isolés ainsi que d'un accès complet en libre-service : votre propre version de PHP et vos propres extensions, le cache d'objets Redis, les environnements de staging et le déploiement en production (push-to-live).
Pour les charges de travail nécessitant une isolation plus stricte que celle par défaut optimisée pour la densité, l'isolation complète d'un conteneur par site est proposée sous forme de variante de pilote de provisionnement : même moteur, même plan de contrôle, placement différent, avec des surcoûts plus élevés.
L'isolation LVE et CageFS, le WAF proactif et l'analyse des logiciels malveillants sont inclus pour chaque client, car un site infecté ou hors de contrôle menace ses voisins et notre réputation IP. Le nettoyage des logiciels malveillants en un clic et les niveaux de protection avancés sont des options payantes, mais pas la base.
La tentation commerciale de l'hébergement consiste à vendre la sécurité par paliers : placer les clients économiques sur un serveur mutualisé aux limites souples, et faire payer ceux qui se soucient des frontières. Nous ne procédons pas ainsi, car le client qui n'a pas payé pour l'isolation est précisément celui dont le site compromis devient l'incident de tout le monde.
Nous hébergeons plus de 650 000 sites dans le monde, sur un parc où la densité constitue le fondement même du modèle économique. Cela ne fonctionne que si l'isolation sous-jacente est inconditionnelle. Des environnements cloisonnés au niveau du noyau, une vue de système de fichiers privée, une limitation des ressources de base de données par site et une version de PHP par site sont le prix à payer pour fonctionner à cette échelle sans destin partagé — ils sont donc activés pour tout le monde, sur tous les abonnements, dès le premier site que vous déployez.
Le résultat est une plateforme qui réagit de manière prévisible face aux mauvais jours des autres. Derrière elle se trouvent une garantie de disponibilité de 99,99 %, des sauvegardes hors site immuables par site avec des restaurations testées, et un journal d'audit complet de chaque action d'application prise sur vos sites.
L'isolation est conçue spécifiquement pour empêcher cela. LVE limite le CPU, la RAM, les E/S, les IOPS et les processus par site, MySQL Governor régule l'utilisation de la base de données par site, et les processus LSAPI sont cantonnés dans la propre cage du site — ainsi, un pic de trafic ou une lourde charge de requêtes d'un voisin est bridé par sa propre limite, et non par la vorte. Chaque incident est journalisé par site, et le moteur de règles peut resserrer automatiquement les limites d'un site bruyant.
La réponse honnête est le confinement plutôt qu'une garantie. CageFS offre à chaque client une vue de système de fichiers isolée — un client compromis ne peut pas voir les autres clients, leurs sites ou les fichiers système sensibles — et un cas avéré de malware ou de phishing déplace ce site vers la mise en quarantaine : hors ligne, fichiers verrouillés, aucune exécution, isolé pour les analyses forensiques. C'est ce qui limite le rayon d'impact. En parallèle, nous exécutons une analyse des malwares et un WAF proactif sur chaque site, ainsi que des sauvegardes hors site immuables par site avec des restaurations testées, de sorte que la récupération ne dépend jamais de l'état de la machine concernée.
Il est inclus dans tous les abonnements. L'isolation LVE et CageFS, le pare-feu applicatif (WAF) proactif et l'analyse des logiciels malveillants constituent la base pour chaque client, car un site infecté ou hors de contrôle menace ses voisins et notre réputation IP ; nous ne pouvons décemment pas laisser cela en option. Ce qui est vendu en option, c'est le nettoyage et la correction des logiciels malveillants en un clic, ainsi que des niveaux de protection avancés tels que des règles WAF renforcées, une analyse prioritaire, la gestion des robots et des niveaux de protection DDoS supérieurs.
Il est bridé dans sa propre cage plutôt que désactivé. Bridé signifie des limites LVE plus strictes et une limitation du taux de requêtes tout en maintenant le site en ligne et actif, et il récupère automatiquement une fois la cause résolue. Vous êtes informé de la raison, la transition est enregistrée avec ses preuves, et elle peut faire l'objet d'un appel. Si la charge correspond à une croissance réelle plutôt qu'à un dysfonctionnement, la solution est de passer à un forfait supérieur, et non à un bridage permanent.
Non — un site suspendu affiche une page d'attente personnalisée et explicite (facturation, maintenance ou abus) afin de paraître intentionnel plutôt que défectueux. La suspension est levée suite à un paiement, à une correction ou à un recours. La mise en quarantaine est plus stricte et fonctionne différemment : elle n'est levée qu'après un nettoyage et un examen, jamais automatiquement.
Sur Zinn® Managed WordPress, oui — CloudLinux alt-PHP offre à chaque site son propre sélecteur de version PHP, ses propres extensions telles que imagick, gd et redis, ainsi que ses propres paramètres renforcés, le tout encadré par les limites LVE de ce site. Footprint-Free Hosting exécute délibérément une configuration par site plus standardisée et verrouillée, car la variété des configurations constitue elle-même une empreinte.
Oui. CloudLinux LVE et CageFS constituent la configuration par défaut optimisée pour la densité sur l'ensemble des gammes de produits. Pour les charges de travail nécessitant une limite plus stricte, une isolation complète par conteneur et par site est proposée en tant que variante de pilote de provisioning : le même moteur et le même plan de contrôle avec un placement différent, échangeant de la surcharge contre une séparation renforcée.
Oui. L'hébergement Footprint-Free commence par un essai de 14 jours sans carte bancaire, couvrant jusqu'à cinq sites — sans coordonnées de paiement, sans engagement. Déployez quelques sites, générez un peu de trafic dessus et observez le comportement des conteneurs avant de vous décider.
Commencez un essai de 14 jours sans carte de crédit sur Footprint-Free Hosting — jusqu'à cinq sites, sans coordonnées de paiement et sans engagement. L'isolation au niveau du noyau, le WAF proactif et l'analyse des logiciels malveillants sont inclus dès le premier déploiement.
Commencer gratuitement