CageFS par site : une nouvelle architecture de sécurité pour l'hébergement mutualisé

CageFS par site sépare strictement les différents sites web au sein d'un compte d'hébergement mutualisé, limitant ainsi le risque de propagation latérale après une intrusion. Je vais vous présenter cette nouvelle architecture de sécurité, vous montrer des scénarios d'utilisation concrets et vous expliquer comment vous pouvez ainsi gérer plusieurs projets en toute sécurité au sein d'un même compte.

Points centraux

• Isolement du site web: Une séparation supplémentaire au sein d'un même compte permet de réduire les risques collatéraux.
• CloudLinux: Extension du concept CageFS au niveau du domaine.
• WordPress: Faire fonctionner plusieurs instances en parallèle en toute sécurité.
• Ressources: Les limites imposées au processeur, à la mémoire vive et aux E/S viennent compléter la séparation des vues de fichiers.
• Cabinet médical: Activation par domaine et stratégie claire en matière de droits d'accès et de chemins d'accès.

Ce que „ Per-Site CageFS “ apporte concrètement

L'extension isole chaque Domaines au sein d'un CageFS utilisateur existant, afin que chaque site web ne voie que ses propres fichiers et processus. Cela permet d'empêcher qu'un projet compromis n'accède aux fichiers de configuration, aux fichiers téléchargés ou aux clés d'autres sites hébergés sur le même compte. Selon CloudLinux Blog (annonce de la version bêta) : CageFS par site renforce l'isolation entre les sites web au sein d'un même compte utilisateur, réduisant ainsi le risque de propagation latérale. Pour moi, l’intérêt est évident : je segmente clairement les comptes d’agence, les configurations multisites et les environnements de test, sans bouleverser la structure d’hébergement. Cet article de fond sur CageFS offre un aperçu rapide de son principe : Système de fichiers CageFS, sur lequel repose l'isolation par site.

Pourquoi l'isolation des comptes ne suffit pas à elle seule

Un compte regroupe souvent plusieurs Projets – environ deux boutiques en ligne, trois blogs et un environnement de test. Si un exploit attaque un plugin vulnérable, un pirate peut, sans segmentation supplémentaire, accéder aux répertoires voisins et y placer d’autres charges utiles. C’est précisément là que Per-Site CageFS restreint l’accès au système de fichiers et aux processus de telle sorte que chaque site web soit isolé comme s’il se trouvait dans son propre Prison fonctionne. C'est notamment le cas lorsque plusieurs instances WordPress distinctes partagent le même utilisateur PHP : cela crée sinon un risque d'escalade que je parviens à éliminer grâce à l'isolation des domaines. Cela permet de limiter les dommages collatéraux, de simplifier l'analyse des incidents et de planifier plus rapidement les restaurations.

Voici comment fonctionne techniquement l'isolation des sites web

CloudLinux utilise CageFS pour créer un environnement virtuel par utilisateur système de fichiers; la couche « par site » étend cette fonctionnalité aux limites des domaines. Chaque domaine activé dispose d'un espace de travail distinct au sein du CageFS de l'utilisateur, comprenant des chemins d'accès restreints, ses propres répertoires temporaires et une exécution de scripts isolée. De ce fait, les fichiers wp-config.php, dossiers de téléchargement ou fichiers de clés étrangers disparaissent du champ de vision du site web attaqué. Les tâches cron, PHP et, le cas échéant, les commandes SSH accèdent aux mêmes bibliothèques système, mais ne voient que les sous-ensembles du système de fichiers. D'après la documentation, cette séparation peut être activée ou désactivée par domaine, ce qui me permet de bénéficier d'un contrôle très précis pour les instances de production, de préproduction et de test.

Comparaison : isolation des comptes, CageFS par site et conteneurs

Pour faire mon choix de manière structurée, je compare trois options courantes Modèles en fonction du niveau d'isolation, de la charge de travail et de la compatibilité. L'isolation par compte assure la séparation des clients, mais laisse ouvertes les frontières internes entre sites. CageFS par site comble cette lacune au niveau du système de fichiers et des processus. Les conteneurs créent des frontières strictes, mais nécessitent souvent davantage de maintenance et d'ajustements. Ce document fournit une classification approfondie de l'isolation des processus. Comparaison entre Chroot, CageFS et Jails.

Approche	Séparation entre les comptes	Séparation des sites web au sein du compte	Compatibilité (PHP/CGI/SSH/Cron)	Charges d'exploitation
Isolement des comptes (classique)	Haute	Faible	Très bon	Faible
CageFS par site	Haute	Moyen à élevé	Très bon	Faible à moyen
Conteneurs par site	Très élevé	Très élevé	Bon à très bon	Moyen à élevé

