Su shared hosting un sito compromesso può contagiare tutti gli altri sullo stesso server. Con CloudLinux e CageFS ogni account vive in un proprio file system virtuale, isolato da quello dei vicini. Sicurezza by default, non policy scritta.
L'isolamento per-account in hosting è una tecnologia che permette di mettere ogni sito in un proprio ambiente virtuale separato dagli altri sullo stesso server fisico, con un proprio file system, limiti di risorse di calcolo dedicati (CPU, RAM, numero di processi), e versione PHP scelta in autonomia. La realizziamo con CloudLinux (sistema operativo specializzato per hosting) e CageFS (il suo modulo di virtualizzazione del file system).
Differenza con shared tradizionale: senza isolamento, tutti i siti su un server condividono lo stesso file system e gli stessi processi. Se un sito viene compromesso, l'attaccante può potenzialmente leggere file di altri siti, iniettare codice nei loro WordPress, usarne le credenziali database. Con CageFS, ogni account vede un file system suo, gli altri non esistono.
Da Vicenza dal 2008 amministriamo direttamente oltre 300 siti sulla nostra infrastruttura, tutti su server con isolamento per-account attivo. È una scelta architetturale di base, non un'opzione che si attiva su richiesta: per noi un server senza CloudLinux non è hosting professionale.
Consolidamento di una decina di siti WordPress su nostra infrastruttura con isolamento per-account attivo. Quando uno dei siti ha avuto un picco di traffico anomalo, gli altri non hanno avuto rallentamenti misurabili. La policy di limiti risorse ha protetto l'intera flotta.
Sito con accessi multipli da staff non tecnico, esposto a tentativi di brute-force ricorrenti. Limiti CPU per account hanno contenuto l'impatto, isolamento file system ha impedito propagazione al resto del server. Imposto subito dopo: 2FA su tutti gli account staff.
Migrazione da shared hosting tradizionale a server con isolamento attivo. Il cliente ha potuto aggiornare PHP da 7.4 a 8.2 senza preoccuparsi degli altri siti, perché ognuno gira sulla propria versione. Aggiornamento programmato dopo test su staging.
File system virtuale, limiti risorse, PHP per versione, kernel rinforzato.
Ogni sito vede solo i propri file.
Con CageFS ogni account ha un proprio file system virtuale: vede solo i propri file e i binari di sistema strettamente necessari, non vede gli home directory degli altri, non può leggere i file di configurazione di siti vicini. Anche la lista dei processi è filtrata: l'utente vede solo i processi del proprio account.
Un sito impazzito non rallenta gli altri.
CloudLinux applica limiti per account su CPU, memoria, numero di processi simultanei, I/O sul disco. Se un sito ha un picco anomalo (attacco, plugin che cicla, traffico massiccio improvviso), consuma solo le proprie risorse riservate, gli altri sullo stesso server non rallentano. Per noi è la difesa di base contro i "vicini di casa rumorosi".
Ogni sito sceglie la sua versione PHP.
Su un singolo server CloudLinux possono coesistere PHP 7.4, 8.0, 8.1, 8.2, 8.3, ognuno usato dall'account che lo sceglie. Aggiornare PHP per un sito non rompe gli altri, e ogni cliente può fare il proprio percorso di aggiornamento secondo i suoi tempi. Tutte le versioni vengono mantenute con patch di sicurezza dal vendor.
Sicurezza al livello più basso, senza riavvii.
Il kernel di CloudLinux include patch di sicurezza specifiche per hosting condiviso (mitigazione di exploit kernel noti) e supporta il patching live: quando esce una vulnerabilità grave, il kernel viene aggiornato senza riavviare il server, mantenendo la disponibilità del sito. Ulteriore livello di protezione rispetto a un kernel Linux standard.
Pattern ricorrenti che vediamo prendendo in carico siti su shared hosting tradizionali:
Approccio pro: file system isolato, limiti risorse, PHP per versione, kernel rinforzato. Sicurezza by default, non opzionale.
Risultati concreti per chi sta su un server con altri siti:
Settimana 1.
Settimana 1-2.
Settimana 2.
Mensile.
Best-in-class per la sicurezza a livello server:
WordPress 
WooCommerce 
PHP 
MySQL 
Cloudflare WordPress WooCommerce PHP MySQL Cloudflare Quello che ti consegniamo come standard:
Il piano è dimensionato sul tuo sito: tipologia (vetrina, e-commerce, multisite), traffico atteso, livello di SLA e backup desiderati cambiano il quadro. Niente listini standard: prima cosa che facciamo è una breve call di scoping, poi mandiamo un preventivo scritto entro 48 ore.
Sì. Su server con CloudLinux ogni account può scegliere la propria versione PHP tra quelle disponibili (tipicamente 7.4 e 8.0 / 8.1 / 8.2 / 8.3). L'aggiornamento si fa dal pannello cPanel oppure su richiesta a noi, con possibilità di test su staging prima del passaggio.
Riceviamo una notifica automatica e analizziamo la causa. Se è un picco fisiologico (campagna marketing, articolo virale) calibriamo i limiti al rialzo. Se è un plugin impazzito o un attacco, interveniamo per sistemare il problema. In nessun caso il sito viene buttato giù senza preavviso.
No. Con CageFS ogni account ha un proprio file system virtuale: vede solo i propri file e i binari di sistema strettamente necessari. Gli home directory degli altri account non sono visibili, e i processi sono filtrati a livello di lista.
Su un VPS dedicato dove gira un solo sito, l'isolamento per-account è meno critico (non hai vicini di casa). Resta utile come livello di protezione contro escalation locale: se il sito viene compromesso, l'attaccante è ulteriormente confinato. Lo applichiamo per default anche sui VPS dedicati.
Sì. Procediamo con copia a freddo, test su staging con isolamento attivo, cambio DNS programmato per zero downtime. Tipicamente in una o due settimane dalla firma. Migrazione a costo zero per chi sceglie il nostro hosting gestito.
Isolamento per-account attivo su tutti i nostri server. Non un'opzione che si attiva su richiesta, una scelta architetturale di base dell'infrastruttura.
CPU, RAM, processi e I/O capati per account. Un sito impazzito non rallenta gli altri. Notifica automatica al superamento delle soglie.
Ogni sito sceglie la propria versione PHP, aggiornamento programmato sui tuoi tempi. Niente passaggi forzati che rompono il sito.
Patch di sicurezza del kernel applicate senza riavvii. Quando esce una vulnerabilità grave, il server resta protetto e disponibile.
Analisi preliminare gratuita + report sintetico via email entro 48h.
