Sicurezza dei ruoli utente WordPress: pulire gli account admin

La maggior parte dei siti WordPress ha più amministratori del necessario. Ognuno di questi account può installare un plugin, e installare un plugin significa eseguire codice sul proprio server. La sicurezza dei ruoli utente WordPress si riduce a una regola, il privilegio minimo: ogni persona ha un account personale, con il ruolo più basso che le consenta comunque di svolgere il proprio lavoro.

Sicurezza dei ruoli utente WordPress: si parte dal conteggio degli admin

Il primo passo è contare gli amministratori. Nella dashboard, aprire Utenti > Tutti gli utenti e cliccare sul filtro "Amministratore" sopra l'elenco. Annotare il numero e i nomi.

Con WP-CLI si ottiene lo stesso elenco, completo di data di registrazione:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

In una rete multisite va verificato anche chi ha il controllo a livello di rete:

wp super-admin list

Per ogni account la domanda è semplice: è possibile indicare la persona reale che lo usa, e ha ancora bisogno del controllo completo? Se la risposta non è chiara, l'account finisce nella lista da rivedere. La documentazione dei comandi WP-CLI per gli utenti elenca tutte le opzioni usate in questo articolo.

I cinque ruoli predefiniti e a chi assegnarli

Il core di WordPress include cinque ruoli, più il Super Admin nel multisite. L'elenco completo delle capacità si trova nella pagina ufficiale Roles and Capabilities. In sintesi:

I plugin aggiungono ruoli e capacità propri. WooCommerce, ad esempio, introduce "Shop manager" e "Cliente", e uno Shop manager può vedere ordini pieni di dati personali dei clienti. Plugin SEO, LMS e di membership fanno spesso qualcosa di simile. Conviene controllare il filtro dei ruoli nella schermata Utenti, individuare i ruoli sconosciuti e leggere nella documentazione del plugin che cosa possono fare.

Il consiglio è questo: il lavoro editoriale quotidiano si svolge con un account Editor. L'account amministratore serve solo per aggiornamenti e manutenzione. Su un sito singolo gli Editor possono comunque pubblicare HTML non filtrato, quindi non si tratta di un confine di sicurezza nei confronti di persone non fidate. Ma un account del marketing compromesso con il phishing non potrà più installare plugin.

Account da rimuovere o declassare: ex dipendenti, agenzie, accessi condivisi

Su quasi tutti i siti di piccole imprese ricorrono gli stessi pochi tipi di account:

• Ex dipendenti il cui account non è mai stato rimosso dopo l'uscita dall'azienda.
• La vecchia agenzia, ancora presente come amministratore anni dopo la fine del contratto.
• Un freelance di un progetto isolato, come un restyling o la migrazione di uno shop.
• Un accesso condiviso "ufficio" o "info", usato da più persone.
• Lo username "admin" dell'installazione originale.

Gli accessi condivisi sono i più difficili da difendere. Quando cinque persone usano un solo account, non è possibile stabilire chi ha cambiato un'impostazione o esportato i dati dei clienti. Inoltre non si può escludere una persona senza cambiare la password a tutte. Ogni persona deve avere un proprio account nominativo.

Lo stesso vale per le agenzie. Ogni collaboratore ha un account nominativo, e questi account vengono rimossi il giorno stesso in cui termina il contratto. Se un'agenzia ha accesso admin a un sito con dati personali, di norma agisce come responsabile del trattamento ai sensi dell'art. 28 del GDPR. Il suo accesso va quindi documentato insieme al contratto con il responsabile del trattamento. Per la parte documentale, vedere che cosa conservare in un report di audit di sicurezza.

Lo username "admin" non si può rinominare dalla dashboard, perché WordPress mostra nel profilo il messaggio "Gli username non possono essere cambiati". La soluzione è creare un nuovo amministratore con uno username personale:

wp user create jane.doe jane@example.com --role=administrator

Dopo aver effettuato l'accesso con il nuovo utente, si elimina il vecchio account "admin" riassegnandone i contenuti, come descritto nella sezione successiva.

Eliminare in sicurezza: riassegnare i contenuti e tenere un amministratore funzionante

wp user delete 7 --reassign=2

Per declassare invece di eliminare, ad esempio un collaboratore che continua a scrivere articoli:

wp user set-role mark.writer editor

Declassare è spesso il primo passo più prudente. Se per due settimane nessuno segnala problemi, si può eliminare l'account.

Password per le applicazioni: gli accessi che sopravvivono al cambio password

Le Password per le applicazioni (Application Passwords) fanno parte del core dalla versione 5.6 di WordPress. Consentono ad app e integrazioni, come un'app mobile, uno strumento di reportistica o un servizio di automazione, di autenticarsi alla REST API. Il problema è che continuano a funzionare anche quando viene cambiata la password principale dell'utente. Se si reimposta la password di una ex agenzia ma si lascia la sua password per le applicazioni, l'agenzia ha ancora accesso.