Dans les environnements d'hébergement mutualisé, CageFS par site offre une combinaison efficace de contrôle précis Séparation et une adaptation minimale, car les scripts fonctionnent généralement sans modification. Cela me permet de pallier la faille la plus courante : plusieurs sites web indépendants hébergés sous un seul compte utilisateur.

En pratique : exploiter plusieurs instances WordPress en toute sécurité

Je sépare chaque instance WordPress sur laquelle est activée la fonction Isolation des domaines et je configure des pools PHP-FPM distincts pour chaque site, afin que les journaux, l'opcache et les limites puissent être clairement attribués. De plus, je définis des SALT/KEY spécifiques à chaque site dans le fichier wp-config.php et j'empêche tout accès croisé via les droits d'accès aux fichiers et des équivalents de la directive open_basedir. Je stocke les fichiers téléchargés strictement au sein du répertoire racine de chaque site et j’interdis l’utilisation de répertoires de téléchargement partagés au niveau global. Lors des déploiements, je limite les chemins d’accès temporaires à l’intérieur du site et je supprime immédiatement les artefacts de compilation afin qu’aucune surface d’attaque inutile ne subsiste. Pour les caches Composer ou NPM, j’utilise des répertoires locaux au site Répertoires, afin d'éviter tout effet indésirable.

Interaction entre la performance et la gestion des ressources

CageFS par site gère la vue des fichiers ; la Performance Je me protège en fixant des limites pour le CPU, la RAM, les E/S et les processus au niveau du compte ou du pool. Cela m'évite qu'un site ne génère une charge excessive à cause de plugins défectueux et ne ralentisse l'ensemble du compte. Dans de nombreuses configurations, cela s’inscrit dans le cadre de quotas LVE ou similaires, que je règle avec précision par pool ou par compte. J’associe cela à une limitation des requêtes au niveau du serveur web ou du WAF, afin que les pics de trafic soient gérés de manière ordonnée. Cette combinaison d’isolation et de quotas renforce la sécurité des services et la prévisibilité Répartition de la charge.

Chaîne de protection : ce que Per-Site CageFS ne remplace pas

L'isolation empêche les vues transversales, mais je considère les mises à jour, Durcissement de PHP et l'utilisation de mots de passe forts sont toujours rigoureusement appliquées. L'authentification multifactorielle (MFA) pour les connexions administrateur, les droits d'accès minimaux aux fichiers et les filtres de téléchargement restent obligatoires. Un pare-feu WAF, des limites de débit et une journalisation continue couvrent des vecteurs d'attaque supplémentaires que la simple séparation des vues de fichiers ne permet pas de contrôler. Je vérifie également régulièrement les tâches cron et les jetons d’intégration, que les attaquants oublient souvent de repérer. Pour en savoir plus sur l’interaction entre la séparation des clients et le durcissement, consultez ce guide sur Sécurité de l'hébergement mutualisé, qui met en évidence cette ligne de pensée.

Mise en place et obstacles courants

J'active l'isolation de domaine de manière ciblée pour chaque site web puis je teste les accès SSH, Cron et PHP en conditions réelles. Les chemins absolus dans les scripts de déploiement ou les plugins peuvent poser des problèmes ; c'est pourquoi je privilégie les chemins relatifs ou les variables. J’évite les liens symboliques entre les projets, car ils affaiblissent le principe de séparation ; je préfère ajouter les bibliothèques nécessaires au dépôt pour chaque site. Pour les sauvegardes, je définis des archives distinctes et je sauvegarde les journaux par domaine, afin que la restauration et l’analyse forensic restent claires. En matière de droits d’accès, les valeurs 640 pour les fichiers et 750 pour les dossiers ont fait leurs preuves, ainsi que Propriétaire adapté au pool PHP correspondant.

Analyse coûts-bénéfices pour les agences et les indépendants

Je compare le gain en matière de sécurité au temps consacré à la gestion administrative et aux coûts potentiels liés à une panne qu'un incident transversal entraînerait, pour aboutir à Euro-Base. Quelques heures d'intervention en cas d'incident coûtent souvent bien plus cher qu'un petit supplément mensuel pour une meilleure isolation. Pour les comptes d’agences gérant plusieurs projets clients, la segmentation réduit sensiblement les risques liés à la responsabilité et à la réputation. Les processus de sauvegarde et de restauration se déroulent également de manière plus ordonnée, car je peux restaurer des sites individuels avec une grande précision. Globalement, CageFS par site offre une solution plus fiable Gestion de l'entreprise avec des processus prévisibles.

