Vai al contenuto 
CageFS per sito separa rigorosamente i singoli siti web all’interno di un account di hosting condiviso, limitando così il rischio di propagazione laterale in caso di attacco. Illustrerò la nuova architettura di sicurezza, mostrerò alcuni scenari pratici di utilizzo e spiegherò come gestirla per gestire in modo sicuro più progetti all’interno di un unico account.
Punti centrali
- Isolamento del sito web: Una separazione aggiuntiva all’interno di un unico conto riduce i rischi collaterali.
- CloudLinux: Estensione del concetto CageFS a livello di dominio.
- WordPress: Gestire in modo sicuro più istanze in parallelo.
- Risorse: I limiti per CPU/RAM/I/O integrano la separazione delle viste dei file.
- Pratica: Attivazione per dominio e una strategia chiara in materia di diritti e percorsi.
Cosa offre concretamente „Per-Site CageFS“
L'estensione isola i singoli Domini all’interno di un CageFS utente esistente, in modo che ogni sito web possa vedere solo i propri file e processi. In questo modo impedisco che un progetto compromesso possa accedere ai file di configurazione, ai file caricati o alle chiavi di altri siti presenti nello stesso account. Secondo CloudLinux Blog (annuncio della versione beta): CageFS per singolo sito amplia l’isolamento tra i siti web all’interno dello stesso account utente, riducendo così il rischio di contaminazione laterale. Per me il vantaggio è evidente: posso segmentare in modo netto gli account dell’agenzia, le configurazioni multisito e gli ambienti di test senza stravolgere la struttura di hosting. Questa panoramica offre una rapida introduzione al principio di funzionamento di CageFS: Sistema di file CageFS, su cui si basa l'isolamento per sito.
Perché l'isolamento degli account da solo non basta
Un account spesso raggruppa diversi Progetti – circa due shop, tre blog e un ambiente di staging. Se un exploit attacca un plugin vulnerabile, un aggressore può, senza ulteriore segmentazione, accedere alle directory adiacenti e inserirvi ulteriori payload. È proprio qui che Per-Site CageFS limita la visibilità sul file system e sui processi in modo tale che ogni sito web sia come in una propria Prigione funziona. Soprattutto nel caso di istanze WordPress separate che condividono lo stesso utente PHP, altrimenti si crea un rischio di escalation che io elimino grazie all’isolamento dei domini. Ciò riduce i danni conseguenti, semplifica l’analisi forense e rende più facile pianificare rapidamente i ripristini.
Ecco come funziona, dal punto di vista tecnico, l'isolamento del sito web
CloudLinux, tramite CageFS, crea un ambiente virtuale per ogni utente sistema di file; il livello "per sito" estende questa protezione ai confini del dominio. Ogni dominio attivato riceve un’area di visualizzazione separata all’interno del CageFS dell’utente, comprensiva di percorsi restrittivi, directory temporanee dedicate ed esecuzione degli script isolata. In questo modo, file wp-config.php estranei, cartelle di upload o file di chiavi scompaiono dalla vista del sito web compromesso. I cronjob, il PHP e, se del caso, i comandi SSH accedono alle stesse librerie di sistema, ma vedono solo le risorse assegnate Sottinsiemi del file system. Secondo la documentazione, è possibile attivare la separazione per ogni dominio, il che mi offre un controllo molto dettagliato per le istanze live, di staging e di test.
Confronto: isolamento degli account, CageFS per sito e container
Per effettuare una scelta in modo strutturato, metto a confronto tre modelli comuni Modelli in base al livello di isolamento, all’impegno richiesto e alla compatibilità. L’isolamento dell’account garantisce la separazione tra i clienti, ma lascia aperte le frontiere interne tra i siti. CageFS per sito colma questa lacuna a livello di file system e di processo. I container creano confini rigidi, ma spesso richiedono maggiore manutenzione e personalizzazioni. Una classificazione approfondita dell’isolamento dei processi è fornita da questo Confronto tra Chroot, CageFS e Jails.
| Approccio | Separazione tra gli account | Separazione tra i siti web nell'account | Compatibilità (PHP/CGI/SSH/Cron) | Spese operative |
|---|---|---|---|---|
| Isolamento dell'account (classico) | Alto | Basso | Molto buono | Basso |
| CageFS per sito | Alto | Medio-alto | Molto buono | Da basso a medio |
| Container per sito | Molto alto | Molto alto | Da buono a molto buono | Medio-alto |
Negli ambienti di hosting condiviso, Per-Site CageFS offre un efficace connubio tra un controllo preciso Separazione e con un intervento minimo, poiché gli script, di norma, continuano a funzionare senza modifiche. In questo modo risolvo il punto debole più comune: la presenza di più siti web indipendenti sotto un unico account utente.
Esempio pratico: gestire in modo sicuro più istanze di WordPress
Isolo ogni istanza di WordPress con l'opzione attivata Isolamento dei domini e imposto pool PHP-FPM dedicati per ogni sito, in modo che log, opcache e limiti rimangano chiaramente attribuibili. Inoltre, definisco SALT/KEY specifici per ogni sito nel file wp-config.php e impedisco qualsiasi accesso trasversale tramite i permessi dei file e le impostazioni equivalenti a open_basedir. Salvo i file caricati rigorosamente all’interno della rispettiva directory document root e vieto l’uso di directory di caricamento condivise a livello globale. Durante le operazioni di distribuzione, mantengo i percorsi temporanei all’interno del singolo sito e elimino immediatamente gli artefatti di build, in modo che non rimangano punti di vulnerabilità superflui. Per le cache di Composer o NPM utilizzo directory locali al sito Elenchi, in modo da evitare effetti collaterali.
Prestazioni e gestione delle risorse in sinergia
CageFS per sito gestisce la visualizzazione dei file; il Prestazioni Mi assicuro di impostare dei limiti per CPU, RAM, I/O e processi a livello di account o di pool. In questo modo impedisco che un sito, a causa di plugin difettosi, generi un carico eccessivo e rallenti l’intero account. In molte configurazioni, ciò avviene tramite quote LVE o simili, che regolo con precisione per ogni pool o account. A questo abbino la limitazione delle richieste nel server web o nel WAF, in modo che i picchi di traffico vengano gestiti in modo ordinato. Questa combinazione di isolamento e quote aumenta la sicurezza dei servizi e la prevedibilità Distribuzione del carico.
Catena di protezione: ciò che Per-Site CageFS non sostituisce
L'isolamento impedisce le viste trasversali, ma ritengo che gli aggiornamenti, Indurimento Continua ad applicare con coerenza le misure relative a PHP e alle password complesse. Anche l’autenticazione a più fattori (MFA) per gli accessi amministrativi, i permessi minimi sui file e i filtri di upload rimangono obbligatori. Un WAF, i limiti di frequenza e la registrazione continua dei log coprono ulteriori varchi di sicurezza che la semplice separazione dei file non è in grado di controllare. Verifico inoltre regolarmente i cronjob e i token di integrazione, che gli aggressori spesso dimenticano di controllare. Maggiori informazioni sull’interazione tra separazione dei clienti e rafforzamento della sicurezza sono disponibili in questa guida su Sicurezza dell'hosting condiviso, che ne sottolinea la linea di pensiero.
Configurazione e ostacoli tipici
Attivo l'isolamento del dominio in modo mirato per ogni singolo sito web e poi verifico l'accesso a SSH, Cron e PHP in condizioni reali. I percorsi assoluti negli script di distribuzione o nei plugin possono causare problemi, quindi preferisco utilizzare percorsi relativi o variabili. Evito i collegamenti simbolici tra i progetti perché indeboliscono il principio di separazione; preferisco aggiungere le librerie necessarie al repository per ogni singolo sito. Per i backup definisco archivi separati e salvo i log per ogni dominio, in modo che il ripristino e l’analisi forense rimangano chiari. Per quanto riguarda i permessi, si sono dimostrati efficaci 640 per i file e 750 per le cartelle, oltre a Proprietario in base al rispettivo pool PHP.
Analisi costi-benefici per agenzie e liberi professionisti
Valuto il guadagno in termini di sicurezza a fronte del tempo dedicato all'amministrazione e dei potenziali costi di inattività che un incidente trasversale comporterebbe, in Euro-Base. Spesso, anche solo poche ore di risposta agli incidenti costano molto di più di un piccolo sovrapprezzo mensile per un isolamento migliore. Per gli account delle agenzie con più progetti di clienti, la segmentazione riduce sensibilmente il rischio di responsabilità civile e di reputazione. Anche i processi di backup e ripristino procedono in modo più ordinato, poiché posso ripristinare singoli siti in modo mirato. Nel complesso, CageFS «per sito» garantisce un funzionamento più affidabile Gestione operativa con procedure pianificabili.
Lista di controllo: quando diventa obbligatorio l'uso di CageFS per ogni sito
Attivo l'isolamento del dominio non appena ce ne sono più di Installazioni funzionano su un unico account e hanno cicli di aggiornamento diversi. Altrettanto importante: team di progetto separati o accessi amministrativi esterni, che aumentano il rischio di interventi involontari. Elevati volumi di upload, convertitori di file o elaborazione delle immagini giustificano ulteriormente la separazione, poiché spesso proprio qui si creano punti di vulnerabilità. Anche i diversi requisiti di conformità (ad es. clienti, mercati, protezione dei dati) depongono a favore di segmenti più dettagliati. Chi gestisce in parallelo gli ambienti di staging, di test e di produzione beneficia di domini di errore ben separati e di una chiara Forense.
Requisiti e compatibilità nella pratica
Prima di mettere in produzione Per-Site CageFS, verifico l’ambiente di esecuzione: l’handler PHP utilizzato (ad esempio PHP-FPM, lsapi), il server web attivo, l’integrazione disponibile con il pannello di controllo e le modalità di gestione dei cronjob e delle sessioni SSH. Negli ambienti condivisi tipici, le applicazioni continuano a funzionare senza modifiche al codice. Mi assicuro che per ogni dominio esista una propria directory document-root, che i percorsi siano univoci (ad es. /home/user/sites/progetto-a/public) e che per ogni sito sia attivo un pool PHP-FPM dedicato. Per i cronjob utilizzo crontab separate per ogni dominio oppure – laddove il pannello di controllo li raggruppi – prefissi e percorsi di log chiari, in modo che i job rimangano all’interno del proprio Carceri lavoro.
Separare chiaramente database, cache e sessioni
La visualizzazione dei file è solo una parte. Estendo la separazione fino al database e alle cache. Per ogni sito web creo un database dedicato e un utente del database con diritti minimi. Per le cache di oggetti o di pagine (ad es. Redis, Memcached) utilizzo istanze separate per ogni sito o, quantomeno, prefissi di chiave e database/namespace dedicati. Le sessioni PHP vengono salvate in percorsi specifici per ogni sito; impostando separatamente il parametro `session.save_path` per ogni pool FPM. Se utilizzo una coda centrale o un backend di ricerca, separo indici e argomenti per ogni sito. Questo principio di „separazione fino all’ultimo miglio“ impedisce che gli incidenti si propaghino ai sistemi secondari.
CI/CD e distribuzioni in isolamento
Nelle pipeline di compilazione adotto l’isolamento come standard: per ogni sito esiste un proprio processo di distribuzione che accede esclusivamente alla directory del sito. Decomprimo gli artefatti all’interno della radice del dominio, quindi eseguo le correzioni relative a proprietario/gruppo e invalido esclusivamente le cache interessate. I comandi WP-CLI vengono eseguiti nel rispettivo contesto CageFS, in modo da non interferire con progetti esterni. Mantengo separate le variabili d’ambiente per ogni sito, mentre i segreti rimangono nei file di configurazione propri del sito o nell’archivio dei segreti del pannello di controllo. Per garantire zero downtime utilizzo switch atomici dei collegamenti simbolici all’interno dei confini del dominio (ad es. current/releases), prestando però attenzione che i collegamenti simbolici non puntino a progetti adiacenti. I controlli post-distribuzione (stato di salute, scansione 404/500, verifica dei permessi) sono obbligatori per ogni sito.
Monitoraggio, registrazione dei log e analisi forense
Separato sistematicamente i log: log di accesso e di errore per ogni dominio, log PHP e Cron dedicati, comprese le rotazioni e i periodi di conservazione. In caso di incidente, posso così ricostruire la cronologia di un singolo sito senza dover setacciare l’intero account. Inoltre, mi affido a controlli di integrità dei file (checksum delle directory principali), log di audit distribuiti per le azioni amministrative e semplici file canary che segnalano tempestivamente eventuali manomissioni. Per gli allarmi spesso bastano già dei valori soglia: aumenti improvvisi dei codici di errore 500, dimensioni di upload insolite, occupazione degli inode in forte crescita o avvii eccessivi dei worker PHP. A questi segnali associo procedure operative chiare: bloccare il sito, verificare i backup, salvare gli artefatti, riavviare in un ambito isolato.
Casi particolari di WordPress: Multisite, plugin MU e flussi di upload
Nel caso di WordPress Multisite valuto attentamente la situazione: un’installazione Multisite trae meno vantaggio da CageFS per singolo sito, poiché più siti condividono intenzionalmente lo stesso codice di base e la stessa struttura. Se ho bisogno di limiti più rigidi (team indipendenti, cache separate, analisi chiara), preferisco configurare singole istanze e isolarle. Distribuisco plugin MU, drop-in o librerie globali "must-use" solo all'interno del sito ed evito le cartelle condivise. I flussi di lavoro multimediali (CDN, ottimizzazione delle immagini, convertitori) vengono eseguiti all’interno del “domain-jail”; escludo gli upload da un sito verso le directory di un altro. Se un team desidera condividere le pipeline delle risorse, le replico per ogni sito oppure le incapsulo in un pacchetto da integrare nel rispettivo repository.
Percorso di migrazione: dal sistema monolitico all'account segmentato
Molti account partono con una cartella public_html molto grande e crescono nel tempo. Io procedo in cinque fasi: 1) Inventario: quali siti, domini, cronjob, database, credenziali? 2) Definizione della struttura dei percorsi: per ogni sito una propria root, cartella temporanea, log e backup. 3) Definire i pool PHP-FPM per ogni dominio e impostare i limiti. 4) Spostare i file, modificare i permessi, ripulire i percorsi assoluti e gli include. 5) Attivare CageFS per ogni sito, eseguire test sotto carico, attivare il monitoraggio. Nel frattempo, tengo pronta una strategia di rollback (snapshot, backup separati). Dopo il cutover, verifico che strumenti come WP-CLI, Composer, i processi di elaborazione delle immagini e i cronjob funzionino nell’ambito corretto e, se necessario, adeguo le variabili di percorso.
Errori e risoluzione dei problemi
- Errori 403/404 dopo l'attivazione: nella maggior parte dei casi, le regole di riscrittura o gli include rimandano a percorsi al di fuori della radice del dominio. Correggo i percorsi in varianti relative oppure utilizzo delle variabili.
- Composer/NPM non funziona: le cache globali non sono visibili. Impostiamo directory di cache locali al sito e modifichiamo le variabili HOME/TMP durante la distribuzione.
- WP-CLI non trova il file wp-config.php: l'esecuzione non avviene nella directory principale del dominio. Impostare correttamente la directory di lavoro oppure specificare esplicitamente il percorso.
- Cronjob inattivi: gli utenti cron o i percorsi non sono stati configurati per ciascun dominio. Controllo le variabili d'ambiente, i percorsi dei file binari e le destinazioni dei log all'interno del site-jail.
- Errori durante il caricamento: session.save_path o tmp_dir puntano alla directory sbagliata. Assegno percorsi temporanei locali al sito per ciascun pool FPM.
- Manca una libreria condivisa: il collegamento simbolico al progetto adiacente è bloccato. Replico la libreria in ogni sito oppure la integro come pacchetto nella distribuzione.
Governance e modello di accesso
Anche se dal punto di vista tecnico tutto è separato, rimane la questione degli accessi. Assegno accessi SSH/SFTP dedicati per ogni sito oppure limito l’accesso al pannello di controllo al rispettivo dominio. I team di sviluppatori e le agenzie ricevono solo le chiavi e le autorizzazioni di cui hanno realmente bisogno. Per le emergenze, ho predisposto una procedura di emergenza (diritti temporaneamente estesi, registrazione completa degli accessi, revoca successiva). Durante gli audit documento per ogni sito: percorsi, pool, limiti, responsabili, assegnazioni RBAC e backup. In questo modo la segmentazione rimane solida non solo dal punto di vista tecnico, ma anche organizzativo.
Riassumendo brevemente
CageFS per sito integra l'attuale separazione degli utenti con una sito web-livello, riducendo così efficacemente il rischio di movimenti laterali. Ritengo che si tratti di una misura concreta, poiché molti account riuniscono diversi progetti indipendenti. La combinazione tra separazione della visualizzazione dei file e limiti delle risorse garantisce ordine in termini di prestazioni, sicurezza e gestione. Chi ospita più istanze di WordPress o di negozi online risparmia tempo nella ricerca degli errori, nei backup e nel ripristino dopo gli incidenti. Grazie a diritti chiari, aggiornamenti, autenticazione a più fattori (MFA) e registrazione degli accessi, si crea una soluzione sostenibile Catena di sicurezza, che rende l'hosting condiviso decisamente più resiliente.
