In breve: per il sito web di uno studio medico si tratta di sicurezza per i dati sanitari, non solo di un biglietto da visita online. Verifichi quali moduli salvano dati o li inviano per e-mail, faccia confermare per iscritto lo stato delle patch PHP del server e, in caso di sospetto, salvi subito i log.
Quali sistemi PHP girano in studi e MVZ
La maggior parte dei siti degli studi si basa su un CMS PHP, spesso WordPress, più raramente TYPO3 o Joomla. Il punto delicato sono le funzioni aggiuntive: moduli per richieste di ricette e impegnative, questionari anamnestici da scaricare o caricare, iscrizioni ai richiami, offerte di lavoro con upload della candidatura e prenotazione online degli appuntamenti.
La prenotazione degli appuntamenti è spesso un servizio esterno, solo incorporato nel sito. In tal caso i dati degli appuntamenti si trovano presso il fornitore. Alcuni studi usano però plugin di prenotazione che salvano gli appuntamenti, insieme al motivo, nel database del proprio sito. Proprio questa differenza conviene conoscerla prima di valutare il rischio.
Dati sanitari: perché il sito è più sensibile di quanto sembri
Una frase come «Mi serve di nuovo il farmaco per la pressione» in un modulo di contatto è un dato sanitario. Tali indicazioni rientrano nelle categorie particolari di dati personali ai sensi dell'art. 9 GDPR. Per medici e mediche vale inoltre il segreto professionale, la cui violazione può essere punibile ai sensi del § 203 StGB (codice penale tedesco).
Per il sito significa che le voci dei moduli che restano nel database, le copie nei plugin dei moduli, i log di posta sul server e i documenti caricati sono tutti raggiungibili in caso di attacco. Chi esegue codice sul server di norma li legge insieme al resto.
Faccia verificare se il plugin del Suo modulo salva le voci anche nel database. Molti lo fanno in modo predefinito. Ciò che non è salvato non può nemmeno andare disperso.
Che cosa comportano per lo studio un'interruzione o una fuga di dati
Se il sito si ferma, i pazienti telefonano, e il telefono dello studio è già sovraccarico. È fastidioso ma gestibile. Pesa di più un attacco passato inosservato: reindirizzamenti verso siti fraudolenti a nome dello studio, moduli falsificati o richieste con riferimento a malattie sottratte.
Un incidente del genere può far scattare obblighi di notifica all'autorità di protezione dei dati e, a seconda del rischio, anche la comunicazione agli interessati. Il termine di 72 ore del GDPR decorre da quando ha conoscenza della violazione. Chiarisca la valutazione con il Suo responsabile della protezione dei dati.
Sito dello studio e sicurezza: il tipico vuoto di responsabilità
Negli studi di solito ci sono tre soggetti, ognuno dei quali si sente responsabile di una parte:
| Soggetto | Di norma si occupa di | Spesso non ha sotto controllo |
|---|---|---|
| Fornitore IT dello studio | gestionale, rete, connettore, postazioni | server del sito presso l'hoster |
| Agenzia web | design, contenuti, plugin | versione di PHP e riavvio del server |
| Hoster | esercizio del server | dati dei moduli e plugin dello studio |
Con PHP2Shell la vulnerabilità si colloca proprio tra questi ruoli: in PHP sul server web. Con l'hosting condiviso di norma è responsabile l'hoster, ma la conferma dello stato del pacchetto deve richiederla Lei stesso. Negli MVZ con più sedi si aggiunge spesso l'ente gestore, che dà indicazioni proprie.
Esiste un ponte tra il sito web e la rete dello studio?
Di norma il sito dello studio gira presso l'hoster e non ha alcun collegamento diretto con il gestionale. Esistono però eccezioni da conoscere: moduli che trasferiscono automaticamente dati nel gestionale, un server del sito nel centro di calcolo del proprio MVZ oppure credenziali usate contemporaneamente per sito, caselle di posta e manutenzione remota.
In questi casi un server web compromesso non è solo un problema del sito. Faccia verificare insieme al Suo fornitore IT e al responsabile del sito quali collegamenti esistono e quali password sono usate più volte. Per l'IT dello studio valgono inoltre le direttive sulla sicurezza informatica della Kassenärztliche Bundesvereinigung (l'associazione federale tedesca dei medici convenzionati). In che misura riguardino anche il sito, lo chiarisca con il Suo responsabile della protezione dei dati.
Le prime ore dopo un'allerta
- Chiedere all'hoster se PHP è alla versione 8.5.12, 8.4.27, 8.3.36 o 8.2.35 oppure se è stato applicato un backport, e se tutti i processi PHP sono stati riavviati.
- Se non c'è conferma: disattivare temporaneamente il sito o sostituirlo con una pagina statica con gli orari telefonici, come raccomanda il BSI (Ufficio federale tedesco per la sicurezza informatica) per i server non aggiornabili.
- Salvare i log del server e degli accessi dal 20/10/2026.
- Prestare attenzione ai segni di una compromissione: file sconosciuti, nuovi account admin, reindirizzamenti modificati.
- Coinvolgere presto il responsabile della protezione dei dati, non solo dopo la bonifica.
Come aiuta concretamente PHP SOS?
- Chiariamo con hoster e agenzia chi aggiorna e riavvia PHP e otteniamo la conferma con lo stato del pacchetto.
- Verifichiamo dove si trovano sul server web dati dei moduli, upload e copie della posta e se esistono collegamenti con la rete dello studio.
- In caso di sospetto preserviamo le tracce, cerchiamo web shell e bonifichiamo il server nell'ambito della nostra assistenza di emergenza per siti web compromessi.
- Documentiamo l'incidente in modo che il Suo responsabile della protezione dei dati possa valutare l'obbligo di notifica.
- In seguito riduciamo i dati memorizzati e rafforziamo il server, così che la prossima volta ci sia meno in gioco.
Domande frequenti
Il software del mio studio è interessato da PHP2Shell?
Il gestionale dello studio e l'accesso all'infrastruttura telematica sanitaria tedesca (Telematikinfrastruktur) di norma girano separati dal sito web. Sono interessati i server web PHP, cioè in genere il sito dello studio e i moduli o portali collegati. Se esistano collegamenti tra sito e rete dello studio dovrebbe verificarlo il Suo fornitore IT.
I dati del modulo di contatto sono dati sanitari?
Spesso sì. Già la richiesta di una ricetta ripetuta o di un appuntamento per determinati disturbi permette di trarre conclusioni sulla salute. Tali dati rientrano nelle categorie particolari ai sensi dell'art. 9 GDPR. L'inquadramento preciso lo chiarisca con il Suo responsabile della protezione dei dati.
Devo informare i pazienti se il sito è stato hackerato?
Dipende dal fatto che siano coinvolti dati personali e da quanto sia elevato il rischio per i pazienti. Con i dati sanitari il rischio è spesso elevato. La decisione la prende con il Suo responsabile della protezione dei dati, se necessario con una consulenza legale.
Chi è responsabile degli aggiornamenti di PHP per il sito dello studio?
Lo stabilisce il contratto di hosting o di manutenzione. Con l'hosting condiviso e gestito di norma provvede l'hoster, con un server proprio il fornitore incaricato. Se manca una regola chiara, conviene metterla per iscritto adesso.