Liste de contrôle : quand l'utilisation de CageFS par site devient obligatoire

J'active l'isolation de domaine dès qu'il y a plusieurs Installations fonctionnent sous un même compte et ont des cycles de mise à jour différents. Autre point important : la présence d’équipes de projet distinctes ou d’accès administrateurs externes, qui augmentent le risque d’interventions involontaires. Les volumes de téléchargement élevés, les convertisseurs de fichiers ou le traitement d’images justifient également cette séparation, car ils constituent souvent des points d’entrée. Des exigences de conformité variées (par exemple, clients, marchés, protection des données) plaident également en faveur d’une segmentation plus fine. Ceux qui exploitent en parallèle les environnements de préproduction, de test et de production bénéficient de domaines d’erreurs clairement séparés et d’une Médecine légale.

Conditions préalables et compatibilité dans la pratique

Avant de mettre en production CageFS par site, je vérifie l'environnement d'exécution : le gestionnaire PHP utilisé (par exemple PHP-FPM, lsapi), le serveur web actif, l'intégration disponible avec le panneau de contrôle et la manière dont les tâches Cron et les sessions SSH sont gérées. Dans les environnements mutualisés classiques, les applications continuent de fonctionner sans modification du code. Je m’assure qu’il existe un répertoire racine distinct pour chaque domaine, que les chemins d’accès sont uniques (par exemple /home/user/sites/projet-a/public) et qu’un pool PHP-FPM dédié est utilisé pour chaque site. Pour les tâches Cron, j’utilise des crontabs spécifiques à chaque domaine ou, lorsque le panneau de contrôle les regroupe, des préfixes et des chemins de journalisation clairs, afin que les tâches restent bien délimitées au sein de leur Jails travailler.

Séparer clairement les bases de données, les caches et les sessions

La vue des fichiers n'est qu'une partie du processus. Je pousse cette séparation jusqu'à la base de données et aux caches. Pour chaque site web, je crée une base de données distincte et un utilisateur de base de données dédié disposant de droits minimaux. Pour les caches d'objets ou de pages (par exemple Redis, Memcached), j'utilise des instances distinctes par site ou, au minimum, des préfixes de clés et des bases de données/espaces de noms dédiés. Les sessions PHP sont stockées dans des chemins propres à chaque site ; je configure le paramètre `session.save_path` séparément pour chaque pool FPM. Si j’utilise une file d’attente centrale ou un backend de recherche, je sépare les index et les sujets par site. Ce principe de „ séparation jusqu’au dernier kilomètre “ empêche les incidents de se propager aux systèmes périphériques.

CI/CD et déploiements en conditions d'isolement

Dans les pipelines de build, je privilégie systématiquement l'isolation : chaque site dispose de sa propre tâche de déploiement, qui n'accède qu'au répertoire du site. Je décompresse les artefacts à la racine du domaine, puis j'effectue les corrections de propriétaire/groupe et je ne valide que les caches concernés. Les commandes WP-CLI s’exécutent dans le contexte CageFS correspondant, de sorte qu’elles n’affectent pas les projets tiers. Je sépare les variables d’environnement par site ; les secrets restent dans les fichiers de configuration propres au site ou dans le magasin de secrets du panneau d’administration. Pour garantir une disponibilité sans interruption, j’utilise des commutations atomiques de liens symboliques au sein des limites du domaine (par exemple, current/releases), mais je veille à ce que les liens symboliques ne pointent pas vers des projets voisins. Les vérifications post-déploiement (état de santé, analyse des erreurs 404/500, vérification des droits) sont obligatoires pour chaque site.

Surveillance, journalisation et analyse forensique

Je sépare systématiquement les fichiers journaux : fichiers d'accès et d'erreurs par domaine, fichiers journaux PHP et Cron distincts, avec rotation et durée de conservation. En cas d'incident, cela me permet de reconstituer la chronologie d'un site donné sans avoir à passer au crible l'ensemble du compte. En complément, je mise sur des contrôles d’intégrité des fichiers (sommes de contrôle des répertoires clés), des journaux d’audit distribués pour les actions d’administration et de simples fichiers « canary » qui signalent rapidement toute manipulation. Pour les alertes, des seuils suffisent souvent : hausses soudaines des codes d'erreur 500, tailles de fichiers téléchargés inhabituelles, augmentation rapide de l'occupation des inodes ou démarrages excessifs de workers PHP. J’associe ces signaux à des procédures d’intervention claires : bloquer le site, vérifier les sauvegardes, sécuriser les artefacts, redémarrer dans un environnement isolé.

Cas particuliers de WordPress : multisite, plugins MU et flux de téléchargement

