Isolamento per sito
L'isolamento fa la differenza tra un incidente e un'interruzione di servizio. Ogni sito da noi ospitato opera all'interno di una gabbia CloudLinux LVE a livello di kernel, dotata di propri limiti di CPU, RAM, IO e processi, di una propria visualizzazione del file system CageFS, della propria versione di PHP e della propria limitazione del database. Un sito attaccato, compromesso o che esegue semplicemente una query gravosa viene confinato nel proprio spazio — e il livello base di isolamento è incluso in ogni piano, non venduto come aggiornamento. Disponibilità: la limitazione del database per sito e le statistiche delle risorse per sito sono in fase di sviluppo attivo e non ancora disponibili. Tutto il resto descritto qui è già attivo oggi.
La flotta di worker esegue CloudLinux OS, che spinge la multi-tenancy direttamente nel kernel. Ogni sito riceve un Lightweight Virtual Environment — un LVE — che costituisce un confine rigido anziché una semplice convenzione di cortesia. Nulla di ciò che un sito compie all'interno della propria gabbia può essere consumato a carico del budget di qualcun altro.
LVE limita CPU, RAM, IO, IOPS, processi e processi di ingresso per ogni sito in modo indipendente. Quando un sito supera la propria soglia massima, viene limitato all'interno della propria gabbia virtuale: l'errore viene registrato a carico di quel sito, mentre i siti circostanti continuano a funzionare senza risentirne.
Un plugin bloccato in un ciclo, un cron job scritto male o un crawler che sovraccarica un endpoint raggiungono prima i limiti di processi e di processi di ingresso del sito stesso. Un singolo sito non può semplicemente consumare l'intera macchina.
Poiché i processi di ingresso sono limitati per ciascuna gabbia di isolamento, un'ondata di traffico diretta verso un singolo sito non può generare un carico di lavoro illimitato sull'host. La limitazione delle connessioni e delle richieste di LiteSpeed e il firewall di rete Imunify360 sono posizionati a monte, facendo sì che l'attacco rimanga un problema esclusivo del bersaglio.
Ogni errore LVE viene registrato per ciascun sito e confluisce nel motore dei criteri della piattaforma, in grado di inasprire o allentare i limiti automaticamente. È possibile visualizzare il motivo e il momento in cui un sito è stato limitato — in modo graduale, reversibile e registrato.
L'isolamento delle risorse impedisce a un sito di sovraccaricare il sistema. L'isolamento del file system gli impedisce di essere indiscreto. CageFS offre a ogni utente una visualizzazione privata e limitata della macchina.
Sotto CageFS, un tenant vede solo i propri file e un set minimo e sanificato di binari di sistema — e non può visualizzare gli altri tenant, i loro siti o file di sistema sensibili. La tipica modalità di fallimento dell'hosting condiviso, in cui un account compromesso diventa un punto di lettura su tutti gli altri account della macchina, viene bloccata a livello di kernel.
Questo è fondamentale soprattutto il giorno in cui qualcosa va storto. Se un sito viene compromesso — a causa di un plugin obsoleto, di credenziali rubate o di un tema vulnerabile — CageFS è ciò che limita il raggio d'azione dell'attacco a quella singola gabbia. Le nostre specifiche di sicurezza sono ponderate nella formulazione: CageFS contiene le violazioni. Il contenimento è una promessa onesta, ed è ciò che determina se un incidente richiede la pulizia di un solo sito o dell'intera infrastruttura.
I backup rafforzano lo stesso perimetro. I backup per singolo sito sono immutabili, offsite e isolati dall'infrastruttura operativa, con ripristini verificati, affinché persino nel peggior scenario di compromissione di un sito sia disponibile un percorso di ripristino pulito e indipendente che non dipenda dallo stato della macchina su cui era in esecuzione.
L'isolamento del livello web è solo una parte della storia. Su una flotta WordPress, ciò che più spesso fa sembrare lento un server sono le query di un sito, non il suo traffico. Questo viene gestito esplicitamente.
CloudLinux MySQL Governor limita l'uso del database per ciascun sito, evitando che le query pesanti di un singolo sito possano rallentare il server per tutti gli altri. È il controllo anti-rallentamento ed è operativo a prescindere dal fatto che il sito rumoroso si accorga o meno di essere limitato.
Il parco macchine esegue MariaDB (o Percona), scelto appositamente per i carichi di lavoro di WordPress anziché essere ereditato per impostazione predefinita, con Governor al di sopra come livello di equità per tenant.
Una cache di oggetti Redis per sito assorbe le letture ripetute prima che raggiungano il database, riducendo fin dall'inizio la pressione che Governor deve gestire. La memorizzazione nella cache e l'isolamento funzionano come un unico sistema.
CloudLinux alt-PHP offre a ciascun sito un proprio selettore di versione PHP, le proprie estensioni (imagick, gd, redis e le altre) e le proprie impostazioni rafforzate — con i worker LSAPI vincolati dai limiti LVE di tale sito, affinché la concorrenza PHP sia parte integrante della gabbia anziché una via di fuga da essa.
L'isolamento determina fino a che punto si diffonde un problema. L'applicazione determina cosa accade dopo. Abbiamo sostituito la brusca sospensione on/off con una macchina a stati, guidata da flussi di lavoro duraturi e applicata sul worker tramite LiteSpeed, LVE e Imunify.
L'isolamento non è una funzionalità del piano che compare tre livelli più in alto. È una proprietà del substrato, pertanto è identico sia che gestiate un singolo negozio WooCommerce, sia che ne gestiate duemila in rete.
Le reti bulk e PBN funzionano sullo stesso substrato LVE e CageFS, insieme alla rotazione degli account CDN consapevole dell'impronta e alla distribuzione di HTML statico. L'isolamento è ciò che rende sicura la densità: i siti condividono una flotta senza condividere la stessa sorte.
I siti gestiti WordPress, WooCommerce, PHP, statici e Node ottengono gli stessi ambienti isolati (cages) e una completa autogestione: la propria versione ed estensioni PHP, cache degli oggetti Redis, staging e push-to-live.
Per i carichi di lavoro che richiedono una delimitazione più rigorosa rispetto a quella predefinita ottimizzata per la densità, viene offerto un isolamento completo con un container per sito come variante del driver di provisioning: stesso motore, stesso piano di controllo, diverso posizionamento, a fronte di un overhead superiore.
L'isolamento LVE e CageFS, il WAF proattivo e la scansione antimalware sono inclusi per ogni cliente, poiché un sito infetto o fuori controllo minaccia i siti vicini e la nostra reputazione IP. La pulizia del malware con un clic e i livelli di protezione avanzata sono componenti aggiuntivi a pagamento: la protezione di base non lo è.
La tentazione commerciale nell'hosting è vendere la sicurezza a livelli: collocare i clienti economici su un server condiviso con limiti flessibili e far pagare chi richiede una separazione netta. Noi non lo facciamo, perché il cliente che non ha pagato per l'isolamento è proprio quello il cui sito compromesso diventa un problema per tutti gli altri.
Ospitiamo oltre 700.000 siti in tutto il mondo, su un'infrastruttura in cui l'alta densità rappresenta l'intera proposta economica. Ciò funziona solo se l'isolamento sottostante è incondizionato. Gabbie a livello di kernel, una visualizzazione privata del file system, limitazione del database per sito e PHP dedicato per sito sono il prezzo da pagare per operare su tale scala senza destini condivisi — pertanto sono attivi per tutti, in ogni piano, sin dal primo sito da Lei distribuito.
Il risultato è una piattaforma che si comporta in modo prevedibile anche nelle giornate più difficili degli altri. Alla base vi sono una garanzia di operatività del 99.99%, backup esterni immutabili per singolo sito con ripristini verificati e un tracciamento di controllo completo di ogni azione di applicazione eseguita sui Vostri siti.
L'isolamento è progettato specificamente per impedire ciò. LVE limita CPU, RAM, IO, IOPS e processi per sito, MySQL Governor regola l'utilizzo del database per sito e i worker LSAPI sono confinati all'interno del cage del sito stesso — quindi un picco di traffico o un pesante carico di query di un vicino viene limitato rispetto al loro massimale, non al Vostro. Ogni errore viene registrato per sito e il motore delle policy può restringere automaticamente i limiti di un sito rumoroso.
La risposta onesta è il contenimento, non una garanzia. CageFS offre a ciascun tenant una visualizzazione isolata del file system — un tenant compromesso non può vedere gli altri tenant, i loro siti o i file di sistema sensibili — e un caso confermato di malware o phishing sposta tale sito in quarantena: offline, file bloccati, nessuna esecuzione, isolato per l'analisi forense. Questo è ciò che limita il raggio dell'impatto. Parallelamente, eseguiamo scansioni antimalware e un WAF proattivo su ogni sito, oltre a backup esterni immutabili per singolo sito con ripristini verificati, affinché il ripristino non dipenda mai dallo stato della macchina interessata.
È incluso in ogni piano. L'isolamento LVE e CageFS, il WAF proattivo e la scansione antimalware sono standard per ogni cliente, poiché un sito infetto o fuori controllo minaccia i server vicini e la reputazione del nostro IP — non possiamo ragionevolmente renderlo facoltativo. Ciò che viene venduto come componente aggiuntivo è la pulizia e correzione del malware in un clic e livelli di protezione avanzati come regole WAF potenziate, scansione prioritaria, gestione dei bot e livelli DDoS superiori.
Viene limitato all'interno della propria gabbia anziché essere disattivato. Essere limitato significa limiti LVE più rigidi e rate limiting mentre il sito rimane attivo e funzionante, con un ripristino automatico non appena la causa si risolve. Riceverà una notifica con il motivo, la transizione verrà registrata con le relative prove ed è possibile presentare ricorso. Se il carico è dovuto a una crescita reale piuttosto che a un guasto, la soluzione è un piano superiore, non una limitazione permanente.
No — un sito sospeso mostra una pagina di attesa personalizzata con il motivo specifico (fatturazione, manutenzione o violazione), in modo che risulti un'azione intenzionale e non un guasto. La sospensione viene revocata a seguito del pagamento, della risoluzione del problema o di un ricorso. La quarantena è più rigorosa e funziona diversamente: viene revocata solo dopo la bonifica e la verifica, mai automaticamente.
Su Zinn® Managed WordPress sì: CloudLinux alt-PHP offre a ciascun sito un proprio selettore di versione PHP, le proprie estensioni come imagick, gd e redis e le proprie impostazioni protette, il tutto limitato dai limiti LVE di quel sito. L'hosting Footprint-Free esegue deliberatamente una configurazione per sito più standardizzata e bloccata, poiché la varietà di configurazione costituisce essa stessa una footprint.
Sì. CloudLinux LVE e CageFS rappresentano l'impostazione predefinita ottimizzata per la densità su entrambe le linee di prodotti. Per i carichi di lavoro che richiedono una delimitazione più rigorosa, viene offerto un isolamento completo con un container per sito come variante del driver di provisioning: lo stesso motore e piano di controllo con un posizionamento diverso, sacrificando l'overhead a favore di una separazione più netta.
Sì. L'hosting Footprint-Free inizia con una prova di 14 giorni senza carta di credito che copre fino a cinque siti: nessun dato di pagamento, nessun impegno. Distribuite alcuni siti, sottoponeteli a un po' di carico e verificate il comportamento delle gabbie prima di decidere.
Inizia una prova di 14 giorni senza carta di credito su Footprint-Free Hosting: fino a cinque siti, nessun dato di pagamento, nessun impegno. L'isolamento a livello di kernel, il WAF proattivo e la scansione dei malware sono inclusi fin dal primo deploy.
Inizia gratis