# Antipatterns mutualisés : vingt sites clients sous le même compte FTP > Un audit de sécurité révèle qu'une agence héberge vingt sites clients sur un unique compte d'hébergement, avec un seul identifiant FTP partagé pour tous. - Auteur : WordPress Développement - Publié le : 2022-01-11 - Mis à jour le : 2022-01-11 - Catégorie : Hébergement & serveurs - URL : https://www.wpmoderne.fr/hebergement/antipatterns-mutualise-vingt-sites-meme-compte-ftp/ ## L’essentiel - Un compte d'hébergement unique pour plusieurs clients crée un risque en cascade - Un identifiant FTP partagé rend impossible toute traçabilité des accès - Isoler chaque client limite l'impact d'une compromission Vingt dossiers, à la racine d'un unique compte d'hébergement mutualisé, chacun correspondant à un site WordPress différent, chacun appartenant à un client distinct de l'agence auditée. Un seul identifiant FTP, connu de l'ensemble de l'équipe, donne accès à la totalité de ces vingt dossiers en même temps. Voici ce que révèle, dès les premières minutes, un audit de sécurité mené avant la reprise de ce parc par une nouvelle équipe. Cette configuration n'a rien d'exceptionnel : elle correspond à une pratique répandue chez les petites agences qui ont grandi progressivement, ajoutant client après client sur le même compte d'hébergement, sans jamais revoir cette organisation initiale une fois le nombre de sites devenu conséquent. ## Ce qu'on observe L'arborescence du compte d'hébergement se présentait ainsi, chaque dossier hébergeant une installation WordPress complète et indépendante : ``` /home/agence-mutualise/ ├── client-boulangerie/ ├── client-garage-auto/ ├── client-cabinet-comptable/ ├── client-association-sportive/ ├── ... (16 autres dossiers similaires) ``` Un unique utilisateur FTP, avec un mot de passe partagé oralement entre les membres de l'équipe et jamais renouvelé depuis la création du compte, plusieurs années auparavant. Aucune séparation des bases de données par utilisateur MySQL dédié : un compte MySQL unique disposait des droits sur les vingt bases. ## Pourquoi c'est un problème La conséquence directe de cette organisation est qu'une compromission d'un seul site — via une extension obsolète ou un mot de passe faible sur un compte administrateur, par exemple — expose potentiellement les dix-neuf autres. Un attaquant ayant obtenu un accès en écriture sur un dossier, via une faille dans un des sites, dispose des mêmes droits système sur l'ensemble des autres dossiers du compte, puisque le système de fichiers ne les isole pas entre eux. - Une faille sur un seul site peut permettre d'écrire dans les dossiers des dix-neuf autres - Aucune traçabilité possible : impossible de savoir quel membre de l'équipe a modifié quel fichier - Un client qui demande la suppression de ses données ne peut pas être isolé sans risque pour les autres > L'essentiel à retenir : Un compte d'hébergement unique pour plusieurs clients crée un risque en cascade ; Un identifiant FTP partagé rend impossible toute traçabilité des accès ; Isoler chaque client limite l'impact d'une compromission ## Quoi faire à la place La correction recommandée, et progressivement mise en œuvre sur ce parc, repose sur une isolation stricte par client, quitte à répartir les sites sur plusieurs comptes d'hébergement mutualisé distincts, ou à migrer vers une offre permettant de créer plusieurs comptes utilisateurs système isolés au sein d'un même contrat : 1. Un compte d'hébergement (ou un compte utilisateur système isolé) par client, avec ses propres identifiants 2. Un utilisateur MySQL dédié par site, disposant uniquement des droits sur sa propre base 3. Des mots de passe générés individuellement et stockés dans un gestionnaire de mots de passe partagé de l'équipe, jamais communiqués oralement 4. Une revue régulière des accès, avec révocation immédiate en cas de départ d'un membre de l'équipe > Mutualiser des sites clients sur un même compte d'hébergement pour réduire les coûts d'infrastructure revient, en réalité, à mutualiser aussi le risque de sécurité entre des clients qui n'ont strictement aucun lien entre eux. Ce choix doit être justifié explicitement, jamais subi par habitude. ## Le coût de la remise en ordre Sur ce dossier, la migration complète vers vingt comptes isolés distincts a représenté plusieurs semaines de travail, principalement pour éviter toute coupure de service pendant la bascule de chaque site, un par un, avec vérification systématique du bon fonctionnement avant de passer au suivant. Ce coût, certes réel, reste sans commune mesure avec celui d'une compromission en cascade touchant vingt clients simultanément. ## Ce que cet audit a changé durablement La nouvelle équipe a inscrit cette isolation par client comme règle non négociable pour toute nouvelle prise en charge de site, quelle que soit la taille du client. Un compte d'hébergement partagé entre plusieurs projets n'est désormais accepté que lorsque ces projets appartiennent à une même entité, jamais lorsqu'il s'agit de clients distincts sans lien juridique ou opérationnel entre eux.