Capita spesso che il server su cui gira un PHP da correggere non sia gestito né dall’azienda proprietaria del sito né da chi deve installare le patch. È ospitato da un provider di hosting gestito o da un cloud, il sistema operativo è curato da un sistemista esterno, l’applicazione da un’agenzia. Quando arriva una CVE critica e serve un intervento sui pacchetti PHP, si scopre che nessuno ha chiarito chi può entrare, con quali credenziali, chi risponde se qualcosa si rompe e come si gestiscono i dati personali che il server tratta.
In questo articolo mettiamo in ordine le tre questioni: le responsabilità tecniche tra i fornitori coinvolti, i ruoli previsti dal GDPR con gli articoli 28 e 32 del Regolamento, e il modo di gestire gli accessi in modo che ogni intervento sia autorizzato, limitato nel tempo e tracciato. Gli aspetti contrattuali e privacy vanno sempre verificati con il proprio consulente: qui descriviamo la parte tecnica e organizzativa che serve a costruirli bene.
Chi fa cosa su un server gestito da altri
Un server è fatto di livelli, e ogni livello può essere affidato a un soggetto diverso. In un’infrastruttura cloud “nuda” il provider gestisce data center, rete e virtualizzazione, mentre tutto il resto spetta al cliente. In un hosting gestito il provider si occupa spesso anche del sistema operativo e, a volte, dei pacchetti PHP. Il primo passo è scrivere, per ogni server, chi è responsabile di ciascun livello.
Prima di qualsiasi intervento sul livello PHP vanno verificati alcuni punti del contratto con l’hosting:
- se il contratto consente l’accesso di terzi al server e a quali condizioni;
- se installare pacchetti diversi da quelli previsti fa decadere garanzie o livelli di servizio;
- se il provider aggiorna automaticamente i pacchetti, con il rischio di sovrascrivere quelli corretti;
- chi esegue i backup, con quale frequenza, e chi può avviare un ripristino;
- chi deve essere avvisato prima di una finestra di manutenzione.
Il terzo punto è più frequente di quanto sembri: un aggiornamento automatico del provider può reinstallare il pacchetto originale vulnerabile al posto di quello corretto. Sulle distribuzioni Debian e Ubuntu si gestisce con il pinning dei pacchetti; sulla famiglia Red Hat con esclusioni o priorità dei repository. In ogni caso va concordato con chi gestisce il sistema.
I ruoli secondo il GDPR
Un server che ospita un sito o un gestionale tratta quasi sempre dati personali: clienti, ordini, utenti, log. Chi interviene su quel server, anche solo per installare pacchetti, può accedervi. Per il Regolamento (UE) 2016/679 l’azienda proprietaria dei dati è di norma il titolare del trattamento, mentre i fornitori che agiscono per suo conto sono responsabili del trattamento.
Articolo 28: il contratto con il responsabile
L’articolo 28 stabilisce che il titolare ricorre solo a responsabili che presentino “garanzie sufficienti” e che il rapporto sia regolato da un contratto o da un altro atto giuridico. Il paragrafo 3 elenca cosa deve prevedere, tra l’altro:
- trattamento dei dati solo su istruzione documentata del titolare;
- impegno alla riservatezza delle persone autorizzate;
- adozione delle misure di sicurezza dell’articolo 32;
- rispetto delle condizioni per ricorrere a un altro responsabile;
- assistenza al titolare negli obblighi degli articoli da 32 a 36, comprese le violazioni dei dati;
- cancellazione o restituzione dei dati alla fine del servizio;
- messa a disposizione delle informazioni necessarie e possibilità di revisioni e ispezioni.
Quando il fornitore lavora per un altro fornitore
Se il fornitore delle patch viene incaricato dall’hosting e non direttamente dal cliente, diventa un sub-responsabile. Il paragrafo 2 richiede la previa autorizzazione scritta del titolare, specifica o generale; nel secondo caso il responsabile deve informare il titolare delle modifiche, dandogli la possibilità di opporsi. Il paragrafo 4 impone al sub-responsabile gli stessi obblighi del contratto principale e prevede che, se non li rispetta, il responsabile iniziale conservi nei confronti del titolare l’intera responsabilità. Nella pratica conviene chiarire fin dall’inizio quale dei due schemi si applica.
Articolo 32: la sicurezza del trattamento
L’articolo 32 vale per titolare e responsabile insieme. Chiede misure tecniche e organizzative adeguate al rischio, che comprendono, se del caso, la capacità di assicurare riservatezza, integrità, disponibilità e resilienza dei sistemi, la capacità di ripristinare tempestivamente i dati dopo un incidente e una procedura per verificare regolarmente l’efficacia delle misure. Il paragrafo 4 aggiunge che chiunque agisca sotto la loro autorità tratta i dati solo se istruito. Mantenere un PHP con vulnerabilità note senza alcuna misura è difficile da conciliare con questo articolo; correggerle con un intervento non tracciato crea un problema diverso, perché toglie la possibilità di dimostrare cosa è stato fatto.
Infine, l’articolo 33 chiede al responsabile di informare il titolare “senza ingiustificato ritardo” dopo essere venuto a conoscenza di una violazione dei dati personali. Il titolare ha poi 72 ore, ove possibile, per notificarla all’autorità di controllo. Il contratto deve quindi indicare canali e contatti per queste comunicazioni, validi anche di notte e nei festivi.
Gli accessi: autorizzati, limitati, tracciati
Installare o sostituire pacchetti di sistema richiede privilegi di amministratore. Restringere i comandi consentiti serve a poco, perché l’installazione di un pacchetto esegue di per sé codice con quei privilegi. Il controllo si sposta quindi su tre aspetti: chi accede, per quanto tempo e con quale traccia.
I principi sono semplici e trovano riscontro anche negli standard. PCI DSS v4.0.1, per esempio, chiede che gli account usati da terzi per l’accesso remoto siano abilitati solo per il tempo necessario e monitorati (requisito 8.2.7), e che le credenziali condivise siano un’eccezione giustificata e approvata (8.2.2). In pratica:
- un account per persona, mai credenziali condivise del fornitore o, peggio, quelle di root;
- chiavi SSH personali al posto delle password, con autenticazione a più fattori sul punto di ingresso;
- accesso da un punto controllato, come una VPN o un bastion host, con indirizzi di origine noti;
- scadenza: l’account si attiva per la finestra concordata e si disattiva alla fine;
- registrazione: comandi eseguiti con privilegi e sessioni conservati secondo la politica dei log.
Su un server Linux, gestire un account con scadenza e verificarne l’uso richiede pochi comandi, da eseguire da parte di chi amministra il sistema:
# Crea l'account nominativo del tecnico esterno, con data di scadenza
useradd -m -e 2026-11-30 -c "Fornitore PHP, tecnico 1" fornitore-t1
# Solo accesso con chiave: blocca la password
passwd -l fornitore-t1
# Privilegi di amministratore solo per questo account (modifica con visudo)
visudo -f /etc/sudoers.d/fornitore-t1
# Durante e dopo l'intervento: accessi e comandi eseguiti con sudo
last fornitore-t1
journalctl _COMM=sudo --since "2026-11-07 08:00"
# A fine intervento: account scaduto subito, chiavi rimosse
chage -E 0 fornitore-t1
rm -f /home/fornitore-t1/.ssh/authorized_keysSu parchi di molti server gli stessi passaggi si automatizzano, per esempio con Ansible, così che attivazione e revoca avvengano ovunque nello stesso modo. Ne parliamo nell’articolo sul patching di PHP con Ansible su parchi misti.
Le responsabilità operative
Oltre ai ruoli privacy, va scritto chi fa cosa durante e dopo l’intervento. Le domande a cui rispondere prima che arrivi un’urgenza:
- chi approva l’intervento e la finestra di manutenzione, e chi avvisa gli utenti;
- chi verifica che esista un backup recente e ripristinabile prima di cominciare;
- chi esegue i test funzionali dopo il rilascio;
- chi decide il ritorno alla versione precedente e chi lo esegue;
- chi è il riferimento se l’intervento coincide con un problema dell’hosting, come un disco pieno o un guasto di rete;
- come si comunica una sospetta violazione dei dati scoperta durante il lavoro.
Per le organizzazioni soggette alla NIS2 queste risposte fanno parte della sicurezza della catena di approvvigionamento prevista dall’articolo 24 del D.Lgs. 138/2024, che chiede di considerare le vulnerabilità e le pratiche di sicurezza di ciascun fornitore diretto. Per chi tratta dati di carte di pagamento rientrano nei requisiti 12.8 di PCI DSS sui fornitori terzi.
Tecnici fuori dall’Unione europea
Un caso da non trascurare: se il fornitore o i suoi tecnici accedono al server da un paese terzo, l’accesso remoto a dati personali può configurare un trasferimento ai sensi del capo V del GDPR, con le garanzie che questo richiede. Va chiesto esplicitamente da dove operano le persone che avranno accesso, e la risposta va valutata con il proprio consulente privacy.
Prima del primo accesso
Una lista di controllo da completare prima che un tecnico esterno entri su un server di produzione gestito da altri:
- mappa dei livelli del server con il responsabile di ciascuno;
- contratto o atto ai sensi dell’articolo 28 con il fornitore, o autorizzazione scritta se è un sub-responsabile;
- verifica del contratto di hosting su accessi di terzi e aggiornamenti automatici;
- procedura di richiesta, attivazione e revoca degli accessi;
- backup verificato e piano di rollback;
- contatti di emergenza di tutti i soggetti coinvolti, validi anche fuori orario.
Per scegliere il fornitore a cui affidare il lavoro, trovi le domande da fare nell’articolo su cosa chiedere a un fornitore di supporto esteso per PHP.
Riassumendo
Correggere PHP su un server gestito da altri richiede di chiarire prima tre cose. Le responsabilità tecniche, livello per livello, insieme alle condizioni del contratto di hosting su accessi di terzi e aggiornamenti automatici. I ruoli privacy: il cliente è di norma titolare, i fornitori sono responsabili con un contratto ai sensi dell’articolo 28 del GDPR, e chi lavora per un altro fornitore è un sub-responsabile che richiede l’autorizzazione scritta del titolare; tutti devono garantire le misure dell’articolo 32 e comunicare le violazioni senza ritardo. Gli accessi: nominativi, con chiavi e autenticazione a più fattori, limitati alla finestra dell’intervento, registrati e revocati alla fine. Così ogni intervento resta dimostrabile, anche davanti a un auditor o a un’autorità. Per l’inquadramento giuridico del tuo caso, il riferimento resta il tuo consulente.