Avec WordPress Multisite, je pèse le pour et le contre : une installation Multisite tire moins parti de CageFS par site, car plusieurs sites partagent délibérément une base de code et une structure communes. Si j'ai besoin de limites plus strictes (équipes indépendantes, caches séparés, analyse claire), je préfère mettre en place des instances individuelles et les isoler. Je ne distribue les plugins MU, les drop-ins ou les bibliothèques globales « Must-Use » qu'au sein d'un même site et j'évite les dossiers partagés. Les workflows multimédias (CDN, optimisation d’images, convertisseurs) s’exécutent au sein de la « prison » du domaine ; j’empêche tout téléchargement depuis un site vers les répertoires d’un autre. Si une équipe souhaite partager des pipelines d’actifs, je les réplique par site ou je les encapsule sous forme de paquet intégré au dépôt correspondant.

Parcours de migration : du système monolithique au compte segmenté

De nombreux comptes démarrent avec un répertoire public_html volumineux et se développent au fil du temps. Je procède en cinq étapes : 1) Inventaire : quels sites, domaines, tâches cron, bases de données, secrets ? 2) Définir la structure des chemins d'accès : pour chaque site, un répertoire racine, un répertoire temporaire, des fichiers journaux et des sauvegardes dédiés. 3) Définir les pools PHP-FPM par domaine et fixer des limites. 4) Déplacer les fichiers, ajuster les droits d’accès, nettoyer les chemins absolus et les inclusions. 5) Activer CageFS par site, effectuer des tests sous charge, mettre en place la surveillance. Pendant ce temps, je prévois une stratégie de restauration (instantanés, sauvegardes séparées). Après la migration, je vérifie si des outils tels que WP-CLI, Composer, les processus d’images et les tâches Cron fonctionnent dans le bon périmètre et j’ajuste les variables de chemin si nécessaire.

Problèmes courants et dépannage

• Erreurs 403/404 après activation : la plupart du temps, les règles de réécriture ou les inclusions renvoient vers des chemins situés en dehors de la racine du domaine. Je corrige ces chemins en utilisant des variantes relatives ou des variables.
• Composer/NPM plante : les caches globaux ne sont pas visibles. Je configure des répertoires de cache spécifiques au site et j'ajuste les variables HOME/TMP lors du déploiement.
• WP-CLI ne trouve pas le fichier wp-config.php : l'exécution ne se fait pas à la racine du domaine. Je définis correctement le répertoire de travail ou j'indique explicitement le chemin d'accès.
• Problème avec les tâches Cron : les utilisateurs Cron ou les chemins d'accès ne sont pas définis par domaine. Je vérifie les variables d'environnement, les chemins d'accès aux binaires et les destinations des journaux au sein de la « site-jail ».
• Échec des téléchargements : session.save_path ou tmp_dir pointe vers le mauvais répertoire. J'attribue des chemins d'accès temporaires propres à chaque site en fonction du pool FPM.
• Bibliothèque partagée manquante : le lien symbolique vers le projet voisin est bloqué. Je réplique la bibliothèque sur chaque site ou je l'intègre sous forme de paquet dans le déploiement.

Gouvernance et modèle d'accès

Même si tout est techniquement séparé, la question des accès reste d'actualité. J'attribue des accès SSH/SFTP dédiés à chaque site ou je limite les accès au panneau d'administration au domaine concerné. Les équipes de développeurs et d'agences ne reçoivent que les clés et les autorisations dont elles ont réellement besoin. En cas d’urgence, je dispose d’une procédure d’urgence (droits temporairement étendus, journalisation complète, retrait ultérieur). Lors des audits, je documente pour chaque site : les chemins d’accès, les pools, les limites, les responsables, les attributions RBAC et les sauvegardes. Ainsi, la segmentation reste solide non seulement sur le plan technique, mais aussi sur le plan organisationnel.

En bref

CageFS par site complète la séparation des utilisateurs existante en ajoutant une site web-niveau, réduisant ainsi efficacement le risque de mouvements latéraux. Je considère cela comme une mesure pratique, car de nombreux comptes regroupent plusieurs projets indépendants. La combinaison de la séparation des vues de fichiers et des limites de ressources permet d’apporter de l’ordre en matière de performances, de sécurité et d’exploitation. Ceux qui hébergent plusieurs instances WordPress ou de boutiques en ligne gagnent du temps lors du dépannage, des sauvegardes et des redémarrages après des incidents. Grâce à des droits clairs, des mises à jour, l’authentification multifactorielle (MFA) et la journalisation, on obtient une solution viable chaîne de sécurité, ce qui rend l'hébergement mutualisé nettement plus résistant.