La Sicurezza WordPress nella PA: Requisiti Specifici che Nessuno Spiega
Gestire WordPress per un comune, un’ASL, o un ente regionale non è come gestirlo per un’agenzia privata. I requisiti di sicurezza sono diversi, più stringenti, e spesso scritti in documenti AGID che nessun developer WordPress legge.
In 15 anni di lavoro con la Pubblica Amministrazione italiana, abbiamo imparato una cosa: il problema non è WordPress. WordPress è perfettamente adatto alla PA. Il problema è che la maggior parte delle installazioni ignora le linee guida AGID, non implementa i requisiti minimi di sicurezza, e tratta un sito istituzionale come un blog personale.
Questo articolo colma il gap tra “sicurezza WordPress generica” e “sicurezza WordPress per la PA”, con i requisiti specifici, le checklist operative e il codice per implementarli.
Le Linee Guida AGID che Contano per WordPress
L’Agenzia per l’Italia Digitale (AGID) pubblica linee guida sulla sicurezza informatica per la PA. Quelle rilevanti per un sito WordPress istituzionale:
Misure Minime di Sicurezza ICT (Circolare AGID 2/2017)
Definisce 3 livelli di implementazione: minimo, standard, avanzato. Per un sito WordPress PA, il livello minimo è obbligatorio. Ecco come si traduce:
| Requisito AGID | Implementazione WordPress | Come farlo |
|---|---|---|
| Inventario dispositivi autorizzati | Lista server e servizi collegati al sito | Documento con IP, hostname, servizi |
| Inventario software autorizzato | Lista plugin, tema, versione PHP/MySQL | wp plugin list + wp core version |
| Configurazione sicura | Hardening server e WordPress | Security headers, disable file editing, 2FA |
| Valutazione vulnerabilità | Scan regolari | Wordfence scan + wp plugin list --update=available |
| Uso controllato privilegi admin | Principio del minimo privilegio | Ruoli WordPress: solo chi serve è admin |
| Difese anti-malware | Scanner + firewall | Wordfence o equivalente |
| Backup | Backup giornaliero off-site | UpdraftPlus + S3 o equivalente |
| Log di audit | Tracciamento azioni utente | WP Activity Log o Simple History |
Linee Guida per i Siti Web della PA (2022)
Specifiche per i siti web istituzionali:
- HTTPS obbligatorio con certificato valido (Let’s Encrypt va bene)
- Accessibilità WCAG 2.1 livello AA (obbligatoria per legge, non opzionale)
- Dichiarazione di accessibilità pubblicata e aggiornata
- Cookie banner conforme a GDPR e linee guida Garante Privacy
- Informativa privacy aggiornata
- Amministrazione trasparente (sezione dedicata con dati obbligatori)
I 5 Problemi di Sicurezza Specifici della PA
1. Utenti con troppi privilegi
Nella PA, il turnover del personale è frequente. Risultato: account admin attivi di dipendenti trasferiti da 3 anni. Ogni account è un vettore di attacco.
Soluzione: audit trimestrale degli utenti WordPress. Disabilita (non cancellare) gli account inattivi.
# Lista utenti admin che non accedono da 90+ giorni
wp user list --role=administrator --fields=ID,user_login,user_email --format=table
# Per ciascuno, controlla l'ultimo login
# (richiede un plugin di tracking login o custom meta)
wp user meta get USER_ID last_login2. Nessun audit trail
La PA richiede tracciabilità di chi fa cosa e quando. WordPress di default non logga le azioni degli utenti. Se un contenuto viene modificato in modo errato, non c’è modo di sapere chi e quando.
Soluzione: installa WP Activity Log (il più completo) o Simple History (più leggero). Configura la retention a 12 mesi (requisito tipico PA).
3. Hosting non conforme
Molti siti PA sono su hosting condivisi economici. Le linee guida AGID richiedono: data center in UE (preferibilmente Italia), backup giornaliero con retention, supporto HTTPS, accesso ai log del server.
Hosting consigliati per PA WordPress: Aruba Business (italiano, certificato per PA), Register.it (italiano), o VPS su Hetzner/OVH (data center UE) gestito internamente.
4. Plugin non mantenuti
Abbiamo visto siti PA con plugin abbandonati da 4 anni, mai aggiornati, con vulnerabilità note. Il responsabile IT del comune non sa che il plugin esiste.
Soluzione: inventario plugin trimestrale. Per ogni plugin: è ancora mantenuto? L’ultima release è più vecchia di 12 mesi? Ha vulnerabilità note in WPScan DB?
# Check plugin con aggiornamenti disponibili
wp plugin list --update=available --format=table
# Check plugin non aggiornati da oltre 1 anno (richiede analisi manuale)
wp plugin list --fields=name,version,update_version,status --format=csv5. Mancanza di procedura incident response
Quando un sito del comune viene hackerato, nessuno sa cosa fare. Non c’è una procedura documentata, non c’è un referente tecnico con accesso al server, non c’è un piano di comunicazione.
Soluzione: documenta la procedura PRIMA che serva. La nostra guida al recovery è un buon punto di partenza. Adattala al contesto PA aggiungendo: chi notificare (DPO, responsabile transizione digitale), tempistiche GDPR (72 ore), canale comunicazione cittadini.
Checklist Sicurezza PA WordPress
| Requisito | Priorità | Frequenza verifica | Strumento |
|---|---|---|---|
| HTTPS attivo e valido | 🔴 Obbligatorio | Settimanale (auto) | certbot, UptimeRobot |
| WordPress core aggiornato | 🔴 Obbligatorio | Settimanale | WP-CLI, auto-update minor |
| Plugin aggiornati | 🔴 Obbligatorio | Settimanale | WP-CLI |
| 2FA per tutti gli admin | 🔴 Obbligatorio | Mensile | WP 2FA |
| Audit log attivo (12 mesi) | 🔴 Obbligatorio | Setup una volta | WP Activity Log |
| Backup giornaliero off-site | 🔴 Obbligatorio | Giornaliera (auto) | UpdraftPlus + S3 |
| Security headers | 🟡 Raccomandato | Dopo ogni deploy | Nginx config |
| Malware scan | 🟡 Raccomandato | Settimanale | Wordfence |
| Utenti review | 🟡 Raccomandato | Trimestrale | WP-CLI + manuale |
| Plugin inventory | 🟡 Raccomandato | Trimestrale | WP-CLI |
| Accessibilità WCAG 2.1 AA | 🔴 Obbligatorio | Annuale (audit) | aXe, WAVE, audit manuale |
| Dichiarazione accessibilità | 🔴 Obbligatorio | Annuale | Template AGID |
| Procedura incident response | 🟡 Raccomandato | Annuale (revisione) | Documento interno |
Il Plugin di Sicurezza Giusto per la PA
Come discusso nel nostro confronto Wordfence vs Sucuri, per la PA raccomandiamo Wordfence:
- I dati di scansione restano sul server (nessun transito verso cloud esteri)
- Log dettagliati per audit trail
- 2FA integrato (un plugin in meno da gestire)
- La versione Free è già sufficiente per il livello “minimo” AGID
Sucuri Platform richiede che tutto il traffico passi dai server Sucuri (USA). Per enti pubblici con requisiti di residenza dati UE, questo può essere problematico senza DPA adeguata.
FAQ
WordPress è approvato per i siti della PA?
Non esiste una “lista di CMS approvati” AGID. Le linee guida sono tecnologicamente neutre: il CMS deve rispettare i requisiti di sicurezza, accessibilità e performance, indipendentemente dal software. WordPress li rispetta se configurato correttamente. Molti comuni e ASL italiani usano WordPress (basta verificare con BuiltWith).
Serve la certificazione AgID per l’hosting?
Per i servizi cloud della PA, la qualificazione AgID (ora ACN) è richiesta. Per il semplice hosting di un sito web istituzionale, la qualificazione non è strettamente necessaria se il sito non tratta dati classificati. Verifica con il responsabile transizione digitale del tuo ente.
Chi è responsabile della sicurezza del sito nella PA?
Il Responsabile per la Transizione Digitale (RTD) dell’ente. In pratica, la gestione tecnica è spesso delegata a un fornitore esterno (l’agenzia), ma la responsabilità legale resta dell’ente. Il contratto di manutenzione deve specificare SLA, responsabilità e procedura incident response.