In breve: sicurezza IT white label significa, per la Sua agenzia: Lei mantiene il rapporto con i clienti, noi svolgiamo in secondo piano il lavoro di sicurezza. Con PHP2Shell ciò comporta l'inventario di tutti i siti dei clienti, la definizione delle priorità in base al rischio, patch e riavvio per ogni server e una prova per cliente che Lei può inoltrare.
Perché con PHP2Shell le agenzie sono sotto particolare pressione
Un'agenzia con molti clienti raramente cura un panorama uniforme. Una parte dei siti si trova su server propri con Plesk, una parte presso gli hoster dei clienti, alcuni vecchi progetti su versioni di PHP che da tempo non ricevono più aggiornamenti ufficiali. Si aggiungono sistemi diversi: WordPress, TYPO3, Shopware, Craft CMS, sviluppi propri su Laravel.
Con una vulnerabilità in PHP stesso sono colpiti tutti i progetti contemporaneamente. I clienti si aspettano una risposta sul fatto che il loro sito sia sicuro, e il team di progetto è già impegnato negli incarichi in corso. Molti contratti di manutenzione regolano il CMS, ma non il server sottostante.
Si aggiungono sistemi che non compaiono più in nessun elenco di progetti: ambienti di staging su sottodomini, siti di campagne di progetti conclusi, installazioni di prova degli sviluppatori su vServer propri. Girano spesso su versioni di PHP più vecchie, non sono sorvegliati e portano comunque il nome della Sua agenzia o del Suo cliente. Per le scansioni automatizzate sono visibili quanto il sito principale.
Quali domande pongono ora i Suoi clienti
- Il mio sito è interessato e, nel frattempo, è stato aggiornato?
- Prima della patch è già stato introdotto qualcosa?
- L'aggiornamento del CMS vale come protezione? No, un aggiornamento del CMS non chiude la vulnerabilità di PHP.
- Devo scollegare il mio sito dalla rete? Il BSI (Ufficio federale tedesco per la sicurezza informatica) lo raccomanda per i server che non possono essere aggiornati subito.
A ciascuna di queste domande la Sua agenzia ha bisogno di una risposta documentabile per cliente, non di una circolare con affermazioni generiche.
Come funziona la sicurezza IT white label per le agenzie
Lavoriamo come parte del Suo team, ma senza contatto diretto con i clienti. La ripartizione è chiara:
| Attività | La Sua agenzia | PHP SOS |
|---|---|---|
| Comunicazione con i clienti e fatturazione | sì | no |
| Inventario di tutti i siti dei clienti con stato di PHP | fornisce gli accessi | lo crea e lo aggiorna |
| Patch, riavvio, verifica per ogni server | autorizza la finestra di manutenzione | esegue o coordina con gli hoster |
| Verifica della compromissione | riceve il risultato | cerca web shell e anomalie |
| Prova per cliente | inoltra | la redige in forma neutra o nel Suo formato |
Per i siti presso hoster esterni otteniamo la conferma dello stato del pacchetto. Il solo numero di versione visualizzato non basta, perché i backport possono lasciarlo invariato.
Assegni la priorità prima ai server con Apache e mod_php, dove il team PHP classifica il rischio come il più alto, poi a shop e siti con login, poi ai progetti su PHP 8.1 e precedente. I vecchi progetti statici che nessuno usa più è meglio spegnerli anziché aggiornarli.
Più siti di clienti su un server: verificare l'isolamento
Sui server delle agenzie molti siti di clienti condividono spesso una macchina. Se uno di essi viene compromesso, la separazione decide se l'aggressore raggiunge anche gli altri. Sono importanti utenti di sistema e pool PHP-FPM propri per ogni sito, permessi dei file corretti e limiti come open_basedir. Sui server Plesk queste impostazioni si possono verificare per ogni abbonamento.
Dopo la patch vale: riavviare tutti i pool e i worker. Solo allora non girano più processi PHP vecchi in memoria. I log dal 20/10/2026 dovrebbero essere conservati per ogni sito dei clienti.
Informazione ai clienti: che cosa è documentato e che cosa no
La tentazione maggiore in questa situazione è una circolare rassicurante. Più sicura è un'affermazione per cliente che contenga solo ciò che è documentato: quale server, quale stato del pacchetto PHP, quando riavviato, se sia stata effettuata una verifica di compromissione e con quale esito. Anche ciò che è ancora aperto vi è indicato.
Formulazioni come «Il Suo sito è sicuro» conviene evitarle. Una patch chiude la vulnerabilità, ma non dimostra che prima non sia successo nulla. Chi separa onestamente le due cose non deve poi dare spiegazioni se dovesse comunque emergere un riscontro.
Riformulare i contratti di manutenzione dopo PHP2Shell
Molti contratti delle agenzie regolano gli aggiornamenti di CMS ed estensioni, ma tacciono sul server. Sfrutti la situazione per stabilire, per ogni cliente, chi aggiorna PHP, chi è responsabile dei riavvii, chi decide in caso di incidente e quali prestazioni vengono incaricate separatamente. Anche un accordo sul trattamento dei dati con tutti i fornitori coinvolti ne fa parte. L'impostazione contrattuale la chiarisca con la Sua consulenza legale.
Come aiuta concretamente PHP SOS?
- Ci occupiamo del censimento di tutti i siti dei clienti con versione di PHP, modalità di esecuzione, hoster e responsabilità.
- Con il nostro servizio di patch PHP aggiorniamo i Suoi server, riavviamo tutti i worker e lo documentiamo per ogni cliente.
- Verifichiamo i siti prioritari per rilevare compromissioni e, in caso di riscontro, bonifichiamo fino alla chiusura e alla documentazione dell'incidente.
- Forniamo moduli di testo per la Sua informazione ai clienti, che Lei adatta e invia da sé.
- In seguito, su richiesta, con un contratto di manutenzione della sicurezza ci occupiamo in secondo piano dell'assistenza continuativa alla sicurezza.
Domande frequenti
Vi presentate ai nostri clienti?
Solo se Lei lo desidera. Nel modello white label lavoriamo esclusivamente in secondo piano e tutta la comunicazione passa dalla Sua agenzia. La nostra documentazione la forniamo in forma neutra o nel Suo formato.
Per questo ci serve un contratto di trattamento dei dati?
Se accediamo a sistemi con dati personali dei Suoi clienti, di norma è necessario un accordo sul trattamento dei dati, spesso come sub-responsabile del trattamento. Come si inserisca nei Suoi contratti esistenti lo chiarisca con la Sua consulenza legale. Forniamo le indicazioni necessarie sulle nostre attività.
Che cosa succede ai siti dei clienti i cui server non gestiamo?
Se i siti dei clienti si trovano presso hoster esterni, otteniamo a Suo nome o con i Suoi modelli conferme su stato delle patch e riavvio. Dove esiste solo l'accesso FTP o al CMS, verifichiamo che cosa sia possibile da lì e indichiamo con chiarezza che cosa può dimostrare solo l'hoster.
Possiamo esternalizzare tutto questo in modo permanente anche dopo PHP2Shell?
Sì. Molte attività si ripetono a ogni vulnerabilità: tenere l'inventario, installare le patch, documentare i riavvii, segnalare le anomalie. Questo lavoro si può organizzare come assistenza continuativa in secondo piano.