In breve: se sia più sicuro il managed hosting o il root server lo decide meno la tecnica che la domanda su chi installa gli aggiornamenti in modo affidabile. Con il managed hosting lo fa il fornitore nella misura concordata, con il root server proprio il Suo team o un fornitore. Per le aziende senza competenze di server il managed hosting è di solito la scelta più sicura. Chi ha bisogno di controllo e dispone di un team di assistenza può viaggiare altrettanto sicuro con un server proprio.
Che cosa ha rivelato PHP2Shell sui modelli operativi
La situazione di ottobre 2026 è stata una prova pratica. Il 21/10 alle 16:00 ora tedesca sono uscite le patch, il BSI (l'Ufficio federale tedesco per la sicurezza informatica) ha raccomandato l'aggiornamento immediato. Chi aveva un piano gestito doveva soprattutto fare una cosa: chiedere al fornitore e farsi confermare stato delle patch e riavvio. Chi gestiva un server proprio doveva agire da sé, spesso di sera o nel fine settimana.
Entrambi avevano insidie. Per i clienti managed il pannello poteva continuare a mostrare un vecchio numero di versione, ad esempio 8.2.34, pur essendo stato installato un backport; senza conferma del fornitore lo stato restava poco chiaro. I gestori di server propri si chiedevano se avessero i pacchetti giusti e se tutti i processi PHP fossero stati riavviati. Le competenze di base le descrivono Server gestito: chiarire la responsabilità e Mettere in sicurezza da soli root server e vServer. Qui si tratta della scelta tra i due.
Managed hosting o root server: il confronto
| Criterio | Managed hosting | Root server o vServer proprio |
|---|---|---|
| Chi applica le patch a PHP e al sistema operativo? | Il fornitore, nella misura concordata | Lei o il Suo fornitore |
| Rapidità con falle critiche | Dipende dai processi del fornitore | Dipende dalla Sua disponibilità |
| Controllo sulla configurazione | Limitato, spesso solo tramite pannello o richiesta | Completo |
| Misure provvisorie a livello di server | Possibili solo tramite il fornitore | Attuabili da sé |
| Prova dello stato delle patch | Serve la conferma del fornitore | Verificabile da sé tramite il changelog del pacchetto |
| Competenze necessarie in azienda | Basse per il server, l'applicazione resta a Lei | Alte, in modo permanente |
| Requisiti particolari, vecchio software | Spesso impossibile | Possibile, ma rischio proprio |
| Ricerca di tracce dopo gli incidenti | Log e accesso solo previo accordo | Accesso completo, ma serve competenza propria |
| Dipendenza | Dal fornitore e dal suo contratto | Dal Suo team e dalla sua reperibilità |
La tabella mostra: entrambi i modelli spostano la responsabilità, nessuno la elimina. Con il managed hosting trasferisce la cura del server, ma mantiene l'obbligo di chiedere e di mettere in sicurezza la Sua applicazione. Con il server proprio mantiene tutto, fine settimana compresi.
Cinque domande per scegliere il modello operativo
- In azienda c'è una persona con competenze di server, sostituita anche in caso di malattia o ferie? In caso contrario, un server proprio senza assistenza esterna è rischioso.
- La Sua applicazione richiede configurazioni particolari, servizi propri o vecchio software? In caso affermativo, il managed hosting trova spesso dei limiti.
- Quanto è critico il sito per fatturato o attività? Più è critico, più sono importanti impegni chiari su aggiornamenti e raggiungibilità, in qualunque modello.
- Quali dati tratta? Con dati sensibili contano prove e accesso ai log. Chiarisca se il Suo fornitore consegna i log nell'emergenza.
- Quanti siti gestisce? Molti siti simili si possono raggruppare in modo efficiente su un server proprio ben assistito. I singoli siti sono spesso meglio affidati al managed hosting.
Le forme miste che funzionano
Tra i due poli ci sono modelli che nella pratica funzionano spesso meglio. Il più frequente è il server proprio con assistenza esterna: Lei mantiene il controllo su configurazione e dati, un fornitore si occupa di aggiornamenti, monitoraggio e reazione all'emergenza secondo accordi fissi.
Una seconda variante è il managed hosting con verifica di sicurezza integrativa. Il fornitore cura il server, un fornitore indipendente verifica regolarmente applicazione, plugin e tracce che esulano dall'ambito managed. Per i siti semplici, infine, l'hosting condiviso resta una soluzione ragionevole se l'hoster applica le patch in modo affidabile e il sito non ha esigenze particolari.
Importante in tutti i modelli: aggiornamenti di sicurezza automatici per il sistema operativo, backup verificati regolarmente e autenticazione a due fattori per tutti gli accessi sono basi che valgono a prescindere dal modello. Chi configura aggiornamenti automatici su un server proprio deve comunque controllare che i processi PHP vengano poi riavviati; perché sia decisivo lo spiega Dopo l'aggiornamento: riavviare PHP-FPM e tutti i worker.
Nessun modello operativo Le toglie la responsabilità per la Sua applicazione e i Suoi dati. Anche con il managed hosting CMS, plugin e account admin vanno curati e le violazioni dei dati valutate da Lei.
Quando un cambio ha senso e quando no
Un cambio conviene se PHP2Shell ha mostrato una debolezza strutturale: il Suo team non ha potuto applicare in tempo la patch al server proprio, oppure il Suo fornitore managed non ha reagito alle richieste e non ha fornito alcuna prova. A che cosa prestare attenzione nel cambio di fornitore lo descrive Cambiare hoster dopo un incidente di sicurezza.
Non è invece un buon motivo di cambio un singolo evento che si risolverebbe con accordi migliori. Spesso basta integrare il contratto esistente con regole su aggiornamenti di sicurezza, riavvii e informazione in caso di falle critiche.
Consideri anche il momento. Un trasloco nel mezzo di una situazione acuta impegna proprio le forze che servono per patch e ricerca di tracce. Meglio mettere prima in sicurezza il server attuale e poi pianificare il cambio con calma, con una ricostruzione pulita anziché una copia del vecchio sistema.
Come aiuta concretamente PHP SOS?
- Confrontiamo il Suo modello attuale con le Sue esigenze effettive e mostriamo dove la responsabilità non è chiara.
- Verifichiamo le descrizioni delle prestazioni dei fornitori managed sui punti che contano nell'emergenza.
- Per i server propri ci occupiamo di aggiornamenti, hardening e monitoraggio nell'ambito di un contratto di manutenzione della sicurezza.
- In caso di cambio accompagniamo il trasloco, perché non migrino vecchi accessi o dati non verificati.
Conclusione
Il managed hosting è la scelta più sicura per le aziende senza competenze di server, il server proprio quella più flessibile per team con conoscenze e disponibilità. Spesso le forme miste ottengono i risultati migliori, con una regola chiara su chi applica le patch, chi riavvia e chi reagisce nell'emergenza.
Domande frequenti
Il managed hosting è in linea di principio più sicuro di un root server?
Non in linea di principio. Il managed hosting è più sicuro se il fornitore installa gli aggiornamenti in modo affidabile e Lei ha poche conoscenze di server. Un server proprio ben assistito può essere altrettanto sicuro, ma richiede costantemente tempo e competenze.
Con un root server, chi è responsabile degli aggiornamenti PHP?
Di regola Lei stesso. Il gestore del centro dati si occupa di solito solo di hardware, rete e virtualizzazione. Sistema operativo, PHP, server web e applicazione spettano a Lei o al Suo fornitore.
Con il managed hosting posso impostare impostazioni PHP personalizzate?
Spesso solo in modo limitato. Molti fornitori consentono modifiche tramite un pannello o su richiesta. Per misure provvisorie come quelle per PHP2Shell alcune impostazioni vanno applicate a livello di server; allora è possibile solo tramite il fornitore.
E l'hosting condiviso?
L'hosting condiviso è la forma più semplice di hosting gestito. Il fornitore cura il sistema per molti clienti insieme. Lei ha poca influenza su versione PHP e configurazione, ma deve anche occuparsene molto poco.
Vale la pena cambiare modello operativo dopo PHP2Shell?
Solo se la situazione ha mostrato una vera debolezza, ad esempio che nessuno ha potuto applicare la patch al server proprio in tempo. Un cambio d'impulso raramente risolve il vero problema.