Vanno controllate per ogni amministratore: aprire Utenti > Tutti gli utenti, modificare l'utente e scorrere fino a Password per le applicazioni. Con WP-CLI:

wp user application-password list jane.doe

L'elenco indica quando ogni password è stata creata e usata l'ultima volta. Va revocato tutto ciò che non è riconducibile a un'integrazione in uso:

wp user application-password delete jane.doe <uuid>

Ogni nuova password per le applicazioni dovrebbe prendere il nome dell'integrazione che la usa, ad esempio "Zapier – export ordini", così la revisione successiva sarà rapida. Se nessuno sul sito usa questa funzione, molti plugin di sicurezza e alcuni hosting permettono di disattivarla del tutto.

Account admin nascosti dopo un attacco: come individuarli

Chi riesce a entrare a volte crea un proprio amministratore e lo nasconde con codice che filtra la query degli utenti. L'account non compare allora sotto Utenti e può non comparire neppure in wp user list, perché WP-CLI carica gli stessi plugin. Una query diretta al database aggira quel codice:

wp db query "SELECT u.ID, u.user_login, u.user_email, u.user_registered FROM wp_users u JOIN wp_usermeta m ON m.user_id = u.ID WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%'"

Il prefisso wp_ è solo il valore predefinito. Eseguire prima wp db prefix e sostituire wp_ nei nomi di entrambe le tabelle e nella chiave meta. Se il prefisso è xy7_, la chiave è xy7_capabilities. Nel multisite ogni sito ha una propria chiave, ad esempio wp_2_capabilities.

Confrontare il risultato con il conteggio della dashboard. Poi cercare date user_registered recenti e domini email che non appartengono a nessuno con cui si collabora. Un amministratore nascosto o inspiegabile è il segno di una compromissione, non un'attività di pulizia. Non va semplicemente eliminato: seguire le indicazioni in segnali che un sito WordPress è stato hackerato.

La scansione degli indicatori di compromissione del plugin di secaudit.eu controlla la presenza di amministratori nascosti nell'ambito del suo audit.

Revisione trimestrale degli accessi come evidenza per NIS2 e GDPR

Una revisione richiede circa 15 minuti. Va eseguita ogni trimestre, e anche ogni volta che qualcuno lascia l'azienda o cambia un contratto con un'agenzia:

• Esportare l'elenco degli amministratori (e dei Super Admin nel multisite).
• Confermare persona e ruolo per ogni account. Declassare o rimuovere gli altri.
• Controllare i ruoli aggiunti dai plugin, come Shop manager.
• Elencare e ripulire le password per le applicazioni di ogni amministratore.
• Verificare che tutti gli amministratori usino l'autenticazione a due fattori.
• Verificare che l'editor di file della dashboard sia disattivato.
• Annotare data, revisore e modifiche effettuate.

Quest'ultima annotazione trasforma un'abitudine in evidenza documentale. L'art. 21, par. 2, lett. i) della direttiva NIS2 include tra le misure minime la sicurezza delle risorse umane, le politiche di controllo dell'accesso e la gestione dei beni (direttiva (UE) 2022/2555). Gli obblighi concreti derivano però dal recepimento nazionale, quindi occorre consultare la normativa NIS2 del proprio Paese. Ai sensi del GDPR, il controllo degli accessi rientra tra le "misure tecniche e organizzative adeguate" dell'art. 32, e l'art. 5, par. 2 impone di poterle dimostrare (regolamento (UE) 2016/679).

Un limite da tenere presente: il core di WordPress non registra quando un utente ha effettuato l'ultimo accesso. Per individuare gli account dormienti servono un plugin di registro delle attività o i log di accesso del server. In alternativa, resta il confronto diretto con le persone.

Il plugin Security Audit & Compliance di secaudit.eu aiuta nella parte ricorrente. Segnala admin nascosti, password deboli o predefinite e lacune di hardening come l'editor di file attivo, associa i risultati all'art. 32 del GDPR e all'art. 21 della NIS2 ed esporta un report da archiviare insieme alle note della revisione.

FAQ

Rinominare lo username "admin" basta a fermare gli attacchi?

No. Elimina un'ipotesi facile, ma gli username si possono spesso scoprire in altri modi. Password robuste e univoche e l'autenticazione a due fattori fanno molto di più.

Un'agenzia può condividere un solo accesso admin tra i suoi collaboratori?

No. Ogni persona deve avere un account nominativo, in modo da sapere chi ha fatto cosa e da poter revocare l'accesso a una persona senza toccare gli altri.

Che cosa succede agli ordini WooCommerce o agli articoli quando si elimina un utente?

Articoli e pagine vengono eliminati, a meno che non siano riassegnati. I plugin salvano i propri dati in modi diversi, quindi prima di eliminare account di clienti o di personale dello shop è opportuno consultare la documentazione del plugin. In caso di dubbio, declassare prima l'account.

Questo articolo è un'informazione di carattere generale e non costituisce consulenza legale.