La gestione dei siti dei clienti su scala richiede di pensare alla sicurezza dell’infrastruttura in modi che vanno oltre la semplice installazione di plugin di sicurezza o l’imposizione di password forti.
Quando si ospitano decine o centinaia di siti WordPress, l’architettura dell’hosting diventa un fattore di sicurezza che può proteggere l’intero portafoglio o metterlo a rischio.
L’hosting condiviso tradizionale consente di contenere i costi, ma comporta anche la condivisione dello stesso file system, dello stesso spazio di processo e dello stesso stack di rete tra siti diversi. Pertanto, quando un sito su un server condiviso viene compromesso, il malware può diffondersi ad altri siti.
I rischi di sicurezza nascosti degli ambienti di hosting condiviso
Ogni sito su un server di hosting condiviso utilizza una parte della CPU, della RAM e dello storage del server. Questo ha senso per i provider di hosting dal punto di vista dei costi e mantiene i prezzi accessibili per i clienti.
Tuttavia, dal punto di vista della sicurezza, esistono vulnerabilità che aumentano con il numero di siti gestiti. Il problema principale riguarda la condivisione delle risorse. I permessi dei file e l’isolamento degli utenti possono fornire una certa protezione, ma si tratta di controlli a livello di software che possono essere sfruttati. Dopotutto, gli attacchi di phishing, malware e ransomware rimangono le principali minacce per qualsiasi sito.
I concetti di “diffusione laterale” e “contaminazione incrociata” possono aiutare a chiarire i rischi:
- La diffusione laterale si riferisce al malware che si sposta da un sistema compromesso ad altri sistemi all’interno della stessa rete o ambiente.
- La contaminazione incrociata si verifica quando un problema di sicurezza che colpisce un sito si diffonde ad altri siti che condividono la stessa infrastruttura.
Se gestisci un portafoglio clienti, risparmiare denaro utilizzando un hosting condiviso può essere interessante. Tuttavia, un plugin obsoleto o la password debole di un singolo cliente possono rappresentare una minaccia per l’intero sistema di hosting.
Se consideri il tempo dedicato al monitoraggio delle minacce e al recupero degli incidenti di sicurezza su più siti, il valore scende.
Come si diffonde il malware tra i siti su server condivisi
L’esatta natura di qualsiasi contaminazione tra siti dipende dal modo in cui il provider di hosting implementa la separazione degli utenti e i permessi dei file. Tuttavia, il problema fondamentale è sempre lo stesso nella maggior parte delle configurazioni di hosting condiviso: questi ambienti creano superfici di attacco in cui gli account compromessi possono accedere ai file di altri utenti attraverso autorizzazioni non configurate correttamente o script vulnerabili.
I percorsi per l’infezione cross-site includono:
- Gli script PHP leggono i file dalle directory di altri utenti quando i permessi sono configurati in modo errato.
- Le directory temporanee condivise permettono al malware di diffondersi tra i siti.
- Le vulnerabilità a livello di server permettono ai processi di un sito di influenzare gli altri.
- Gli account utente compromessi accedono alle directory vicine attraverso pool di risorse condivise.
Bookswarm, cliente di Kinsta, ha scoperto questo problema mentre gestiva centinaia di siti di clienti su una piattaforma di hosting condivisa. Hanno scoperto che la configurazione mista dei server creava problemi di sicurezza oltre alla compromissione dei singoli siti. L’architettura rendeva “un attacco a uno un attacco agli altri”.
Questo crea anche un onere operativo, in quanto è necessario un monitoraggio costante per individuare le compromissioni prima che si diffondano. Se un sito mostra segni di infezione, è necessario controllare tutti gli altri siti sullo stesso server. La risposta agli incidenti diventa un esercizio a livello di portafoglio piuttosto che una soluzione isolata.
Il problema della contaminazione delle blacklist
Gli indirizzi IP condivisi creano un altro livello di rischio nell’hosting condiviso tradizionale. Quando più siti condividono lo stesso IP, condividono anche la stessa reputazione agli occhi dei provider di posta elettronica, dei motori di ricerca e dei servizi di sicurezza.
Poiché una singola compromissione può portare l’intero indirizzo IP nella lista nera, ogni sito su quell’IP soffre di diversi problemi a cascata:
- La deliverability delle e-mail diminuisce in tutto il tuo portfolio quando un sito compromesso attiva i filtri antispam come Spamhaus.
- I motori di ricerca segnalano l’IP condiviso come sospetto, influenzando negativamente le classifiche di tutti i siti associati.
- I servizi di sicurezza e i firewall bloccano le richieste provenienti dall’IP, interrompendo la funzionalità dei siti non collegati alla compromissione originale.
- I siti dei clienti perdono gli indicatori di fiducia quando gli strumenti di sicurezza associano l’IP condiviso ad attività dannose.
Il processo di recupero da una lista nera di IP richiede uno sforzo coordinato con il tuo provider di hosting. È necessario identificare il sito che ha causato il problema, ripulirlo e quindi richiedere la rimozione dalle varie blacklist. Durante questo processo, tutti i siti sull’IP condiviso continuano a subirne le conseguenze.
Nel frattempo, dovrai spiegare ai tuoi clienti perché la loro e-mail ha smesso di funzionare o perché il loro sito è stato segnalato, anche se hanno seguito le migliori pratiche di sicurezza di WordPress. La causa principale è da ricercare in decisioni infrastrutturali su cui i singoli proprietari dei siti non hanno alcun controllo. Tutta questa manutenzione continua sottrae tempo al lavoro dei clienti e ai progetti di sviluppo.
Isolamento a livello di container per l’hosting WordPress
L’isolamento del sito risolve molti dei problemi fondamentali dell’hosting condiviso. Ad esempio, Kinsta gestisce ogni sito nel proprio container isolato con risorse dedicate. Ciò significa che ogni sito WordPress ha un proprio container che include tutto ciò che è necessario per funzionare: Linux, NGINX, PHP e MySQL.
L’isolamento avviene a livello di sistema operativo attraverso due meccanismi fondamentali:
- Gli spazi dei nomi, o name space, forniscono a ciascun container la propria visione delle risorse di sistema. Un processo in esecuzione in un container non può vedere o interagire con i processi di un altro container.
- I gruppi di controllo (“cgroup”) impongono limiti alle risorse e assicurano che ogni container abbia accesso alla sua allocazione dedicata di CPU e RAM.
Inoltre, i thread PHP di un sito WordPress non possono vedere o interagire con i processi di altri siti. Questa separazione a livello di kernel evita scenari in cui il processo compromesso di un sito tenta di accedere a risorse appartenenti ad altri siti.
Anche gli stack di rete operano in modo indipendente all’interno di ciascun container. Ogni sito ha la propria interfaccia di rete e la propria gestione IP. Questo isolamento si estende a tutto lo stack ed elimina il problema dei vicini invadenti che affligge l’hosting condiviso.
Quando un sito subisce un picco di traffico o esegue operazioni ad alta intensità di risorse, ciò si ripercuote solo sul container di quel sito. L’allocazione dedicata delle risorse fa sì che gli altri siti continuino a funzionare con la loro allocazione completa, indipendentemente da ciò che accade altrove nell’infrastruttura.
Come l’isolamento dei container previene la diffusione laterale del malware
Quando un sito viene compromesso in un ambiente containerizzato, il malware rimane confinato all’interno del container. Questa separazione impedisce ai processi compromessi di accedere ad altri container attraverso diversi meccanismi:
- I file system rimangono isolati, quindi il malware non può diffondersi sfruttando directory condivise o file temporanei.
- Gli spazi dei nomi dei processi impediscono al codice dannoso di scansionare o interagire con i processi di altri container.
- L’isolamento della rete limita la capacità dei siti compromessi di scansionare o attaccare i siti vicini.
- Gli spazi di memoria rimangono completamente separati, impedendo agli attacchi di buffer overflow di superare i confini dei container.
Se il sito è ospitato su Kinsta, i nostri sistemi di monitoraggio possono rilevare immediatamente il container compromesso e rispondere mentre gli altri siti del tuo portfolio continuano a funzionare.
Come verificare se è un vero isolamento rispetto alle dichiarazioni del marketing
Non tutti i provider di hosting implementano l’isolamento dei container allo stesso modo. Alcuni usano il termine “isolato” per descrivere limiti morbidi all’uso delle risorse, pur continuando a gestire più siti in ambienti condivisi. Capire cosa costituisce un vero isolamento a livello di container aiuta a valutare le opzioni di hosting e a evitare i rischi per la sicurezza derivanti da un marketing ingannevole.
Un vero isolamento a livello di container significa che ogni sito viene eseguito nel proprio spazio dei nomi del sistema operativo con risorse dedicate a cui non possono accedere altri siti. Se sei alla ricerca di un nuovo provider di hosting, ci sono alcuni punti di attenzione:
- Ogni sito ha un proprio container con allocazioni dedicate di CPU e RAM a cui gli altri siti non possono accedere?
- I file system sono completamente separati a livello di kernel utilizzando spazi dei nomi e non solo permessi a livello utente?
- Cosa succede agli altri siti quando un container viene compromesso o si verifica un picco di traffico?
- Quale tecnologia di containerizzazione utilizza l’host (LXC, LXD, Docker) e come applica l’isolamento?
- L’host può fornire una documentazione tecnica sui suoi meccanismi di isolamento e sulla sua architettura?
La differenza tra limiti morbidi e isolamento rigido è importante sia per la sicurezza che per le prestazioni. I limiti morbidi possono limitare la quantità di CPU che un sito può utilizzare, ma operano all’interno di un ambiente condiviso in cui i processi di un sito possono comunque interagire con gli altri. L’isolamento rigido con risorse dedicate implica che ogni sito operi in un ambiente completamente separato dove i siti vicini non possono accedere alle sue risorse o essere influenzati dalle sue attività.
Metodi di verifica tecnica
La ricerca delle specifiche tecniche che descrivono in dettaglio la tecnologia di containerizzazione può aiutarti a capire fino a che punto un host conosce l’architettura sottostante. Ad esempio, i fornitori che utilizzano LXC, LXD, Docker o tecnologie simili dovrebbero essere in grado di descrivere i meccanismi di isolamento specifici che implementano.
Le certificazioni di conformità come SOC 2 Type II e ISO 27001 indicano che le pratiche di sicurezza sono state verificate da soggetti indipendenti. Queste certificazioni richiedono controlli di sicurezza documentati e test regolari, che forniscono maggiori garanzie rispetto alle sole dichiarazioni di marketing. Kinsta mantiene entrambe le certificazioni e si sottopone a controlli regolari per verificare che i meccanismi di isolamento funzionino come pubblicizzato.
Se hai la possibilità di utilizzare l’host attraverso un periodo di prova, puoi anche verificare il funzionamento dell’isolamento in diversi modi, ad esempio monitorando il consumo di risorse di più siti sullo stesso server o osservando cosa succede durante le operazioni che richiedono un uso intensivo della CPU per un singolo sito.
Con Kinsta, questo tipo di verifica pratica è possibile durante il primo mese, a costo zero.
Cosa significa l’isolamento del sito per la tua strategia di hosting
Passare da un hosting condiviso a un’architettura isolata a container può cambiare in meglio la sicurezza del tuo intero portafoglio WordPress e anche il modo in cui affronti la gestione dell’infrastruttura su scala.
Tra più siti di clienti su hosting condiviso, la probabilità che almeno un sito subisca un incidente di sicurezza è quasi certa. La vera domanda da porsi è se l’incidente rimane circoscritto a un singolo sito o se crea problemi a cascata in tutto il tuo portfolio.
Per le agenzie e i team che gestiscono molti siti WordPress, l’hosting è in definitiva una decisione di rischio a livello di portafoglio. Se stai cercando un’infrastruttura progettata appositamente per la gestione di siti su scala, Kinsta offre soluzioni su misura per le agenzie e per gli ambienti WordPress ad alto volume.
